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

眾所周知，“架構(gòu)（architecture）”一詞來源于建筑，具有 “建筑學(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)系，而且是通過接口連接起來，以降低系統(tǒng)的耦合性。如果需要提升系統(tǒng)的可靠性，系統(tǒng)還要增加冗余組件。

軟件架構(gòu)也是項(xiàng)目早期必須做出的設(shè)計(jì)決策，即從體系結(jié)構(gòu)的角度思考軟件的核心組成、決定什么是重要的，并能使這些體系結(jié)構(gòu)元素處于良好的狀態(tài)。而軟件架構(gòu)師是能夠識別哪些元素是重要的，能識別出哪些元素不加以控制，可能會(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ì)是非常重要的。

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

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

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

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

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

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

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

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

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

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

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

圖4敏捷測試過程模型

審核編輯 ：李倩