我喜欢所有单位＆amp;每次提交/合并到主develop分支后运行的检测测试（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的方法欢迎任何建议！你们是如何解决这个问题的？
答案 0 :(得分：7)
恭喜！太多的自动化是一个很大的问题。听起来你已经在加快执行时间方面取得了很多进展。我说15分钟是一个非常合理的数字，但是这里有一些替代方法可以让这个数字更低：
创建一个更小，更快的测试用例，每个提交运行最高优先级测试用例，而长时间运行的完整测试套件针对最新的合并提交连续运行。这是整个行业中非常普遍的模式。您可以使用Android的内置@Small, @Medium, and @Large annotations或软件包名称来划分测试。
优化测试用例，以便一次测试多个功能。基本上，不是测试A1，A2，B1，B2等每个组合，而是仅测试A1，B2。有关更详细的说明，请参阅pairwise testing Wikipedia page。
如果您的应用可以使用，请尝试使用模拟器。在过去几年中，性能有了很大提高。使用英特尔硬件加速执行管理器（HAXM）驱动程序，我发现测试比大多数物理设备运行得更快，更可靠。这也可以使您的目标更容易在云中运行。
检查每个测试运行所需的时间与其优先级相对应。低优先级长时间运行测试可以转移到不太频繁运行的测试。
观察测试运行以确定测试的睡眠或其他慢速运行区域以进行改进。
寻找从未失败的测试。这些也可能成为转向不常运行测试的另一个候选者。
如果您正在寻找分片测试的其他方法，您可以通过使用adb shell am instrument选项在针对您的测试子集的设备之间启动并行脚本来推出自己的方法。虽然，这会创建许多单独的测试报告，您需要自己平均分配测试。
答案 1 :(得分：2)
可能会看一下Flank open source project，它似乎是以几乎相同的目标构建的：https://medium.com/walmartlabs/flank-smart-test-runner-for-firebase-cf65e1b1eca7
Flank是Firebase测试实验室工具，可用于大规模扩展您的自动Android测试。同时在多个设备/版本/配置上并行运行大型测试套件。 Flank可以很容易地在CI环境中使用，其中Gradle（或类似）首先构建APK：s然后Flank用于执行测试。
答案 2 :(得分：0)
我也会投票给上述建议，特别是第1项 “创建一个更小，更快的测试用例，每个提交运行最高优先级测试用例，而长时间运行的完整测试套件针对最新的合并提交持续运行。这是整个行业中非常常见的模式。您可以使用Android的内置@Small，@ Medium和@Large注释或包名称来划分测试。 优化您的测试用例，以便在“
上测试多个功能使用注释并通过TestNG框架（通过Jenkins）推动执行将是将大型套件拆分为多个部分的一种方法 - 如果注释管理按逻辑组划分您的测试，那么合并结果也不会太痛苦（希望这有帮助）