川模型

出自 MBA智库百科(https://wiki.mbalib.com/)

　　川模型,是在學習借鑒了前輩們提出的X模型、H模型、前置測試模型等測試過程指導模型的基礎上,根據"以測試者引導開發,以文檔化把控質量"的測試實施理念和多年的工作經驗,作者提出了一款新的、更適合中國國情的軟體測試模型。

　　1）驗收測試實施流程

　　該流程提出的目的與重點在於保護用戶的真實需求，因為最終產品或項目能否成功交付，驗收結果是重要的依據，而驗收的主導者一定是用戶（代表）。該流程的起始階段就是在投入真正的研發和測試之前，根據項目需求及測試需求設計出驗收方案，以紙質方案的形式與用戶（代表）進行評審，以減少後期由於三方（用戶、研發、測試）需求不一致的原因導致開發迭代增加。同時，以此驗收方案為標尺，約束另兩個流程的實施。

　　2）需求級測試實施流程

　　該階段強調測試伴隨著整個軟體開發周期，測試與開發並行進行，達到儘早發現問題的目的。把測試的對象擴展成程式、設計(文檔資料)、數據等內容，測試工作實時準備，以達到在某個測試點準備就緒時，可迅速切入到測試執行階段。在該流程中，把迭代測試的內容進行了細緻的分析與說明，明確提出迭代過程中需要進行單元/集成測試、功能測試、自動化測試、安全性測試以及專項測試。把自動化測試與安全性測試提高到測試指導階段，也是當今科技發展的必然趨勢。

　　3）業務級測試實施流程

　　如果把測試人員按測試能力分為測試負責人、測試執行人員，那麼需求級測試實施階段的測試執行可以讓測試執行人員進行，但是業務級測試實施流程的主要執行人員就應該定位成測試負責人，至少應該是測試負責人主導測試。其根本原因在於該階段的意義是業務、風險等的把控，並且引入了探索性測試，是作為需求級測試階段的有利補充。

　　需求級測試實施流程與研發流程無縫有機結合。業務級測試實施流程存在的價值在於把控與掌握住了產品實際投入使用時的場景、風險等因素，對著重需求進行針對性的設計，滿足“八二法則”的經典理論，該流程即把重點放在了“二”上（用戶使用的80%的場景可能就存在於20%的功能中）。驗收測試實施流程依托於用戶的實際需求與前期的測試分析，它作為軟體生命周期的標尺，運行到產品或項目結項，最大程度上滿足用戶需求。

　　川模型突出體現了測試活動對質量把控的重要性。從項目的可行性分析開始，測試人員就擔負著重要的角色。同時，把測試需求說明書、驗收方案、測試方案的重要性與提出時機進行了說明。體現：

　　1）需求分析需要產品/項目經理、用戶、測試人員等全程參與；

　　2）測試需求說明書需要測試人員起草，由產品/項目經理、用戶、研發等共同審核通過；

　　3）驗收方案提前由測試人員編寫，由產品/項目經理、用戶共同審核通過；

　　4）研發設計階段主要依據測試需求說明書編寫（其次可參考軟體需求說明書），在還沒有進行完代碼開發之前，測試人員提前輸出依據測試需求說明書編寫的測試案例，由研發人員提前參考，提高研發依據測試案例開發代碼的測試通過率；

　　5）迭代階段大部分在需求級測試實施流程，測試工作實時準備，以便迅速切入測試執行；

　　6）業務級測試實施階段的執行工作是需求級的補充，在軟體研發的中後期無縫切入；

　　7）驗收執行的觸發點是業務級測試通過，驗收工作完成後，進行項目資料歸檔工作；

　　8）研發過程中，如果有任何變更，需走變更控制程式，返回測試需求分析階段，並根據實際情況與要害人員輸出變更後的系列資料（驗收方案、測試案例等）。

　　1）體現測試的使命與重要地位

　　在川模型上，可以很容易的看出測試工作對軟體質量的保證意義與實施方法。區別於其他模型，該模型更加清晰、系統的說明瞭測試的使命，並且該模型真正站到了測試的角色，以測試保證最終用戶質量的認可下指導研發的工作，作為研發工作的標尺。

　　2）體現測試先行的重要意義

　　從產品/項目的可行性分析開始，測試活動就一直伴隨整個生命周期，真正體現了“儘早地、不斷地進行軟體測試”的原則。

　　3）文檔化的重要性與可追溯性的提出

　　在現今越來越快的產品/項目的交互進程中，人們對文檔化的需求越來越迫切，文檔化不僅可以使研發、測試過程更加有理、有據、科學，也為以後的可追溯性提供了基礎。同時，產品/項目前期就對測試案例化的要求，對研發的指導意義更大，研發完全可以“依據測試案例設計軟體，案例通過即研發完成”的標準進行開發活動，避免了由於需求不一致的情況下導致研發冗餘或功能缺失，提高了工作效率。

　　4）提出三種測試技術相結合的規程

　　川模型第一次提出了三條執行線的工作模式。驗收實施流程作為整個產品/項目的指導流程執行，它與用戶最緊密相關，最能體現用戶的實際需求，同時避免、減少了在工作過程中的隨意變更；需求級實施流程則最有效的保證了測試覆蓋率，並且與研發的交互也更加順暢，提高了測試與研發迭代的敏捷度；業務級實施流程則通過有經驗的測試人員，把最重要需求做了風險、場景、探索等地設計驗證，可以這樣說，經過最後一條執行線的梳理後，用戶的實際並且經常使用的功能都被覆蓋到。

　　除了需求級實施流程與研發的交互緊密而充分外，另兩個流程相對獨立，降低了研發過程干擾，為保證軟體質量提供了有利基礎。

　　5）等時線為質量保證提供了基礎

　　該模型首次提出等時線的概念，在時序上，避免了工作重覆甚至沒有必要的交叉。正如該模型的約束，我們必須先進行測試需求分析，輸出測試需求說明書後，才可進行驗收測試設計；在驗收測試設計快完成時，才可以進行需求級測試設計，保證了測試設計與驗收標準的高度統一；業務級實施流程通過後，才可進行驗收執行工作。從另一層面，也對測試提出了更高的要求，例如在研發提交代碼之前，測試的準備工作必須完成，可隨時切入工作；有需求變更時，測試人員需要先後更新測試需求說明書、驗收方案、測試方案等內容，審核通過後，實時共用給要害人員，確保項目的順利進行。