无标题

[易木]

记一次基于 Robotium 改造的测试实践

1、前言

去年年终复盘，测试这边留了两个 Action：一是自动化工具推广，提高开发可操作性；二是 App 自动化稳定性及推广。如何提高可操作性？如何推广？由此便萌生了要做一个专门的 App。
今年初，我们上线了买家端入口，产品采用大量 H5 开发，随着产品迭代的加快以及开发测试比的增加，老的框架已经无法满足新的挑战：

开发自测
前端页面变动频繁（目前来看这点还好）
App 上各类组件的测试
获取测试覆盖率

无论如何，对于本篇读者我都默认你已经会了一点 Android 测试开发的基础。本篇不谈论做 UI 自动化的投入产出比，而是对 Android 测试技术的研究和一些想法，希望能给到测试开发们工作上的一些帮助。

2、我们的需求

给开发自测用
增强 H5 测试能力
支持组件测试，但不限于 UI 组件
能稳定支持 Api >= 15 以上版本
方便扩展其他的能力

其中如何能让开发方便使用是本次改造的核心需求。按我的理解，越是简单的操作方式越是方便，所以需求又具体到：

要在真机上脱机运行
界面操作越简单越好

所以，最终的界面成了这样：
1 个页面 + 1 个按钮。空白的部分是给结果打印留的位置（虽然有点丑，但简单）。
整体流程如下：

3、实现

先说说工具大致的架构：

解释：

Instrumentation： Google 测试框架。Robotium 就是在此之上做的封装。通过它来启动被测应用，从而被测应用和测试代码是出于同一进程中。
Service： 监听和控制测试任务的开始和停止。在测试 App 启动时作为 service 启动。
Util、Helper、Model、Config： 其中 Helper 提供给 service 调用，作为任务启动的入口。Model 是一些 Javabean。Config 配置类，主要配置被测应用的包名和主 Activity 包名。
CrashHandler、Reporter、Receiver： 用于监控 crash、发送邮件报告、接收三方推送消息，在 APP 启动时初始化。
testcase： 粗粒度的 UI 测试用例，和一些组件测试用例。
BroadCast： 现在是通过广播的方式，在主线程和子线程之间进行通信。在这里就是由主线程向 service 发起任务开始和结束的信号。
第三方云推送平台： 通过 CI（持续集成）平台向三方发送任务推送，最终推送到手机上。

下面是主要实现过程。

3.1 框架选择

有了需求就拿需求去套，看目前哪个开源框架满足。比较了下业界比较流行的框架，最后还是选择了 Robotium。首先它是基于 Android 官方 Instrumentation 测试框架上做的封装，支持所有的 Api 版本，其次通过 Js 注入的方式，对 H5 测试更好的支持，并且可以使用 Js 进行功能扩展，而且能够很方便的进行二次开发，在 BAT 自主研发的 Android 测试框架中很多是基于它。
顺便提下为什么不是 UIAutomator？Espresso？答：因为不支持 WebView 哦。

3.2 框架改造

本次主要基于 Robotium 对 Webview 相关的测试能力进行改造，加了一些自定义的 JS 方法，用来满足 WebCache 组件的测试需求。

3.2.1 原理

先说说 Robotium 是如何来操控 Webview 的：如上图，主要涉及到的类有两个 WebUtils 和 RobotiumWebClient。简单来讲，过程是这样的：在执行某个方法，如 getWebElements() 时，Robotium 先将当前 webview 的 WebChromeClient 替换为自己的 RobotiumWebClient，在 RobotiumWebClient 里面重写了 onJsPrompt()，当 Js 里面有调用到 prompt() 的地方，都会走到这个方法里面，收到内容后再封装成 WebElement。
替换后，getJavaScriptAsString() 再拿到 RobotiumWeb.js 的内容通过 webview.loadUrl("javascript:") 的方式注入到当前页面中。
所以，从这里能看出来，主要实现的方法都在 RobotiumWeb.js 这个文件里面，我们的目的也是往里面增加方法。

3.2.2 动手

根据需求，本次我们要完成 WebCache 组件的测试。测试用例需要验证每个 H5 页面中的静态资源部分可用性，包括 js、css 和图片，另外还需要对组件性能进行评估，最后，还有机型兼容。
如果是手工测试，需要将我们产品下面所有页面都点一遍，看图片有没有正常加载，操作是否顺利，完了后还要记录页面加载时间、资源个数等数据，然而肯定不是测一遍就完事，肯定是要测多遍取平均值。因此我们要自动化，要改造 RobotiumWeb.js。
与前端同学沟通过，判断当前页面图片是否加载，可以从以下两个方面：

加载完成后判断当前图片真实的宽高（naturalWidth、naturalHeight）
如果是懒加载图片还需要判断 data-src 和 src 是否相同

因此，我们改动的内容如下：

function allDirtyImgs(){  
    var imgs = document.querySelectorAll('img');
    for (var key in imgs){
        try{
            if(typeof(imgs[key]) == "number"){// 这个情况过滤
                return
            }
            promptDirtyImg(imgs[key]);          
        }catch(ignored){}
    }
    finished();
}
123456789101112

// promptDirtyImg部分 -->
    var w = element.naturalWidth;
    var h = element.naturalHeight;
    var src = element.getAttribute('src');
    var da = element.getAttribute('data-src');
    if(da ==null && (w == 0 || h == 0) ){
        prompt('');
    }else if(da != null && url !=null && url != da) { 
        prompt('');
    }
12345678910

然后，在 WebUtils 类里面封装一个 getAllDirtyImgs() 的方法暴露给 Solo，就能直接调用 Solo 了。

boolean javaScriptWasExecuted = executeJavaScriptFunction("allDirtyImgs();");  
1

获取性能数据需要开发同学配合写到 SD 卡中，再常规测试结束后，在通过访问 Sd 卡来拿到数据。最后清理当前数据，这样保证每次测试都是最新。

3.2.3 免不了的失败重试

对于 UI 测试，总会有不稳定的时候，所以此时失败了重新再跑一遍少不了。我们在测试基类里面同样加入了重试机制：

@Override
protected void runTest() throws Throwable {  
        int retryTimes = 3;
        while(retryTimes > 0)
        {
            try{
                super.runTest();
                break;
            } catch (Throwable e)
            {
                if(retryTimes > 1) {
                    retryTimes--;
                    tearDown();
                    setUp();
                    continue;
                }
                else
                    throw e;  //记得抛出异常，否则case永远不会失败
            }
        }
    }
123456789101112131415161718192021

3.3 脱机

刚开始，也和网上大部分人一样，在 App 里面我是通过命令方式来启动测试：

Runtime.getRuntime().exec("am instrument");  
1

但是很快就发现，在 Android4.2（Api 17）以上由于权限问题导致不可运行。最终解决方案调整为调用在 Context 下面的 startInstrumentation (ComponentName className, String profileFile, Bundle arguments) 方法。比如：

ComponentName componentName = new ComponentName(packageName, InstrumentationTestRunnerClassName);
mContext.startInstrumentation(componentName, null, null);  
123

参数： packageName： 测试 App 的包名。 InstrumentationTestRunnerClassName： TestRunner 的类名。

3.3.1 脱机持续集成

以往，我们的 CI（持续集成）构建是基于虚拟机或者有 USB 连接线通过 ADB 的方式进行，那么现在是脱机了如何做到？答案是：PUSH。
我们在客户端上集成了三方平台的云推送，在 CI 环境（如 Jenkins）上，封装了云推的透传 API 接口，大概的构建命令像这样：

java -jar /Users/youzan/apis/AppPushServer.jar -run true -mail true -address xx@xx.com -channelId xxx  
1

-channelId不传，默认推给所有手机，如果要单点推送，需要知道手机的channelId。 -mail true :运行结果会通过邮件，以HTML报告的形式发送。
这种方式缺陷很明显：不能保证手机 100% 收到消息，受网络和软件环境的影响较大。
目前，我们主要使用这种方式来做 H5 页面的回归测试和线上接口的稳定性监控。
最后补充一下，毕竟还是涉及 UI 的测试，考虑到执行效率和稳定，我们最终选用作为持续集成的用例仅占到全部用例的 10% 左右。

4、集成其他工具

4.1 集成 UiAutomator

用过 Robotium 的同学都应该知道，我们的测试应用和被测应用处在同一进程的不同线程中，所以如果有需求是跳其他进程（如：调摄像头、相册、手机通知栏）进行操作，Robotium 自己是做不到的。好在 google 在 uiautomator2.0 以上为我们提供了这样的能力，并且可以直接使用 getInstance() 拿到 device 实例。

UiDevice device;  
device = UiDevice.getInstance(getInstrumentation());  
12

值得注意的是： 如果通过上面我们使用的 mContext.startInstrumentation() 去启动测试是拿不到device实例的，此时就必须是通过执行"am instrument"命令的方式去启动。

4.2 覆盖率统计

由于我们的开发都是使用 gradle 进行打包，而 gradle 自带了 jacoco 的插件，所以我们在被测应用的 build 中加入

buildTypes {  
        debug{
            testCoverageEnabled = true // 主要是这里
        }
}        
12345

便开启了统计。
为了生成可读性更好的报告，可以再增加task命令来指定源码路径和忽略一定规则的 class，如：

def coverageSourceDirs = [  
    '../app/src/main/java'
]
task jacocoTestReport(type: JacocoReport) {  
    ...
    classDirectories = fileTree(
            dir: './build/intermediates/classes/debug',
            excludes: ['**/R*.class',
                       '**/*$InjectAdapter.class',
                       '**/*$ModuleAdapter.class',
                       '**/*$ViewInjector*.class'
            ])
    sourceDirectories = files(coverageSourceDirs)
    executionData = files("$buildDir/outputs/code-coverage/connected/coverage.ec")
}
123456789101112131415

然后，需要测试应用执行测试结束的时候，在指定路径生成覆盖率文件coverage.ec，主要调用是：

out = new FileOutputStream(CoverageFilePath(),false);  
Object agent = Class.forName("org.jacoco.agent.rt.RT").getMethod("getAgent").invoke(null);
out.write((byte[])agent.getClass().getMethod("getExecutionData", boolean.class).invoke(agent, false));  
1234

最后，将coverage.ec从手机 pull 下来放到被测应用下outputs/code-coverage/connected下面（注意一定要是这个路径），执行gradle jacocoTestReport最终生成 html 报告。

5、为了改进

到此，我们这个测试 App 能满足我们 90% 日常测试的需求，可是，要完全当作持续集成来用，还有一些事情要做：

自动拉取被测包并静默安装
聚合报告（将所有手机上的运行结果汇总后，再邮件通知收件人）
对 Robotium 再次封装，满足动态用例管理
用例推送执行（测试用例以 json 或 xml 方式推送到手机上执行）
基于 Robotium 控件遍历的 monkey 测试

以上就是我在平常工作中从一些想法到最后实施的过程。虽然实现上可能不是最好的，也还有些功能待完善，但希望可以借此起到抛砖引玉的效果，帮助无线测试开发们提升产品的测试效率和提高覆盖率。
欢迎关注我们的公众号

↙↙↙阅读原文可查看相关链接，并与作者交流