app复杂业务逻辑自动化验证案例分享

这两天公司没什么事情，赶紧总结一下上半年的学习成果，上一篇文章是介绍了上传专项测试，这一篇是通过自动化减少测试人力的案例，如果有任何建议请联系我。
专项测试案例–上传成功率对比专项测试

今天这一篇，会给大家分享app自动化在项目中验证复杂逻辑的应用。在上一阶段，是实现了UI自动化对主流程的监控，只有apk版本通过了基本的UI自动化用例，才可以提测，一定程度提高了转测的产品质量，提升了我们测试的效率。然而，自动化的正真功效当然不止主功能逻辑监控，它还可以在复杂逻辑上起到自动化校验，可以节省人力，那么这篇就是给大家分享下项目中编写的这个实现。

第一步，分析需求痛点

分享功能基本上是没一个项目都支持的功能，因为我们的项目是全景项目，和传统的直接扔一个图和一个链接不同，复杂度大大上升(流程可以参考上一篇文章)。同时，由于是面向国内外用户，所以平台覆盖是需要非常多的，搜索代码发现，有如下几十种类型，可怕：

同时，由于不全是链接形式分享，导致每个分享平台支持的分享类型和分享方式各不相同，比如支持全景识别的平台需要通过sdk上传，不支持的需要通过链接上传，又比如youtube只支持视频分享…最后可以总结成几个字：杂、多、乱。这对测试来说是一个不小的挑战，如果全覆盖的话会有130+种测试点需要覆盖，如果每个用例耗时5、6分钟，那么每次发版需要一天半。是的，仅仅是分享这个需求就要1.5d，再加上其他需求，发一个版本的完全测试时间就需要将近一周，测试人员基本是累死的节奏，那么就迫切需要某种手段去解决这个难题。

第二步，手工测试时期如何快速上线

知道了问题所在，我们就需要想办法解决了，在项目初期，产品处在快速迭代阶段，我使用的方式是部分用例覆盖 + 随机抽查(用户场景)。这个是什么意思呢？
假如你有500条用例，你本次迭代只运行一部分p0级别的用例，然后依照用户使用习惯抽取最常用的用户场景进行测试，等待下次迭代或者下下次迭代再把遗留用例执行完毕。

优点很明显，减少组员的测试时间，同时又保证了基本功能。缺点也很明显，覆盖率不会太高，有盲