狠狠地聊一下UI自動化測試(3)

下面我們來開開腦洞，大家有木有想過用例可以生成，生成用例自動化：

描述好Action和State生成的Map

最簡單的用例生成就是基于數據驅動的自動化測試，生成基于不同的數據輸入的用例。當然，用例的邏輯肯定要是一致的，就如QQ的狀態變更能力，用例用選擇輸入不同的狀態變更，如離線，繁忙，在線等等，最后檢查狀態欄的情況。如果輸入之間有排列組合的關系，則可以利用pairwise來減少用例的個數，但是保持一定的覆蓋率。

另外一種用例生成，則是用例邏輯的自動生成，想想，只要定義好每個Action在不同狀態下切換到的新狀態，狀態機算法就幫助我們生成一系列的用例。這個技術叫MBT, Model Base Testing?，F在各種語言都有Model Base Testing的庫，跟UI自動化結合起來就可以了。python的就例如pyModel。但是為什么這么好的東西一直沒有做起來呢? 1. 入門稍微困難了一點，需要理解一下狀態機本身的算法。這個對測試本身的素質要求更高 2. 如果說UI自動化測試的維護大部分在于排錯，那么基于MBT的自動化，則排錯更加困難了。原因是什么呢？因為腳本邏輯是生成的，所以對于依賴固定邏輯的Assert會變得非常復雜，但是也不是不可行。況且，退一步說，驗證CRASH這種簡單的Assert是沒有問題的。只要能把排查錯誤的能力在普通UI自動化測試下做到極致，排查時間能夠控制在幾分鐘之內，那么結合MBT當然也就不是夢想了。另外，最能證實可行性的證據，應該就是“即時戰略”游戲里面的電腦，他們就是狀態機編程的結果，比一個應用復雜得多，都尚且能無差無錯的完成。

再開個腦洞，前面說的UI自動化都是長長的用例，所以才有了分Step。但是這些UI自動化測試的用例有沒有可能變短，例如我們測試QQ聊天，我們不需要在界面上登陸，我們直接打開就是聊天窗口，甚至里面各種類型的消息都準備好了。要做到這不需要什么，只需要一點，“解耦”，聊天窗口跟別的類的關聯是清晰的，簡單的。如果能，例如在android，用接口測試操作，獲取QQ聊天窗口必須的SKEY等等資源，然后繞過登陸，搜索好友這些步驟，直接起來QQ聊天界面， 簡單，快捷，穩定?？上Ы怦畈皇情_發天然做到的，需要逼， 國外用來逼的方式就是UnitTest，國內呢？

總結

UI自動化是一種能力，常常無法回避。

UI自動化會給人幻覺，要看清現實與價值。

UI自動化最適合一句話，喜歡是放肆，愛是克制。而克制是UI自動化能發揮作用的關鍵。