物聯網產品測試框架——物聯網測試地圖
物聯網的出現，給測試帶來了很多有意思的挑戰，使得眾多QA開始重新思考傳統的測試過程。
例如，我最近測試了一個產品，在這個產品中的移動APP會跟連接的機器產生會話。這兩個設備各種各樣的狀態給測試場景的設計帶來了特別大的挑戰。下面給大家介紹一個很有用的物聯網產品測試框架——物聯網測試地圖，它可以幫助我們管理物聯網設備多種排列的復雜狀態。
物聯網測試因素
當我們測試簡單的web應用時，通常要考慮的狀態有：
- 服務器宕機
- HTTP請求超時
- 網速慢
- 授權和認證錯誤
測試任何互聯網應用的時候，需要警惕這四種狀態。對于移動應用，操作的是移動環境，需要關注額外的幾種情況：
- 離線模式
- 在線模式
- 殺掉Activity
- 后臺行為
- 語言
- 地理位置
我們再看“連接的機器”所帶來的狀態多樣性，通常還有：
- 機器WiFi斷開
- 機器WiFi連接
- 機器繁忙
- 機器休眠
這意味著即使只有上述給定的狀態集，整個系統在任何時間點上可能會有96(4x6x4)種狀態。
由于系統中狀態轉換會引入附加的約束，這些狀態都不能當做獨立的實體。例如，狀態從“離線”變成“在線”很可能觸發一系列的事件。
上述因素還僅僅是冰山一角。隨著對規范的深入了解，把不同的狀態跟邏輯場景結合起來將會更加的復雜。
對于靜態系統的可變數據集，已有的web測試技術可以很好的用來抽取測試場景，比如all pairs(開源的配對測試工具)、等價類劃分、邊界值分析法等。這些技術通過淘汰的邏輯來優化測試數據集。
例如，all pairs技術會淘汰重復的數據配對組合。但是，對系統的可變狀態設計測試場景時，這些技術是不可靠的，廢棄的系統狀態會使得系統通訊不暢。當然，這些技術對于物聯網系統中的單個單元還是很適用的。
因此，非常有必要搞一個物聯網測試地圖。
可視化地圖
大家肯定都在地理課上看過地圖。但我這里所說的地圖是針對測試場景的，它列出所有潛在的系統因素，在測試某個特性時可以從中抽取必要的測試場景。
產品的每個系統的n種狀態在同一個可轉動的圓環中列出，邏輯上相鄰的狀態在環中相互挨著。非功能需求(NFR)在測試復雜集成的時候很容易被忽略掉，于是把它們在一個環中單獨列出。
下圖就是我所說的物聯網測試地圖：
下面以一個例子介紹地圖的使用場景，該例子僅涉及移動設備和機器交互部分，需要關注的環是設備、機器和網絡。
把移動設備和機器固定在WiFi連接的狀態，轉動網絡環，可以得到下面這些場景：
- 未授權用戶嘗試訪問機器會在App上觸發“訪問被拒絕”的錯誤消息
- 服務器宕機和服務器錯誤會觸發相應的業務錯誤消息——“程序出錯，請稍后重試”
- 響應超時可能有兩種情形：重發同一個請求并顯示“正在加載”圖示，或者顯示上面那樣相似的錯誤消息
- 非法請求會觸發消息“請更新你的App”
繼續保持移動設備的WiFi為連接狀態，轉動機器環：
- 當機器是離線模式的時候，App應該顯示“請檢查機器的網絡連接”
- 當機器繁忙的時候，彈出警告“機器繁忙，無法完成請求”
- 當機器休眠或者在另一個網絡上的時候，應該顯示“沒找到機器”等類似的消息
- 然后，機器調到正確的網絡，應該恢復移動設備和機器的連接
切換機器環為WiFi連接，轉動移動設備環：
- 當移動設備離線時，應該彈出對應的消息或者禁掉操作按鈕
- 當移動設備恢復在線模式時，App應該發送相應的請求去連接機器
- 當移動設備的網絡從WiFi切換到3G，應該有什么樣的行為?
- 當用戶正在試圖連接物聯網設備的時候突然接到電話，將App置于后臺運行，這時候還能收到完整的請求還是需要從頭開始發送請求?
- 安卓設備殺掉一個在后臺運行了一段時間的App，用戶的***屏幕狀態還會保存嗎?
- 有本地化需求的App要在每個場景層面進行驗證
就這樣，多次旋轉地圖可以擴展產生多個場景。盡管有些場景可能不適合當前的特性，有些甚至跟業務需求無關，這個測試地圖還是非常詳盡的。
在實踐層面，對于有多個QA在測試同一個物聯網產品的團隊，地圖可以作為大家共同參考的手冊。這個地圖把工具、設備、場景和協議的排列以易于理解的方式呈現出來，覆蓋了測試場景設計這個獨特的需求，是一種非常高效的合作方式。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
