如何加速执行Android UI测试作为CI系统的一部分

概述我想要所有的单位&每次提交/合并到主开发分支后运行的检测测试(Espresso).单元测试足够快,允许这样做,但UI测试不是 – 150个完全模拟的UI测试需要大约1小时才能在单个设备上运行. Shazam’s FORK library在所有连接设备上对这150个测试进行分片时表现非常出色.目前的解决方案是运行Jenkins的本地计算机.将4个设备连接到它可以将运行UI测试的时间缩短到约15分钟. 我想要所有的单位&每次提交/合并到主开发分支后运行的检测测试(Espresso).单元测试足够快,允许这样做,但UI测试不是 – 150个完全模拟的UI测试需要大约1小时才能在单个设备上运行. Shazam’s FORK library在所有连接设备上对这150个测试进行分片时表现非常出色.目前的解决方案是运行Jenkins的本地计算机.将4个设备连接到它可以将运行UI测试的时间缩短到约15分钟.这不是理想的,但可以忍受.

理想情况下,我想找到一个基于云的CI系统,它允许我使用Fork运行UI测试,以便本地Jenkins可以被抛弃而不是内部维护.

我尝试了AWS Device Farm和Firebase Test Lab,但两者都使用他们自己的系统来运行测试.似乎他们没有给出在多个设备上分割单个测试套件的选项.它们似乎是同时在不同设备上运行整个测试套件的好工具,但这不是我想要的CI解决方案(将测试套件同时拆分到多个设备).

尝试了BuddyBuild,但在内部他们使用Firebase测试实验室,所以这对我的情况也不起作用.

我主要考虑的是这些方向的解决方案：

>找到一种在基于云的解决方案上运行Fork的方法
>找到另一种方法来跨多个设备分割单个测试套件

欢迎任何建议！你们是如何解决这个问题的？

解决方法 恭喜！太多的自动化是一个很大的问题.听起来你已经在加快执行时间方面取得了很多进展.我说15分钟是一个非常合理的数字,但是这里有一些替代方法可以让这个数字更低：

>创建一个更小,更快的测试用例,每个提交运行最高优先级测试用例,而长时间运行的完整测试套件针对最新的合并提交连续运行.这是整个行业中非常普遍的模式.您可以使用AndroID的内置@Small,@Medium,and @Large annotations或软件包名称来划分测试.
>优化测试用例,以便一次测试多个功能.基本上,不是测试A1,A2,B1,B2等每个组合,而是仅测试A1,B2.有关更详细的说明,请参阅pairwise testing Wikipedia page.
>如果您的应用程序可以使用,请尝试使用模拟器.在过去几年中,性能有了很大提高.使用英特尔硬件加速执行管理器(HAXM)驱动程序,我发现测试比大多数物理设备运行得更快,更可靠.这也可以使您的目标更容易在云中运行.
>检查每个单独测试运行的时间与其优先级相对应.低优先级长时间运行测试可以移动到不太频繁运行的测试.
>观察测试运行以识别测试的睡眠或其他慢速运行区域以改善.
>寻找从未失败的测试.这些也可能是转向不常运行测试的另一个候选者.
>如果您正在寻找分片测试的其他方法,您可以通过使用adb shell am instrument选项在针对您的测试子集的设备之间启动并行脚本来推出自己的方法.虽然,这会创建许多单独的测试报告,您需要自己平均分配测试.

总结

以上是内存溢出为你收集整理的如何加速执行Android UI测试作为CI系统的一部分全部内容，希望文章能够帮你解决如何加速执行Android UI测试作为CI系统的一部分所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。