前言

在日常的開發(fā)中，尤其是app開發(fā)，因?yàn)椴幌駑eb端那樣 出錯(cuò)以后可以熱更新，所以app開發(fā) 一般對(duì)軟件質(zhì)量有更高的要求（你可以想一下 一個(gè)發(fā)出去的版本如果有重大缺陷 需要強(qiáng)制更新新客戶端是多么蛋疼的事情）。所以我們app的開發(fā)者一定要學(xué)會(huì)自己測試自己的代碼，自己測試自己的app，不要寄希望于測試來幫你找bug，絕大多數(shù)隱藏極深的bug 都是開發(fā)自己發(fā)現(xiàn)的。

那么如何測試自己的app，測試自己的模塊呢？

1.Monkey

http://developer.android.com/intl/zh-cn/tools/help/monkey.html

這個(gè)工具是最簡單的，我主要用他來壓力測試，所謂壓力測試就是 亂點(diǎn)。。。模擬各種各樣奇怪的操作 看你的app能不能抗的住。

可以簡單看一下 這個(gè)命令的用法。看一下help 介紹的參數(shù)說明。

舉例來說：

1 android shell monkey -p 你想測試程序的包名 -v 500

比如 我現(xiàn)在想看看android 系統(tǒng)自帶的日歷應(yīng)用 在壓力下表現(xiàn)如何。

你看 這個(gè)地方模擬器自己就開始瘋狂點(diǎn)擊了。當(dāng)然在實(shí)際使用中，我們都是會(huì)把次數(shù)調(diào)到 幾十萬次到幾百萬次，然后下班以后開始跑，第二天來看結(jié)果 看看在哪里出了問題~~?；旧?/p>

每日構(gòu)建完畢以后都會(huì)跑一下。Monkey基本上 就是這樣使用的。非常簡單 但是作用也非常有限。不過可以極大幫助你 找出你app的一些隱藏極深的bug。

比如evernote，這個(gè)我平常使用的軟件 我自己是沒有碰到過crush的，但是你跑一下monkey，1個(gè)多小時(shí) 就崩潰了。。。。。所以monkey是提升軟件質(zhì)量的 好幫手。

2.MonkeyRunner

http://developer.android.com/intl/zh-cn/tools/help/monkeyrunner_concepts.html

這個(gè)相對(duì)于Monkey 來說 就是真正意義上的 自動(dòng)化測試工具了。只需要編寫腳本即可完成 我們平時(shí)所需要的 大部分 冒煙用例等等。

尤其是在4.x以下的機(jī)型里，由于無法使用uiautomator， MonkeyRunner幾乎就是唯一的自動(dòng)化測試編寫辦法。

下面我舉個(gè)例子，比如我們app里最常用的登錄功能，我們就可以編寫一個(gè)腳本來完成。

復(fù)制代碼

1 # coding=UTF-8

2 from com.android.monkeyrunner import MonkeyRunner as mr

3 from com.android.monkeyrunner import MonkeyDevice as md

4 from com.android.monkeyrunner import MonkeyImage as mi

5 from com.android.monkeyrunner.easy import EasyMonkeyDevice

6 from com.android.monkeyrunner.easy import By

7

8 #定義安裝文件路徑

9 installPackage = ‘C：UsersAdministratorViewPageTestappuildoutputsapkapp-debug.apk’

10

11 #要測試的程序的包名

12 apkPackageName =‘com.example.administrator.viewpagetest’

13

14 #要啟動(dòng)的第一個(gè)activity的名稱

15 initActivityName=apkPackageName+“/com.example.administrator.viewpagetest.MainActivity”

16

17

18 device = mr.waitForConnection（）

19

20

21 #安裝apk包

22 device.installPackage（installPackage.decode（‘utf-8’））

23

24

25 #啟動(dòng)應(yīng)用程序

26 device.startActivity（component=initActivityName）

27 #防止啟動(dòng)首頁面 需要時(shí)間過長

28 mr.sleep（3）

29

30 easy_device = EasyMonkeyDevice（device）

31

32 mr.sleep（3）

33

34

35

36 easy_device.type（By.id（‘id/username_et’），‘zhangsan’）

37 # 這里的mr靜止 主要用于演示demo上的gif效果

38 mr.sleep（2）

39 easy_device.type（By.id（‘id/password_et’），‘123456’）

40 mr.sleep（2）

41 easy_device.touch（By.id（‘id/submit_bt’），md.DOWN_AND_UP）

然后運(yùn)行他 看看效果：

你看上面的腳本 完成了 自己安裝apk 輸入用戶名和密碼 并且點(diǎn)擊登錄按鈕的過程。

有人問，你這個(gè)模擬登錄的過程是模擬出來了，那我怎么知道 到底登錄成功沒有呢？

其實(shí)也很簡單。主要有幾個(gè)方法。

1.登錄成功以后你這個(gè)頁面肯定是要跳轉(zhuǎn)到主界面的對(duì)吧，你就用腳本執(zhí)行下shell命令 看看主頁面 是否在棧的最上方？（前面我的activity 啟動(dòng)模式那篇博客里講過這個(gè)命令的）

2.你可以在log 里面 打印出登錄成功這個(gè)消息 然后用腳本捕捉到這個(gè)log 日志 就知道是否登錄成功了。

3.甚至你還可以捕獲界面上某個(gè)控件的文字值。

4.比較某個(gè)操作結(jié)束后的 截屏。保存為圖像以后 和正確操作以后的圖像進(jìn)行對(duì)比。

這里我就不繼續(xù)往下寫這個(gè)腳本了。有興趣的同學(xué)可以自己嘗試 完成日常工作里的 那些冒煙用例。（意義重大，否則每次發(fā)版本 你的那些用例全部要用手點(diǎn)擊手機(jī)完成一遍 那多麻煩?。?/p>

此外 我們還可以利用recorder來錄制腳本，然后再反過來用python執(zhí)行這個(gè)腳本 來執(zhí)行我們的測試過程。這個(gè)方法 我就不做詳細(xì)分析了，很簡單。（但是要注意 這個(gè)方法 啟動(dòng)的 捕捉器 在多數(shù)情況下都非?？D，所以采用率不高。）

3.UiAutomator

http://developer.android.com/intl/zh-cn/tools/testing-support-library/index.html

這個(gè)工具我個(gè)人認(rèn)為是所有android 程序員都必須要掌握的，有了這個(gè)強(qiáng)大的工具，我們就可以負(fù)責(zé)任的對(duì)自己的代碼 說 木問題，ok！

此工具 能模擬幾乎所有對(duì)android設(shè)備的操作。

而且代碼也非常簡單 全部都是java代碼，并且android的api 他還幾乎都能夠使用。簡直酷到?jīng)]有朋友！比android studio 自帶的ApplicationTestCase 強(qiáng)到不知道哪里去了。

在這之前 你需要對(duì)gradle腳本有少許了解。具體可參見我的blog http://www.cnblogs.com/punkisnotdead/p/5029125.html

這個(gè)工具的原理實(shí)際上和http://www.cnblogs.com/punkisnotdead/p/4885572.html 里面提到的輔助服務(wù)是差不多的。都是利用的那個(gè)service。

你只要會(huì)寫UiAutomator testcase，就意味著你的代碼 幾乎是永遠(yuǎn)不會(huì)出錯(cuò)噠~~

好，下面給出一個(gè)基本的例子 來讓你明白 為何這個(gè)工具這么吊。

首先 給出gradle里的改動(dòng)：

apply plugin： ‘com.android.application’

2

3 android {

4 compileSdkVersion 23

5 buildToolsVersion “23.0.2”

6

7 defaultConfig {

8 //不要遺漏這句話

9 testInstrumentationRunner “android.support.test.runner.AndroidJUnitRunner”

10 applicationId “com.example.administrator.testcaseone”

11 minSdkVersion 18

12 targetSdkVersion 23

13 versionCode 1

14 versionName “1.0”

15 }

16 buildTypes {

17 release {

18 minifyEnabled false

19 proguardFiles getDefaultProguardFile（‘proguard-android.txt’）， ‘proguard-rules.pro’

20 }

21 }

22 }

23

24 dependencies {

25 compile fileTree（dir： ‘libs’， include： ［‘*.jar’］）

26 testCompile ‘junit:junit:4.12’

27 //這個(gè)地方要注意了 studio自帶的里面版本號(hào)一般都比較高，如果出錯(cuò)的話 你要手動(dòng)把這個(gè)版本號(hào)調(diào)低一點(diǎn)

28 compile ‘com.android.support:appcompat-v7:23.0.1’

29 compile ‘com.android.support:design:23.0.1’

30 //對(duì)這個(gè)androidTestCompile不理解的 可以參考我的博客里講gradle的那篇

31 androidTestCompile ‘com.android.support.test:runner:0.4’

32 androidTestCompile ‘com.android.support.test:rules:0.4’

33 androidTestCompile ‘com.android.support.test.uiautomator:uiautomator-v18:2.1.2’

34 }

復(fù)制代碼

然后變更一個(gè)conifg

然后我們就可以在studio里面直接run我們的testcase啦：

好，然后我們來假設(shè)一個(gè)場景，假設(shè)我們現(xiàn)在要做的功能是 有一個(gè)界面，界面上有2個(gè)輸入框，你在這2個(gè)輸入框里輸入數(shù)字以后，點(diǎn)擊計(jì)算按鈕

另外一個(gè)textview 就會(huì)顯示出來 2個(gè)數(shù)字相加的結(jié)果。 那我們的testcase就要來完成 用戶模擬操作的這個(gè)過程 并且看看結(jié)果是否和我們預(yù)想中的相匹配！

（假設(shè)我們現(xiàn)在的android代碼里這個(gè)計(jì)算的代碼是有錯(cuò)誤的）

1 textView.setText（Integer.parseInt（et1.getText（）.toString（）） + Integer.parseInt（et2.getText（）.toString（）） + 1 + “”）;

你看 這里 我故意加了一個(gè)1.

然后寫我們的testcase 注意testcase的位置

然后看一下這個(gè)testcase的代碼：

package com.example.administrator.testcaseone;

2

3 import android.support.test.uiautomator.UiAutomatorInstrumentationTestRunner;

4 import android.support.test.uiautomator.UiAutomatorTestCase;

5 import android.support.test.uiautomator.UiDevice;

6 import android.support.test.uiautomator.UiObject;

7 import android.support.test.uiautomator.UiObjectNotFoundException;

8 import android.support.test.uiautomator.UiScrollable;

9 import android.support.test.uiautomator.UiSelector;

10

11 /**

12 * Created by Administrator on 2016/1/5.

13 */

14 public class FirstUiautomatorTest extends UiAutomatorTestCase {

15

16 public void testDemo（） throws UiObjectNotFoundException {

17

18 UiDevice.getInstance（getInstrumentation（））;

19 //19-27 行 其實(shí)就是用這個(gè)框架提供的功能來直接啟動(dòng)你的app.

20 //這里其實(shí)主要就是要找到你的app那個(gè)textview 然后點(diǎn)擊他 具體api自己去慢慢看吧

21 getUiDevice（）.pressHome（）;

22 UiScrollable appViews = new UiScrollable（new UiSelector（）

23 .scrollable（true））;

24 UiObject myApp = appViews.getChildByText（new UiSelector（）

25 .className（“android.widget.TextView”）， “TestCaseOne”）;

26 //要等到新的窗口出來才繼續(xù)往下走

27 myApp.clickAndWaitForNewWindow（）;

28 //29-32行 就很簡單了，無非就是找到界面上的元素。

29 UiObject et1 = new UiObject（new UiSelector（）.resourceId（“com.example.administrator.testcaseone:id/et”））;

30 UiObject et2 = new UiObject（new UiSelector（）.resourceId（“com.example.administrator.testcaseone:id/et2”））;

31 UiObject bt1 = new UiObject（new UiSelector（）.resourceId（“com.example.administrator.testcaseone:id/bt1”））;

32 UiObject tv1 = new UiObject（new UiSelector（）.resourceId（“com.example.administrator.testcaseone:id/tv1”））;

33 //這里的sleep只是為了gif動(dòng)畫能顯示的更清楚罷了，一般我們自己寫的時(shí)候?yàn)榱擞美俣瓤煲稽c(diǎn) 是不會(huì)加sleep的

34 //某些特殊場景除外

35 et1.setText（“12”）;

36 sleep（3000）;

37 et2.setText（“21”）;

38 sleep（3000）;

39 bt1.click（）;

40 //12和21相加 明顯應(yīng)該是33，所以判斷下 我們的代碼是否正確

41 assertEquals（33， Integer.parseInt（tv1.getText（）.toString（）））;

42

43 }

44 }

然后直接run我們的這個(gè)defaluttest，看看模擬器會(huì)發(fā)生什么？

自動(dòng)都幫你模擬了用戶的操作，這個(gè)testcase就跑完了，然后看下我們的studio：

顯然的也報(bào)錯(cuò)了。并且這個(gè)工具能自動(dòng)捕獲ui錯(cuò)誤哦~~什么anr 之類的 都不在話下。有了他，我們就能為自己寫的代碼負(fù)責(zé)了，每次發(fā)版本之前 跑跑我們寫好的testcase

基本上就能保證我們app的絕大多數(shù)流程是ok的~~所以這個(gè)工具一定要掌握！至于他其他好多api 我就不過多介紹了，留給你們自己去探索吧！