測試模型無處不在，你只有真正理解了“什么是測試架構”、擁有了測試建模能力，才能成為名副其實的測試架構師。

眾所周知，“架構（architecture）”一詞來源于建筑，具有 “建筑學、體系結構” 等含義。建筑學的內涵要比體系結構豐富得多，但其核心往往關注其造型和體系結構的設計，綜合考慮環(huán)境需求和使用者的需求，進行空間上合理的功能分配，滿足安全、經濟、適用、美觀等需求，達到人和環(huán)境的和諧。

軟件體系架構是一個比喻(或稱之為“系統(tǒng)隱喻”)，類似于建筑物的體系結構，主要指軟件系統(tǒng)的基本結構及其設計規(guī)范，軟件體系架構包括軟件系統(tǒng)構成元素及其之間的關系、元素和關系的特性等。例如，一個系統(tǒng)由數據層、數據訪問層、服務層、業(yè)務邏輯層、展示層等組成，每個層次都是系統(tǒng)的構成元素，各個元素之間不僅有層次關系，而且是通過接口連接起來，以降低系統(tǒng)的耦合性。如果需要提升系統(tǒng)的可靠性，系統(tǒng)還要增加冗余組件。

軟件架構也是項目早期必須做出的設計決策，即從體系結構的角度思考軟件的核心組成、決定什么是重要的，并能使這些體系結構元素處于良好的狀態(tài)。而軟件架構師是能夠識別哪些元素是重要的，能識別出哪些元素不加以控制，可能會導致嚴重的問題。如果在軟件開發(fā)早期沒有做出基本結構的正確選擇或設計出良好的結構，后續(xù)軟件系統(tǒng)會存在某些質量問題而不得不進行修改，而且這種修改會付出高昂的代價，導致功能的實現更慢、缺陷也更多。所以，軟件架構及其設計是非常重要的。

那么軟件測試中存在架構或基本結構嗎？即軟件測試中是否存在一些測試元素及其關系，我們需要研究這些元素、關系，從而能提高測試的效率和質量？其實是存在的，其中一個顯著的例子就是自動化測試框架或測試平臺的架構，如圖1案例所示，雖然它基本符合軟件架構的特性，但同時也要滿足軟件測試的特定需求。所以，軟件測試平臺的架構不能單單看作是一類通用的軟件架構。

圖1阿里云測試平臺架構TestMaster示意圖 除了自動化測試平臺之外，面對一個具體的測試項目，也存在著一系列的測試建模：

測試需求建模（有時也包含了測試設計）——眾所周知的基于模型的測試方法（MBT）,如相對簡單的分類樹、黒盒測試方法（如圖2所示）、因果圖、狀態(tài)樹、有限狀態(tài)機等，以及更復雜的建模，符號執(zhí)行、模型檢驗等，如圖3所示；

測試方案的設計，包含著如何識別出測試項、測試風險、測試方法等眾多測試元素，以及確定它們之間的關系；

測試用例的結構，如在基于腳本測試中，如何分解測試目標、如何構建測試集（test suite）、如何組織好測試用例（含層次劃分）等。

探索式測試的設計，如何將測試目標分解為Mission，再將Mission分解為Session。

自動化測試腳本的設計，如何對測試腳本的封裝、層次劃分等。

圖2黑盒測試方法抽象為模型

圖3符號執(zhí)行模型示意圖

軟件測試離不開業(yè)務、更離不開開發(fā)，軟件測試團隊或相關人員需要和業(yè)務架構師（或業(yè)務分析人員）、產品經理和軟件開發(fā)架構師進行溝通，參與需求評審和（技術架構和功能結構、UI等）設計評審，理解業(yè)務架構、產品結構和技術架構等（如果不了解這些內容，不要急，后續(xù)有詳細討論），從而更好地設計出測試方案，更有效地進行測試，如分層測試、精準測試、契約測試等都有測試建模的影子。這里也不僅僅是功能測試，還有性能測試、安全性測試和可靠性測試，像這些專項測試的結果分析，需要對系統(tǒng)的技術結構、產品結構有很深的理解，才能完成缺陷的分析與定位。更重要的是，一些非功能性的缺陷，甚至在技術架構設計評審時就能發(fā)現問題，而且這時修復設計缺陷的成本，會遠遠低于在系統(tǒng)的專項測試之后的修復成本。

測試模型進一步延伸，可以延伸到測試過程建模，如W模型、TMap等，這里給出敏捷測試的過程模型，如圖4所示。

圖4敏捷測試過程模型

審核編輯 ：李倩