设备自动化测试

AlexQin

测试框架

测试框架完全独立于自动化服务，因为测试框架只是用于在设备上运行测试所用。大部分测试可以无须自动化服务手工运行，而这也是设计这套系统时的一个核心原则。这种情况下可以手工启动测试，并在测试完成后的手工获得并查阅结果。

然而测试框架也可以配合自动化服务使用（例如用测试服务存储测试进度和结果）。如果通过运行器在CI中运行测试，我们需要将其与自动化服务相集成。

为了用灵活的方式实现这一目标，我们创建了一个在内部被称之为TPL（Test Portability Layer）的抽象层。测试和测试框架通过调用这个抽象层可以为每个自动化服务定义一个简单的接口。每个自动化服务可提供这些接口所需的实现。

针对该系统所实现的服务，这个抽象层可以让原本需要自动运行的测试能够通过TPL接口提供的截然不同的自动化系统来运行。这样就可以让其他团队（使用其他自动化系统）编写的测试案例不经改动直接运行。如果测试无须改动，设备上测试运行失败后就无须由测试的所有者进行排错，这正是我们希望实现的。

AlexQin

进展

通过让测试框架与自动化服务保持独立，按需使用自动化服务并增添所需的设备功能，我们实现了：

• 将自动化测试机制扩展至更大范围的游戏主机和参考应用程序。
• 将这一基础结构扩展至移动设备（Android、iOS，以及Windows Mobile）。
• 让其他QA部门借此执行自己的测试，并将自动化框架应用给我们的设备基础结构。
  
  

从最新的测试执行覆盖图中可以看到，仅针对参考应用程序，每个构建版本已执行了大概1500次测试。从全局的角度来看，开发团队每天会为每个分支生成大约10-15个构建版本，每个版本包含5个不同用途（例如调试、发布、AddressSanitizer等）的参考应用程序。对于游戏主机，每天每个用途会生成大约3-4个构建版本。总的来说，针对单一用途的构建版本，我们的生态系统每天可以运行大约1500*10 + 1500*3，即大约2万个测试案例。

AlexQin

新的挑战

考虑到每天要运行大量测试，我们又遇到了两个重要的挑战：

• 设备和生态系统的缩放性和弹性
• 测试结果造成繁重的遥测分析负担
  
  

在后续文章中，我们将深入介绍为了解决上述两大挑战，目前我们所采取的一系列创新措施。

作者：Benoit Fontaine、Janaki Ramachandran、Tim Kaddoura、Gustavo Branco，阅读英文原文：Automated testing on devices

AlexQin

原文地址： http://www.infoq.com/cn/articles/equipment-automation-test