3. H模型

3.1 H模型的提出和過程

• 真正的測試級別之間不存在嚴格的次序問題，各階段間可以反覆觸發、迭代、增量。

3.2 特點

• 將測試活動完全獨立成一個流程，測試貫穿了整個產品週期。
• 軟體測試不僅僅指測試的執行，還包含了其他活動(如：計畫、需求分析、案例設計、環境建置、提交缺陷、評估總結等)。
• 當某個測試時間點就緒時，測試即從準備階段進入到執行階段。
• 軟體測試是根據被測物的不同而分層次進行的，不同層次的測試活動可以是按照某個次序先後進行的，但也可能是反覆的。

4. 敏捷測試模型

4.1 極限編程

• 20世紀90年代Kent Beck設計了一種名為極限編程（Extreme programming，縮寫為XP）的新型軟體開發方式。

4.2 極限測試

• 為了滿足XP的流程和思想，開發人員使用了極限測試方法，該方法強調「連續」測試。
• 測試在XP中非常重要，所以需要先創建單元測試和驗收測試，才能創建程式庫(Code Base)，這種形式的測試稱為極限測試(Extreme Testing，縮寫為XT)
• XP模型需要客戶參與，高度依賴模組的單元和驗收測試。
  • 對於任何一個遞增的程式碼變更，開發人員都需要進行單元測試，以確保程式庫滿足其規格說明的要求。
  • 單元測試完成後，用戶進行驗收測試。

4.3 基於XP的項目步驟

1. 與客戶會談，確定產品需求並建立使用場景，後續將需求分解為獨立任務，並評估每個任務所需工時，提交任務清單與時間估計，並要求客戶產生一個功能優先級清單。
2. 根據規格說明，對其產生單元測試案例。
3. 在單元測試通過前不斷修改和重測程式碼，每天整合程式庫，並發布一個預覽版本。
4. 客戶進行驗收測試，確認該版本是否正確，或提交一份報告指出存在的缺陷、短版，開發人員在驗收測試成功的基礎上發布一個產品版本。
5. 開發人員根據最新的經驗更新時間估計。

4.4 敏捷測試的要點總結

• 敏捷測試是協同測試的另一種型態，開發人員結對編碼，並分是測試人員角色，敏捷測試是連續測試。
• 敏捷測試側重單元測試和驗收測試，單元測試的過程是先設計單元測試案例，然後進行開發，之後執行測試。

盡可能地去應用模型中對任務有實用價值的方面，但不強求的為使用而使用