前言
這一篇比較特別，內容提供者是我的好朋友jingle——專業的ios測試工程師。
什麼叫基於狀態的測試
基於狀態的測試，是一種基於模型的測試，常用於事件驅動的系統中，這些系統往往是實時系統，比如數字技術和硬體電路。實際中的系統，比如下面這些通常會用到狀態機：
1）作業處理系統
2）atm機
3）介面處理程式
基於狀態的測試，也是一種黑盒測試設計技術，所涉及的測試用例用來執行（遍歷）有效和無效的狀態轉換，當有一系列的事件和條件，且對特定事件/條件的處理又取決於曾經發生過的事件和條件時，比較適合使用基於狀態的測試技術。
模型
在狀態機主要分為兩類，一類是輸出只和狀態有關與輸入無關，稱為moore狀態機；另一類是輸出不僅和狀態有關還和輸入有關，稱為mealy狀態機。
1）mealy狀態機
基本概念：
--node（節點）：代表系統的狀態
--link（鏈結）：代表節點之間的關聯
2）moore狀態機
節點：代表系統中發生的事件
3）優劣
mealy狀態機因為有以下幾個特點更簡單的運用在實際工作中：
1）更接近於實際執**況
2）有較少的狀態，且
3）狀態穩定
4）當狀態圖變得更加複雜的時候可以比較簡單的重複事件
5）在表中更加容易去展現狀態圖
書中講到，在拿到我們待分析的物件後，首先需要描述該物件的所有狀態，其次，是描述各個狀態之間的轉換以及轉換過程中發生的事件。其中，整個過程中最難的也是最有意思的部分是設計狀態機模型。但是一般該過程會包括以下四個部分：
1）列出分析物件所包含的各種狀態
2）列出不同狀態之間的轉換
3）確定引起各個轉換的事件
4）分析各個轉換過程中發生的事件
乙個簡單的例子
書中舉了乙個atm機的例子來說明是如何設計狀態機的，以及由狀態轉換圖怎樣變為最終的測試用例的。
a.首先根據第二節中提到的4個基本步驟設計atm機的狀態轉換圖
1）分析各種狀態：未插卡狀態，插卡請求pin狀態，獲取到pin狀態 （待轉換）
2）為不同的狀態列出其之間的轉換
3）引起各個狀態轉換的事件
插卡輸入正確的pin碼
輸入錯誤的pin碼
輸入正確的轉換條件
輸入錯誤的轉換條件
選擇退出
4）轉換過程中發生的事件
請求新的pin碼
請求新的卡片
請求新的轉換
返回錢，卡片，交易憑證
b.根據上面分析的結果，畫出狀態轉換圖
圖中最後乙個節點是v3，而不是v1（從書中直接截的圖）。
c.根據狀態圖編寫基本的測試用例
有了狀態轉換圖，我們就可以根據節點以及節點之間的鏈結編寫測試用例了，測試用例就是從乙個狀態到另乙個狀態，然後遍歷兩個狀態間的路徑。那麼，問題來了，怎麼覆蓋狀態與狀態之間的所有路徑呢？顯然，使用人工的方法是最容易想到的，但是不會漏掉某一條路徑嗎，尤其是當狀態機非常複雜的時候？幸運的是，現成的理論中有很多種方法來解決這個問題，比如下面的覆蓋狀態圖的方法：
1）覆蓋典型路徑
2）旅行推銷員路徑
3）中國郵遞員路徑
4）基於風險去覆蓋
5）覆蓋所有狀態轉移長度
6）離開乙個狀態的所有方法
7）不產生狀態轉換的事件
2）和3）這兩種方法也是數學界裡比較典型的兩個問題，感興趣的可以去google搜尋下。
當然，你也可以先使用最簡單的辦法建立出狀態轉換表，如下表：
該錶的建立方法為：
1）列出狀態轉換圖的所有狀態，本例子atm的狀態為v1，v2，v3
2）列出狀態轉換圖中所有事件/條件的組合
3）建立**，對於每個狀態，將其與每個事件/條件組合填入表中
通過上面的內容，應該對狀態機以及怎麼設計狀態機有了一定的認識，下面一起來學習下怎麼通過狀態機來設計簡單的測試用例，以及如何擴充套件更加全面的測試用例。
建立測試用例
根據剛才生成的表，設計測試用例，去覆蓋到上表所示的所有狀態轉換。設計的測試用例如下：
第一條case：
1）插入卡片（狀態v1）
2）輸入錯誤密碼（狀態v2）
3）輸入正確密碼（狀態v3）
4）等待轉換（狀態v3）
5）取出錢和卡片（狀態v1）
第二條case：
1）輸入錯誤密碼（狀態v1）
2）取走被拒絕的卡片（狀態v2）
第三條case：
1）插入卡片（狀態v1）
2）輸入錯誤的密碼（狀態v2）
3）輸入錯誤的密碼（狀態v2）
4）輸入錯誤的密碼（狀態v2）
5）卡片彈出，回到初始狀態（狀態v1）
這三條case，可以覆蓋到狀態轉換表中的所有轉換，其中，在第一條case中覆蓋了b，c，e，g這4個轉換，第二條case覆蓋了a轉換，第三條case覆蓋了轉換d。但是這三條case是否覆蓋了所有狀態以及轉換呢？顯然，沒有覆蓋完全。
轉換對
這裡說一下這個表是怎麼得到的？該錶中共有5列，第一列是狀態轉換圖中的三個狀態，第二列是對每個狀態節點出去的邊和回來的邊（參考圖論中的節點的出度和入度），第三四五列是從狀態節點出去或者進來的邊（即狀態機中的轉換），除此之外，每個狀態節點都有一行資料（第三行），該行資料是通過in那一行指向out那行得到的，即對應乙個轉換。如下圖所示：
從in節點c到out節點e和a（紅色箭頭和紅色框框所示），便形成了轉換15：c-e和16：c-a，同理，其他的轉換也是這麼來的。
有了轉換對得到的擴充套件狀態轉換表後，就很容易得到擴充套件版的轉換表，如下圖：
由之前的只有7行的狀態轉換表到上表16行的狀態轉換表，很明顯擴充套件了不少，然後我們只需要設計足夠的測試用例來覆蓋這些狀態轉換就行了，相比之前的7行狀態轉換，這個顯然做到了高覆蓋度和高精確度。
小結
從簡單的幾條case到擴充套件版的狀態轉換表，我們要做的就是根據狀態轉換圖來盡可能多的覆蓋圖中所示的各種轉換（其實，這裡我們可以把狀態轉換圖看成乙個普通的圖，然後利用圖論中的知識來進行覆蓋就會顯得比較簡單了）。
學習了狀態機，對我們測試而言，需要自己去分析被測物件是否適合用狀態機的方法去進行測試？如果適合的話，怎麼去設計被測物件的狀態圖？這些就需要因被測物件而異了。
個人認為，基於狀態的測試適用於：被測物件擁有多個狀態，且各個狀態之間的轉換由事件來觸發，且各狀態之間的轉換還可能導致一些動作action的發生。其難點在於：如何設計被測物件的狀態轉換圖？如何根據狀態轉換圖設計測試用例？這需要各位在實際工作中慢慢體會了。
測試執行緒的狀態
測試執行緒的狀態 package cn.com.state public class testallstate catch interruptedexception e system.out.println 快樂的學習 thread.state state t.getstate 新生狀態 new s...
基於流表項刪除的測試與分析
一 測試目的 本測試的目的是為了得知在執行openflow協議的sdn網路中，交換機上的流表項的生存時間問題，即流表項被生成後在流表中持續時間的問題。我們知道流表項中的timeout欄位為流表項維護了最大空閒時間 idle timeout 也就是一條流表項不再匹配資料報時能夠持續的最大時間。那麼這個...
基於測試用例的功能測試
功能測試 unctiona test 通常使用黑盒測試的方法 將程式視為乙個不能開啟的黑盒，在完全不考慮程式內部結構和內部特徵的情況下，從軟體產品的介面 架構 介面出發，輸入預定的資料，在預期結果和實際結果之間進行評測，並判斷軟體產品是否符合使用者需求。使用黑盒測試方法的功能測試流程簡述如下 1.確...