從測試策略到測試架構(4)

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

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

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

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

再談測試策略

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

原文轉自：http://insights.thoughtworkers.org/from-strategy-to-architecture/