随着产品发布越来越快，渠道包越来越多，渠道包自动化验证重要性逐渐凸显出来，需要将大把的人力从中解放出来，且避免人工失误造成的验证不完全；
最近客户端产品尝试使用渠道包自动化测试的方法，这里说说我们目前的做法；
需求：验证渠道包的 渠道号、使用到的URL地址，以及简单冒烟；
一、验证渠道号
三个方法，根据产品自身的情况而定；
1. 通过反编译apk包获得 渠道号
说明：apk的 res/xml下存放渠道号信息，如存放在 channel.xml文件里
（1）使用apktool工具，反编译apk，从 channel.xml中取出 该包的渠道号；
（2）从apk文件名称截取出渠道号；
两两进行对比；
2. 从logcat获取渠道号信息
说明：客户端启动时，打印渠道号信息
（1）启动客户端，从logcat日志中，截取出渠道号；
（2）从apk文件名截取出渠道号；
两两进行对比；
具体渠道号信息如何存放，可以同项目组进行讨论商定。
3.（1）编写单元测试用例（可以用athrun框架），读取出渠道号；启动客户端，通过命令执行该测试用例，即可获得渠道号
（2）从apk文件名截取出渠道号；两两进行对比；
二、URL地址验证
两个方法，类似签名的渠道号验证：通过反编译获得URL，或者通过启动客户端时，截取logcat日志获得；
当然事先要准备期望的URL地址列表；
验证URL的目的，是因为，发布apk使用的现网地址与测试环境地址是不同的，要确保打出的各渠道包的URL地址使用是否正确。
三、简单冒烟
目的：验证各渠道包基本功能是否可用，根据实际情况写脚本；
下面介绍2个方法：
1. 使用monkeyrunner验证简单功能；
2. 通过athrun编写的测试用例执行，但该方法不一定对所有产品试用，如果渠道包的代码经过混淆，那么无法使用；
其实如果项目组里的自动化做得比较好的话，这里的冒烟脚本可以直接使用日常使用的冒烟脚本
最新内容请见作者的GitHub页：http://qaseven.github.io/