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測試設計的目的在于幫助測試人員更方便的進行測試設計，后續會再做繼續演進，在設計的時候結合自動化，能夠在測試設計的時候也組合成對應的自動化，每一個步驟就對應自動化執行的一步。最終測試人員可以基于模型去執行自動化，并能評估產品質量。

原文轉自：http://tech.it168.com/a2018/0622/3210/000003210659.shtml