像 google 一样测试系列之三：方案选型篇

作者：郑小辉团队：腾讯移动品质中心TMQ

三种测试模式预研

在测试代码放在什么位置上，及如何运行上， 经历了如下过程：

最初模式：采用google官网单测模式：Local unit tests和 Instrumented Tests。

但：组内希望与大组保持一致，即用testng，提供一个界面点击后运行用例。同时是运行在业务app内。

因此，模式a诞生

模式考虑：和开发代码写在同一目录下，以不同package区分，同时新建测试activity界面供点击运行用例，整体测试代码编进开发代码以app运行。

缺点：

（1）和业务耦合太大，业务app在打包时需要裁掉测试代码和资源，和mainfest.xml中的测试元素。开发也不建议写在一起；

（2）同时都能以命令行运行了，还要搞界面来点击运行用例，感觉多此一举；

（3）测试范围上有些减少，比如 Android层的测试，Activity内一些private的逻辑的测试，则测试不了。非要测，就会变成触发UI点击来测，就变成了UI自动化了；

（4）与google单测理念不一致，一些google提供的测试库不支持；

（5）调试不方便，每调试一次，都要打一次包，而打包耗时较久。

优点：

（1）测试代码是在真的Android环境上执行；

（2）可以直接调用业务代码和被测接口。

综上，考虑到该模式，在测试范围，业务代码耦合，CI上，均不够好，因此放弃。

希望继续保持和大组一致，诞生了模式B。

模式考虑：因为目前小组内的产品，均是AS+gradle开发环境，而且AS+gradle也是行业趋势。因此，新建module，类型为lib，测试代码写在module下，同时被业务module依赖，相当于手管插件方式。和业务代码统一打成app，真机运行。

缺点：

1.、需要先运行业务app，才能触发测试代码，如果还需要和大组有界面点击运行，仍然需要在业务代码上 增加该代码，也是有耦合，同时业务app在打包时，需要裁掉该代码；

2、因为module只能是lib，因此被测接口要反射来调用，不能直接调用；

3、调试不方便；

4、业务打包，要裁掉该module；

5、测试范围上同样有些减少，比如 Android层的测试，Activity内一些private 的逻辑的测 试，同样测试不了。

优点：

1、测试代码剥离了，和业务耦合小了点。也可以不用界面点击来运行；

2、测试运行环境为真Android环境。

综上，考虑到该模式，在测试范围，调试方便性，均不够好，因此放弃。

最终还是回归到了最初模式：Local Unit Tests和Instrumented Tests。

[1506067687824_2376_1506067890819.png]

方案选型

在经过各模式的预研，实践，选好测试模式后，选用什么框架来测试也是个选择。

考虑的是：Robolectric。

[1506067699217_6372_1506067901963.png]

Robolectric样例代码：

[1506067707496_708_1506067910309.png]

综上：

1、从Robolectric样例代码可以看出，目前Robolectric 基本是 从UI层介入，理论上可以忽略UI层，测试单一组件的逻辑，但关键的是不能测试组件的集成逻辑。

2、android层的测试也是运行在PC端的，它并不能测试业务app在真实Android环境上的表现。

因此，最终放弃了Robolectric，选择了Local Unit Tests和Instrumented Tests。

未完待续......

搜索微信公众号：腾讯移动品质中心TMQ，获取更多测试干货！