文／劉冉
今年是我做軟件測試的第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加入對于第三方依賴系統的契約測試或者監控測試，還需要使用測試數據生成系統參數，將各種測試數據存入數據庫系統用于支持契約測試等。
對于不同軟件系統，其架構一般都是根據業務需求、技術能力等各種條件來設計的。與軟件架構一樣，測試策略和測試架構在不同的項目里面，需要根據其軟件系統的架構、技術棧、業務需求、人員的技能等因素來定制和設計。
再談測試策略
現在業界流行的測試金字塔和測試象限只是兩種高度抽象和簡化的測試策略模型，不具備實際可操作性，只具備高層次的指導性和參考性。直接根據這兩個模型來工作是低效的，甚至可能帶來負面效果。所以對于測試金字塔和測試象限不能盲目的使用，而是需要根據項目的實際情況來生成適合自己項目的測試策略和測試架構，并在此基礎上執行真實的測試工作。
擴展閱讀：
http://www.infoq.com/cn/articles/an-effective-test-strategy
http://www.testingexcellence.com/test-strategy-and-test-plan/
更多精彩洞見，請關注微信公眾號：思特沃克
京公網安備 11010502049343號