現在大家對探索性測試討論得很熱門，在自動化測試大行其道的今天，探索性測試似乎是唯一一塊測試人員更能體現自己專業性的領域。甚至我還看到有人在討論如何通過探索性測試來達到較高的代碼覆蓋率。

個人以為，如果你真的對覆蓋到代碼的每個分支更感興趣，或者說希望測到哪怕是一些比較細節的用戶行為，通過探索性測試的方法來做也許并不是一個很推薦的做法。

我這里想介紹一種基于模型的測試，通過它，我們可以對軟件的功能達到更強的覆蓋，達到更有效的測試，同時還能發現一些隱藏更深的問題。

同時，它也被某些業內人士譽為繼關鍵字驅動之后的下一代自動化測試技術。

該方面的專家 Harry Robinson，來自微軟的測試架構師，有一個很有意思的說法：“MBT is not your parents'  test automation”， 也說明了這個意思。

首先來看它的定義：

Model based testing, 基于模型的測試

基于模型的測試屬于軟件測試領域的一種測試方法。按照此方法，測試用例可以完全或部分的利用模型自動產生。以上所說的模型通常是指對被測系統（SUT, system under test）某些（通常是功能性的）方面的描述。

什么是模型：

模型是系統的抽象描述，同時模型比真實的系統簡單。

狀態機是一種常見的表示用戶操作的模型，比如以下的操作就可以模型化。

所有的測試都是基于模型的，但是不是每個模型都被保留：

我們在做測試的時候，腦子里面都預先會有軟件的行為應該是怎么樣的概念，它會指導我們去做相關的測試。

如何來建立測試領域的模型：

通常來講，建模是應用MBT的一個難點，原因可能在于，大部分的測試人員都是在已經實現的系統上工作，在他們的日常工作中，比較少的受到如何來構建一個產品的訓練。

而建模所需要的技能更多是一個軟件工程師所需要的那一些技能，比如

1. 抽象和歸納

有時候，為了認清事物的本質，我們必需拋棄掉事物的細節，透過事物的表象。我總結了一下，就是抽象抽象再抽象，歸納歸納再歸納

2. 分而治之

一個大的系統通常是復雜的，我們工作的領域的軟件也類似。為了能從它們中有效地抽象出模型，建議可以采取分而治之的策略。

3. 從概念本質到實現細節

那我們有哪些建模的方法呢：

從我有所實踐的經驗看，應該可以歸納成數據模型的建模和狀態機的建模

  以下分別選取了兩個例子，介紹如何對其進行數據模型或者狀態機模型的建模，并最后生成可執行的自動化測試用例。

有關數據模型的建立：

Linux的發明者 Torvalds, Linus 曾經有過一句話：

Bad programmers worry about the code.

Good programmers worry about data structures and their relationships.

在Agile Testing領域比較知名的一位專家 Elisabeth Hendrickson 也從測試的角度對數據的重要性做過一些闡述，她列舉了常見的測試設計技術：

Test Design Technique

等價類

邊界值

Data Type Attacks

CRUD

Different configurations

Count (user count, resource count)

…

然后做出了歸納，

It’s all about the variables.

所以我們可以看到，如果能建立系統的數據模型，無論對于開發和測試都是很有幫助的。

以計算機行業常見的和磁盤相關的測試，來說明如何用數據模型對測試需求建模：

然后我們把它翻譯成框架可以識別的格式，用了一些非常簡單的python語法來描述。

然后可以通過框架生成自動化用例：

另外一種常見的模型是狀態機模型，主要是針對用戶的行為建模：

比如Bug管理系統的工作流模型

或者SIP 協議的呼叫模型：

SIP協議呼叫相關的測試：

首先我們還是把它描述成框架可以識別的格式：

我們看到，可能的測試路徑是很多的，那怎么才可以以最小的測試代價達到我們的覆蓋率的目標呢？

假設我們的覆蓋率目標定義成以最小的成本覆蓋所有狀態之間的遷移，那我們面臨的其實是一個數學問題，那就是在一個有向圖上，如何找到最短的路徑覆蓋。

這其實是一個著名圖論問題。郵遞員從郵局出發送信，要求對轄區內每條街，都至少通過一次，再回郵局。在此條件下，怎樣選擇一條最短路線?此問題由中國數學家管梅谷于1960年首先研究并給出算法，故名。

通過郵遞員算法，我們看到我們一共需要28個步驟才能覆蓋所有圖中的變化：

然后我們也可以把它變成可執行的Robot Case