比如一个项目迭代很快，变化很多，为了提升 roi，那么我选择 calabash 作为 bvt。这样既能应对快速变化，又节省测试写 case 的成本.
然后现在盲从到最后发现也仅仅是 ui 自动化，得不偿失

注：
roi = rate output/input
bvt 版本验证测试 build verify testing or build valid testing

bvt 说完，说 regression。选择 robotium 的二次封装。动态获取控件 list，并做 mapping。然后写 regression test。ios 就用 ui automation。

然后说到 ci 的策略。有界面的 RGBA 验证，有 bvt，有 lint 扫描，有混淆包，有 android junit test 保证、基本可以 cover 很多

然后是性能和安全，一部分敏感词扫描，contentprovider 共享风险，sql 注入等。剩下的必须人为介入，分析，出报告

--RGBA ？Red（红色）Green（绿色）Blue（蓝色）和 Alpha 的色彩空间

然后说性能

除了大家知道的电量，流量，GC，界面启动，cpu，内存等。还有 GPU 使用消耗，bitmap 重复绘制，然后各种网络下不同的消耗。然后方法对应的 cpu 消耗，重复调用等

然后接下来是从 app 里层直接调用 api 方法，从客户端发请求，从客户端接请求。完全的从 cs api 的测试,验证点以前说过，很多。结构，key value，数据库落地等.

先说 ci 策略
android 原生目前最稳定，扩展性强的还是 instrumentation，uiautomator 本身不建议使用.
被动触发的话，lint 扫描，自己写的 python 安全扫描。都是代码扫描，findbugs。然后看 build，主要 ant ，mvn，gradle，然后看混淆包打出来是不是对。然后 bvt 的测试

然后主动的话，包括界面的 RGBA 的 check，然后是主要功能的 android junit test 开始跑，然后 ios 用 kif 或者 ui automation 开始跑。因为这种要依赖 device 或者 emulator 或者 simulator，所以效率会比较低。就放在晚上主动触发