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

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

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

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

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

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

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

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

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

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

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

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

圖3符號執行模型示意圖

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

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

圖4敏捷測試過程模型

審核編輯 ：李倩