開發轉測試七年，我從測試策略到測試架構（Test architecture）
程式員之間流傳著這樣一句順口溜：有人喜歡創造世界，他們做了開發者;有的人喜歡開發者，他們做了測試員。什麼是軟體測試?軟體測試就是一場本該在使用者面前發生的災難提前在自己面前發生了，這會讓他們生出一種救世主的感覺，拯救了使用者，也就拯救者這個軟體，避免了他們被解除安裝的命運。
今年是我做軟體測試的第7個年頭了，當年我從軟體開發轉做軟體測試的時候，沒有想過我能在這個領域做這麼久。在這7年裡面，我在軟體測試領域摸爬滾打，從自動測試起步，逐步接觸到軟體測試的各個領域：各種測試方法(等價類，全配對等)、測試技術(單元測試，功能測試，效能測試，探索性測試等)、自動化測試工具(JUnit，Selenium，Gatling，ZAP等)、測試流程(傳統測試流程，敏捷測試流程等)以及測試策略(測試象限和測試金字塔等)。
其中“測試策略”在測試業界是討論的比較少的，因為大多數人的工作重點是設計測試用例，執行測試或者開發和維護自動化測試，而只有少部分人才會涉及到測試策略的工作，從而導致很多測試人員其實並沒有系統的瞭解測試策略。
所以我準備將我這幾年對於測試策略的經驗、總結以及思考以系列文章的形式寫出來，希望能稍微幫助一下大家去理解測試策略，從而做到更好的測試，減少缺陷，提高質量。
測試策略
測試策略(Test Strategy)的第一目標就是“減少缺陷的出現和釋出”。其中“減少缺陷的出現”可以通過測試前移等方法來解決，在進行軟體需求分析和架構設計的時候發現缺陷;而“減少缺陷釋出”可以使用各種測試方法、技術來驗證和測試編碼完成的功能(這兩點在今後的文章裡面會通過不同的例子進行更詳細的闡述)。
由此可見，“測試策略”並不是只由測試人員定製的，它是由一個團隊的各個角色一起來制定和建立的，目的是保證軟體的質量，減少缺陷。
而“測試計劃”是用於實施測試策略的。只有充分理解測試策略目的和實施方式，才能充分理解測試策略，為什麼要做測試策略，什麼樣的測試策略才更有意義、更好，怎樣實施才能更有效等問題。
測試計劃
制定測試計劃是保證測試策略能被有效執行的一種方式。它告訴了團隊在什麼階段，什麼樣的角色應該執行測試策略中什麼樣測試技術和測試方法。它主要由測試人員編寫，但是應該由整個團隊進行評審，因為開發人員、產品經理、業務分析人員甚至使用者都可能參與到測試計劃的執行中。
測試計劃是可以根據專案的實際進展情況進行調整的，所以它並不是一成不變的。
測試架構
在上個世紀六七十年代軟體系統還處於小規模的時候，軟體開發並沒有談什麼架構，軟體測試也不存在什麼策略可言。但是隨著軟體規模的極速增大，複雜性也成指數級增加，專業的軟體架構應運而生。
為了有效的在規定時間內完成複雜軟體系統的測試，必須有一個指導性的策略來幫助團隊理解、選擇和組織大量的測試，因此軟體測試策略就出現了。而測試策略往往是高層次的指導，對於一些中小型專案也許已經足夠了，但是卻不足以應付現代越來越複雜的軟體系統。
因為隨著微服務、移動網際網路、物聯網、大資料分析系統、AI系統等的出現，要測試一個包含各種技術，外部依賴，或者獨立子系統的複雜系統，並不是簡單的根據測試策略在不同層面上做不同的測試就可以了，而是要理清各種測試之間的相互聯絡和制約，然後思考怎麼有效的將各個維度上的測試聯絡起來，以軟體系統架構的思維去思考整個測試體系。
請注意這裡不是說要去設計一套全自動化的測試系統來完成整個系統的所有測試，而是通個各種有效的方式(無論手動還是自動)把各種測試合理且有效的聯絡起來，形成一個擁有完整架構的測試體系，這樣才能使整個系統的各種測試更加視覺化和更易於理解，使整個系統的各種測試更加有效，避免重複測試，節約成本。
舉例來說，一個前後端分離的Web業務系統不僅有前端UI和大量的JavaScirpt程式碼，還有後端的API和第三方依賴系統以及資料庫系統，如何將各層測試有效的聯絡起來就是測試架構需要解決的問題。
首先，前端、後端API、第三方依賴系統和資料庫系統有各自的單元測試、整合測試等，然後可以使用契約測試來測試統一前端和後端API，再使用Stub加入對於第三方依賴系統的契約測試或者監控測試，還需要使用測試資料生成系統引數，將各種測試資料存入資料庫系統用於支援契約測試等。
如果對軟體測試、介面測試、自動化測試、效能測試、LR指令碼開發、面試經驗交流。感興趣可以175317069，群內會有不定期的發放免費的資料連結，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
對於不同軟體系統，其架構一般都是根據業務需求、技術能力等各種條件來設計的。與軟體架構一樣，測試策略和測試架構在不同的專案裡面，需要根據其軟體系統的架構、技術棧、業務需求、人員的技能等因素來定製和設計。
再談測試策略
現在業界流行的測試金字塔和測試象限只是兩種高度抽象和簡化的測試策略模型，不具備實際可操作性，只具備高層次的指導性和參考性。直接根據這兩個模型來工作是低效的，甚至可能帶來負面效果。所以對於測試金字塔和測試象限不能盲目的使用，而是需要根據專案的實際情況來生成適合自己專案的測試策略和測試架構(專案不需要測試架構)，並在此基礎上執行真實的測試工作。