本文主要是介绍【腾讯TMQ】像google一样测试系列之三：方案选型篇，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
三种测试模式预研
在测试代码放在什么位置上，及如何运行上， 经历了如下过程：
最初模式：采用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。
方案选型
在经过各模式的预研，实践，选好测试模式后，选用什么框架来测试也是个选择。
考虑的是：Robolectric。
Robolectric样例代码：
综上：
1、从Robolectric样例代码可以看出，目前Robolectric 基本是 从UI层介入，理论上可以忽略UI层，测试单一组件的逻辑，但关键的是不能测试组件的集成逻辑。
2、android层的测试也是运行在PC端的，它并不能测试业务app在真实Android环境上的表现。
因此，最终放弃了Robolectric，选择了Local Unit Tests和Instrumented Tests。
未完待续……
关注微信公众号：腾讯移动品质中心TMQ，获取更多测试干货！
这篇关于【腾讯TMQ】像google一样测试系列之三：方案选型篇的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
