自從圖形化界面成為個人桌面電腦的主流，應用程序復雜程度與日俱增，針對人機交互的自動化測試迫在眉睫，從而在市場上涌現了一大批針對圖形界面應用程序功能測試的自動化測試工具（參考鏈接1）。2001年QTP第一個版本發布；2002年Robot初始版發布。自此，自動化工具已經經歷了十年的發展。隨著近兩年移動應用呈現爆炸性的增長，移動應用自動化測試工具也開始陸續呈現（參考鏈接2）。
需求的延續
無論從PC端應用的自動化測試，還是移動應用的自動化測試，人們的關注點從未轉移，期望也從不改變，那就是，盡可能多的模擬人工測試動作和相應的結果檢查，從而釋放手工勞動，替代大量重復性的執行和驗證工作。進入移動應用時代，移動應用項目開發一直走的是“短小精干”的路子，即應用程序小而精。開發模式也拋棄了傳統的規范流程，熱衷于敏捷式開發。版本發布周期約來越短，迭代頻密。這些似乎與自動化測試遙不可及。但是，隨著移動應用逐漸從個人娛樂領域滲透到商業應用，諸如金融、辦公、政務等方面的應用比重逐步擴大，對移動應用質量的要求也越來越高，自動化測試始終會回到人們的視線之內。在加上安卓特有的碎片化問題，使得安卓平臺自動化回歸測試和兼容性測試的呼聲極高。
理念的傳承
回顧桌面應用的自動化測試歷程，我們看到，工具的發展經歷了從最初“坐標點操作”過渡到“對象識別”的過程。移動應用測試工具走的路子也有幾分相似。以開放的Android平臺為例，最開始出現Monkey/MonkeyRunner等坐標點操作的工具（后來有很多工具開發商做了對MonkeyRunner的封裝）；之后出現了如Robotium等基于源碼層面對于界面控件識別的工具；也有一些工具開發商如DroidPilot.com推出了純粹的對象識別工具；當然，也有一些如PerfectoMobile.com的工具開發商，為了兼容iOS/BlackBerry/Windows Phone等平臺，采用圖像識別技術。但無論如何，“關鍵字驅動”、“數據驅動”等理念已經是傳統PC行業自動化測試的成功經驗，移動應用測試方面應該借鑒。再搭配性能測試工具、輕量級測試需求管理、用例管理、缺陷跟蹤等工具，相信足以成為移動應用項目質量保證的基礎工具支撐。
有所不能vs凡事都能
似乎所有管理者都期望一旦引入自動化測試，則萬事大吉，貌似自動化能做到全方位的測試服務，可以釋放測試工程師了。但事實求是的說，即使在擁有十年歷程的傳統自動化測試行業，自動化所能涉及的測試用例比例也是有限，通常覆蓋60%～80%的測試用例，已經能說是不錯的成績了。問題是，項目的成本和進度，以及測試人員的配備，是否能足以支撐自動化測試持續的進行。否則事半功倍，未免太可惜了。借鑒傳統項目的自動化測試失敗案例，對于項目預算相對較少的移動應用開發項目，考慮引入自動化測試的確需要慎之又慎。
精益求精
然而對于自動化測試工程師來說，通常并不滿足于部分用例的自動化測試，甚至僅僅是自動化冒煙測試。他們總想走的更遠，甚至不惜代價去完善一些鳳毛麟角之功能。當然，從這一點也可以看出自動化測試工程師們精益求精的精神，同時，也對自動化測試工具開發者提出了更高的要求。從目前發展現狀來看，他們也的確在著眼于提高工具的測試深度和廣度，增強工具易用性，剝離工具對于源代碼的依賴，延伸傳統自動化測試的方法論。希望看到移動應用自動化測試領域呈現蓬勃的發展。
參考鏈接
1、<List of GUI testing tools - wikipedia>
http://en.wikipedia.org/wiki/List_of_GUI_testing_tools
2、<安卓應用自動化測試工具大匯總–測試窩>
http://www.testwo.com/space.php?uid=11328&do=blog&id=5956
版權聲明：本文出自 anthony.wang 的51Testing軟件測試博客：http://www.51testing.com/?507238
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。