随着产品发布越来越快，渠道包越来越多，渠道包自动化验证重要性逐渐凸显出来，需要将大把的人力从中解放出来，且避免人工失误造成的验证不完全；
　　最近客户端产品尝试使用渠道包自动化测试的方法，这里说说我们目前的做法；
　　需求：验证渠道包的 渠道号、使用到的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编写的测试用例执行，但该方法不一定对所有产品试用，如果渠道包的代码经过混淆，那么无法使用；
　　其实如果项目组里的自动化做得比较好的话，这里的冒烟脚本可以直接使用日常使用的冒烟脚本