1.1測試策略和計劃
在制定測試策略時，要基于被測軟件的質量目標。質量目標就是測試的需求。它們決定了測試的階段和質量的目標。要想最優化測試的活動并制定一個切實可行的測 試計劃，需要將被測軟件分解成為一個一個的業務功能。在進行業務功能分解時，要以黑盒的方法來看待被測軟件的功能，即獨立于軟件的實現方法。若想計算測試 的效果并且保證測試的活動適合于特定業務的需要，則需要引入風險評估的手段。
1.1.1 需求
測試的必要條件是要確定預期結果或者需求。為了能更好的了解需求，將需求進行分類是非常有幫助的。以我們的觀點，可以將需求分為功能性需求和質量需求（非功能性需求）。功能性需求描述了在業務上期望如何使用新的軟件系統，且該系統中應該包括哪些功能。質量需求包括的是軟件系統的通用特性，且獨立于功能。
1.1.1.1 功能性需求
功能性需求以業務設計圖的方式記錄于文檔中。為了在TestDirector中將需求作為測試的基礎，需要將需求導入到TestDirector中。相應的業務設計圖作為需求的附件存在，并作為將來測試活動的依據。
1.1.1.2 質量需求
質量需求由兩部分構成，一部分是為整個產品或者項目定義的質量目標，另一部分是每個業務功能的質量需求，這些業務功能的質量需求取決于風險評估的結果。
1.1.1.2.1 質量目標
1）適應性
組件被修改以適應新需求的難易程度。
2）完整性
組件實現所有需要的能力的程度。
3）正確性
a) 組件在規格分析、設計和實現過程中無錯誤的程度
b) 組件滿足需求或者用戶需要與期望的程度
c) 基于給定輸入產生相應輸出的能力，并且這個過程符合或者滿足需求
4）有效性
當組件完成指定任務時，能最少使用所需資源的程度。
5）可維護性
組件被修改以糾正錯誤，提高性能或其他屬性，或者適應被改變了的環境的難易程度
6）模塊性
軟件系統由離散的組件組成的程度，即改變一個組件時能將對其他組件的影響降至最低。
7）可移植性
軟件系統或組件能被轉移到其他硬件平臺或者軟件平臺上的難易程度。
8）可靠性
組件在一定的時間內、一定的條件下執行所需完成功能的能力。
9）可用性
用戶對軟件組件的理解和操作的難易程度。
1.1.1.2.2 業務功能的質量需求
業務功能的質量需求是依據業務的風險進行定義的。業務風險和技術復雜度的信息存儲在測試的需求中。這兩個參數決定了測試的程序和測試的工作量。另外，針對業務功能分配測試員，并且將測試活動的當前狀態落實到紙面上。只有這樣做才能在針對業務功能的整個測試過程中監控測試的狀態。
1.1.2 測試階段的定義
依據已經定義的質量目標，我們需要將測試階段進行合理的劃分。
通常情況有以下幾個階段：
1）開發員自測試階段（不在我們的考慮范圍之內）
2）業務功能測試（單元測試）
3）業務流程測試（應用級的集成測試）
4）業務集成測試（端到端的集成測試）
5）性能測試
6）系統集成測試
下面的表中描述了每個測試階段需要達到的質量目標：
業務功能測試和業務流程測試是在軟件項目開發過程中完成的。而業務集成測試和系統集成測試則組合成回歸測試，用于軟件系統上線前或者發布為產品前來檢驗軟件的質量。
1.1.3 質量門
測試是在不同的階段中完成的。劃分不同階段的原因就是將不同的質量目標分配到不同的階段中，從而能將測試的執行盡可能的提前。所以，在相鄰的測試階段中設置一個質量門就成為保障成功的關鍵要素。
下面的圖中展示了每兩個相鄰階段的質量門是如何設定的：
下面是對質量門的一種詳細定義：
1）在業務功能測試之后
u 業務功能測試的測試用例執行了80%以上
u 業務功能測試的測試用例（A級風險）執行了100%
u 少于5個服務器端錯誤
u 少于30個中級錯誤
u 無致命性缺陷
2）在業務流程測試之后
u 業務功能測試通過
u 業務流程執行了100%
u 無業務流程完全失效，所有的錯誤都可以被修復
u 無致命性缺陷
3）在業務集成測試之后
u 業務流程測試通過
u 業務集成流程執行了100%
u 無致命性缺陷
1.1.4 功能分解
在計劃測試活動之前，功能分解應該作為第一個要完成的活動。進行功能分解時，應該邀請業務方面和需求分析方面的代表共同參加。通常情況下，要遵從下面的原則：
1) 每個用戶情形都是一個業務功能
2) 如果一組用戶情形非常相似，那它們應該組合在一起形成一個業務功能
3) 如果一個用戶情形非常大或者非常復雜，則應該將其分解為兩個或者更多的業務功能
進行功能分解的思路體現在“將測試的單元確定為包含少量功能點的單位”，這樣，每個測試單元的測試用例的數量就會被限制在一定的范圍之內。我們可以將分解的目標設定為每個業務功能只有最多30-40個測試用例。 既然質量保證的基本思路是降低缺陷破壞業務的風險，同時為了確保質量保證的資源得到充分的利用，我們需要對每個業務功能進行風險的評估。
1.1.5 風險評估
還要考慮到的是，我們也要對技術影響進行分析。這樣我們能對完成每個業務功能的測試活動所需的工作量進行估算。
1.1.5.1 業務風險分析
業務風險評估需要針對被測軟件的所有業務功能。評估的標準應該在整個業務的范圍內是唯一的，才能在企業范圍內使不同的評估結果具有可比性。
| 結果 標準 | A 高級風險 | B 中級風險 | C 低級風險 |
| 流程的類型 | 計算/驗證 | 數據的改變 | 顯示 |
| 業務影響 | 合法性 | 錯誤信息 | 無 |
| 使用頻度 | 非常頻繁 | 經常 | 極少 |
| 受影響客戶的數量 | 大量/非常重要 | |