導語

加入測試建模小組八個多月的時間，在日常的測試工作中，經常會有身邊的小夥伴們對我們的建模很好奇，會問“什麼是測試建模？”“為什麼要測試建模？”“建模能給我們帶來什麼好處？”“建模和我們現在的測試設計區別到底在哪裡？“等等諸如此類的問題。思來想去，實在有必要跟大家分享下自己對測試建模的一些想法，如有不正確的地方，歡迎指正。

一、為什麼要測試建模？

抽象是認知事物的一種關鍵途徑，是人類智慧的體現。比如，在立體幾何中，三維座標用於抽象世界空間（X+Y+Z）；在地理學中，地圖用於抽象生存空間（交通路線+標誌性建築+其它）；在生活中，身份證用於個人身份抽象（身份證號+照片）；在軟體工程中，類/結構體用於目標的抽象等。可以說，抽象是為了用少量的特徵或屬性來給物件打標籤，這些標籤要具體、可度量，且識別性強等。抽象這個詞大家都不陌生，那麼建模是什麼呢？我認為，建模是對目標進行的系統的、結構化的、多層次的和多視角的抽象。我們知道，軟體測試是一個複雜冗長的工作。我們是否能夠通過對待測試目標進行抽象和建模來指導我們的測試工作呢？下面我將從測試建模的必然性以及它的重要性兩個方面來闡述我們為什麼要測試建模。

1.1測試建模的必然性

當前的軟體測試它包括哪些方法呢？我覺得下面這張圖承載的內容非常的立體豐富，基本涵蓋了軟體測試的主要方法。軟體測試，它是一個系統工程。可以從單元測試到系統測試；可以從壓力測試到功能測試；從黑盒測試到白盒測試等。隨著軟體容量的擴增和軟體需求的變更，常用測試方法需要重新設計和增加測試用例，而一些特定用處的測試用例會變得越來越不重要，尤其是複雜系統的潛在問題會更加隱蔽，導致常用方法更加捉襟見肘了。

1常用的軟體測試方法

系統的規模越來越大，測試工作越來越複雜，工作量越來越繁重，如何減少測試過程的盲目性，提高測試過程的效率，基於模型的測試（Model-based testing, MBT），MBT應運而生。它具有科學性、系統性和指導性，為我們的思考、實踐和測試工作指明瞭方向。

2 MBT的特性

對於有測試工作經驗的人而言，它能激發你的頭腦風暴，鍛鍊你的思維方式，讓你高屋建瓴，有理有據；對於初次接觸測試的人而言，它能誘導你特異才華的展現，用一種不一樣的視角來看待軟體建模，給老司機們帶來驚喜。可以說，測試建模能夠挖掘出團隊和個人的潛能，讓大家能夠多層次、多視角來認識和量化待測試目標，從而更加系統科學地指導軟體測試工作。

1.2測試建模的重要性

通過對系統的行為（Behavior）進行抽象和建模，MBT能夠處理好常用方法的困難之處。一項調研統計發現，MBT能夠額外檢測出59%的Bugs，降低17%的測試費用並縮短25%的測試時間。它已經成為測試管理的一個重要參考依據。實際上，在設計測試用例之前，我們的頭腦中已經有一些需要面對的測試場景以及一些大致的測試思路，也可能有功能清單或某種圖表，或者會有誰是使用者、使用者關心什麼等一些初步概念。然而更重要的是，我們如何將這些測試思路或內容形成條理清晰、系統全面、分工明確的軟體測試文件和用例，以供測試評審和執行、Bug分析和修復等。此外，軟體測試涉及到的人，他們職能不同，視野高度不同，關注度不同，比如產品經理、開發人員、測試人員和終端使用者等等，因此，它需要涉及產品各個維度的質量驗證。

MBT體現了團隊和個人的專業素養、思維角度以及思考深度，能夠增強我們的推理能力，同時識別潛在的風險。它正成為測試工程師的基本技能要求。需要指出的是，MBT是為了更好的進行軟體測試，而不是為了撰寫儘量多的測試用例。下面，從主觀（人的角度）和客觀（產品的角度）角度來說明MBT的重要性。

1.2.1 –主觀角度

測試建模有利於個人認識被測物件
MBT有利於個人更系統全面地認識被測系統。針對被測系統，我們一般需要明確“5W”規則的內容：測試目的（Why），測試範圍和內容（What），測試時間範圍（When），測試方法和工具（What）以及測試文件和軟體的存放位置（Where）。在MBT情況下，Why體現在被測系統的抽象建模和初步驗證模型階段，What體現在可控地生成測試用例階段。如果對測試目的有疑問，需要及時溝通以校正個人或補充團隊對測試物件的認識；如果對測試方法和工具有疑問，那麼自我學習和技術交流就變得比較重要。對被測系統的深入認識，是個人合理有效執行測試用例的前提，也是團隊內和團隊間進行高效溝通的第一步。

測試建模有利於團隊合作和問題解決
針對同一被測系統，團隊內的我們由於能力和經驗的差異可能出現認識水平上的不一致。這種不一致可能體現在內部組會討論、測試任務分配以及上下級溝通等方面。然而，對被測系統進行多維度建模後，大家可以在指定的維度上進行有效溝通和討論。

團隊間的有效溝通在測試工作中非常重要，通常也非常困難。比如在軟體開發過程中，Bug的出現就將軟體測試介面人員與對應的開發人員聯絡在一起。基於MBT來梳理被測系統的內部邏輯和資料流情況，高效的跨角色、跨團隊和跨時間交流變得可能。

以上兩點也要求被測系統相關人員能夠在關注本職工作之餘，關注整體專案進展，從而瞭解本階段的重點關注內容，提前作好準備工作，使得自己在遇到問題時候能夠從容應對和團隊合作。

1.2.2–客觀角度

測試建模有利於系統高效的軟體測試
MBT是被測系統的抽象模型，它可以根據需要和專案進展而動態更新，而測試用例則可以根據實際需要自動生成（如U2TP, UML 2 Test Profile）。這就意味著，我們可以藉助專業工具來設計和自動生成測試用例，而我們的工作重心可以放在

（1）被測系統的多視角建模；

（2）MBT模型質量；

（3）MBT模型更新；

（4）自動化測試；

（5）風險評估；

以及（6）個人能力提升。

這樣，我們測試人員就可以變被動為主動，來關注專案進展和對應技能提升。

測試建模有利於客觀合理地度量測試進度
常用的軟體測試度量方法包括缺陷度量、測試用例深度、測試執行效率和測試覆蓋度等。這些度量方法能夠檢測到的缺陷是隨著時間的推進才能逐步發現的，而檢測到的bug可能是冰山一角。相對地，在建立被測系統模型後，MBT能夠通過程式碼覆蓋率（code coverage）、規範覆蓋率（specification coverage）或其它度量方法來生成測試用例的數量，更加客觀合理，也更加高效。

二、什麼是測試建模

2.1測試建模的概念

測試建模，我認為就是將測試思路或內容形成條理清晰、系統全面的模型而展開的測試（MBT）。這裡，需要對本文後面要論述的幾個專業名次進行說明。

SUT：System Under Test，被測系統模型，也稱類比模型。

TRM：Test Ready Model，測試準備模型，也稱分析模型。

2.2測試建模的方法

測試建模的方法從巨集觀上來看，主要分為SUT建模和TRM建模。從微觀上來看又派生了很多的模型。在實際工作中，我們拿到被測系統後，會在腦海裡進行瞬時畫像建模，也就是構建了心智模型。而從心智模型過渡到測試用例，中間過程的不同決定了不同的測試設計，如圖3所示。

MBT與其它測試設計的區別

路徑一（紅色箭頭）：從心智模型（Mental Model）直接得到測試用例（Ad-hoc Test Design，基於臨時需求）；

路徑二（黃色箭頭）：從心智模型得到TRM模型，再由TRM模型生成測試用例（TraditionalExploratory傳統測試設計）；

路徑三（藍色箭頭à紫色箭頭）：從心智模型到SUT模型，再由SUT模型生成測試用例（教科書式）；

路徑四（藍色箭頭）：從心智模型到SUT模型，再由SUT模型到TRM模型，最終由TRM模型生成測試用例（MBT）。

由上圖所示，MBT強調中間過程。特別說明的是，MBT是一個循序漸進、逐步完善的過程，需要將被測系統的各個方面進行考慮，在釋出週期之前形成完善的模型有利於整個產品的開發、測試和釋出等工作，如圖4所示。

MBT建模步驟

我們拿到被測需求後，首先會進行SUT抽象建模；分析需求進行TRM建模；初步模型驗證；基於模型可控地生成測試用例；優化並生成可執行測試用例。根據使用者關注重點的差異，第一步可以對被測系統進行功能建模，也可以進行使用者使用環境建模；第四步可以針對一些模式（Patterns）或測試特異性（Test specifications）來生成用例，也可以根據測試覆蓋率等軟體測試度量規則（Criteria）來生成測試用例。

2.2.1–SUT模型

SUT模型是心智模型（對產品的理解、設想和體驗）的外化（以及與現有模型的整合），是一種圖形化或形式化的類比模型。它涉及到不同的層次（如系統、元件和工作環境）、不同視角（如語境/上下文、元件與結構、功能、行為和使用者體驗）和不同關注點（如資料型別、因果關聯、程式結構、任務控制、動作、事件和介面）等。

5 SUT建模的語言及表示法

經過抽象、泛化和刪減後，SUT模型只保留有助於實現特定測試目的的特徵。在生成可執行測試用例前，SUT模型的例項化可能用到的技術（如圖5）包括Finite State Machine (FSM)，Message Sequence Chart (MSC)， Control FlowGraph (CFG)，Event Flow Diagram，MarkovChains和UML Testing Profile 等。圖5裡面的模型僅作為例項更多偏向區域性，實際SUT遠不止這些，如語法測試（SYNTAX TESTING），NLP（自然語言語義模型），此外還有從整體視角的HTSM和ACC等等。

2.2TRM模型

TRM模型是對SUT模型的擴充套件和轉化（參考圖3），以使模型達到可測試的標準；該模型也可獨立使用，即給出相關資訊，我們就可以設計或使用一套測試設計演算法，用來產生可以執行的測試用例。它根據SUT模型特徵和專案實際情況增加或凸顯質量風險資訊。必要時TRM需要建立新的模型，這是測試建模的主要難點之一，但也體現了我們價值所在。另外，它轉化SUT模型以達到可測試標準，並增加“怎麼測”的資訊，同時為SUT模型修改重構提供反饋。

由圖3可知，SUT和TRM模型有密切的關係，那麼它們的側重點有哪些區別呢？相對來說，SUT層次更高，更溫和，以描述被測物件為己任（更抽象）；而TRM更接地氣，更直接，以揭露風險為使命（更具體）。實踐中，TRM模型一般以發現SUT的潛在風險為導向。與SUT建模相比，TRM缺少現成的系統的方法論指導，缺少可參考借鑑的方法，更倚重經驗，卻缺少經驗積累（探索式測試提供了一些思路）。因此，TRM建模是目前研究探索的一個重點。

SUT TRM

1   描繪了測試物件 體現測試策略，如測什麼，測多少以及怎麼測？
2   系統思維    創造性思維
3   “面”（等價類、平均值）    “點”（邊界值）
4   構建為目的，重點關注可能產生質量風險的地方（know what）    直接為“破壞”/“攻擊”服務，關注如何揭露質量問題（know how）

三、怎樣展開測試建模

下面主要針對新手初次接觸測試建模，該如何展開進行舉例說明。

6測試建模輸入輸出

在實際測試過程中，我們拿到的輸入通常是需求說明書或是開發的實現程式碼等，經過測試人員的建模加工後，最終生成測試用例。針對需求分析從整體角度，我們往往會使用HTSM或ACC模型進行全域性系統化分析（二者選其一，針對具體的模型含義可以參考相關的資料有詳細的說明）；針對區域性分析我們會使用NLP分析深入理解被測需求（包括識別關鍵變數），基於NLP的分析結果再進行具體的模型構建，如業務流程圖、決策樹等等；接著，結合關鍵變數進行風險分析，完善模型；最終將模型通過自動化或手工方式轉換成用例。

由於篇幅所限，下面是我的一個小需求的實踐，看官們重點看思路哈。

需求描述如下

3.1需求理解

（本次需求無程式碼許可權，因此不涉及開發實現）

本需求比較小，屬於區域性需求，因此無需使用全域性模型。首先使用NLP（3點12要素）進行需求理解。

3.2依據需求特點進行SUT建模

依據NLP的分析，識別該需求的關鍵變數。

依據需求特點，該需求涉及多個屬性（變數）間存在不同的關係，對應有不同的規則，因此主要採用決策樹模型，輔助其它場景補充。

7 SUT建模

3.3SUT轉換TRM建模

8 TRM建模

3.4TRM模型轉換用例

決策樹轉換程決策表即是所得用例，關於決策樹轉換決策表的方法本文不贅述。特別需要注意的是，經過分析存在較多的重複驗證點，在轉換過程中剔除重複驗證點，如執行退出的case。

上述過程是為了說明MBT的過程以及美觀，實際工作中無需工具繪圖。

四、總結

也許最開始你總是在糾結測試建模和測試設計有什麼區別，一旦你習慣性使用測試建模去進行測試分析時，你會發現你的測試工作會變得更加有條不紊，有理有據。這就是測試建模真正給你帶來的幫助。它在潛移默化地讓你用科學系統化的方法論去指導自己開展測試工作，讓你的思維更加縝密而又細緻。MBT模型能夠根據被測系統的改變而更新，還能夠根據規則動態生成測試用例，尤其是它能夠抽象出複雜的被測系統的結構和內在邏輯，給我們多層面多維度地呈現被測系統。MBT將是未來軟體測試的一個重要方向。

模型種類繁多，不在於它好或是不好，對或是不對，而在於合不合適，在於使用它的人如何去用。各個模型好比烹飪時的各種調料，想做出什麼樣的佳餚憑君搭配選擇，當然也存在推薦，你可以選擇接受或是拒絕，烹飪出來的佳餚只要是你想要的，目的就達到了。

本文主要闡述了測試建模的趨勢，測試建模的概念以及測試建模的實踐，鑑於水平有限，若有理解欠妥的地方，歡迎指正。

測試建模的精髓大家get到了嗎？你在測試工作中克服複雜需求是如何展開測試分析的呢？

關注我們的微信公眾號檢視完整內容哦~~~~

想知道更多測試相關乾貨
請關注我們的微信公眾號：騰訊移動品質中心TMQ
二維碼：