程序員之間流傳着這樣一句順口溜：有人喜歡創造世界，他們做了開發者；有的人喜歡開發者，他們做了測試員。什麼是軟件測試？軟件測試就是一場本該在用戶面前發生的災難提前在自己面前發生了，這會讓他們生出一種救世主的感覺，拯救了用戶，也就拯救者這個軟件，避免了他們被卸載的命運。

今年是我做軟件測試的第7個年頭了，當年我從軟件開發轉做軟件測試的時候，沒有想過我能在這個領域做這麼久。在這7年裏面，我在軟件測試領域摸爬滾打，從自動測試起步，逐步接觸到軟件測試的各個領域：各種測試方法（等價類，全配對等）、測試技術（單元測試，功能測試，性能測試，探索性測試等）、自動化測試工具（JUnit，Selenium，Gatling，ZAP等）、測試流程（傳統測試流程，敏捷測試流程等）以及測試策略（測試象限和測試金字塔等）。

其中“測試策略”在測試業界是討論的比較少的，因爲大多數人的工作重點是設計測試用例，執行測試或者開發和維護自動化測試，而只有少部分人才會涉及到測試策略的工作，從而導致很多測試人員其實並沒有系統的瞭解測試策略。

所以我準備將我這幾年對於測試策略的經驗、總結以及思考以系列文章的形式寫出來，希望能稍微幫助一下大家去理解測試策略，從而做到更好的測試，減少缺陷，提高質量。

測試策略

測試策略（Test Strategy）的第一目標就是“減少缺陷的出現和發佈”。其中“減少缺陷的出現”可以通過測試前移等方法來解決，在進行軟件需求分析和架構設計的時候發現缺陷；而“減少缺陷發佈”可以使用各種測試方法、技術來驗證和測試編碼完成的功能（這兩點在今後的文章裏面會通過不同的例子進行更詳細的闡述）。

由此可見，“測試策略”並不是只由測試人員定製的，它是由一個團隊的各個角色一起來制定和建立的，目的是保證軟件的質量，減少缺陷。

而“測試計劃”是用於實施測試策略的。只有充分理解測試策略目的和實施方式，才能充分理解測試策略，爲什麼要做測試策略，什麼樣的測試策略才更有意義、更好，怎樣實施才能更有效等問題。

測試計劃

制定測試計劃是保證測試策略能被有效執行的一種方式。它告訴了團隊在什麼階段，什麼樣的角色應該執行測試策略中什麼樣測試技術和測試方法。它主要由測試人員編寫，但是應該由整個團隊進行評審，因爲開發人員、產品經理、業務分析人員甚至用戶都可能參與到測試計劃的執行中。

測試計劃是可以根據項目的實際進展情況進行調整的，所以它並不是一成不變的。

測試架構

在上個世紀六七十年代軟件系統還處於小規模的時候，軟件開發並沒有談什麼架構，軟件測試也不存在什麼策略可言。但是隨着軟件規模的極速增大，複雜性也成指數級增加，專業的軟件架構應運而生。

爲了有效的在規定時間內完成複雜軟件系統的測試，必須有一個指導性的策略來幫助團隊理解、選擇和組織大量的測試，因此軟件測試策略就出現了。而測試策略往往是高層次的指導，對於一些中小型項目也許已經足夠了，但是卻不足以應付現代越來越複雜的軟件系統。

因爲隨着微服務、移動互聯網、物聯網、大數據分析系統、AI系統等的出現，要測試一個包含各種技術，外部依賴，或者獨立子系統的複雜系統，並不是簡單的根據測試策略在不同層面上做不同的測試就可以了，而是要理清各種測試之間的相互聯繫和制約，然後思考怎麼有效的將各個維度上的測試聯繫起來，以軟件系統架構的思維去思考整個測試體系。

請注意這裏不是說要去設計一套全自動化的測試系統來完成整個系統的所有測試，而是通個各種有效的方式（無論手動還是自動）把各種測試合理且有效的聯繫起來，形成一個擁有完整架構的測試體系，這樣才能使整個系統的各種測試更加可視化和更易於理解，使整個系統的各種測試更加有效，避免重複測試，節約成本。

舉例來說，一個前後端分離的Web業務系統不僅有前端UI和大量的JavaScirpt代碼，還有後端的API和第三方依賴系統以及數據庫系統，如何將各層測試有效的聯繫起來就是測試架構需要解決的問題。

首先，前端、後端API、第三方依賴系統和數據庫系統有各自的單元測試、集成測試等，然後可以使用契約測試來測試統一前端和後端API，再使用Stub加入對於第三方依賴系統的契約測試或者監控測試，還需要使用測試數據生成系統參數，將各種測試數據存入數據庫系統用於支持契約測試等。

如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。

對於不同軟件系統，其架構一般都是根據業務需求、技術能力等各種條件來設計的。與軟件架構一樣，測試策略和測試架構在不同的項目裏面，需要根據其軟件系統的架構、技術棧、業務需求、人員的技能等因素來定製和設計。

再談測試策略

現在業界流行的測試金字塔和測試象限只是兩種高度抽象和簡化的測試策略模型，不具備實際可操作性，只具備高層次的指導性和參考性。直接根據這兩個模型來工作是低效的，甚至可能帶來負面效果。所以對於測試金字塔和測試象限不能盲目的使用，而是需要根據項目的實際情況來生成適合自己項目的測試策略和測試架構（項目不需要測試架構），並在此基礎上執行真實的測試工作。