文／劉冉
今年是我做軟體測試的第7個年頭了，當年我從軟體開發轉做軟體測試的時候，沒有想過我能在這個領域做這麼久。
在這7年裡面，我在軟體測試領域摸爬滾打，從自動測試起步，逐步接觸到軟體測試的各個領域：各種測試方法（等價類，全配對等）、測試技術（單元測試，功能測試，效能測試，探索性測試等）、自動化測試工具（JUnit，Selenium，Gatling，ZAP等）、測試流程（傳統測試流程，敏捷測試流程等）以及測試策略（測試象限和測試金字塔等）。
其中“測試策略”在測試業界是討論的比較少的，因為大多數人的工作重點是設計測試用例，執行測試或者開發和維護自動化測試，而只有少部分人才會涉及到測試策略的工作，從而導致很多測試人員其實並沒有系統的瞭解測試策略。
所以我準備將我這幾年對於測試策略的經驗、總結以及思考以系列文章的形式寫出來，希望能稍微幫助一下大家去理解測試策略，從而做到更好的測試，減少缺陷，提高質量。
測試策略
首先來看一下Wikipedia上對於測試策略的定義：
A test strategy is an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.
Test strategies describe how the product risks of the stakeholders are mitigated at the test-level, which types of testing are to be performed, and which entry and exit criteria apply. They are created based on development design documents. System design documents are primarily used and occasionally, conceptual design documents may be referred to. Design documents describe the functionality of the software to be enabled in the upcoming release. For every stage of development design, a corresponding test strategy should be created to test the new feature sets.
更多內容詳見：https://en.wikipedia.org/wiki/Test_strategy
所以測試策略（Test Strategy）的第一目標就是“減少缺陷的出現和釋出”。其中“減少缺陷的出現”可以通過測試前移等方法來解決，在進行軟體需求分析和架構設計的時候發現缺陷；而“減少缺陷釋出”可以使用各種測試方法、技術來驗證和測試編碼完成的功能（這兩點在今後的文章裡面會通過不同的例子進行更詳細的闡述）。
由此可見，“測試策略”並不是只由測試人員定製的，它是由一個團隊的各個角色一起來制定和建立的，目的是保證軟體的質量，減少缺陷。
而“測試計劃”是用於實施測試策略的。只有充分理解測試策略目的和實施方式，才能充分理解測試策略，為什麼要做測試策略，什麼樣的測試策略才更有意義、更好，怎樣實施才能更有效等問題。
測試計劃
測試計劃在Wikipedia中是這樣定義的：
A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from test engineers.
更多內容詳見：https://en.wikipedia.org/wiki/Test_plan
制定測試計劃是保證測試策略能被有效執行的一種方式。它告訴了團隊在什麼階段，什麼樣的角色應該執行測試策略中什麼樣測試技術和測試方法。它主要由測試人員編寫，但是應該由整個團隊進行評審，因為開發人員、產品經理、業務分析人員甚至使用者都可能參與到測試計劃的執行中。
測試計劃是可以根據專案的實際進展情況進行調整的，所以它並不是一成不變的。
測試架構
在上個世紀六七十年代軟體系統還處於小規模的時候，軟體開發並沒有談什麼架構，軟體測試也不存在什麼策略可言。但是隨著軟體規模的極速增大，複雜性也成指數級增加，專業的軟體架構應運而生。
為了有效的在規定時間內完成複雜軟體系統的測試，必須有一個指導性的策略來幫助團隊理解、選擇和組織大量的測試，因此軟體測試策略就出現了。而測試策略往往是高層次的指導，對於一些中小型專案也許已經足夠了，但是卻不足以應付現代越來越複雜的軟體系統。
因為隨著微服務、移動網際網路、物聯網、大資料分析系統、AI系統等的出現，要測試一個包含各種技術，外部依賴，或者獨立子系統的複雜系統，並不是簡單的根據測試策略在不同層面上做不同的測試就可以了，而是要理清各種測試之間的相互聯絡和制約，然後思考怎麼有效的將各個維度上的測試聯絡起來，以軟體系統架構的思維去思考整個測試體系。
請注意這裡不是說要去設計一套全自動化的測試系統來完成整個系統的所有測試，而是通個各種有效的方式（無論手動還是自動）把各種測試合理且有效的聯絡起來，形成一個擁有完整架構的測試體系，這樣才能使整個系統的各種測試更加視覺化和更易於理解，使整個系統的各種測試更加有效，避免重複測試，節約成本。
舉例來說，一個前後端分離的Web業務系統不僅有前端UI和大量的JavaScirpt程式碼，還有後端的API和第三方依賴系統以及資料庫系統，如何將各層測試有效的聯絡起來就是測試架構需要解決的問題。
首先，前端、後端API、第三方依賴系統和資料庫系統有各自的單元測試、整合測試等，然後可以使用契約測試來測試統一前端和後端API，再使用Stub加入對於第三方依賴系統的契約測試或者監控測試，還需要使用測試資料生成系統引數，將各種測試資料存入資料庫系統用於支援契約測試等。
對於不同軟體系統，其架構一般都是根據業務需求、技術能力等各種條件來設計的。與軟體架構一樣，測試策略和測試架構在不同的專案裡面，需要根據其軟體系統的架構、技術棧、業務需求、人員的技能等因素來定製和設計。
再談測試策略
現在業界流行的測試金字塔和測試象限只是兩種高度抽象和簡化的測試策略模型，不具備實際可操作性，只具備高層次的指導性和參考性。直接根據這兩個模型來工作是低效的，甚至可能帶來負面效果。所以對於測試金字塔和測試象限不能盲目的使用，而是需要根據專案的實際情況來生成適合自己專案的測試策略和測試架構（專案不需要測試架構），並在此基礎上執行真實的測試工作。
擴充套件閱讀：