最近產品新添加了一個新功能，在測試用例設計上應用到了基於狀態圖的測試用例測試方法，今天不是很忙，整理下看的資料寫出這篇文章，不足的地方請指出。
首先，大概介紹下這個功能(就不詳細透露產品信息)：當郵件服務器收到一封帶有可疑附件的郵件，新功能會把這封郵件隔離到一個nsf數據庫中，然后將這些可疑附件上傳到一特定服務器上(類似360，右擊選中文件，在沙盒中運行)，在這個特定服務器上會運行幾個VM，分析這些可疑文件並給這些文件進行打分，判斷是不是Virus，過一段時間，根據SHA值到特定服務器中查詢可疑文件的分析結果，一旦拿到這封郵件中所有可疑文件的分析結果，便對這些那些Virus文件采取指定的動作(如，清除，刪除，隔離等)，最后釋放這封郵件。這交互過程如下圖所示：
這篇文章只考慮兩台Server間交互方面的測試用例設計，其他方面(如，郵件編碼、文件類型大小、和其他功能的交互)先不用管。依據RD的design doc 和SRS文檔，利用xmind列出這一功能的所有測試點，然后寫測試用例。我們來看看在思維導圖中列出的關於兩台server交互方面的測試點：
第一個是正常流程，在備注中給出了正常流程的具體步驟(如我上面所述)。第二個是error handling，列出了sandbox出錯的可能，但沒有講清楚這樣的錯誤發生在什么樣的場景下。測試用例也是基於這樣的思維導圖細化出來的。剛開始我也沒察覺出有什么不妥，或則說有漏測的地方。依據這樣的測試用例，兩輪測試后，理應沒有什么大問題了。直到我無意中發現這樣兩個問題：
問題一：一封郵件中有兩個可疑文件，如果一個可疑文件過一段時間拿到了分析結果，但另一個文件一直無法給出分析結果，這時候預先設定的超時等待時間(1小時)到了，預期行為是不會再等待那個文件的結果，直接對拿到結果的文件做動作，然后release郵件。但實際結果是，每過大概半小時左右，就會把超時時間置0，導致的結果是這封郵件永遠被hold在nsf中。
問題二：一封郵件中有可疑文件，被隔離到nsf中，然后把可疑文件上傳到特定服務器，但這時候server負載過大，無法響應，可疑文件很長時間無法上傳完成，這時候關閉服務器，發現處理進程無法退出。
先不管這兩個問題是由什么原因造成的，兩輪過后，這樣的問題依舊沒有被發現，說明這一塊的測試用例設計還是不完善的。最近在看《探索性測試》這本書，書中“局部探索式測試法”提到了“如何測試軟件狀態“，我就想嘗試着畫出兩台server間交互的狀態圖，又找了些關於state-based test方面的文章看。
設計狀態圖，需要：
- Models each state a system can exist in
- Models each state transition
- Defines for each state transition(start state、input、output、finish state)
用狀態圖來描述系統狀態，一個節點代表一種狀態。有一個初始狀態開始，接收到輸入，觸發狀態轉換，到達下一個狀態。來看看用visio畫的兩台server間的狀態圖：
完成后別忘了請同事review下，看有沒有漏掉的點。有了這個狀態圖，便可以給出switch coverage圖了：
接下來，表格化這些步驟，這里僅列出兩個：
顯而易見，通過狀態圖可以很清晰地掌握整個交互過程, 保證cover這些狀態轉換,減少出現之前漏測情況的發生。
基於狀態轉換圖的測試用例設計只是眾多測試技術中一種，它也不是適用於所有場景，只有基於特定場景選用特定的測試技術，才能事半功倍。這需要我們不斷總結，思考。
參考資料：