開發轉測試七年，我從測試策略到測試架構

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

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

其中「測試策略」在測試業界是討論的比較少的，由於大多數人的工做重點是設計測試用例，執行測試或者開發和維護自動化測試，而只有少部分人才會涉及到測試策略的工做，從而致使不少測試人員其實並無系統的瞭解測試策略。

因此我準備將我這幾年對於測試策略的經驗、總結以及思考以系列文章的形式寫出來，但願能稍微幫助一下你們去理解測試策略，從而作到更好的測試，減小缺陷，提升質量。

測試策略

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

因而可知，「測試策略」並非只由測試人員定製的，它是由一個團隊的各個角色一塊兒來制定和創建的，目的是保證軟件的質量，減小缺陷。

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

測試計劃

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

測試計劃是能夠根據項目的實際進展狀況進行調整的，因此它並非一成不變的。

測試架構

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

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

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

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

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

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

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

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

再談測試策略

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