測試知識70問（面試寶典）

1.問：你在測試中發現了一個 bug ，可是開發經理認爲這不是一個 bug ，你應該怎樣解決。

• 首先，將問題提交到缺陷管理庫裏面進行備案。
• 而後，要獲取判斷的依據和標準：
• 根據需求說明書、產品說明、設計文檔等，確認實際結果是否與計劃有不一致的地方，提供缺陷是否確認的直接依據；
• 若是沒有文檔依據，能夠根據相似軟件的通常特性來講明是否存在不一致的地方，來確認是不是缺陷；
• 根據用戶的通常使用習慣，來確認是不是缺陷；
• 與設計人員、開發人員和客戶表明等相關人員探討，確認是不是缺陷；
• 合理的論述，向測試經理說明本身的判斷的理由，注意客觀、嚴謹，不參雜我的情緒。
• 等待測試經理作出最終決定，若是仍然存在爭議，能夠經過公司政策所提供的渠道，向上級反映，並由上級作出決定。

2.問：給你一個網站，你如何測試？

1. 首先，查找需求說明、網站設計 m 等相關文檔，分析測試需求。
2. 制定測試計劃，肯定測試範圍和測試策略，通常包括如下幾個部分：
   功能性測試；界面測試；性能測試；數據庫測試；安全性測試；兼容性測試
3. 設計測試用例：
   功能性測試能夠包括，但不限於如下幾個方面：

• 連接測試。連接是否正確跳轉，是否存在空頁面和無效頁面，是否有不正確的出錯信息返回等。
• 提交功能的測試。
  多媒體元素是否能夠正確加載和顯示。
  多語言支持是否可以正確顯示選擇的語言等。
• 界面測試能夠包括但不限於一下幾個方面：
  頁面是否風格統一，美觀
  頁面佈局是否合理，重點內容和熱點內容是否突出
  控件是否正常使用
  對於必須但爲安裝的空間，是否提供自動下載並安裝的功能
  文字檢查
• 性能測試通常從如下兩個方面考慮：
  壓力測試；負載測試；強度測試
• 數據庫測試要具體決定是否須要開展。數據庫通常須要考慮連結性，對數據的存取操做，數據內容的驗證等方面。
• 安全性測試：
  1 基本的登陸功能的檢查
  2 是否存在溢出錯誤，致使系統崩潰或者權限泄露
  3 相關開發語言的常見安全性問題檢查，例如 SQL 注入等。
  4 若是須要高級的安全性測試，肯定得到專業安全公司的幫助，外包測試，或者獲取支持
• 兼容性測試，根據需求說明的內容，肯定支持的平臺組合：
  瀏覽器的兼容性；操做系統的兼容性；軟件平臺的兼容性；數據庫的兼容性

4. 開展測試，並記錄缺陷。合理的安排調整測試進度，提早獲取測試所需的資源，創建管理體系（例如，需求變動、風險、配置、測試文檔、缺陷報告、人力資源等內容）。
5. 按期評審，對測試進行評估和總結，調整測試的內容。

3.在搜索引擎中輸入漢字就能夠解析 到對應的域名，請問如何用 LoadRunner 進行測試。

• 創建測試計劃，肯定測試標準和測試範圍
• 設計典型場景的測試用例，覆蓋經常使用業務流程和不經常使用的業務流程等
• 根據測試用例，開發自動測試腳本和場景：
  錄製測試腳本
  新建一個腳本（Web/HTML 協議）
  點擊錄製按鈕，在彈出的對話框的 URL 中輸入」about:blank」。
  在打開的瀏覽器中進行正常操做流程後，結束錄製。
  調試腳本並保存。可能要注意到字符集的關聯。
• 設置測試場景
  針對性能設置測試場景，主要判斷在正常狀況下，系統的平均事務響應時間是否達標
  針對壓力負載設置測試場景，主要判斷在長時間處於滿負荷或者超出系統承載能力的條件下，系統是否會崩潰。
• 執行測試，獲取測試結果，分析測試結果

4.問：一臺客戶端有三百個客戶與三百個客戶端有三百個客戶對服務器施壓，有什麼區別? ?

300 個用戶在一個客戶端上，會佔用客戶機更多的資源，而影響測試的結果。
線程之間可能發生干擾，而產生一些異常。
300 個用戶在一個客戶端上，須要更大的帶寬。
IP 地址的問題，可能須要使用 IP Spoof 來繞過服務器對於單一 IP 地址最大鏈接數的限制。
全部用戶在一個客戶端上，沒必要考慮分佈式管理的問題；而用戶分佈在不一樣的客戶端上，須要考慮使用控制器來總體調配不一樣客戶機上的用戶。同時，還須要給予相應的權限配置和防火牆設置。

5.試述軟件的概念和特色？軟件複用的含義？構件包括哪些？

• 軟件是計算機系統中與硬件相互依存的另外一部分，它是包括程序、文檔的完整集合。
• 軟件複用(Software Reuse)是將已有軟件的各類有關知識用於創建新的軟件,以縮減軟件開發和維護的花費。軟件複用是提升軟件生產力和質量的一種重要技術。早期的軟件複用主要是代碼級複用，被複用的知識專指程序，後來擴大到包括領域知識、開發經驗、設計決定、體系結構、需求、設計、代碼和文檔等一切有關方面。
• 能夠被複用的軟件成分通常稱做可複用構件

6.軟件生存週期及其模型是什麼？

軟件生存週期是軟件開發所有過程、活動和任務的結構框架，是從可行性研究到需求分析、軟件設計、編碼、測試、軟件發佈維護的過程。
在經歷需求、分析、設計、實現、部署後，軟件將被使用並進入維護階段，直到最後因爲缺乏維護費用而逐漸消亡。這樣的一個過程，稱爲"生命週期模型"（Life Cycle Model）。

7.什麼是軟件測試？軟件測試的目的與原則

• 使用人工或自動手段，來運行或測試某個系統的過程。其目的在於檢驗它是否知足規定的需求或弄清預期結果與實際結果之間的差異。
• 軟件測試的目的：
  測試是程序的執行過程，目的在於發現錯誤
  確保產品知足用戶需求（功能，性能，兼容性等）
  確保產品是健壯的和適應用戶環境的
• 軟件測試的原則：
  教材的說法：
  軟件測試應儘早執行，並貫穿於整個軟件生命週期
  軟件測試應追溯需求
  測試應由第三方來構造
  窮舉測試是不可能的,要遵循 Good-enough 原則
  必須肯定預期輸出（或結果）
  必須完全檢查每一個測試結果
  關注缺陷的修復

8.軟件配置管理的做用？軟件配置包括什麼？

軟件配置管理做爲軟件開發過程的必要環節和軟件開發管理的基礎，貫穿整個軟件生命週期，同時對軟件開發過程的宏觀管理即項目管理也有重要的支持做用。一個軟件開發組織真正有效的實施軟件配置管理，將會使軟件開發過程有更好的可預測性，使系統具備可重複性，大大提升軟件組織的競爭力。
軟件配置包括以下內容：
配置項識別
工做空間管理
版本控制
變動控制
狀態報告
配置審計

9.什麼是軟件質量？

軟件質量：軟件產品的特性能夠知足用戶的功能、性能需求的能力。

10.目前主要的測試用例設計方法是什麼？

白盒測試：
邏輯覆蓋
循環覆蓋
基本路徑覆蓋
黑盒測試：
邊界值分析法
等價類劃分
錯誤猜想法
因果圖法
狀態圖法
隨機測試
場景法

11.軟件的安全性應從哪幾個方面 去測試？

軟件安全性測試包括程序、數據庫安全性測試。根據系統安全指標不一樣測試策略也不一樣。

• 用戶認證安全的測試要考慮問題：
  明確區分系統中不一樣用戶權限
  系統中會不會出現用戶衝突
  系統會不會因用戶的權限的改變形成混亂
• 用戶登錄密碼是不是可見、可複製
• 是否能夠經過絕對途徑登錄系統（拷貝用戶登錄後的連接直接進入系統）
• 用戶退出系統後是否刪除了全部鑑權標記，是否能夠使用後退鍵而不經過輸入口令進入系統
• 系統網絡安全的測試要考慮問題
  測試採起的防禦措施是否正確裝配好，有關係統的補丁是否打上
  模擬非受權攻擊，看防禦系統是否堅固
  採用成熟的網絡漏洞檢查工具檢查系統相關漏洞（即用最專業的黑客攻擊工具攻擊試一下，如今最經常使用的是 NBSI 系列和 IPhacker IP ）
  採用各類木馬檢查工具檢查系統木馬狀況
  採用各類防外掛工具檢查系統各組程序的外掛漏洞
• 數據庫安全考慮問題：
  系統數據是否機密（好比對銀行系統，這一點就特別重要，通常的網站就沒有過高要求）
  系統數據的完整性
  系統數據可管理性
  系統數據的獨立性
  系統數據可備份和恢復能力（數據備份是否完整，能否恢復，恢復是否能夠完整）

12.什麼是測試用例 什麼是測試腳本 二者的關係是什麼？

爲實施測試而向被測試系統提供的輸入數據、操做或各類環境設置以及指望結果的一個特定的集合。
測試腳本是爲了進行自動化測試而編寫的腳本。
測試腳本的編寫必須對應相應的測試用例，

13.簡述什麼是靜態測試、動態測試、黑盒測試、白盒測試、α測試 β測試

• 靜態測試是不運行程序自己而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。
• 動態測試是實際運行被測程序，輸入相應的測試實例，檢查運行結果與預期結果的差別，斷定執行結果是否符合要求，從而檢驗程序的正確性、可靠性和有效性，並分析系統運行效率和健壯性等性能。
• 黑盒測試通常用來確認軟件功能的正確性和可操做性,目的是檢測軟件的各個功能是否能得以實現,把被測試的程序看成一個黑盒,不考慮其內部結構,在知道該程序的輸入和輸出之間的關係或程序功能的狀況下,依靠軟件規格說明書來肯定測試用例和推斷測試結果的正確性。
• 白盒測試根據軟件內部的邏輯結構分析來進行測試,是基於代碼的測試，測試人員經過閱讀程序代碼或者經過使用開發工具中的單步調試來判斷軟件的質量，通常黑盒測試由項目經理在程序員開發中來實現。
• α測試是由一個用戶在開發環境下進行的測試，也能夠是公司內部的用戶在模擬實際操做環境下進行的受控測試，Alpha 測試不能由程序員或測試員完成。
• β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者一般不在測試現場，Beta 測試不能由程序員或測試員完成。

14.軟件質量保證體系是什麼 國家標準中與質量保證管理相關的幾個標準是什麼? ? 他們的編號和全稱是什麼? ?

SQA 由一套軟件工程過程和方法組成，以保證（軟件的）質量。SQA 貫穿整個軟件開發過程，(它)應包括需求文檔評審、代碼控制、代碼評審、變動管理、配置管理、版本管理和軟件測試。

15.軟件產品質量特性是什麼? ?

功能性：適應性、準確性、互操做性、依從性、安全性。
可靠性：成熟性、容錯性、以恢復性。
可以使用性：易理解性、易學習性、易操做性。
效率：時間特性、資源特性。
可維護性：易分析性、易變動性、穩定性、易測試性。
可移植性： 適應性、易安裝性、遵循性、易替換性。

16.軟件測試的策略是什麼? ?

軟件測試策略：在必定的軟件測試標準、測試規範的指導下，依據測試項目的特定環境約束而規定的軟件測試的原則、方式、方法的集合。

17.軟件測試分爲幾個 階段 各階段的測試策略和要求是什麼? ?

軟件測試按階段劃分能夠分爲單元測試、集成測試、系統測試和<驗收測試>（不必定有）幾個階段

• 單元測試測試策略：
  自頂向下的單元測試策略
  總結：比孤立單元測試的成本高不少，不是單元測試的一個好的選擇。
  自底向上的單元測試策略
  總結：比較合理的單元測試策略，但測試周期較長。
  孤立單元測試策略
  總結：最好的單元測試策略。
• 集成測試的測試策略：
  大爆炸集成
  適應於一個維護型項目或被測試系統較小
  自頂向下集成
  適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或常常可能被修改；產口控制組件具備較大的技術風險，須要儘早被驗證；但願儘早能看到產品的系統功能行爲。
  自底向上集成
  適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。
  基於進度的集成
  優勢：具備較高的並行度；可以有效縮短項目的開發進度。
  缺點：樁和驅動工做量較大；有些接口測試不充分；有些測試重複和浪費。
• 系統測試的測試策略
  數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試

18.在軟件測試各個階段一般完成什麼工做？各個階段的結果文件是什麼？包括什麼內容？

• 單元測試階段。各獨立單元模塊在與系統地其餘部分相隔離的狀況下進行測試，單元測試針對每個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現了規定的功能。
  生成單元測試報告，提交缺陷報告。
• 集成測試階段。集成測試是在單元測試的基礎上，測試在將全部的軟件單元按照概要設計規格說明的要求組裝成模塊、子系統或系統的過程當中各部分工做是否達到或實現相應技術指標及要求的活動。
  該階段生成集成測試報告，提交缺陷報告。
• 系統測試階段。將經過確認測試的軟件，做爲整個給予計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其餘系統元素結合在一塊兒，在實際運行環境下，對計算機系統進行全面的功能覆蓋。該階段須要提交測試總結和缺陷報告。

19.測試人員在軟件開發過程當中的任務是什麼？

一、尋找 Bug；
二、避免軟件開發過程當中的缺陷；
三、衡量軟件的品質；
四、關注用戶的需求。
總的目標是：確保軟件的質量。

20.在您以往的工做中，一條軟件缺陷（或者叫 Bug）記錄都包含了哪些內容？如何提交高質量的軟件缺陷（Bug）記錄？

• 一條 Bug 記錄最基本應包含：編號、Bug 所屬模塊、Bug 描述、Bug 級別、發現日期、發現人、修改日期、修改人、修改方法、迴歸結果等等；
• 要有效的發現 Bug 需參考需求以及詳細設計等前期文檔設計出高效的測試用例，而後嚴格執行測試用例，對發現的問題要充分確認確定，而後再向外發布如此才能提升提交 Bug 的質量。

21.黑盒測試和白盒測試是軟件測試的兩種基本方法，請分別說明各自的優勢和缺點！

• 黑盒測試的優勢有：
  比較簡單，不須要了解程序內部的代碼及實現；
  與軟件的內部實現無關；
  從用戶角度出發，能很容易的知道用戶會用到哪些功能，會遇到哪些問題；
  基於軟件開發文檔，因此也能知道軟件實現了文檔中的哪些功能；
  在作軟件自動化測試時較爲方便。
  黑盒測試的缺點有：
  不可能覆蓋全部的代碼，覆蓋率較低，大概只能達到總代碼量的 30%；
  自動化測試的複用性較低。
• 白盒測試的優勢有：
  幫助軟件測試人員增大代碼的覆蓋率，提升代碼的質量，發現代碼中隱藏的問題。
  白盒測試的缺點有：
  程序運行會有不少不一樣的路徑，不可能測試全部的運行路徑；
  測試基於代碼，只能知道測試開發人員作的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；
  系統龐大時，測試開銷會很是大。

21.測試計劃工做的目的是什麼？測試計劃文檔的內容應該包括什麼？其中哪些是最重要的？

答案：軟件測試計劃是指導測試過程的綱領性文件。
包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟件測試計劃，參與測試的項目成員，尤爲是測試管理人員，能夠明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程當中的各類變動。
測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從宏觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。
因此其中最重要的是測試測試策略和測試方法（最好是能先評審）。

22.黑盒測試的測試用例常見設計方法都有哪些？請分別以具體的例子來講明這些方法在測試用例設計工做中的應用。

• 等價類劃分
  劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.併合理地假定:測試某等價類的表明值就等於對這一類其它值的測試.
  所以,能夠把所有輸入數據合理劃分爲若干等價類,在每個等價類中取一個數據做爲測試的輸入條件,就能夠用少許表明性的測試數據.取得較好的測試結果.等價類劃分可有兩種不一樣的狀況:有效等價類和無效等價類.
• 邊界值分析法
  邊界值分析方法是對等價類劃分方法的補充。測試工做經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.所以針對各類邊界狀況設計測試用例,能夠查出更多的錯誤.
  使用邊界值分析方法設計測試用例,首先應肯定邊界狀況.一般輸入和輸出等價類的邊界,就是應着重測試的邊界狀況.應當選取正好等於,剛剛大於或剛剛小於邊界的值做爲測試數據,而不是選取等價類中的典型值或任意值做爲測試數據.
• 錯誤猜想法
  基於經驗和直覺推測程序中全部可能存在的各類錯誤, 從而有針對性的設計測試用例的方法.
  錯誤推測方法的基本思想: 列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 之前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據爲 0 的狀況.輸入表格爲空格或輸入表格只有一行. 這些都是容易發生錯誤的狀況. 可選擇這些狀況下的例子做爲測試用例.
• 因果圖方法
  前面介紹的等價類劃分方法和邊界值分析方法,都是着重考慮輸入條件,但未考慮輸入條件之間的聯繫, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的狀況. 但要檢查輸入條件的組合不是一件容易的事情, 即便把全部輸入條件劃分紅等價類,他們之間的組合狀況也至關多. 所以必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動做的形式來考慮設計測試用例. 這就須要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是斷定表. 它適合於檢查程序輸入條件的各類組合狀況.
• 正交表分析法
  有時候，可能由於大量的參數的組合而引發測試用例數量上的激增，同時，這些測試用例並無明顯的優先級上的差距，而測試人員又沒法完成這麼多數量的測試，就能夠經過正交表來進行縮減一些用例，從而達到儘可能少的用例覆蓋儘可能大的範圍的可能性。
• 場景分析方法
  指根據用戶場景來模擬用戶的操做步驟，這個比較相似因果圖，可是可能執行的深度和可行性更好。
• 狀態圖法
  經過輸入條件和系統需求說明獲得被測系統的全部狀態，經過輸入條件和狀態得出輸出條件；經過輸入條件、輸出條件和狀態得出被測系統的測試用例。

23.詳細的描述一個測試活動完整的過程。

答案：（供參考，本答案主要是瀑布模型的作法）

• 項目經理經過和客戶的交流，完成需求文檔
• 由開發人員和測試人員共同完成需求文檔的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯衝突或者沒法實現的功能的地方。
• 項目經理經過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。而後 SQA 進入項目，開始進行統計和跟蹤
• 開發人員根據需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內容包括是否有遺漏或者雙方理解不一樣的地方。
• 測試人員完成測試計劃文檔，測試計劃包括的內容上面有描述。
• 測試人員根據修改好的需求分析文檔開始寫測試用例，同時開發人員完成概要設計文檔，詳細設計文檔。此兩份文檔成爲測試人員撰寫測試用例的補充材料。
• 測試用例完成後，測試和開發須要進行評審。
• 測試人員搭建環境
• 開發人員提交第一個版本，可能存在未完成功能，須要說明。測試人員進行測試，發現 BUG後提交給 BugZilla。
• 開發提交第二個版本，包括 Bug Fix 以及增長了部分功能，測試人員進行測試。
  重複上面的工做，通常是 3-4 個版本後 BUG 數量減小，達到出貨的要求。
• 若是有客戶反饋的問題，須要測試人員協助重現並從新測試。

24.BUG 管理工具的跟蹤過程

用 BugZilla 爲例子
測試人員發現了 BUG，提交到 Bugzilla 中，狀態爲 new，BUG 的接受者爲開發接口人員
開發接口將 BUG 分配給相關的模塊的開發人員，狀態修改成已分配，開發人員和測試確認BUG，若是是本人的 BUG，則設置爲接收；若是是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行爲；若是認爲不是問題，則須要你們討論並確認後，拒絕這個 BUG，
而後測試人員關閉此問題。
若是開發人員接受了 BUG，並修改好之後，將 BUG 狀態修改成已修復，並告知測試在哪一個版本中能夠測試。
測試人員在新版本中測試，若是發現問題依然存在，則拒絕驗證；若是已經修復，則關閉BUG。

25.您認爲在測試人員同開發人員的溝經過程中，如何提升溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其餘成員 良好的人際關係的關鍵是什麼？

• 儘可能面對面的溝通，其次是能直接經過電話溝通，若是隻能經過 Email 等非及時溝通工具的話，強調必須對特性的理解深入以及能表達清楚。
  運用一些測試管理工具如 TestDirector 進行管理也是較有效的方法，同時要注意在TestDirector 中對 BUG 有準確的描述。
• 在團隊中創建測試人員與開發人員良好溝通中注意如下幾點：
  一真誠
  二是團隊精神
  三是在專業上有共同語言
  四是要對事不對人，工做至上
  固然也能夠經過直接指出一些小問題，而不是進入 BUG Tracking System 來增長對方的好感。

26.你對測試最大的興趣在哪裏？爲何？

回答這個面試題，沒有固定統一的答案，但多是許多企業都會問到的。提供如下答案供考：
最大的興趣，感受這是一個有挑戰性的工做；
測試是一個經驗行業，工做越久越能感受到作好測試的難度和樂趣
經過本身的工做，能使軟件產品愈來愈完善，從中體會到樂趣
回答此類問題注意如下幾個方面：
儘量的切合招聘企業的技術路線來表達你的興趣，例如該企業是數據庫應用的企業，那麼表示你的興趣在數據庫的測試，而且但願經過測試提高本身的數據庫掌握能力。
代表你作測試的目的是爲了提高能力，也是爲了更好的作好測試；提高能力不是爲了之後轉開發或其餘的，除非用人企業有這樣的安排。
不要過多的表達你的興趣在招聘企業的範疇這外。

27.你自認爲測試的優點在哪裏？

該面試也沒有固定不變的答案，但可參考如下幾點，並結合自身特色：
有韌性
有耐心
作事有條理性
喜歡面對挑戰
有信心作好每一件事情
較強的溝通能力
從之前的經理處都獲得了很好的評價代表我作的很好

28.集成測試一般都有那些策略？

一、大爆炸集成
二、自頂向下集成
三、自底向上集成
四、三明治集成適應於大部分軟件開發項目
五、基幹集成
六、分層集成
七、基於功能的集成
八、基於消息的集成
九、基於風險的集成
十、基於進度的集成

29.請你分別畫出 I OSI 的七層網絡結構圖和 P TCP/IP 的四層結構圖。

答：OSI 七層網絡結構圖，由上至下：
應用層 ；表示層 ;會話層 ;傳輸層 ;網絡層 ;數據鏈路層;物理層
TCP/IP 的四層結構圖
應用層;傳輸層;互聯層;鏈路層

30.一個 e byte 幾個單位。( ( 計算機基礎) )

答：8bit。

31.經常使用 X UNIX 命令x (Linux 的經常使用命令) ) （至少 0 10 個）； (Unix)

答：ls pwd mkdir rmdir rm cp mv cd ps ping tail more echo adduser passwd logout exit，

32.簡述你在之前的工做中作過哪些事情，比較熟悉什麼。

此問題每一個人都不同。參考答案以下。
我過去的主要工做是系統測試和自動化測試。在系統測試中，主要是對 BOSS 系統的業務邏輯功能，以及軟交換系統的 Class 5 特性進行測試。性能測試中，主要是進行的壓力測試，在各個不一樣數量請求的狀況下，獲取系統響應時間以及系統資源消耗狀況。
自動化測試主要是經過本身寫腳本以及一些第三方工具的結合來測試軟交換的特性測試。
在測試中，我感受對用戶需求的徹底準確的理解很是重要。另外，就是對 BUG 的管理，要以需求爲依據，並非全部 BUG 均須要修改。
測試工做須要耐心和細緻，由於在新版本中，雖然多數原來發現的 BUG 獲得了修復，但原來正確的功能也可能變得不正確。所以要注重迭代測試和迴歸測試。

33.在 C/C++中 中 c static 有什麼用途？（請至少說明兩種）

1)在函數體，一個被聲明爲靜態的變量在這一函數被調用過程當中維持其值不變。

2. 在模塊內（但在函數體外），一個被聲明爲靜態的變量能夠被模塊內所用函數訪問，但不能被模塊外其它函數訪問。它是一個本地的全局變量。
3. 在模塊內，一個被聲明爲靜態的函數只可被這一模塊內的其它函數調用。那就是，這個函數被限制在聲明它的模塊的本地範圍內使用

34.引用與指針有什麼區別？

1. 引用必須被初始化，指針沒必要。
2. 引用初始化之後不能被改變，指針能夠改變所指的對象。
3. 不存在指向空值的引用，可是存在指向空值的指針。

35.Internet 採用哪一種網絡協議？該協議的主要層次結構？t Internet 物理地址和 P IP 地址轉換採用什麼協議？

TCP/IP 協議
主要層次結構爲： 應用層/傳輸層/網絡層/數鏈路層。
ARP (Address Resolution Protocol)（地址解析協議）

36.說說你對集成測試中自頂向下集成和自底向上集成兩個策略的理解，要談出它們各自的優缺點和主要適應於哪一種類型測試；

• 自頂向下集成
  優勢：較早地驗證了主要控制和判斷點；按深度優先能夠首先實現和驗證一個完整的軟件功能；功能較早證明，帶來信心；只需一個驅動，減小驅動器開發的費用；支持故障隔離。
  缺點：柱的開發量大；底層驗證被推遲；底層組件測試不充分。
  適應於產品控制結構比較清晰和穩定；高層接口變化較小；底層接口未定義或常常可能被修改；產口控制組件具備較大的技術風險，須要儘早被驗證；但願儘早能看到產品的系統功能行爲。
• 自底向上集成
  優勢：對底層組件行爲較早驗證；工做最初能夠並行集成，比自頂向下效率高；減小了樁的工做量；支持故障隔離。
  缺點：驅動的開發工做量大；對高層的驗證被推遲，設計上的錯誤不能被及時發現。
  適應於底層接口比較穩定；高層接口變化比較頻繁；底層組件較早被完成。

37.軟件驗收測試包括正式驗收測試、alpha 測試、beta 測試三種測試。

38.系統測試的策略有不少種的，有性能測試、負載測試、強度測試、易用性測試、安全測試、配置測試、安裝測試、文檔測試、故障恢復測試、用戶界面測試、恢復測試、分佈測試、可用性測試。

39.設計系統測試計劃須要參考的項目文檔有軟件測試計劃、軟件需求工件、和迭代計劃。

40.利用因果圖生成測試用例的基本步驟是：

§ 分析軟件規格說明描述中，哪些是緣由（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），並給每一個緣由和結果賦予一個標識符。
§ 分析軟件規格說明描述中的語義，找出緣由與結果之間，緣由與緣由之間對應的是什麼關係? 根據這些關係，畫出因果圖。
§ 因爲語法或環境限制，有些緣由與緣由之間，緣由與結果之間的組合狀況不可能出現。爲代表這些特殊狀況，在因果圖上用一些記號標明約束或限制條件。
§ 把因果圖轉換成斷定表。
§ 把斷定表的每一列拿出來做爲依據，設計測試用例。
1、 測試的種類不少，好比：
代碼、函數級測試
模塊、組件級測試
系統測試
請說出這些測試最好由那些人員完成，測試的是什麼？
代碼、函數級測試通常由白盒測試人員完成，他們針對每段代碼或函數進行正確性檢驗，檢查其是否正確的實現了規定的功能。
模塊、組件級測試主要依據是程序結構設計測試模塊間的集成和調用關係，通常由測試人員完成。
系統測試在於模塊測試與單元測試的基礎上進行測試。瞭解系統功能與性能，根據測試用例進行全面的測試。

41設計測試用例時應該考慮哪些方面，即不一樣的測試用例針對那些方面進行測試？

設計測試用例時須要注意的是，除了對總體流程及功能注意外，還要注意強度測試、性能測試、壓力測試、邊界值測試、穩定性測試、安全性測試等多方面。（測試用例須要考慮的四個基本要素是輸入、輸出、操做和測試環境；另外，測試用例須要考慮的是測試類型（功能、性能、安全„„），這部分能夠參照 TP 作答。此外，還須要考慮用例的重要性和優先級）

42.在 windows 下保存一個文本文件時會彈出保存對話框，若是爲文件名創建測試用例，等價類應該怎樣劃分？

單字節，如 A；
雙字節， AA、我我；
特殊字符 /‘。‘；、=-等；
保留字，如 com；
文件格式爲 8.3 格式的；
文件名格式爲非 8.3 格式的；
/,,*等九個特殊字符。

43.假設有一個文本框要求輸入 0 10 個字符的郵政編碼，對於該文本框應該怎 樣劃分等價類？

特殊字符，如 10 個*或￥；
英文字母，如 ABCDefghik；
小於十個字符，如 123；
大於十個字符，如 11111111111；
數字和其餘混合，如 123AAAAAAA；
空字符；
保留字符

44.軟件測試項目從何時開始，？爲何？

軟件測試應該在需求分析階段就介入,由於測試的對象不只僅是程序編碼,應該對軟件開發過程當中產生的全部產品都測試,而且軟件缺陷存在放大趨勢.缺陷發現的越晚,修復它所花費的成本就越大.

45.什麼是白盒測試？什麼是黑盒測試? ? 什麼是迴歸測試? ?

• 白盒測試是測試人員要了解程序結構和處理過程,按照程序內部邏輯測試程序,檢查程序中的每條通路是否按照預約要求正確工做.它主要的針對被測程序的源代碼,測試者能夠徹底不考慮程序的功能.
  白盒測試流程:詳細設計-->源程序-->分析程序內部邏輯結構-->流程圖-->制定測試用例-->被測程序-->執行路徑-->覆蓋狀況分析 .
• 黑盒測試:（Black-box Testing，又稱爲功能測試或數據驅動測試）是把測試對象看做一個黑盒子。利用黑盒測試法進行動態測試時，須要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。
• 迴歸測試: (regression testing): 迴歸測試有兩類：用例迴歸和錯誤迴歸；用例迴歸是過一段時間之後再回頭對之前使用過的用例在從新進行測試，看看會從新發現問題。
  錯誤迴歸，就是在新版本中，對之前版本中出現並修復的缺陷進行再次驗證，並以缺陷爲核心，對相關修改的部分進行測試的方法。

46.單元測試、集成測試、系統測試的側重點是什麼？

• 單元測試針對的是軟件設計的最小單元--程序模塊（面向過程當中是函數、過程；面向對象中是類。）,進行正確性檢驗的測試工做,在於發現每一個程序模塊內部可能存在的差錯.通常有兩個步驟:人工靜態檢查\動態執行跟蹤
• 集成測試針對的是經過了單元測試的各個模塊所集成起來的組件進行檢驗,其主要內容是各個單元模塊之間的接口,以及各個模塊集成後所實現的功能.
• 系統測試針對的是集成好的軟件系統，做爲整個計算機系統的一個元素,與計算機硬件\外設\某些支持軟件\數據和人員等其餘系統元素結合在一塊兒,要在實際的運行環境中,對計算機系統進行一系列的集成測試和確認測試.

47. 一個測試工程師應具有那些素質？

一、責任心
二、溝通能力
三、團隊合做精神
四、耐心、細心、信心
五、時時保持懷疑態度，而且有缺陷預防的意識
六、具有必定的編程經驗

48.你所瞭解的的軟件測試類型都有哪些，簡單介紹一下。

• 按測試 策略分類：
  一、靜態與動態測試
  二、黑盒與白盒測試
  三、手工和自動測試
  四、冒煙測試
  五、迴歸測試；
• 按測試階段分類：單元測試、集成測試、系統測試；
• 其餘常見測試方法：一、功能測試 二、性能測試 三、壓力測試 四、負載測試 五、易用性測試 六、安裝測試 七、界面測試 八、配置測試 九、文檔測試 十、兼容性測試 十一、安全性測試 十二、恢復測試

49.你認爲作好測試計劃工做的關鍵是什麼？

明確測試的目標，加強測試計劃的實用性
採用評審和更新機制，保證測試計劃知足實際需求
分別建立測試計劃與測試詳細規格、測試用例

50.您認爲作好測試用例設計工做的關鍵是什麼？

白盒測試用例設計的關鍵是以較少的用例覆蓋儘量多的內部程序邏輯結果
黑盒法用例設計的關鍵一樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能作到徹底測試，以最少的用例在合理的時間內發現最多的問題

51.您認爲性能測試工做的目的是什麼？作好性能測試工做的關鍵是什麼？

• 性能測試的目的主要是發如今併發多用戶和大數據量操做時是否會出現與需求有差別的地方。
• 性能測試工做的關鍵是作好系統分析和功能分析，肯定系統瓶頸所在

52.在您以往的測試工做中，最讓您感到不滿意或者不堪回首的事情是什麼？您是如何來對待這些事情的？

53.你的測試職業發展目標是什麼？

測試經驗越多，測試能力越高。因此個人職業發展是須要時間累積的，一步步向着高級測試工程師奔去。並且我也有初步的職業規劃，前 3 年累積測試經驗，不斷的更新本身改正本身，作好測試任務。

54.你對咱們公司瞭解有多少？

建議從招聘廣告上多瞭解信息，同時到應聘公司的網站上去儘量多的瞭解這個公司的狀況，以便回答好這類問題。

55.測試結束的標準是什麼？

從微觀上來講，在測試計劃中定義，好比系統在必定性能下平穩運行 72 小時，目前 BugTracking System 中，本版本中沒有通常嚴重的 BUG，普通 BUG 的數量在 3 如下，BUG 修復率 90%以上等等參數，而後由開發經理，測試經理，項目經理共同簽字認同版本 Release。
若是說宏觀的，則是當這個軟件完全的消失之後，測試就結束了。

56. 軟件測試分爲黑盒和白盒，分別適合什麼狀況？ ？

軟件測試方法通常分爲兩種：白盒測試與黑盒測試。

• 白盒測試又稱爲結構測試、邏輯驅動測試或基於程序自己的測試，它着重於程序的內部結構及算法，一般不關心功能與性能指標；
• 黑盒測試又被稱爲功能測試、數據驅動測試或基於規格說明的測試，它其實是站在最終用戶的立場，檢驗輸入輸出信息及系統性能指標是否符合規格說明書中有關功能需求及性能需求的規定。

57.一套完整的測試應該由哪些階段組成？

可行性分析、需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試、驗收測試

58測試用例一般包括那些內容？

不一樣結構的用例包括的不同。
（版本、編號、項目、設計人員、設計日期、輸入、預期輸出„„）
軟件測試用例的基本要素包括測試用例編號、測試標題、重要級別、測試輸入、操做步驟、預期結果。

• 用例編號： 測試用例的編號有必定的規則，好比系統測試用例的編號這樣定義規則：PROJECT1-ST-001 ，命名規則是項目名稱＋測試階段類型（系統測試階段）＋編號。定義測試用例編號，便於查找測試用例，便於測試用例的跟蹤。
• 測試標題： 對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。好比 「 測試用戶登陸時輸入錯誤密碼時，軟件的響應狀況 」 。
• 重要級別： 定義測試用例的優先級別，能夠籠統的分爲 「 高 」 和 「 低 」 兩個級別。
  通常來講，若是軟件需求的優先級爲 「 高 」 ，那麼針對該需求的測試用例優先級也爲「 高 」 ；反之亦然，通常而言，是 5 級劃分。
• 測試輸入： 提供測試執行中的各類輸入條件。根據需求中的輸入條件，肯定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，若是軟件需求中沒有很好的定義需求的輸入，那麼測試用例設計中會遇到很大的障礙。
• 操做步驟： 提供測試執行過程的步驟。對於複雜的測試用例，測試用例的輸入須要分爲幾個步驟完成，這部份內容在操做步驟中詳細列出。
• 預期結果： 提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。若是在
  實際測試過程當中，獲得的實際測試結果與預期結果不符，那麼測試不經過；反之則測試經過。

59.您是否瞭解以往所工做的企業的軟件開發過程？若是瞭解，請試述一個完整的開發過程須要完成哪些工做？分別由哪些不一樣的角色來完成這些工做？您在以往的測試工做中都曾經具體從事過哪些工做？其中最擅長哪部分工做？

開發過程---需求調研（需求人員）、需求分析（需求人員）、概要設計（設計人員）、詳細設計(設計人員)、編碼（開發人員）
測試過程---需求評審、系統測試設計、概要設計評審、集成測試設計、詳細設計評審、單元測試設計、測試執行
測試工做的整個過程都作過，擅長作測試設計
過程決定質量，軟件的過程改進正是爲了提升軟件的質量，將過往的種種經驗和教訓積累起來。

60.在您所經歷的測試活動中，參與人員有哪些？您所擔任的角色是什麼？

有項目管理員、開發管理員、系統分析員、設計員、開發員、質量管理員、測試管理員、測試設計員、測試員
擔任過測試管理員、測試設計員、測試員

61.測試用例設計的原則是什麼？目前主要的測試用例設計方法有哪些？

• 表明性：可以表明並覆蓋各類合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數據、操做和環境設置等.
• 可斷定性：即測試執行結果的正確性是可斷定的，每個測試用例都應有相應的指望結果.
• 可再現性：即對一樣的測試用例，系統的執行結果應當是相同的。
• 方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法

61.LoadRunner 分爲哪三個模塊？請簡述各模塊的主要功能。

Virtual User Generator：用於錄製腳步
Mercury LoadRunner Controller：用於建立、運行和監控場景
Mercury LoadRunner Analysis：用於分析測試結果

62.你對測試最大的興趣在哪裏？爲何？

最大的興趣就是測試有難度，有挑戰性！作測試越久越能感受到作好測試有多難。曾經在無憂測試網上看到一篇文章，是關於如何作好一名測試工程師。一共羅列了 11，12 點，有部分是和人的性格有關，有部分須要後天的努力。但除了性格有關的 1，2 點我沒有把握，其餘點我都頗有信心作好它。剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是衝着作測試須要不少技能才能作的好，雖然入門容易，但作好很難，比開發更難，雖然當時我很想作開發（學校專業課我基本上不缺席，由於我喜歡個人專業），但看到測試比開發更難更有
挑戰性，想作好測試的意志就更堅決了。
我以爲作測試整個過程當中有 2 點讓我以爲頗有難度（對我來講，有難度的東西我就很是感興趣），第一是測試用例的設計，由於測試的精華就在測試用例的設計上了，要在版本出來以前，把用例寫好，用什麼測試方法寫？（也就是測試計劃或測試策略），若是你剛測試一個新任務時，你得花必定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那麼簡單了，這須要你自覺的學習能力，好比說網站吧，最基本的技術知識你要知道網站內部是怎麼運做的的，後臺是怎麼響應用戶請求的？測試環境如何搭建？這些都須要最先的學好。至少在開始測試以前能作好基本的準備，可能會遇到什麼難題？需求細節是否是沒有肯定好？這些問題都能在設計用例的時候發現。
第二是發現 BUG 的時候了，這應該是測試人員最基本的任務了，通常按測試用例開始測試就能發現大部分的 bug，還有一部分 bug 須要測試的過程當中更瞭解所測版本的狀況得到更多信息，補充測試用例，測試出 bug。還有如何發現 bug？這就須要在測試用例有效的狀況下，經過細心和耐心去發現 bug 了，每一個用例都有可能發現 bug，每一個地方都有可能出錯，因此測試過程當中思惟要清晰（測試過程數據流及結果都得看仔細了，bug 都在裏面發現的）。如何描述 bug 也頗有講究，bug 在什麼狀況下會產生，若是條件變化一點點，就不會有這個 bug，以哪些最少的操做步驟就能重現這個bug，這個bug產生的規律是什麼？若是你夠厲害的話，能夠幫開發人員初步定位問題。

63.當開發人員說不是 G BUG 時，你如何應付？

開發人員說不是 bug，有 2 種狀況，

• 一是需求沒有肯定，因此我能夠這麼作，這個時候能夠找來產品經理進行確認，需不須要改動，3 方商量肯定好後再看要不要改。
• 二是這種狀況不可能發生，因此不須要修改，這個時候，我能夠先儘量的說出是 BUG 的依據是什麼？
  若是被用戶發現或出了問題，會有什麼不良結果？程序員可能會給你不少理由，你能夠對他的解釋進行反駁。若是仍是不行，那我能夠給這個問題提出來,跟開發經理和測試經理進行確認,若是要修改就改,若是不要修改就不改。其實有些真的不是 bug，我也只是建議的方式寫進 TD 中，若是開發人員不修改也沒有大問題。若是肯定是 bug 的話，必定要堅持本身的
  立場，讓問題獲得最後的確認。

64.爲何要在一個團隊中開展軟件測試工做？

由於沒有通過測試的軟件很難在發佈以前知道該軟件的質量，就比如 ISO 質量認證同樣，測試一樣也須要質量的保證，這個時候就須要在團隊中開展軟件測試的工做。在測試的過程發現軟件中存在的問題，及時讓開發人員得知並修改問題，在即將發佈時，從測試報告中得出軟件的質量狀況。#####65.若是有機會轉成開發人員，你會去作開發工做嗎？
若是公司確實須要我能夠從事開發，但我仍是喜歡作測試，我認爲我更適合作測試。

66.軟件測試分哪些階段？各階段的含義？

分爲單元測試、集成測試、確認測試、系統測試、驗收測試。單元測試是最小單位的測試，測試獨立模塊；
集成測試主要測試模塊之間的接口是否正常，
確認測試相似於冒煙測試一般在大規模系統測試以前驗證版本主要功能是否實現，版本的穩定性是否能夠進入系統測試，
系統測試是全面測試驗證系統是否知足用戶需求包括功能、性能、兼容性等等。
驗收測試是用戶參與的測試。

67.一份測試計劃應該包括哪些內容？

背景、項目簡介、目的、測試範圍、測試策略、人員分工、資源要求、進度計劃、參考文檔、經常使用術語、提交文檔、風險分析。

68.什麼是兼容性測試？請舉例說明如何利用兼容性測試列表進行測試。

主要驗證軟件產品在不一樣版本之間的兼容性。包括向下兼容和交錯兼容，向下兼容是測試軟件新版本保留它早期版本功能的狀況，
交錯兼容是驗證共同存在的兩個相關但不相同的產品之間的兼容性。

69.對某軟件進行測試，發如今 8 WIN98 上運行得很慢，怎麼判別是該軟件存在問題仍是其軟硬件運行環境存在問題？

看軟件的運行環境要求。若是符合要求則是程序存在問題，若不符合要求則是硬件系統存在問題

70.需求測試的注意事項有哪些？

是否使用了公司的模板 文檔內容是否符合規範 全部的需求是分級是否清析適當？ 全部的需求是否具備一致性 需求是否可行（即，該需求組合有解決方案） 需求能否用己知的約束來實現 需求是否足夠（即，能夠把它送到一個規範的開發組織，並有一個生產出所須要產品的合理的可能性） 全部的其它需求是交叉引用是否正確 用戶描述是否清楚 是否用客戶的語言來描述需求 每一個需求描述是否清楚沒有岐義，能夠移交給一個獨立的組去實現時也能理解 是否全部的需求都是可驗證的 是否每條需求都具備獨立性，即便發生了變化也不會影響其它需求 性能指標是否明確 非功能性需求是否獲得充分表現 是否完整列出適用的標準或協議 標準和協議之間是否存在衝突