知識點總結：

1、什麼是軟體測試?

答:軟體測試是為了發現錯誤而執行程式的過程。或者說，軟體測試是根據軟體開發各階段的規格說明和程式的內部結構

而精心設計一批測試用例(即輸入資料及其預期的輸出結果)，並利用這些測試用例去執行程式，以發現程式錯誤的過程。

2、軟體測試的目的?

答;測試的目的是想以最少的人力、物力和時間找出軟體中潛在的各種錯誤和缺陷，通過修正錯誤和缺陷提高軟體質量，

迴避軟體釋出後由於潛在的軟體缺陷和錯誤造成的隱患帶來的商業風險。

3、什麼是需求文件測試：

答:主要測試需求中是否存在邏輯矛盾以及需求在技術上是否可以實現;

4、什麼是設計文件測試?

答:測試設計是否符合全部需求以及設計是否合理。

5、什麼是α測試?

答:Alpha測試(α測試)是由一個使用者在開發環境下進行的測試，也可以是公司內部的使用者在模擬實際操作環境下進行的受控

測試，Alpha測試不能由程式設計師或測試員完成。Alpha測試發現的錯誤，可以在測試現場立刻反饋給開發人員，由開發人員

及時分析和處理。目的是評價軟體產品的功能、可使用性、可靠性、效能和支援。尤其注重產品的介面和特色。Alpha測

試可以從軟體產品編碼結束之後開始，或在模組(子系統)測試完成後開始，也可以在確認測試過程中產品達到一定的穩定

和可靠程度之後再開始。有關的手冊(草稿)等應該在Alpha測試前準備好。

6、什麼是β測試?

答:Beta測試(β測試)是軟體的多個使用者在一個或多個使用者的實際使用環境下進行的測試。開發者通常不在測試現場，Beta

測試不能由程式設計師或測試員完成。因而，Beta測試是在開發者無法控制的環境下進行的軟體現場應用。在Beta測試中，由

使用者記下遇到的所有問題，包括真實的以及主管認定的，定期向開發者報告，開發者在綜合使用者的報告後，做出修改，最

後將軟體產品交付給全體使用者使用。Beta測試著重於產品的支援性，包括文件、客戶培訓和支援產品的生產能力。只有當

Alpha測試達到一定的可靠程度後，才能開始Beta測試。由於Beta測試的主要目標是測試可支援性，所以Beta測試應該盡

可能由主持產品發行的人員來管理。

7、什麼是驅動模組？

答:驅動模組在大多數場合稱為"主程式"，它接收測試資料並將這些資料傳遞到被測試模組.單元測試一個函式單元時，被

測單元本身是不能獨立執行的，需要為其傳送資料，為此寫驅動。

驅動模組主要完成以下事情

1、接受測試輸入;

2、對輸入進行判斷;

3、將輸入傳給被測單元，驅動被測單元執行;

4、接受被測單元執行結果，並對結果進行判斷;

5、將判斷結果作為用例執行結果輸出測試報告。

8、什麼是樁模組?

答:比如對函式A做單元測試時，被測的函式單元下還包括了一個函式B，為了更好的錯誤，定位錯誤，就要為函式B寫

樁，來模擬函式B的功能，保證其正確。

9、什麼是白盒測試?

答:白盒測試(White-box Testing，又稱邏輯驅動測試,結構測試),它是知道產品內部工作過程，可通過測試來檢測產品內部

動作是否按照規格說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求

正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。

對開發語言的支援：白盒測試工具是對原始碼進行的測試，測試的主要內容包括詞法分析與語法分析、靜態錯誤分析、動

態檢測等。目前測試工具主要支援的開發語言包括：標準C、C++、Visual C++、Java、Visual J++等。

10、什麼是靜態測試?

答:通過執行程式測試軟體稱為動態測試.通過評審文件、閱讀程式碼等方式測試軟體稱為靜態測試,在動態測試中,通常使用白

盒測試和黑盒測試從不同的角度設計測試用例,查詢軟體程式碼中的錯誤。

靜態測試方法是指不執行被測程式本身，僅通過分析或檢查源程式的語法、結構、過程、介面等來檢查程式的正確性。對

需求規格說明書、軟體設計說明書、源程式做結構分析、流程圖分析、符號執行來找錯。靜態方法通過程式靜態特性的分

析，找出欠缺和可疑之處，例如不匹配的引數、不適當的迴圈巢狀和分支巢狀、不允許的遞迴、未使用過的變數、空指標

的引用和可疑的計算等。靜態測試結果可用於進一步的查錯，併為測試用例選取提供指導。

11、什麼是迴歸測試?

答:迴歸測試的目的是在程式有修改的情況下，保證原有功能正常的一種測試策略和方法。

說白了就是，我們測試人員在對程式進行測試時發現bug，然後返還程式設計師修改，程式設計師修改後釋出新的軟體包或新的軟

件補丁包給我們測試人員，我們就要重新對這個程式測試，已保證程式在修正了以前bug的情況下，正常執行，且不會帶

來新的錯誤的這樣一個過程。 一般情況下是不需要全面測試的，而是根據修改的情況進行有效的測試。

12、白盒測試有哪幾種方法?

答:白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格

說明書的規定正常進行，按照程式內部的結構測試程式，檢驗程式中的每條通路是否都有能按預定要求正確工作，而不顧

它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。“白盒”法全面瞭解程式內部邏輯結構、對

所有邏輯路徑進行測試。“白盒”法是窮舉路徑測試。

13、軟體的缺陷等級應如何劃分?

軟體缺陷的等級可以用嚴重性和優先順序來描述；

嚴重性：衡量缺陷對客戶滿意度影響的滿意程度，分為

1.致命錯誤，可能導致本模組以及其他相關的模組異常，宕機等問題；

2.嚴重錯誤，問題侷限在本模組，導致模組功能失常或異常退出；

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

4.建議模組，有問題提出人對測試模組的改進建議；

優先順序：缺陷被修復的緊急程度；

1.立即解決（P1級）：缺陷導致系統功能幾乎不能使用或者測試不能繼續，需立即修復；

2.高優先順序（P2級）：缺陷嚴重，影響測試，需優先考慮；

3.正常排隊（P3級）：缺陷需要正常排隊等待修復；

4.低優先順序（P4級）：缺陷可以在有時間的時候被糾正；

14、如果能夠執行完美的黑盒測試，還需要進行白盒測試嗎?(白盒與黑盒的區別)

答:任何工程產品(注意是任何工程產品)都可以使用以下兩種方法之一進行測試。

黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。 白盒測試：已知產品的內部

工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。

軟體的黑盒測試意味著測試要在軟體的介面處進行。這種方法是把測試物件看做一個黑盒子，測試人員完全不考慮程式內

部的邏輯結構和內部特性，只依據程式的需求規格說明書，檢查程式的功能是否符合它的功能說明。因此黑盒測試又叫功

能測試或資料驅動測試。黑盒測試主要是為了發現以下幾類錯誤：

1、是否有不正確或遺漏的功能?

2、在介面上，輸入是否能正確的接受?能否輸出正確的結果?

3、是否有資料結構錯誤或外部資訊(例如資料檔案)訪問錯誤?

4、效能上是否能夠滿足要求?

5、是否有初始化或終止性錯誤?

軟體的白盒測試是對軟體的過程性細節做細緻的檢查。這種方法是把測試物件看做一個開啟的盒子，它允許測試人員利用

程式內部的邏輯結構及有關資訊，設計或選擇測試用例，對程式所有邏輯路徑進行測試。通過在不同點檢查程式狀態，確

定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白盒測試主要是想對程式模組進行如

下檢查：

1、對程式模組的所有獨立的執行路徑至少測試一遍。

2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。

3、在迴圈的邊界和執行的界限內執行迴圈體。

4、測試內部資料結構的有效性，等等。

以上事實說明，軟體測試有一個致命的缺陷，即測試的不完全、不徹底性。由於任何程式只能進行少量(相對於窮舉的巨

大數量而言)的有限的測試，在未發現錯誤時，不能說明程式中沒有錯誤。

15、軟體測試應該劃分幾個階段?簡述各個階段應重點測試的點?各個階段的含義?

答:大體上來說可分為單元測試,整合測試,系統測試,驗收測試,每個階段又分為以下五個步驟: 測試計劃，測試設計，用例設

計，執行結果，測試報告初始測試集中在每個模組上，保證原始碼的正確性，該階段成為單元測試，主要用白盒測試方

法。 接下來是模組整合和整合以便組成完整的軟體包。整合測試集中在證實和程式構成問題上。主要採用黑盒測試方

法，輔之以白盒測試方法。軟體整合後，需要完成確認和系統測試。確認測試提供軟體滿足所有功能、效能需求的最後保

證。確認測試僅僅應用黑盒測試方法。

16、什麼是單元測試?

答:單元測試是對軟體中的基本組成單位進行的測試，如一個模組、一個過程等等。它是軟體動態測試的最基本的部分，

也是最重要的部分之一，其目的是檢驗軟體基本組成單位的正確性。

17、什麼是整合測試?

答:整合測試是在軟體系統整合過程中所進行的測試，其主要目的是檢查軟體單位之間的介面是否正確。

18、系統測試

答:系統測試是對已經整合好的軟體系統進行徹底的測試，以驗證軟體系統的正確性和效能等滿足其規約所指定的要求，

檢查軟體的行為和輸出是否正確並非一項簡單的任務，它被稱為測試的“先知者問題”。

19、驗收測試

答:驗收測試旨在向軟體的購買者展示該軟體系統滿足其使用者的需求。它的測試資料通常是系統測試的測試資料的子集.

20、迴歸測試

答:迴歸測試是在軟體維護階段，對軟體進行修改之後進行的測試。其目的是檢驗對軟體進行的修改是否正確。

21、針對缺陷採取怎樣的管理措施?

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

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

3. 所有發現的缺陷(不管是測試發現的還是走讀程式碼發現的)都必須全部即時的、準確的提交到缺陷管理工具中，這是缺陷

提交的管理。

4. 缺陷提交後，需要即時的指派給相應的開發人員，提交缺陷的人需要密切注意缺陷的狀態， 幫助缺陷的儘快解決。缺

陷解決後需要即時對缺陷的修復進行驗證。這樣的目的有兩個：一個是讓缺陷儘快解決;二是方便後面缺陷的分析(保證缺

陷相關的資訊準確，如齡期等)，這是缺陷狀態的管理。

5. 為了更好的改進開發過程和測試過程，需要對缺陷進行分析，總結如缺陷的類別、缺陷的齡期分佈等資訊，這是缺陷分

析的管理。

22、單元測試、整合測試、系統測試的側重點是什麼?

答:單元測試是在軟體開發過程中要進行的最低級別的測試活動，在單元測試活動中，軟體的獨立單元將在與程式的其他

部分相隔離的情況下進行測試，測試重點是系統的模組，包括子程式的正確性驗證等。 整合測試，也叫組裝測試或聯合

測試。在單元測試的基礎上，將所有模組按照設計要求，組裝成為子系統或系統，進行整合測試。實踐表明，一些模組雖

然能夠單獨地工作，但並不能保證連線起來也能正常的工作。程式在某些區域性反映不出來的問題，在全域性上很可能暴露出

來，影響功能的實現。測試重點是模組間的銜接以及引數的傳遞等。

系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的

有效方法。測試重點是整個系統的執行以及與其他軟體的相容性。

23、設計用例的方法、依據有那些?

答:白盒測試用例設計有如下方法:基本路徑測試\邊界值分析\覆蓋測試\迴圈測試\資料流測試\程式插樁測試\變異測試.這時

候依據就是詳細設計說明書及其程式碼結構

黑盒測試用例設計方法:基於使用者需求的測試\功能圖分析方法\等價類劃分方法\邊界值分析方法\錯誤推測方法\因果圖方法

\判定表驅動分析方法\正交實驗設計方法.依據是使用者需求規格說明書,詳細設計說明書。

24、描述使用bugzilla缺陷管理工具對軟體缺陷(BUG)跟蹤的管理的流程

答:1) 測試人員或開發人員發現bug後，判斷屬於哪個模組的問題，填寫bug報告後，系統會自動通過Email通知專案組長

或直接通知開發者。

2) 經驗證無誤後，修改狀態為VERIFIED.待整個產品釋出後，修改為CLOSED.

3) 還有問題，REOPENED，狀態重新變為“New"，併發郵件通知。

4) 專案組長根據具體情況，重新reassigned分配給bug所屬的開發者。

5) 若是，進行處理，resolved並給出解決方法。(可建立補丁附件及補充說明)

6) 開發者收到Email資訊後，判斷是否為自己的修改範圍。

7) 若不是，重新reassigned分配給專案組長或應該分配的開發者。

8) 測試人員查詢開發者已修改的bug，進行重新測試。