天天大廠我也遭不住啊！來！66道樸實的Python軟體測驗筆試面試題（含答案）拿走！

（以下內容是本人在準備面試時從相關網站整理出來的軟體測驗匯總，實際面試做題時果然有很多熟悉的題目，貼在這里供日后自己回顧和大家參考）

1、什么是軟體測驗？

從廣義上說，軟體測驗是軟體生命周期中的所有檢查、評審和確認作業，包括在分析、設計階段，以及完成開發后確認階段的各類檔案、代碼的審查和確認，
從狹義上說，是識別軟體缺陷的程序，即實際結果與預期結果不一致，

2、軟體測驗的目標？

最終目標是確保軟體功能符合用戶需求，在產品發布或交付前盡可能多的發現并改正缺陷，

3、軟體測驗的原則？

1.Good-enough原則，一種權衡投入/產出比的原則，

2.保證測驗的覆寫度，但窮舉測驗是不可能的，

3.所有測驗都應追溯到用戶需求，

4.越早測驗越好，測驗程序與開發程序應是相互結合的，

5.測驗的規模由小到大，從單元測驗到系統測驗，

6.為了盡可能的發現錯誤，應由獨立的第三方進行測驗，

7.不能為了便于測驗擅自修改程式，

8.既應該測驗軟體應該做什么，也應該測驗軟體不應該做什么，

9.測驗只是展示缺陷，測驗只能表明有缺陷存在，但不能證明沒有缺陷，測驗能降低未發現缺陷留存的概率，卻不能證明軟體是
絕對正確的，

10.窮盡測驗是不可能的，測驗所有的輸入和條件組合是不可能的，可以取而代之的是基于風險和優先級的測驗，

11.缺陷簇生，要對缺陷發生率高的模塊投入更多的測驗，少量的模塊往往隱藏了大部分的缺陷，缺陷發生率高的模塊往往與需求不清、設計不當、編碼復雜度高等內在原因關聯，所以從風險的角度來看必然較高，

12.殺蟲劑悖論，相同的測驗再重復多次后就無法再找到缺陷了，測驗用例要不斷評審修改，不斷添加新的和不同的測驗，就有可能找到更多缺陷，

13.測驗是背景關系關聯的，測驗在不同背景關系環境中的執行是不同的，

14.無錯謬論，即使修改了系統中存在的大部分缺陷，但若系統本身背離了用戶需求，那么發現和修復缺陷就毫無幫助了，

4、軟體測驗的度量？

1.測驗覆寫率：有多少需求、代碼已經被測驗了，

2.缺陷發現率：缺陷是何時被發現，且有多少缺陷已經被發現，缺陷可以根據嚴重性來分類，需要記錄的資料有：缺陷數量、缺陷的嚴重等級等，

3.測驗成功率：有多少測驗用例已經通過，且有多少運行正常的，需要記錄的資料有：通過的測驗用例數、未通過的測驗用例數、已執行的測驗用例數等，

5、多少測驗才足夠？

取決于風險程度（商業風險和技術風險）和專案約束條件（時間和經費），

6、除錯和測驗的區別？

除錯 for開發人員發現缺陷原因，修復代碼并確認缺陷已經被修復；

測驗 for 測驗人員識別缺陷，

7、測驗的主要步驟？

計劃與控制；分析與設計；實施與執行；評估出口準則和報告；測驗結束活動，

8、什么是回歸測驗？

回歸測驗是指修改了舊代碼后，重新測驗以確認修改沒有引入新的錯誤或導致其他代碼產生錯誤，

9、測驗的標準是什么？

測驗的標準是用戶的需求，

10、為什么要避免測驗自己的程式？

測驗自己的程式時，容易順著撰寫代碼時的思路進行測驗，很少從其他角度思考，基于這種思維定勢，就難以發現潛在的錯誤，
由于心理因素，人們潛意識都不希望找到自己的錯誤，基于這種思維定勢，人們難以發現自己的錯誤，一定程度的獨立測驗可以更加高效的發現軟體缺陷和軟體存在的失效，

11、軟體測驗的要素有哪些？

1.質量，軟體質量是軟體測驗的目標，也是軟體測驗作業的中心，一切從質量出發，也就是一切從客戶需求出發，任何違背質量的東西都是問題，測驗就是要找出這些問題，

2.人員，人是決定的因素，測驗人員的態度、素質、能力決定著測驗的效果，對測驗產品的質量也有很大的影響，測驗人員因素包括測驗組織結構、角色和責任的定義，

3.技術，軟體測驗技術，包括方法、工具，

4.資源，主要是指測驗環境中所需要的硬體設備、網路環境，甚至包括測驗資料，另一個重要因素就是測驗時間，時間也是測驗的資源，

5.流程，從測驗計劃和測驗用例的創建、評審到測驗的執行、報告，設定每個階段的進出標準，

12、什么是軟體質量？

軟體特性的總和，軟體滿足規定或潛在用戶需求的能力，

13、軟體測驗與軟體質量保證的區別？

軟體測驗只是保證作業中的一個環節，軟體質量保證與軟體測驗是軟體質量工程的兩個不同層面的作業，
從性質上看，軟體測驗屬于技術性作業，而軟體質量保證屬于管理型作業；從物件上看，軟體測驗的物件是軟體產品，而質量保證的物件是整個軟體程序，覆寫公司層面的各個領域；從手段上看，軟體測驗以事后測驗檢驗為主，而軟體質量保證則強調缺陷的預防，

14、測驗團隊的基本責任？

1.發現軟體程式、系統或產品中所有的問題-

2.盡早的發現問題----------

3.督促和協助開發人員盡快地解決程式中的缺陷

4.幫助專案管理人員制定合理的開發計劃

5.對缺陷進行跟蹤、分析和分類總結，以便讓專案的管理人員和相關的負責人員能夠及時、清楚地了解產品當前的質量狀態

6.幫助改善開發流程、提高產品開發效率

7.促行程式撰寫的規范性、易讀性、可維護性等

15、什么是缺陷發現率（DDP）？

DDP=Bugs(tester)/(Bugs(tester)+Bugs(customer))
測驗人員發現的bug/（測驗人員發現的bug+用戶發現的bug）

16、什么是單元測驗？

定義：又稱模塊測驗，是針對軟體設計的最小單位程式模塊進行正確性檢查的測驗作業；可以從程式的內部結構出發設計測驗用例，多個模塊測驗可以平行地獨立進行測驗，

目的：發現模塊內部可能存在的各種差錯，

內容：模塊介面測驗（資料的流入流出）、區域資料結構測驗、路徑測驗、錯誤處理測驗、邊界測驗，

步驟：利用設計檔案設計測驗用例；創建被測驗模塊的樁模塊或驅動模塊；利用被測驗模塊、驅動模塊和樁模塊來建立測驗環境，進行測驗，

17、什么是集成測驗？

定義：又稱組裝測驗或聯合測驗，在單元測驗基礎上，將所有模塊按概要設計和詳細設計進行組裝，

目的：發現模塊連接中的介面可能存在的各種差錯，

內容：穿越模塊之間的資料是否會丟失；一個模塊組裝后是否會對另一個模塊或其他模塊存在影響；各個子功能組裝在一起是否會達到預期的父功能；全域資料結構是否有問題，

組裝方法：一次性組裝、增殖式組裝，
完成標志：成功地執行了測驗計劃中規定的所有測驗用例；修正了所發現的錯誤；測驗結果通過專門小組的評審，

18、什么是系統測驗？

目的：驗證和確認系統是否達到其原始目標，而對集成的硬體和軟體系統進行的測驗，

測驗內容：在真實或模擬系統運行環境下，檢查完整的程式系統能否和系統（硬體、網路、軟體）正確配置、連接，滿足用戶需求，

19、什么是驗收測驗？

目的：在用戶環境中進行測驗，以確定系統和產品是否能滿足合同或用戶所規定的需求，

內容：根據任務書或合同、供需雙方約定的驗收依據檔案進行對整個系統的測驗和評審，確認是否接識訓拒絕系統，

20、什么是靜態測驗？

又稱為靜態分析技術，不執行被測驗軟體，對需求分析說明書、軟體設計說明書、源程式做結構檢測、流圖分析、符號執行等找出軟體的錯誤，

21、什么是動態測驗？

通過輸入一組預先按照一定的測驗準則構造的實體資料動態運行程式，而達到發現程式錯誤的程序，

22、什么是自動化測驗？

自動化測驗是把以人為驅動的測驗行為轉化為機器執行的一種程序，

23、測驗用例有哪些設計原則？

1.單個用例覆寫最小化原則，每個測驗用例應該盡可能的簡單，只驗證你所要驗證的內容，

2.測驗用例替代產品檔案功能原則，

3.單次投入成本和多次投入成本原則，

4.使測驗結果分析和除錯最簡單化原則（針對自動化測驗用例的擴展和延續），

24、什么是Alpha測驗？

是驗收測驗的一種，是由用戶在開發者的場所來進行的，Alpha測驗是在一個受控的環境中進行的，

25、什么是Beta測驗？

是驗收測驗的一種，由軟體的最終用戶在一個或多個用戶場所來進行的，開發者通常不在現場，用戶記錄測驗中遇到的問題并報告給開發者，

26、如何進行單元測驗？

內容有：介面測驗、內部資料結構、全域資料結構、邊界測驗、路徑測驗、錯誤處理測驗，

27、手工測驗和自動測驗的優缺點？

手工測驗：缺點在于測驗作業量大、重復多、回歸測驗難以實作，

自動測驗：利用軟體測驗工具自動實作全部或部分測驗作業，管理、設計、執行和報告，節省大量的測驗開銷，并且能夠完成一些手工測驗無法實作的測驗，

手工完成測驗的全部程序無法保證測驗的科學性和嚴密性：

修改的缺陷越多，回歸測驗越困難；

沒有人能向決策層提供精確的資料以度量當前的作業進度及作業效率；

反復測驗帶來的倦怠情緒及其他人為因素使得測驗標準前后不一；

測驗花費的時間越長，測驗的嚴格性也就越低，

自動測驗將測驗人員從反復、煩雜的測驗執行中解放出來，用更多的時間進行測驗設計和結果分析：

軟體測驗不可能完全自動化；

不能完成所有手工測驗任務；

無創造性且靈活性差，不能改進測驗的有效性；

程序中可能會遇到許多意想不到的問題，特別是當軟體不穩定時；

測驗腳本的維護成本高，

28、測驗用例設計有哪些方法？

等價類劃分法；邊界值分析法；場景法；正交試驗法；因果圖；決策表；錯誤推測法，

29、什么是測驗計劃？

根據專案相關檔案制定的、用于指導整個測驗程序的檔案，需要定義測驗范圍、測驗策略、人員分配、軟硬體配置、進度表及測驗程序每個階段需要達到的目標，

30、測驗用例包含哪些關鍵內容？

用例編號、用例描述、前提條件、輸入資料、測驗步驟、預期結果6項關鍵內容，

31、查找遺漏問題的方法有哪些？

說明書是基礎和標準；相關變動郵件、討論記錄；不定期閱讀別人的缺陷；多和開發人員溝通；有選擇的重新驗證以前的缺陷；

關注變化；簡單思維方式，以主線為主，減少大遺漏，

32、敏捷開發的理念？ 以人為核心、迭代、循序漸進的開發方式，

個體和互動 勝過 程序和工具；

可以作業的軟體 勝過 面面俱到的檔案；

客戶合作 勝過 合同談判；

回應變化 勝過 遵循計劃，

33、敏捷開發遵循的原則？

通過盡早的、持續的交付有價值的軟體來使客戶滿意；

即使到了開發的后期，也歡迎改變需求，敏捷程序利用變化來為客戶創造競爭優勢；

經常性的交付可以作業的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好；

在整個專案開發期間，業務人員和開發人員必須天天都在一起作業；

圍繞被激勵起來的個體來構建專案，給他們提供所需的環境和支持，并且信任他們能夠完成作業；

在團隊內部，最具有效果并富有效率的傳遞資訊的方法，就是面對面的交談；

作業的軟體是首要的進度度量標準；

敏捷程序提倡可持續的開發速度，責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度；

不斷地關注優秀的技能和好的設計會增強敏捷能力；

簡單是最根本的；

最好的架構、需求和設計出自組織團隊；

每隔一定時間，團隊會在如何才能更有效地作業方面進行反省，然后相應的對自己的行為進行調整，

34、什么是敏捷測驗？

敏捷測驗是適應敏捷開發方法而采用的新的測驗流程、方法和實踐，

簡單的說，敏捷測驗就是持續的對軟體質量問題進行及時的反饋，

35、什么是軟體缺陷（bug）？

軟體缺陷是指系統或系統部件中那些導致系統或部件不能實作其應有功能的缺陷，如：

軟體未實作產品說明書要求的功能；

軟體出現產品說明書指明不應該出現的錯誤；

軟體實作了產品說明書未說明的功能；

軟體未實作產品說明書雖未明確提及但應該實作的目標；

軟體難以理解，不易使用，運行速度慢，或者軟體測驗員認為最終用戶會認為不好，

36、提交缺陷（bug）的要求？

Bug描述的基本要求：分類準確、敘述簡潔、步驟清楚、實際結果描述清楚、復雜問題有據可依，

問題描述：模塊或功能的—測驗步驟—期望結果—實際結果—其他資訊，

單一、簡潔、再現、復雜問題、報告不允許使用抽象的詞語，

37、白盒測驗？

白盒測驗又稱結構測驗、邏輯驅動測驗或基于程式的測驗，一般用來分析程式的內部結構，白盒測驗要求對被測程式的結構特性做到一定程度的覆寫，

控制流測驗：

1.陳述句覆寫準則：陳述句覆寫測驗是最簡單的結構性測驗方法之一，要求在測驗中，程式中的每條陳述句都得到運行，在控制流圖中，要求所有陳述句都被運行的充要條件是覆寫圖中的所有節點，
2.分支覆寫準則：分支測驗要求在軟體測驗中，每個分支都至少獲得一次“真”值和一次“假”值，== 分支覆寫測驗包含陳述句覆寫測驗==
3.謂詞測驗：一個分支的條件是由謂詞組成的，單個謂詞稱為原子謂詞，原子謂詞可通過邏輯運算子（或、與、非）構成復合謂詞，
（1）原子謂詞覆寫準則：要求在軟體測驗中，每個復合謂詞所包含的每一個原子謂詞都至少獲得一次真值和一次假值，原子謂詞覆寫準則和陳述句覆寫準則相互之間沒有包含關系，和分支覆寫準則相互之間也沒有包含關系，
（2）分支–謂詞覆寫準則：要求在軟體測驗中，不僅每個復合謂詞所包含的每一個原子謂詞都至少獲得一次真值和一次假值，而且每個復合謂詞本身也至少獲得一次真值和一次假值，分支–謂詞覆寫準則包含陳述句覆寫準則、分支覆寫準則、原子謂詞覆寫準則，
（3）復合謂詞覆寫準則：要求在軟體測驗中，每個條件中謂詞的各種可能都至少出現一次，復合謂詞覆寫準則包含陳述句覆寫準則、分支覆寫準則、原子謂詞覆寫準則、分支–謂詞覆寫準則，
路徑覆寫準則：要求觀察程式運行的整個路徑，要求程式的運行覆寫所有的完整路徑，路徑覆寫準則包含了分支覆寫準則，但與謂詞測驗之間沒有包含關系，

38、TDD（Test-Driven Development測驗驅動開發）？

TDD要求在撰寫某個功能的代碼之前，先撰寫測驗代碼，然后只撰寫使測驗通過的功能代碼，通過測驗來推動整個開發的進行，這有助于撰寫簡潔可用和高質量的代碼，并加速開發程序，

39、因果圖法設計測驗用例的步驟？

①分析需求，提取因果關系，并賦予識別符號；②分析需求，提取輸入與輸出，并表示為因果圖；③標明因果圖上的約束條件；④將因果圖轉化為判定表；⑤根據判定表中每一列顯示的情況設計測驗用例，

40、決策表法設計測驗用例的步驟？

①列出所有的條件樁和動作樁；②確定規則的個數；③填入條件項；④填入動作項；⑤簡化決策表，合并類似的規則或動作，

41、自動化測驗框架有哪些？

模塊化框架、函式庫框架、資料驅動框架、關鍵字驅動框架，

42、測驗覆寫率分為哪幾種統計方式？分別是什么？

代碼覆寫率、功能模塊覆寫率、需求覆寫率、資料庫覆寫率，

43、什么是FMEA?

FMEA(failure mode and effects analysis)：失效模式與效應分析，是一種可靠性設計的重要方法，對各種風險進行評價、分析，以便在現有技術的基礎上消除這些風隙訓將風險減少到可以接受的水平，

44、列舉出你所了解的EMC測驗和環境測驗專案？

45、請描述TCP/IP建立連接的程序？

46、呼叫一個DLL有哪幾種方式？

47、白盒測驗有哪些覆寫方法？

陳述句覆寫、分支覆寫、謂詞覆寫、路徑覆寫，

48、行程與執行緒的區別？

執行緒是行程的一個執行單元，也是行程的可調度物體，

49、軟體的缺陷等級應如何劃分？

1.致命錯誤，可能會導致本模塊或其他相關模塊例外、死機等問題；

2.嚴重錯誤，問題局限在本模塊，導致模塊功能失效或退出例外；

3.一般錯誤，模塊功能部分失效；

4.建議問題，由問題提出人對測驗物件的改進意見，

50、針對缺陷采取怎樣的管理措施？

1.要更好的管理缺陷，必須引入缺陷管理工具，商用的或者開源的都可；

2.根據缺陷的生命周期，考慮缺陷提交的管理、缺陷狀態的管理和缺陷分析的管理；

3.所有發現的缺陷都必須全部即時的、準確的提交到缺陷管理工具中，這是缺陷提交的管理；

4.缺陷提交后，需要即時的指派給相應的開發人員，提交者需要密切注意缺陷的狀態，幫助缺陷的盡快解決，缺陷解決后需要即時對缺陷的修復進行驗證；

5.為更好地改進開發程序和測驗程序，需要對缺陷進行分析總結，如缺陷的類別、缺陷的齡期分布等資訊，

51、并發性能測驗？

并發性能測驗的程序是一個負載測驗和壓力測驗的程序，即逐漸增加負載，直到系統的瓶頸或不能接收的性能點，通過綜合分析交易執行指標和資源監控指標來確定系統并發性能的程序，

52、負載測驗？

負載測驗是確定在各種負載下系統的性能，目標是測驗當負載逐漸增加時，系統組成部分的相應輸出項，例如通過量、回應時間、CPU負載、記憶體使用等來決定系統的性能，負載測驗是一個分析軟體應用程式和支撐架構、模擬真實環境的使用，從而來確定能夠接收的性能程序，

53、壓力測驗？

壓力測驗是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能夠提供的最大服務級別的測驗，

54、疲勞測驗？

疲勞測驗是采用系統穩定運行情況下能夠支持的最大并發用戶數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定系統處理最大作業量強度性能的程序，

55、大資料量測驗？

大資料量測驗分為兩種型別：針對某些系統存盤、傳輸、統計、查詢等業務進行大資料量的獨立資料量測驗；與壓力性能測驗、負載性能測驗、疲勞性能測驗相結合的綜合資料量測驗方案，大資料量測驗的關鍵是測驗資料的準備，可以依靠工具準備測驗資料，

56、客戶沒給性能指數，怎么開展性能測驗？

與專案經理、測驗主管等人協商，根據慣例和經驗設定、參考類似系統的性能指標、參考歷史資料等方法確定性能指數，

57、測驗程序中是如何來保證軟體質量的？

①測驗用例撰寫完成后要加強評審力度，確保測驗用例覆寫所有需求點；②測驗執行程序中要注意檢查測驗覆寫情況、審視所提交缺陷質量、復測時應注意相關模塊的測驗；③測驗時間寬裕的話可以做交叉測驗，用以確保測驗質量，

58、測驗方案都寫什么內容？

概述；被測物件分析；應測驗的特性；不被測驗的特性；總體設計方法；

測驗模型：測驗組網圖、結構/物件關系圖、測驗原理、操作規程；

測驗需求：環境需求、被測物件需求、測驗工具需求、測驗代碼需求、資料需求、其他需求；

測驗設計：工具設計、測驗代碼設計、用例設計、設計原則、測驗專案；

附錄，

59、測驗方案與測驗計劃的區別？

測驗方案是技術性的；測驗計劃是管理性的，

測驗計劃主要要考慮測驗的技術可行性、關鍵技術、資源投入、進度安排、風險管理、配置管理、輸入輸出等，測驗計劃更多地供高層管理者決策時做參考，同時對后續測驗作業開展起指導作用，

在一些小專案中，可能只需要一個測驗方案，測驗計劃內容相對較少，可以與測驗方案合并；而在一些大專案中，可能要設計數十個測驗方案，則就需要測驗計劃來提綱挈領，

60、單元測驗和系統測驗的側重點？

單元測驗側重系統模塊，包括子程式的正確性驗證等；系統測驗側重整個系統的運行以及與其他軟體的兼容性，

61、BUG流程？

提交缺陷–>分配缺陷–>確認缺陷–>推遲處理–>固定–>處理缺陷–>回歸缺陷–>關閉缺陷，

62、請寫出電腦的組成及有哪些作業系統？

計算機由硬體和軟體兩大部分組成，

硬體：輸入設備、輸出設備、存盤器、運算器、控制器；

軟體：系統軟體、應用軟體，

作業系統有：DOS（磁盤作業系統）、UNIX、XENIX、LINUX、Windows、Netware（網路作業系統），

63、loadrunner的使用流程？

制定測驗計劃à創建測驗腳本à創建場景à運行場景à監控測驗場景à分析測驗結果，

64、有什么是你覺得是bug而開發人員不認為是bug的經歷？

在測驗某個系統時，進行了洗掉操作后，系統未彈出相應的洗掉成功或失敗的資訊，只是重繪了資料串列，被執行洗掉操作的資料從串列中消失，開發人員認為這樣就能體現洗掉操作成功了，但是對于用戶而言，操作結果通過提示資訊來表示會更直觀，

65、軟體測驗的生命周期？

需求分析、測驗計劃、測驗設計、測驗開發、測驗執行、測驗評估，

66、BUG（指程式編碼上的錯誤）的生命周期？

new、open、in process、check、resolved、closed、reopened，

點擊鏈接加入群聊【Python自動化測驗交流群】