这两天公司没什么事情，赶紧总结一下上半年的学习成果，上一篇文章是介绍了上传专项测试，这一篇是通过自动化减少测试人力的案例，如果有任何建议请联系我。
专项测试案例–上传成功率对比专项测试
今天这一篇，会给大家分享app自动化在项目中验证复杂逻辑的应用。在上一阶段，是实现了UI自动化对主流程的监控，只有apk版本通过了基本的UI自动化用例，才可以提测，一定程度提高了转测的产品质量，提升了我们测试的效率。然而，自动化的正真功效当然不止主功能逻辑监控，它还可以在复杂逻辑上起到自动化校验，可以节省人力，那么这篇就是给大家分享下项目中编写的这个实现。
第一步，分析需求痛点
分享功能基本上是没一个项目都支持的功能，因为我们的项目是全景项目，和传统的直接扔一个图和一个链接不同，复杂度大大上升(流程可以参考上一篇文章)。同时，由于是面向国内外用户，所以平台覆盖是需要非常多的，搜索代码发现，有如下几十种类型，可怕：
同时，由于不全是链接形式分享，导致每个分享平台支持的分享类型和分享方式各不相同，比如支持全景识别的平台需要通过sdk上传，不支持的需要通过链接上传，又比如youtube只支持视频分享…最后可以总结成几个字：杂、多、乱。这对测试来说是一个不小的挑战，如果全覆盖的话会有130+种测试点需要覆盖，如果每个用例耗时5、6分钟，那么每次发版需要一天半。是的，仅仅是分享这个需求就要1.5d，再加上其他需求，发一个版本的完全测试时间就需要将近一周，测试人员基本是累死的节奏，那么就迫切需要某种手段去解决这个难题。
第二步，手工测试时期如何快速上线
知道了问题所在，我们就需要想办法解决了，在项目初期，产品处在快速迭代阶段，我使用的方式是部分用例覆盖 + 随机抽查(用户场景)。这个是什么意思呢？
假如你有500条用例，你本次迭代只运行一部分p0级别的用例，然后依照用户使用习惯抽取最常用的用户场景进行测试，等待下次迭代或者下下次迭代再把遗留用例执行完毕。
优点很明显，减少组员的测试时间，同时又保证了基本功能。缺点也很明显，覆盖率不会太高，有盲区，实际体验下来大问题没有，小问题总会冒出来。
第三步，自动化可行性分析
于是纯手工测试成为了瓶颈，于是笔者开始尝试自动化解决方案。
在编写之前，我们需要先分析业务逻辑自动化的可行性，避免人力投入浪费(弯路我都走过,哭)。
首先需要列出所有的可能性：
平台x13 乘以 分享类型x2 乘以 分享画质x3 乘以 分享画面x3 乘以 分享画面比例x3
根据开发逻辑结果，是实现归类的方式上传的，也就是最终抽象出3类平台：使用sdk的为一类、使用连接的为一类，其他类型为最后一类。归类之后也就是说明可以根据平台类型判断最终判断输出的分享类型。
如下面关键代码：
if (isPhoto) {
if (isSupportPlainVideo()) {
... ...
}
if (isSupportLink()) {
... ...
}
if (isSupportPlainPhoto()) {
... ...
}
} else {
if (isSupportLink()) {
... ...
}
if (isSupportPlainVideo()) {
... ...
}
}分享画质部分是通过读取sharepreference的值进行判断，这一部分可以直接到用户设置的值，可以直接判断做处理。
分享的资源类型是可以通过endwith很方便的判断
其他的参数选择部分是考虑封装UI点击事件进行切换，那么经过这一轮分析后，我们发现自动化是可行的，于是进行下一部编码。
第四步，编写框架和编写思路
首先看看设计思路，整体流程是这样的：
选择资源–选择平台–进入分享面板–遍历面板的分享参数按钮–分享–断言
所以啊，我们是这样设计的：
核心的东西就是ShareTestManager类，负责接受一个分享平台列表，然后getter类解析分享的种类，并执行N个xxxmodel类的run方法：
for(ShareTarget shareTarget:shareTargets){ //分享平台
for(ITestModel iTestModel:new ShareTargetModelGetter(shareTarget,shareWork).getTestList()){ //获取分享校验模块
//SystemTools.launcherShareEditActivity(solo,shareWork.getUrl(),shareTarget);
iTestModel.run(solo,shareTarget,shareWork);
}
}然后xxxmodel其实是UI自动化的具体实现业务逻辑，在重写的run方法里面完成对UI的实际操作：
@Override
public void run(Solo solo,ShareTarget shareTarget,ShareWork shareWork) {
Log.i("holo","run model-->"+this.getClass().getName());
SharePageActions sharePageActions = new SharePageActions(solo);
ShareExportAssert shareExportAssert = new ShareExportAssert(solo);
for(String ratio:new String[]{"1:1","16:9","4:3"}){
for(String template:new String[]{solo.getString(R.string.template_animation_asteroid_to_around),
solo.getString(R.string.template_animation_around_to_magicball),
solo.getString(R.string.emplate_animation_multi_person_photograph),
solo.getString(R.string.template_animation_around_to_asteriod)}) {
SystemTools.launcherShareEditActivity(solo, shareWork.getUrl(), shareTarget);
sharePageActions.clickTemplateAnimation();
sharePageActions.clickTemplateRecycle(template);
sharePageActions.changeRatio(ratio);
sharePageActions.clickShareBtn();
solo.sleep(20000);
shareExportAssert.assertBitrate(3000,SystemTools.getDirLastModifyFile("/sdcard/dcim/camera","export"));
SystemTools.closeShareActivity(solo);
}
}
}UI的封装遵循PO模式，也就是吧界面的操作封装在一个类当中，这种实现好处是分离动作和业务逻辑，具体实现就略过了。
最终，断言也是调用了封装好的断言，包含两个部分：UI的展示和输出文件的属性判断，因为是公司私有封装格式属性，这里就不放出来了。
效果
每个迭代版本只需要机器执行，替代部分手动执行(注意是部分)，剩余部分需要手工补充，比如分享的不同参数类型的校验可以交给自动化，但是分享出去的效果，网络因素、重试等逻辑还是需要手动覆盖。但是至少，已经节省了非常多的人力了。
总结：
那么本篇主要分享的是UI自动化在复杂重复业务逻辑中的自动化验证，在引入自动化方案后，大大降低了人力的成本，使测试更加高效、准确，一定程度适应了敏捷开发的需求；同时也要明确，自动化最终只能是作为补充，不能完全替代人工，完全替代也有可能，但是得考虑成本问题，这个问题未来交给ai实现吧！