MBT測試思想在蘇寧蛙測的運用實踐分享

　　什麼是MBT測試設計?

　　MBT(Model based testing)中文名稱為基於模型的測試, 基於模型的測試屬於軟體測試領域的一種測試方法。

　　通常MBT的方法是需要搭配工具使用的，這樣在模型畫好的同時，可以自動生成對應的測試用例以及自動化指令碼。

　　MBT的測試設計理念，是基於需求的功能流程，然後進行建模，基於這個模型，才稱得上是測試需求。也就是說做MBT測試設計的前提是對需求和業務有深刻的認識。

　　為什麼要做MBT測試設計？

　　我們所熟悉的傳統測試設計方式主要分為等價類、邊界值、決策表、狀態轉換圖、決策樹、正交法等。傳統測試設計沒有一些工具的支援，主要依賴與測試人員的思考分析。

　　傳統測試設計流程

　　先介紹一下傳統測試設計的主要流程，測試人員首先進行需求評審後，這個過程是熟悉和了解需求的過程，然後開始進行測試設計，測試設計主要運用的方法是之前提到過的“等價類、邊界值、決策表、狀態轉換圖、決策樹、正交法等”，但是這些方法沒有現成的工具使用，通常情況測試人員需要用筆在紙上去畫一下，計算下場景組合，這些思考完成後，距離測試用例還有一段距離，此時測試人員會用在思維導圖軟體上把之前想到的場景列出來，之後再根據列出的場景逐一轉化成文字案例。

　　下面舉一個例子來說明一下：

　　以物流列印作業通知單功能為例，功能的場景為在採購入庫搜尋/列印頁面按照條件搜尋出條目點選列印操作。

　　·第一步業務梳理，該需求場景流程如下圖：

　　·第二步分析列印操作這步有哪些場景：

　　分析這步時需要依賴測試人員對需求的理解，對測試設計方法的運用，如下圖在思維導圖中梳理出所有場景，分別運用了流程場景設計、判斷法、正交法設計方法。

　　·第三步將列好的思維導圖編寫成測試用例

　　此時需要測試人員逐條去編寫測試用例，編寫步驟描述、預期輸出、預置條件、標記編號、名稱等資訊。全部完成後才輸出完整測試用例。

　　·第四步用例評審

　　用例評審也是測試設計中的關鍵一步，傳統用例評審時是測試人員把設計好的用例，一般是excel格式發給相關人員評審。

　　·第五步用例修改

　　評審後，根據評審意見需要對測試用例進行修改。改動可能是某一步驟修改，也可能是需要增加其中一個場景。

　　·第六步用例維護

　　測試用例不僅僅是編寫完成工作就結束，後續需求功能變動，都需要去維護修改測試用例，後續功能如果發生變更時則需要修改之前的測試用例，其中某一步驟功能變更後可能需要修改所有的測試用例。

　　傳統測試設計的存在痛點

　　由上述例子可以看出，測試人員在測試設計時，分析場景、編寫用例、評審用例以及用例後期維護都是比較耗費時間的。

　　·需求分析的痛點

　　上述傳統的測試設計中，測試人員只需在頭腦中理解大致的需求，即根據自己的理解輸出測試用例;

　　·分析場景的痛點

　　之前在做測試設計場景分析時，運用的設計方法對測試人員個人技術依賴比較高，不同的測試人員設計出來的測試用例質量也是存在差別，其中如正交法，如果正交因子比較多時，沒有工具支撐的情況下很容易遺漏。

　　·編寫用例的痛點

　　將思路轉化成用例這步，也是耗時比較長的一步，測試人員需要逐條編寫，工作相對枯燥，佔用時間長，往往用例的步驟描述時存在偷工減料的現象，用例編寫規範得不到落實。

　　·評審用例的痛點

　　評審用例時，評審人員拿到的是成型的用例，此時評審人員並不能看到設計者的當時的思路，以及運用的測試設計方法。逐條檢視完整用例才能明白這步用例具體的操作，同樣耗費評審人員的寶貴時間。

　　·後期維護的痛點

　　測試用例後期最怕的是用例維護，往往需求後續過程中一個小的優化點，都需要逐條修改用例，修改的時間甚至趕上了之前的編寫時間，往往很多測試人員都忽視了這一環節。

　　贅述了這麼多，既然傳統測試設計存在這麼多痛點，為什麼我們不去解決改變這些痛點呢?

　　所以我們要做的MBT測試設計工具，目的就是為了解決測試設計中的痛點，進而提升測試設計過程的效率。

　　MBT測試設計流程

　　還是繼續上文的例子，用MBT測試設計流程工具如何去做設計呢?

　　·首先拿到需求後對需求進行分析

　　首先需求分析是我們做測試設計的前提，這步是必不可少的一步，主要分析對應使用者是誰?解決什麼場景問題?

　　·明確被測特性的目的和價值

　　明確使用者時如何使用這個功能，存在哪些場景、邊界。從使用者使用角度，會發現很多因子，將因子記錄下來。

　　·功能點劃分

　　將整個需求分成多個功能點，每個模型內部主題明確，模型間沒有太多重複，需求要被完整覆蓋。

　　·對每個模型進行粗略設計

　　模型的業務流程是怎麼樣，有哪些分支因子在模型什麼位置，有哪些資料因子在模型什麼位置。

　　同樣我們會先梳理出業務主流程。用MBT進行測試建模是基於需求的功能流程，然後進行建模，基於這個模型，才稱得上是測試需求。鑑於此，就要求對於需求要有深刻的認知，所以熟悉業務是很必要的，若是業務不熟悉，那建模過程將會充滿艱難險阻。這樣也反向促進測試人員需要在需求和功能理解上下更多的功夫。

　　·建立MBT測試模型，對每個功能點進行進一步分析

　　經過分析在列印這步操作上會有一些業務場景分支。這時候在模型中對這一步進行細化分析。中間可能會用到場景劃分、判斷法、正交因子等設計方法，會在模型中體現出來。這樣當時運用了哪些方法，思路都會體現在模型中。

　　合作伙伴功能為SH的因子圖：

　　·通過工具基於模型生成測試用例

　　進一步去填寫步驟中對應的預置條件、測試步驟、預期結果。關鍵節點的公用步驟只需要填寫一次，這樣也減少了重複工作。

　　·MBT測試設計評審

　　測試設計評審時展現給評審人員的是模型圖，不再是一行行的用例記錄。評審人員能夠看到設計者當時的設計思路，用的什麼測試方法。

　　·測試用例的維護

　　用例維護與之前不同點在於，維護是在模型上維護，如果增加一條分支，或者其中一個步驟有修改，只需要修改對應的分支和步驟再次點選同步。後續需求功能點優化時，重新開啟對應的模型能看到之前業務流程圖，新參與的人員可以更快的熟悉對應的功能。

　　由上所述，對比MBT測試設計和傳統測試設計是不是有很大的不同呢。我們總結一下，MBT測試設計要求測試人員對需求理解更深，設計、編寫、評審以及維護都圍繞了一張模型圖，設計評審過程都比較透明。

　　MBT測試設計在蘇寧蛙測的運用

　　既然MBT測試設計對比傳統測試設計有很多優勢點，那為何很多測試人員沒有去用呢?其實是因為做MBT測試設計必須得依賴工具，市面上又沒有合適的工具，久而久之測試人員還是用的老方法。

　　現在蘇寧蛙測平臺結合業務場景，分析測試人員需求，研發出了一套MBT測試設計建模工具，下面介紹一下蘇寧蛙測平臺這款工具的特點。

　　工具使用介紹

　　在蘇寧蛙測平臺中MBT測試建模工具的入口在建立測試案例中，使用者可以在對應案例集的模組下右擊建立測試設計模型。

　　建模的操作非常簡單，測試人員只需要做簡單的拖拉連線的動作，在模型中梳理自己的思路。

　　·初始建模頁面

　　左側方有步驟、案例、多因子和批註。“步驟“對應到模型設計中的具體操作步驟，設計時將多個步驟和案例串聯起來，一條連線上會對應一個測試場景。

　　·編輯案例/步驟屬性選單

　　選擇步驟名，右擊步驟，可自定義步驟屬性;

　　編輯步驟視窗可以去細化測試步驟、預期、預置條件的描述。

　　·編輯後按儲存

　　經過一系列拖拉連線動作後，測試人員的模型就設計好了。

　　這時點選一下儲存，或者同步。就可以生成案例了。

　　·同步後生成案例

　　工具支援多種設計方式

　　前面提到的多種測試設計方法如流程圖、等價類、邊界值、正交法等，測試人員設計時主要是通過自己在紙上筆畫或者在腦海裡思考，沒有對應的工具。

　　而蛙測平臺的MBT測試設計工具也支援這些設計方法，模型中的多因子功能就運用了正交法，運用工具可用省去了測試人員在紙上筆畫和思考的過程。

　　操作舉例如下：拖動多因子到模型中，右擊多因子圖示，選擇開啟多因子。

　　·第一步：設定多因子json報文

　　注：如果多因子變數值是字串用””號表示，如使用者名稱[“張三”];

　　如果是數字就輸阿拉伯數字，如ID[123456];

　　·第二步：選擇組合因子數(預設因子數為2)

　　·校驗多因子json資料格式

　　·生成多因子組合

　　點選生成組合按鈕，輸入多因子變數名名稱，按確定按鈕後，生成多因子案例

　　工具特點與效果

　　平臺工具結合了多種測試設計方法，用模型表達需求，工具的支撐可以實現科學覆蓋。

　　模型設計通過拖拉連線方式，操作簡單，無需複雜的培訓學習成本。

　　蛙測平臺的測試設計建模工具正在多個業務中心推廣使用，試用過程中，經過對比測試人員用例寫作效率和用例維護效率上都有所提升。隨著廣泛推廣以及工具的持續優化效果將更明顯。

　　願景

　　MBT測試設計的目的在於幫助測試人員更方便的進行測試設計，後續會再做繼續演進，在設計的時候結合自動化，能夠在測試設計的時候也組合成對應的自動化，每一個步驟就對應自動化執行的一步。最終測試人員可以基於模型去執行自動化，並能評估產品質量。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2156495/，如需轉載，請註明出處，否則將追究法律責任。