測試，任何一個開發者都不愿意提起的話題，但是又不得不提。測試作為軟件開發的最后環節往往不被人重視，但往往就在這最后一哆嗦，前面付出的諸多心血付之東流了。在軟件開發階段完成之后經常嚴格的測試環節才能對外發布，測試是一個軟件邁向市場的最后環節。

當進入移動互聯網時代，各個行業中涌現出來的App質量良莠不齊，這是由于國內整體的技術環境導致的，不重視測試。有人會說，Google不會對自己的應用進行測試，我們也可以學習Google。但Google的工程師都是領域內頂尖的高手，你聘請的工程師呢？大部分公司出于成本考慮，會雇一些比較初級的開發人員，做出來的東西也是比較粗糙，而且還不測試，APP的質量可想而知。

當與一些創業者溝通交流的時候他們往往會有這樣的想法，先發布再說，有了用戶反饋在修改。就是這樣的想法讓好不容易有了的用戶群慢慢消散，因為當你出現問題的時候用戶就已經有了卸載應用的理由，為什么不將一個接近完美的產品放在用戶面前呢？

在與一些移動創業者交流的過程中發現，這并不是產品與研發不想做測試，而是由于根本沒有精力和成本來做測試。因為在移動互聯網領域版本快速迭代，采用傳統測試方式的話黃花菜都涼了。就目前的狀況來看，似乎只有自動化測試者一條路可走，但傳統自動化測試的模式真的能滿足移動互聯網創業者的需求么？

傳統自動化測試不是你想測就能測

首先傳統測試需要購買大量的測試設備，這對于初創型團隊來講是一筆不小的成本，這些設備的購買成本甚至要比整個團隊的日常運作費用還要高。如果考慮做自動化測試，您還得雇幾個懂的人來搞，更是一大塊成本。所以自動化測試雖然看上去很美，但很少有公司愿意去碰它，原因也是這里邊，前期需要投入的成本，是大部分公司不能接受的。

其次，傳統測試對于技術和時間的要求較高，不能適應移動互聯網快速版本迭代的現狀。在與某大型公司的測試經理交流之后了解到，傳統測試也可以實現自動化測試，但步驟比較繁瑣。

實現Android測試項目自動化，需要一下幾個步驟：

1. 了解產品功能。

2. 評估手動測試用例，篩選出適合自動化的用例。

3. 搭建腳本開發環境(配置Eclipse，下載測試框架，安裝Android SDK，配置環境等)

4. 根據用例描述編寫測試腳本

5. 調試完善腳本

6. 執行自動化測試(可能需要搭建多個設備同時執行測試的環境)

7. 腳本在應用升級迭代中不斷地維護更新，并重復執行

一位就職于國內大型企業中的測試工程師介紹到，根據以往的經驗，一般測試項目，可實現自動化的測試用例比例大約為30% ~ 50%。有些手動測試用例，需要進行拆分才能較好的實現自動化。類似于單元測試，UI自動化測試，最好也是一條用例只驗證一個測試點，這樣有利于測試腳本的編寫和維護。

這還不包括后續編寫腳本與調試完善腳本的事情，假設我們已經對測試用例進行拆分，一條用例只驗證一個測試點。這類測試用例，對于初級自動化測試工程師來說，完成這樣一條用例的腳本的編寫和調試需要3~4個小時，中高級的人員平均需要1個小時左右。到了測試腳本的后期維護階段，耗費的時間更加不可預知。

在與這位測試工程師交流過后，感覺傳統的測試模式對于快速發展的移動互聯網公司來說就是一個噩夢，一個耗時費力的噩夢。

創業路上 喊你父母來解決傳統測試之痛

關于移動應用自動化測試解決方案在市場上已經有一些非常成熟的案例。這位不愿意透露姓名的測試工程師介紹到，目前市場上有幾個較為成熟的自動化測試軟件可以用來輔助測試工作。

國內目前使用比較廣泛的是iTestin，也有一部分人使用百度的MTC和易測云的Radar，但是從更新頻率和維護熱度上來看還是稍差一些，國外的自動化測試工具以收費的居多，其實核算下來成本并不低。

iTestin是國內Testin云測公司推出了一款免費的安卓自動化測試腳本錄制工具iTestin，可以幫助你所在的項目組快速實現穩定模塊的功能自動化測試，或者實現某個版本的深度兼容性測試。

iTestin還可直接捕獲操作者在真實手機設備上對被測應用的操作，并直接生成可跨分辨率執行的功能測試腳本。該腳本能在應用的多個版本間復用，并隨時可以提交云測平臺，在1000多款真機上重復執行。測試報告包括測試腳本包涵蓋的功能點的驗證結果，還有測試過程中的日志、截圖、和性能數據等。通過使用iTestin，你可能只需一位黑盒測試工程師，就可以在一天之內啟動自動化測試。

從另外一個角度來看，iTestin可以讓一個完全沒有測試經驗的人完成繁瑣而且機械的測試工作。換句話說，你甚至可以把你的父母喊來幫你做測試工作，在你創業的路上又添加了一抹戲劇化的元素。