參考書籍

軟件測試技術基礎教程

軟件測試概述

第一類測試：在設計規定的環境下運行軟件的功能，將其結果與用戶需求或設計結果相比較，如果相符則測試通過，如果不相符則視為Bug

第一類測試方法以需求和設計為本

第二類測試：強調測試人員發揮主觀能動性，用逆向思維方式，不斷思考開發人員理解的誤區、不良習慣、程序代碼的邊界、無效數據的輸入及系統的各種弱點，試圖破壞系統、摧毀系統，目標是發現系統中各種各樣的問題

測試是以評價一個程序或系統屬性為目標的任何一種活動。測試是對軟件質量的度量

對于軟件缺陷的定義：

1. 軟件未達到產品說明書要求的功能
2. 軟件出現了產品說明書指明不會出現的錯誤
3. 軟件功能超出了產品說明書規定的功能
4. 軟件未實現產品說明書雖未明確指出膽應該實現的目標

軟件測試的充分性準則：

1. 對任何軟件都存在有限的充分測試集合
2. 軟件測試的單調性：當一個測試的數據集合對于一個被測的軟件系統的測試是充分的，那么再多增加一些測試數據任然是充分的
3. 軟件測試的非復合性：即使對軟件所有成分都進行了充分的測試，也并不意味著整個軟件的測試已經充分
4. 軟件測試的非分解性：即使對一個軟件的系統整體的測試是充分的，也并不意味著這個軟件系統各個成分都已經充分地的得到了測試
5. 軟件測試的復雜性：軟件測試的數據量正比于軟件的復雜度
6. 軟件測試的充分性與軟件的需求、軟件的實現相關
7. 軟件測試具有回報遞減性，即隨著測試次數的增加，檢查出軟件缺陷的概率不斷減少

軟件測試基礎

軟件測試的目的

• 測試時程序的執行過程，目的在于發現錯誤
• 一個好的測試用例在于可以發現還未曾發現的錯誤
• 一個成功的測試是發現了至今還沒有發現的錯誤

軟件測試的原則

• 盡早開始測試
• 測試用例包括測試輸入數據和與之對應的預期輸出結果
• 避免檢查自己的程序
• 設計測試用例時，包括合理的輸入條件和不合理的輸入條件

軟件測試的分類

按照軟件測試的生命周期分類

• 單元測試

  目的：檢查每個程序單元能否正確實現詳細設計說明中的模塊功能、性能、接口和設計約束等

• 集成測試

  目的：用于檢驗程序單元或部件的接口關系，使其符合概要設計

• 確認測試

  目的：檢驗軟件的功能、性能及其他特性是否與用戶的要求一致

• 系統測試

  目的：通過與系統的需求相比較，發現所開發的系統與用戶需求不符或矛盾的地方

  可以分為三個階段

  • 模塊測試 測試模塊程序
  • 組裝測試 測試模塊之間的接口
  • 確認測試 測試整個軟件系統

• 驗收測試

  目的：用戶對軟件系統進行測試和接收

按照軟件測試技術分類

• 白盒測試

  通過對程序內部結構的分析、檢測來發現系統代碼中存在的問題

  常用的測試方法：

  • 靜態測試 不執行
  • 動態測試 需要執行

• 黑盒測試

  在不考慮程序內部結構的情況下，檢查程序的功能是否按照需求規格說明書的規定

  常用的測試方法：

  • 等價類劃分
  • 邊界值分析法
  • 錯誤推斷法
  • 因果圖法

• 灰盒測試

  關注輸出對于輸入的正確性，同時也關注內部表現，通過表征性的現象、實踐、標志來判斷內部的運行狀態

按照軟件測試實施主體分類

1. 開發方測試(驗證測試)

   在軟件開發環境下，由開發者通過檢測和提供客觀證據，證實軟件的實現能否滿足規定的需求

2. 用戶測試(Beta測試)

   用戶在真實的應用環境下，通過運行和使用軟件，檢測與核查軟件是否符合自己預期的要求

3. 第三方測試(獨立測試)

   軟件第三方測試是由在技術、管理和財務上與開發方和用戶方相對獨立的組織進行的軟件測試

按照測試內容分類

• 功能性測試

  考察方面：

  1. 適合性：是否提供了滿足需求的功能，以及系統所提供的功能對需求的適合程度的測試工作
  2. 準確性：檢驗系統處理數據是否準確，以及處理數據的精度是否符合需求
  3. 互操作性：檢查系統的相關功能與其他特定系統之間交互能力
  4. 安全性：檢驗系統的安全性，防止對系統及數據非授權的故意或意外訪問等
  5. 功能的依從性：檢驗軟件產品的功能是否遵循有關的標準、約定、法規等

• 可靠性測試

  1. 成熟性測試：檢驗軟件系統故障導致失效的可能程度的測試
  2. 容錯性測試：檢驗軟件系統在出現故障或違反指定接口的情況下，是否能維持規定的性能水平
  3. 易恢復性測試：檢驗軟件失效后，重建其直接受影響的數據，以及為達此目的所需的實踐和相關工作

• 易用性測試

  1. 易理解性測試：主要檢查用戶為認識系統的邏輯概念及系統的應用
  2. 易學習性測試：主要檢查用戶為學習軟件的輸入、輸出、計算、控制等應用所實施的相關工作
  3. 易操作性測試：檢查系統中用戶為操作和運行控制所付出努力有關

• 效率測試

  1. 時間特性測試：主要考查系統的執行效率
  2. 資源利用性測試：檢測系統的設備效率與網絡效率

• 可移植性測試

  1. 適應性測試：檢測系統軟件無需特殊準備就可適應不同的規定環境的軟件測試工作
  2. 易安裝性測試：檢測軟件系統在指定環境下的安裝中所需的相關工作
  3. 共存性測試：檢驗軟件系統與指定的其他軟件共存于指定環境下的軟件屬性
  4. 易替換性測試：檢驗軟件系統在該軟件環境中用于替代指定的其他軟件的機會

• 文檔測試

  1. 文檔完整性：檢查開發文檔、管理文檔等相關文檔是否按照實際系統的全部功能提供了相關信息說明
  2. 文檔正確性：檢查開發文檔、管理文檔等想相關文檔的描述信息是否與實際系統的全部功能一一對應
  3. 文檔一致性：考察文檔與文檔的一致性、文檔與系統的一致性兩部分
  4. 文檔易理解性

軟件質量保證的工作內容

1. 參與制定軟件質量要求
2. 組織正式評審
3. 軟件測試管理
4. 對軟件的變更進行控制
5. 對軟件質量進行度量
6. 對軟件質量情況及時記錄和報告

軟件開發各階段SQA(軟件質量保證)的目標

1. 需求分析階段
   • 確保客戶所需求的系統是可行的
   • 確保客戶指定的需求確實能夠滿足真正的要求
   • 避免開發者與客戶之間的誤解
2. 軟件規格說明書編制階段
   • 確保規格說明書與系統需求保持一致
   • 建立測試策略
   • 建立現實的開發進度表
   • 設計正式的變更流程
3. 軟件設計階段
   • 建立用于描述設計的標準
   • 適當地控制并用文檔記錄對設計進行的變更
4. 編碼階段
   • 遵循已建立的風格、結構和文檔標準
   • 確保代碼經過適當測試和集成
   • 代碼編寫遵循進度
5. 測試階段
   • 確保測試計劃的建立和遵循
6. 維護階段
   • 代碼和文檔的一致性
   • 對已建立的變更控制過程進行監測

ISO 9000系列標準是ISO組織制定的國際標準

核心標準是質量保證標準ISO 9001 ~ ISO 9003和質量管理標準ISO 9004

ISO 9001 ~ ISO 9003作為第一類用于建立客戶對生產商質量要求保證

ISO 9004作為第二類用于生產商自身建立質量保障體系

ISO 9000系列標準的兩個主要特點：

• 目標在于整個產品流程的控制
• 產品缺陷提早預防

CMM(能力成熟度模型)是軟件行業的標準模型，用來定義和評價軟件公司開發過程的成熟度，以通用性好作為特點

CMM將軟件過程能力成熟度劃分為五個等級

1. 等級1(初始級)

   開發過程是隨意的、混亂的

2. 等級2(可重復級)

   成熟度主要集中在項目級。建立基本的項目管理過程。軟件開發具有一定的組織性

3. 等級3(已定義級)

   具備了組織化，不僅僅針對具體項目。軟件開發中的管理活動和工程活動被文檔化或標準化。所有項目均在標準軟件過程中進行

4. 等級4(已管理級)

   軟件過程和產品質量有具體的度量標準，軟件過程和產品質量等到了定量理解和控制

5. 等級5(優化級)

   能夠進行持續的過程改進，達到質量更佳

軟件質量保證和軟件測試的關系

軟件測試可以查找錯誤并修改，從而提高軟件質量

軟件質量保證則是避免錯誤，從而提高軟件質量

正規的軟件測試系統主要包括：

• 制定測試計劃
• 測試設計
• 實施測試
• 建立和更新測試文檔

軟件質量保證的工作為：

• 制定軟件質量要求
• 組織正式審查
• 軟件測試管理
• 對軟件的變更進行控制
• 對軟件質量進行度量
• 對軟件質量 情況及時記錄和報告

共同之處：盡力確保軟件產品滿足需求

不同之處：軟件質量保證側重于對軟件開發過程中的各個過程進行管理與控制；測試是對已產生的軟件缺陷進行修復

軟件測試規范

通常分為國家標準、行業標準、企業規范和項目規范

軟件測試過程與方法

軟件測試過程

按照從編寫到交付的各個階段的先后順序可以分為：

1. 單元測試
2. 集成測試
3. 確認測試
4. 系統測試
5. 驗收測試

軟件測試過程與軟件開發過程的關系

軟件開發過程是自下向上、逐步細化的過程

軟件測試是自上向下、逐步集成的過程

單元測試

單元測試的對象是軟件設計的最小單位---模塊

單元測試的主要目標：確保個單元模塊被正確的編碼

單元測試的主要內容：

• 模塊接口測試：對通過被測模塊的數據流進行測試
• 局部數據結構測試：設計測試用例檢查數據類型說明、初始化、默認值等問題
• 獨立路徑測試：對模塊中重要的執行路徑進行測試
• 出錯處理測試：檢查模塊的錯誤處理功能是否含有錯誤或缺陷
• 邊界條件測試

單元測試的步驟

在編碼階段進行，在代碼經過評審和驗證，確認沒有語法錯誤后，開始進行單元測試

在單元測試中，會使用輔助模塊幫助單元測試的進行

• 驅動模塊：相當于被測模塊的主程序，接受測試數據，并將數據輸入到測試模塊中
• 樁模塊：用以代替被測模塊調用的子模塊，樁模塊可以做少量的數據操作

集成測試

是單元測試的擴展和延伸，為了測試程序模塊之間接口的規范性、一致性等

需要根據實際情況對程序模塊采用適當的策略組裝起來

集成測試的層次：

集成測試對傳統軟件和面向對象的應用系統的測試是不同的

傳統軟件的3個測試層次：

1. 模塊被集成測試
2. 子系統內集成測試
3. 子系統間集成測試

面向對象的應用系統的兩個測試階段：

1. 類內集成測試
2. 類間集成測試

集成測試的模式：

采用不同的集成方式對應的測試不同

把模塊組裝成系統的測試方式有兩種：

• 一次性集成測試

  先分別測試每個模塊，再把所有模塊按設計要求一次性全部組裝起來所要的系統，然后進行整體測試

• 增量式集成測試

  將下一個要測試的模塊同已經測好的模塊結合起來進行測試，即邊組裝邊測試

  • 自頂向下增量測試

    從主控模塊開始，按照軟件的控制層次結構，以深度優先或廣度優先的策略，逐步組裝各個模塊

    優點：盡早對程序的主要控制和決策機制進行檢驗

    缺點：底層樁模塊不符合真實情況

  • 自底向上增量測試

    從軟件結構最底層的模塊開始向上一層層地組裝測試

    優點：及早解決容易出錯的部分

    缺點：程序的主要控制和決策機制不能及時驗證

  • 混合增量測試

    • 改進的自頂向下增量測試

      基本思想是強化對輸入/輸出模塊和引入新算法模塊的測試，并自底向上組裝成為功能相當完整且相對獨立的子系統，然后由主模塊開始自頂向下進行增量測試

    • 自底向上-自頂向下

      首先對含讀操作的子系統自底向上直至根結點模塊進行組裝和測試，然后對含寫操作的子系統做自頂向下的組裝與測試

    • 回歸測試

      取自頂向下的方式測試被修改的模塊及其子模塊，然后將這一部分視為子系統，再自底向上測試，以檢查該子系統與其上級模塊的接口是否適配

集成測試的測試計劃：測試計劃表、各模塊單元測試完成日期、首次集成測試日期、集成測試全部完成日期、測試用例及期望結果

集成測試完成的標志：

• 成功地執行力測試計劃中規定的所有集成測試
• 修正了所發現的錯誤
• 測試結果通過了專門小組的評審

集成測試需要提交的文檔：集成測試計劃、集成測試規格說明、集成測試分析報告

確認測試

目的是驗證軟件的功能和性能及其特性是否與客戶的要求一致，是否滿足軟件需求規格說明書中的規定。

確認測試的流程：

1. 進行有效性測試和軟件配置審查
2. 進行驗收測試和安裝測試
3. 專家鑒定

確認測試的準則：

若一個軟件的功能、性能及限制條件達到了設計要求，這個軟件的開發是成功的

確認測試后發現嚴重錯誤和偏差一般很難在預定工期內改正，需要和用戶協商

確認測試需要交付的文檔有：

• 確認測試分析報告
• 最終的用戶手冊和操作手冊
• 項目開發總結報告

確認測試需要進行軟件配置復審，目的在于保證軟件配置齊全、分類有序，各方面的質量符合要求，具備維護階段所需的細節資料并且已經編排好分類的目錄

系統測試

它是將已經集成好的軟件系統，作為整個計算機系統的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統元素結合在一起，在實際運行的環境下，對計算機系統進行一系列的組裝測試和確認測試

系統測試的目的在于：通過與系統的需求定義進行比較，檢車軟件是否與系統需求頂不符合或與之矛盾的地方，以驗證軟件系統的功能和性能等是否滿足其規約所指定的要求

系統測試的目標

• 確保系統測試的活動是按計劃進行的
• 驗證軟件產品是否與系統需求用例不相符合或與之矛盾
• 建立完善的系統測試缺陷記錄跟蹤庫
• 確保軟件系統測試活動及其結果及時通知相關小組和個人

系統測試的過程：

1. 軟件項目立項
2. 測試工程師參與前期的需求分析活動等
3. 測試工程師根據測試需求定義測試策略，進行工作量估計
4. 總體測試工作量估計并進行測試任務分配
5. 系統測試計劃評審
6. 根據系統測試計劃中的要求搭建測試環境
7. 設計測試用例
8. 系統測試用例評審
9. 定義系統用例執行過程，并更新系統測試用例
10. 執行系統測試并記錄測試結果

系統測試的設計：

• 用戶層：面向產品最終的使用操作者的測試
• 應用層：針對產品工程應用或行業應用的測試
• 功能層：針對產品具體功能實現的測試
• 子系統層：針對產品內部結構性能的測試
• 協議/指標層：針對系統支持的協議、指標的測試

常見的系統測試方法：

• 恢復測試

  用來檢查系統的容錯能力。通過對軟件的非法處理，使其不能正常工作，從而檢驗系統的恢復能力

• 安全測試

  檢測系統對外界非法入侵的防范能力

• 強度測試

  檢測程序對異常情況的抵抗能力

• 性能測試

  測試軟件在系統運行時的性能表現

• 容量測試

  在系統正常運行的范圍內測定系統能夠處理的數據容量

• 正確性測試

  檢測軟件的各項功能是否符合產品規格說明的要求

  主要包括：枚舉法、邊界值法

• 可靠性測試

  檢測系統的可靠性是否達到預期目標的測試方法

• 兼容性測試

  指軟件在特定的硬件平臺上、不同的應用軟件之間、不同的操作系統平臺上、不同網絡等環境中是否能夠很好運行

• web測試

  不同廠商、不同版本的瀏覽器對某些構建和設置的適應性

驗收測試

驗收測試是軟件開發結束后，用戶對軟件投入實際應用前進行的最后一次質量檢驗活動

軟件驗收測試應該完成的內容：

• 規定驗收通過的標準
• 確定測試方法
• 決定驗收測試的組織機構和可利用資源
• 選定測試結果分析方法
• 指定驗收測試計劃并評審
• 設計驗收測試的測試用例
• 審查驗收測試的準備工作
• 執行驗收測試
• 分析測試結果
• 得出測試結論，明確驗收結果

驗收測試的常用策略：

• 正式驗收測試

  是系統測試的延續

• 非正式驗收測試(Alpha測試)

  測試步驟和內容由測試人員決定

• Beta測試

  Beta測試是所有測試中最主觀的

驗收測試可以分為兩大部分：軟件配置審查、可執行程序測試

白盒測試

白盒測試側重于分析內部結構是否合理，以及設計測試用例來檢驗產品內部操作是否按照規格說明書正確執行

白盒測試可以分為：靜態測試和動態測試

靜態測試：不在計算機上執行程序，以人工模擬技術或使用測試軟件對軟件進行分析和測試

• 靜態結構分析
• 靜態質量度量
• 代碼檢查方法
• ...

動態測試：設計一系列的測試用例，動態地運行程序，以發現程序中的缺陷

• 邏輯覆蓋
• 路徑測試
• ...

邏輯覆蓋測試

邏輯覆蓋測試通過對程序的邏輯結構的遍歷實現程序的覆蓋

覆蓋率是度量測試完整性的一個手段，是測試有效性的度量。

覆蓋率計算公式：

測試覆蓋可以分為：

• 語句覆蓋

  每條可執行語句至少被執行一次

  不能發現邏輯錯誤

• 判斷覆蓋(分支覆蓋)

  被測程序中的每個判斷的"真"、"假"分支至少被執行一次

• 條件覆蓋

  被測程序中的每判斷語句中的每個邏輯條件的可能值至少被滿足一次

• 判斷/條件覆蓋

  被測程序中的每個判斷本身的判定結果至少滿足一次，同時，每個邏輯條件的可能指也至少被滿足一次

• 條件組合覆蓋

  被測程序中的每個判斷的所有可能條件取值的組合至少被滿足一次

  不同的判斷語句內的條件取值之間無需組合

  條件組合只針對同一個判斷語句內存在多個條件的情況

• 路徑覆蓋

  被測程序中的每條路徑至少被覆蓋一次

路徑分析測試

常見的路徑覆蓋方法：獨立路徑選擇和Z路徑覆蓋

控制流圖是對程序流程圖的簡化

控制流圖的特點：

• 具有唯一的入口結點
• 具有唯一的出口結點
• 結點由帶有標號的圓圈表示；包含條件的結點被稱為判定結點
• 控制流線由帶箭頭的直線或弧表示

環型復雜度是描述程序邏輯復雜度的軟件度量，適用于獨立路徑方法，是確保程序中每個可執行語句至少執行一次所必須的測試用例數目的上限

對于控制流圖G，設其環型復雜度為V(G)，常見的計算方法：

1. \(V(G) = E - N + 2\) E是邊的數量，N是結點的數目
2. \(V(G) = P + 1\) P是判定結點的數目
3. \(V(G) = A\) A是區域的數目

由邊和結點圍成的區域叫做區域，控制流圖外的區域也作為一個區域

獨立路徑測試

一條獨立路徑是至少包含有一條在其他獨立路徑中從未有過的邊的路徑

獨立路徑測試的步驟：

1. 到處程序控制流圖
2. 求出程序環型復雜度
3. 設計測試用例

如果程序中的條件判斷表達式是由一個或多個邏輯運算符連接的復合表達式，則需要變換為一系列只有單個條件的復合表達式，需要變換為一系列只有單個條件的嵌套的判斷

Z路徑覆蓋測試

采用簡化循環方法的路徑覆蓋。不考慮循環的執行次數，只考慮通過循環體0次和1次。即將循環結構轉變為選擇結構

循環測試

著重循環結構有效性測試的白盒測試方法

循環結構測試用例的設計有4種模式：

• 簡單循環

  測試集的幾種情況：

  1. 零次循環：跳過循環體
  2. 通過一次循環體：檢查循環初始值
  3. 通過兩次循環體：檢查兩次循環
  4. m次通過循環體：檢查多次循環
  5. n-1,n,n+1次通過循環體：檢查最大次數循環以及比最大次數多一次，、少一次的循環

• 嵌套循環

  1. 對最內層按照簡單循環的測試方法，把其他外層循環設置為最小值
  2. 逐步外推，對其外面一層的循環進行測試。保持本次循環的所有外層循環仍取最小值
  3. 反復進行(b)中操作，向外層推進，直到所有各層循環測試完畢

• 串接循環

  如果彼此獨立，則采用簡單循環；否則采用嵌套循環

• 非結構循環

  需要重新設計結構化程序

代碼檢查法

主要檢查代碼和設計的一致性，代碼對標準的遵循、可讀性，代碼邏輯表達的正確性，代碼結構的合理性等

代碼審查

代碼審查的步驟

1. 計劃
2. 概述
3. 準備
4. 審查會議
5. 審查報告
6. 返工
7. 跟進

代碼審查的特點：

• 專注于缺陷的檢測
• 參與者有明確的角色
• 主持人不能是產品的作者
• 參與者需要做出相應的準備
• 高層管理人員不參加審查會議
• 檢查單關注的是審查者過去所遇到的問題

桌面檢查

通過對源程序代碼進行分析、檢驗來發現程序中的錯誤。桌面檢查關注的是變量的值和程序邏輯

代碼走查

和代碼審查類似，只是在會議進程上有所區別。

代碼走查中，由測試者為所測程序準備一批代表性的測試用例，由參與者扮演計算機的角色，讓測試用例按照代碼邏輯運行，記錄程序的狀態

白盒測試綜合策略

• 應盡量先用測試工具進行靜態結構分析
• 采取先靜態后動態的組合方式
• 利用靜態分析的結果引導動態測試
• 覆蓋率測試是白盒測試的重點，一般采用獨立路徑測試達到語句覆蓋標準
• 不同測試階段，測試的側重點不同。單元測試：代碼檢查、邏輯覆蓋；集成測試：靜態結構分析、靜態質量度量；系統測試：根據黑盒測試結果采取對應的白盒測試

使用N-S圖表示基本的控制結構可以用于計算最少測試用例數

測試覆蓋準則

1. Foster的ESTCA覆蓋準則
2. Woodward等人的層次LCSAJ覆蓋準則

黑盒測試

又稱為功能測試或數據驅動測試，主要從用戶的觀點出發，以軟件規格說明書為依據，著重測試軟件的功能需求，對程序功能和程序接口進行測試

黑盒測試的兩種基本方法

• 通過測試

  確認軟件能做什么，不會去考驗能力如何

• 失敗測試

  為了破壞軟件而設計和執行的測試用例

常見黑盒測試方法：

• 等價類劃分
• 邊界值分析
• 決策表
• 因果圖

等價類劃分法

把所有可能的輸入數據劃分為若干部分，對每個部分中選取具有代表性的數據作為測試用例

有效等價類：對軟件規格說明書來說，合理、有意義的輸入數據所構成的集合

無效等價類：不滿足程序輸入要求或無效的輸入數據所構成的集合

劃分等價類的幾個原則：

• 如果規定了輸入條件的取值范圍或者個數，則可以確定一個有效等價類和兩個無效等價類
• 如果規定了輸入值的集合，則可以確定一個有效等價類和一個無效等價類
• 如果規定了輸入數據的一組值，并且程序要對每一個輸入值分別進行處理，則可為每一個值確定一個有效等價類，所有不允許的輸入值的集合為無效等價類
• 如果規定里輸入數據必須遵守的規則，則可以確定一個有效等價類和若干個無效等價類
• 如果已知的等價類中各個元素在程序中的處理方式不同，則應將該等價類進一步劃分

劃分等價類的標準：

• 完備性
• 無冗余性

針對是否對無效數據進行測試，將等價類測試分為

• 標準等價類測試

  不考慮無效數據，測試用例使用每個等價類中的一個值

• 健壯等價類測試

  考慮無效數據，對于有效數據，測試用例從每個有效等價類中取一個值；對無效數據，一個測試用例有一個無效值，其他值均為有效值

邊界值分析法

邊界值分析法的測試用例來自于等價類的邊界，是一種補充等價類劃分的測試用例設計技術

應用邊界值分析法設計測試用例時，應遵循以下原則：

• 如果輸入條件規定了值的范圍，則應該選取剛達到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作為測試輸入數據
• 如果輸入條件規定了值的個數，則用最大個數、最小個數、比最小數多1、比最大數少1的數作為測試數據
• 根據規格說明的每一個輸出條件，分別使用以上兩個原則
• 如果程序的規格說明給出的輸入與或者輸出域時有序集合，則應選取集合的第一個元組和最后一個元素作為測試用例
• 如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界值作為測試用例

決策表法

用于分析和表達多個邏輯條件下執行不同操作情況

決策表由四部分組成：

• 條件樁：列出來問題的所有條件
• 動作樁：列出來問題規定的可能采取的操作
• 條件項：針對條件樁給出的條件列出所有可能的取值
• 動作項：列出條件項的各組取值情況下應該采取的動作

任何一個條件組合的特定取值及其相應要執行的操作稱為一條規則，在決策表中貫穿條件項和動作項的一列就是一條規則。

建立決策表的步驟：

1. 確定規則的個數
2. 列出搜有的條件樁和動作樁
3. 填入條件項
4. 填入動作項
5. 化簡

決策表適用于：

• 規格說明以決策表形式給出
• 條件或規則的排列順序不會也不應影響執行哪些操作
• 每當某一規則的條件滿足，并確定要執行的操作后，不必檢驗別的規則
• 如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要

因果圖法

利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，適用于檢查程序輸入條件的各種情況的組合

講解

各種測試方法選擇的綜合策略

• 進行等價類劃分，包括輸入條件和輸出條件的等價類劃分，將無限測試變成有限測試
• 在任何情況下都必須使用邊界值分析法
• 采用錯誤推測法再最佳測試用例
• 對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度
• 如果程序的功能說明中含有輸入條件的足額和情況，應再一開始就選用因果圖法

軟件測試計劃

軟件測試計劃(STP)是描述對計算機軟件配置，系統或子系統進行合格性測試的計劃安排，內容包括進行測試的環境、測試工作的標識及測試工作的時間安排等

測試計劃的內容：

• 測試目的
• 測試范圍
• 測試對象
• 測試策略
• 測試任務
• 測試用例
• 資源配置
• 測試結果分析
• 度量及測試風險評估

軟件測試計劃是整個軟件測試流程工作的基本依據，測試計劃中所列條目在實際測試中必須一一執行

軟件測試計劃的目的是明確測試活動的意圖，規范了軟件測試內容、方法和過程，為有組織地完成測試任務提供保障

軟件測試計劃的主要作用：明確測試內容、測試完成時間、測試資源、測試風險、測試方法和過程

測試計劃的編制原則：

1. 明確測試目標，增強測試計劃的實用性
2. 堅持5W規則，明確測試的內容與過程
3. 采用評審和更新機制，保證測試計劃滿足實際需求
4. 分別創建測試計劃與測試詳細規格、測試用例

測試過程實施所必備的核心文檔是：測試計劃、測試用例和軟件測試報告

測試用例

測試用例是對一項特定的軟件產品進行測試任務描述，體現測試方案、方法、技術和策略

測試用例的內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔

一個完整有效的測試用例應該具備的特點有：

• 覆蓋率100%
• 對測試環境，用戶環境，模擬用戶環境，以及之間差別的描述
• 設計場景測試法虛擬業務流程
• 建立測試公共數據，并根據系統內部關系組織數據的關聯性
• 測試用例可執行
• 如果有標準的模板，使用用例模板

[Y]表示測試結果全部通過

自動化測試

主要是通過所開發的軟件測試工具、腳本呢等來實現，具有良好的可操作性、可重復性和高效率等特點

測試的自動化部分在于測試過程自動化或測試結果分析自動化

手動測試的目的著重于發現新的軟件故障

自動化測試的目的著重于發現舊的軟件故障

自動化測試有點：

• 對程序的新版本運行回歸測試

  回歸測試：在新版本中存在和舊版本相似的功能，可以復用舊版本的測試

• 可以運行更多更頻繁的測試

• 可以進行一些手工測試難以完成的任務

自動化測試的適用情況：

• 回歸測試
• 設計大量不同數據輸入的功能測試
• 用手工完成難度較大的測試，如性能測試

自動化測試方法：

1. 代碼分析

2. 捕獲和回放

   捕獲：記錄用戶每一步操作并轉換為腳本

   回放：將腳本轉換為用戶的操作

3. 腳本技術

   • 線性腳本

   • 結構化腳本

   • 共享腳本

     某個腳本可以被多個測試用例使用

   • 數據驅動腳本

   • 關鍵字驅動腳本

自動化測試過程

1. 自動化測試需求分析
2. 自動化測試框架的搭建
3. 腳本的編寫
4. 腳本的測試與試運行

自動化測試工具

• 白盒測試工具

  1. 靜態測試工具

     Logiscope、PRQA

  2. 動態測試工具

     DevPartner、Purify

  工具名	支持語言
  Jtest	Java
  Jcontract	Java
  C++Test	c/c++
  Code Wizard	c/c++
  Insure++	c/c++
  .test	.Net
  BiundChecker	c++, Delphi
  TrueTime	c++,java,VB
  Failsafe	VB
  TrueCoverage	c++,java,VB
  CodeReview	VB
  Jcheck	MS Visual J++

• 黑盒測試工具

  主要包括功能測試工具、負載測試工具、性能測試工具

  工具名
  WinRunner
  Astra Quick Test
  LoadRunner
  Robot
  Team Test
  QARun
  QALoad
  Silk Test
  Silk Performer
  e-Test
  e-Load
  WAS
  Webload
  OpenSTA

• 測試管理工具

  用于對測試進行管理。負責對測試計劃、測試用例、測試的實施進行管理

  TeamManager、TrackRecord、TestDirector