測(cè)試模型無(wú)處不在，你只有真正理解了“什么是測(cè)試架構(gòu)”、擁有了測(cè)試建模能力，才能成為名副其實(shí)的測(cè)試架構(gòu)師。

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

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

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

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

圖1阿里云測(cè)試平臺(tái)架構(gòu)TestMaster示意圖 除了自動(dòng)化測(cè)試平臺(tái)之外，面對(duì)一個(gè)具體的測(cè)試項(xiàng)目，也存在著一系列的測(cè)試建模：

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

測(cè)試方案的設(shè)計(jì)，包含著如何識(shí)別出測(cè)試項(xiàng)、測(cè)試風(fēng)險(xiǎn)、測(cè)試方法等眾多測(cè)試元素，以及確定它們之間的關(guān)系；

測(cè)試用例的結(jié)構(gòu)，如在基于腳本測(cè)試中，如何分解測(cè)試目標(biāo)、如何構(gòu)建測(cè)試集（test suite）、如何組織好測(cè)試用例（含層次劃分）等。

探索式測(cè)試的設(shè)計(jì)，如何將測(cè)試目標(biāo)分解為Mission，再將Mission分解為Session。

自動(dòng)化測(cè)試腳本的設(shè)計(jì)，如何對(duì)測(cè)試腳本的封裝、層次劃分等。

圖2黑盒測(cè)試方法抽象為模型

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

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

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

圖4敏捷測(cè)試過程模型

審核編輯 ：李倩