接觸Andorid有幾個月了,一直認為做系統,應用開發根本不需要懂Android自動化測試之道,認為那都是測試人員需要掌握的東西,我們只要懂開發,只要讀懂系統,根據客戶的需求可以做相應的更改就可以了,只要熟悉了API,寫出的應用可以實現某功能就可以了。其實不是的。
舉個例子說,我們偉大的客戶,瘋狂地更換硬件配置,那么我們的驅動就跟著來回換,相關功能的c實現也要換,上層java對應稍作修改,碰上膩歪點的客戶提出膩歪的需求,那么只有Good Luck了……幸運的整完了,好使了。Google及時發布Android的高版本,客戶要跟風要升級,這時候突然發現,自己修改的系統相對于原生Android并非只是優化和添加XX功能,4個字:傷筋動骨。這個時候,完美升級幾乎等于重寫。避免這個悲劇的發生其實很簡單,就是在完成開發任務之后,用cts測試一下符合不符合Android兼容性規范。倘若全部pass那么OK謝天謝地歡天喜地,若有fail項(不影響系統編譯和相關功能實現,只是不符合兼容性規范),就要及時查看相關文件可以不可以修改,將其實現回歸到Android正道。如若實在困難 ,就要提前和客戶打好招呼,避免日后被他們扔回來,自己不好收拾。
Android自動化測試不單單只是cts,還有Monkey,ASE,Robotium,Instrumentationd ......都是非常實用的工具。比如應用中的UI測試,單個Activity測試,Instrumentationd就是最大的功臣。
android.test為我們提供了些什么?
舉個例子來夸夸 ActivityInstrumentationTestCase2 <Textends Activity >
通過getActivity()可以輕松的獲得activity,肆意使用其中的方法,回避了無法實例化對象使用不了某類的方法的問題。在get之前,
setActivityIntent(Intent)
and/or
setActivityInitialTouchMode(boolean)
, provide custom setup values to your Activity 。
我最近時間在接觸camera這塊,解決了幾個bug,測了一下cts,意外的發現cts中,camera 的hardware test這塊原來不符合兼容規范的fail項,全部都pass了。所以頓時很悔恨,為什么開始不先針對cts的結果來找bug出口,這個目標就鎖定的很快,解決的效率會提高一倍。
簡單說一下cts吧
$ make cts //android源碼編譯好后,在編譯cts
解壓上一步生成的android-cts.zip 然后就可以進行測試了。詳細的操作搜一下資料,網上相關資源很多。
CTS測試會自動生成相應的測試包,該包位于如下目錄:
android-cts/repository/results
每個測試包中包含了如下文件;
cts_result.css
cts_result.xsl
logo.gif
newrule-green.png
testResult.xml
該包的測試情況都在 testResult.xml 文件中,通過查看該文件可以知道,那些是和 Android兼容的
還有一點,特別需要注意,隨著android版本的更新,cts也在不斷更新。
如果你夠好奇,可以試一試,同一系統的同一設備,用從r1到r5不同版本的cts都來測試一遍,會有意外的收獲!
不懂測試,就不要說自己是優秀的開發人員。尤其,Android為我們提供方便的自動化測試機制,還有什么理由說不需要。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
