最近測試架構收到回報，詳查後發現了一個Robotium的問題，甚有趣，遂記錄。
問題場景：
Robotium.enterText輸入資料後，點選"發送"按鈕，多數情況下失敗，少數時候成功。
問題分析：
這個問題不需要深入的分析流程，直接看enterText源碼便可發現大概問題：
<a></a>
重點是performClick和hideSoftKeyboard。
1. 為什麼Robotium要這麼做呢？
如果不這麼做，editText.setText(msg)也成功。但這和真實操作不一緻，真實流程是：點選editText，彈出鍵盤，輸入文字，隐藏鍵盤。雖然這個流程短，但狀态變化很大：
（1）焦點發生變化，這可能會影響後續的檢查/業務流程（觸發事件之類…）。
（2）彈出/隐藏鍵盤，這會觸發Android從Touch模式變為鍵盤模式。另外彈出/隐藏鍵盤可能有監聽事件，如不觸發操作，監聽事件不會執行。
2. 為什麼要在setText之前hideSoftKeyboard？
如果performClick和hideSoftKeyboard是上面的原因，那麼hideSoftKeyboard在setText之前/後都沒所謂了，因為他壓根不影響輸入。
3. 如果不執行hideSoftKeyboard會怎麼樣？
（1）隐藏鍵盤的監聽事件不執行。
（2）Android将停留在鍵盤模式。
（3）最重要的是：不藏起來，鍵盤一直占了半個屏啊，Robotium要可視控件才能操作，彈出鍵盤可能會影響其他控件的操作。
這麼說，Robotium在enterText的時候做performClick和hideSoftKeyboard是很合理的。
回到之前的問題，為什麼它會導緻“資訊發送失敗”呢？
因為：這個産品設計是，藏起鍵盤時，bottom_bar會回退到初始狀态。如圖：
bottom_bar初始狀态時，是沒有輸入框和發送按鈕的。先不管edit和btn有沒被GC，光控件不可視，click操作就會失敗。至于成功/失敗随機，是因為hideSoftKeyboard事件響應和click速度參差造成的。
隻能說這種應用場景下，Robotium表示無能為力。
解決方案：
1. 對Robotium進行擴充，實施額外enterText接口，但這會對日後更新Robotium帶來不便。
2. 修改案例避免問題。
本文轉自hyddd部落格園部落格，原文連結：http://www.cnblogs.com/hyddd/p/4126979.html，如需轉載請自行聯系原作者。