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

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

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

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

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

再談測試策略

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

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