軟件測試總結

時間 2019-11-13

標籤軟件測試總結简体版

原文原文鏈接

按照開發階段劃分，軟件測試可分爲單元測試、集成測試，系統測試和驗收測試。

單元測試：針對每一個單元的測試，以確保每一個模塊能正常工做爲目標。

集成測試：對已測試過的模塊進行組裝，進行集成測試。目的在於檢驗與軟件設計相關的程序結構問題。

確認（有效性）測試：是檢驗所開發的軟件可否知足全部功能和性能需求的最後手段。有的劃分方法中，也將確認測試合併入系統測試中。瀏覽器

1、集成測試基本概念

1.把單獨的軟件模塊結合在一塊兒做爲總體接受測試，其目標是利用已經過單元測試的構件創建設計中描述的程序結構。安全

2.集成測試的主要任務：服務器

將各模塊鏈接起來，檢查模塊相互調用時，數據通過接口是否丟失；數據結構

將各個子功能組合起來，檢查可否達到預期要求的各項功能；工具

一個模塊的功能是否會對另外一個模塊的功能產生不利的影響；性能

全局數據結構是否有問題，會不會被異常修改；單元測試

單個模塊的偏差積累起來，是否被放大，從而達到不可接受的程度。測試

2、集成測試過程

1.計劃階段：spa

依據需求規格說明書、概要設計文檔和開發計劃，擬定軟件集成測試計劃；操作系統

2.設計階段

根據被測對象的結構、待集成模塊、接口，集成測試策略、測試工具進行分析，擬定集成測試計劃

3.實現階段

主要進行集成測試設計和集成測試代碼設計

4.執行階段

執行測試，生成代碼報告

3、集成測試原則

1.全部公共接口都要被測試到

2.關鍵模塊必須進行充分的測試

3.集成測試應該按必定的層次進行

4.集成測試的策略應該綜合考慮質量、進度、成本

5.當測試計劃中的結束標準知足時，集成測試結束

6.集成測試根據集成測試的計劃和方案進行，放着測試的隨意性

7.項目管理者保證測試用例通過審查

8.測試的結果應該如實的被記錄

4、測試技術和步驟

1.技術：

黑盒測試技術爲主，白盒測試技術爲輔（灰盒測試技術）

布驟：

與集成測試策略相關

2.集成測試策略

(1)基於功能分解的集成測試

(2)非增量型

(3)瞬間集成：

又稱大爆炸測試、一次性集成。首先對每一個模塊分別進行模塊測試，而後將全部模塊集成起來在一塊兒進行測試，最終獲得要求的軟件系統。

(4)增量式：

特色：

將程序分紅小的部分進行構造和測試；

優勢：

1.錯誤容易分離和修正；

2.接口容易進行完全測試；

缺點：

會有額外開銷，但能大大減小發現和修正錯誤的時間。

(5)基於調用圖的集成測試

(6)基於路徑的集成測試

5、其餘集成測試策略

1.層次集成

2.客戶/服務器集成

3.分佈服務集成

4.高頻集成

6、集成測試總結

集成測試是一個必要的測試階段：

從將兩個組件集成到一塊兒開始，到全部系統組件在一塊兒運行位置的全部測試活動，都是集成測試階段的一部分

集成測試能減小系統測試階段的缺陷

系統測試：系統測試是將通過集成測試的軟件，做爲計算機系統的一個部分，與系統中其餘部分結合起來，在實際運行環境下對計算機系統進行的一系列嚴格有效地測試，以發現軟件潛在的問題，保證系統的正常運行。

1、主要內容包括

功能測試：

即軟件系統的功能是否正確，依據產品的需求文檔

健壯性測試：即軟件系統在異常狀況下可否正常運行。

健壯性有兩層含義：

1.容錯能力。

2.恢復能力

2、分類

1.恢復測試

恢復測試做爲一種系統測試，主要關注致使軟件運行失敗的各類條件，並驗證其恢復過程可否正確執行。在特定狀況下，系統需具有容錯能力。另外，系統失效必須在規定時間段內被更正，不然將會致使嚴重的經濟損失。

2.安全測試

安全測試用來驗證系統內部的保護機制，以防止非法侵入。在安全測試中，測試人員扮演試圖侵入系統的角色，採用各類辦法試圖突破防線。所以系統安全設計的準則是要千方百計使侵入系統所需的代價更加昂貴。

3.壓力測試

壓力測試是指在正常資源下使用異常的訪問量、頻率或數據量來執行系統。在壓力測試中可執行如下測試：

①若是平均中斷數量是每秒一到兩次，那麼設計特殊的測試用例產生每秒十次中斷。

②輸入數據量增長一個量級，肯定輸入功能將如何響應。

③在虛擬操做系統下，產生須要最大內存量或其它資源的測試用例，或產生須要過量磁盤存儲的數據。

3、步驟

Step1 制定系統測試計劃

系統測試小組各成員共同協商測試計劃。測試組長按照指定的模板起草《系統測試計劃》。該計劃主要包括：

測試範圍（內容）

測試方法

測試環境與輔助工具

測試完成準則

人員與任務表

項目經理審批《系統測試計劃》。該計劃被批准後，轉向Step2。

Step2 設計系統測試用例

系統測試小組各成員依據《系統測試計劃》和指定的模板，設計（撰寫）《系統測試用例》。

測試組長邀請開發人員和同行專家，對《系統測試用例》進行技術評審。該測試用例經過技術評審後，轉向 Step3。

Step3 執行系統測試

系統測試小組各成員依據《系統測試計劃》和《系統測試用例》執行系統測試。

將測試結果記錄在《系統測試報告》中，用「缺陷管理工具」來管理所發現的缺陷，並及時通報給開發人員。

Step4 缺陷管理與改錯

從Step1至Step3，任何人發現軟件系統中的缺陷時都必須使用指定的「缺陷管理工具」。該工具將記錄全部缺陷的狀態信息，並能夠自動產生《缺陷管理報告》。

開發人員及時消除已經發現的缺陷。

開發人員消除缺陷以後應當立刻進行迴歸測試，以確保不會引入新的缺陷。

4、目標和原則

目標：

1. 確保系統測試的活動是按計劃進行的；

2. 驗證軟件產品是否與系統需求用例不相符合或與之矛盾；

3. 創建完善的系統測試缺陷記錄跟蹤庫；

4. 確保軟件系統測試活動及其結果及時通知相關小組和我的。

原則：

1.測試機構要獨立；

2.要精心設計測試計劃，包括負載測試、壓力測試、用戶界面測試、可用性測試、逆向測試、安裝測試、驗收測試；

3.要進行迴歸測試；

4.測試要聽從經濟性原則。

5、方針

一、爲項目指定一個測試工程師負責貫徹和執行系統測試活動

二、測試組向各事業部總經理/項目經理報告系統測試的執行情況

三、系統測試活動遵循文檔化的標準和過程

四、向外部用戶提供經系統測試驗收經過的預部署及技術支持

五、創建相應項目的（BUG）缺陷庫，用於系統測試階段項目不一樣生命週期的缺陷記錄和缺陷狀態跟蹤

六、按期的對系統測試活動及結果進行評估，向各事業部經理/項目辦總監/項目經理彙報/提供項目的產品質量信息及數據

驗收測試能夠分紅Alpha測試和Beta測試。
Alpha測試是由用戶在開發環境下完成的測試，Beta測試是由用戶在用戶環境下完成的測試。

1、驗收測試過程和主要內容

1.驗收測試的概念

驗收測試(Acceptance Test):在軟件產品完成了功能測試和系統測試以後、產品發佈以前所進行的軟件測試活動它是技術測試的最後一個階段,也稱爲交付測試。

2.驗收測試的過程和內容

    前提:
        系統或軟件產品已經過了系統測試的軟件系統。
    測試內容:
    驗證系統是否達到了用戶需求規格說明書（可能包括項目或產品驗收準則）中的要求，測試試圖儘量地發現軟件中存留的缺陷，從而爲軟件進一步改善提供幫助，並保證系統或軟件產品最終被用戶接受。主要包括易用性測試、兼容性測試、安裝測試、文檔（如用戶手冊、操做手冊等）測試等幾個方面的內容。

3.測試步驟

        制定測試計劃，測試項，測試策略及驗收經過準則，並通過客戶參與的計劃評審。
        創建測試環境，設計測試用例，並通過評審。
        準備測試數據，執行測試用例，記錄測試結果。
        分析測試結果，根據驗收經過準則分析測試結果，做出驗收是否經過及測試評價。

測試項目經過

測試項目沒有經過，而且不存在變通方法，須要很大的修改

測試項目沒有經過，但存在變通方法，在維護後期或下一個版本改進

測試項目沒法評估或者沒法給出完整的評估。此時必須給出緣由。若是是由於該測試項目沒有說明清楚，應該修改測試計劃。

提交測試報告

4.驗收標準和注意事項

驗收測試完成標準:

徹底執行了驗收測試計劃中的每一個測試用例。

在驗收測試中發現的錯誤已經獲得修改而且經過了測試或者通過評估留待下一版本中修改。

完成軟件驗收測試報告。