Netflix设备的自动化测试(上)(2)

无测试结构约束
使用自动化系统不应限制于特定格式编写的测试。重点在于这样做便于未来能够创新测试的编写方式。此外，不同的团队（我们与负责平台，安全，播放/媒体/ UI等的团队进行了交流）可能会提出不同的方法来构建测试，以更好地满足他们各自的需求。确保自动化系统与测试结构解耦从而提高其可重用性。

测试层尽量少的抽象层（Few layers at the test level）
当构建大规模系统时，很容易终止于太多的抽象层。虽然这在许多情况下这样做并不是不好，但是当这些层也被添加到测试中以便能让它们与自动化集成时，这就会出现问题。事实上，这会导致你离实际需要测试的功能越来越远，并且在问题出现时将很难调试：在被测的应用程序之外的很多调用可能会出错。

在我们的案例中，我们在设备上测试Netflix，因此我们要确保在设备上运行的调用函数尽可能靠近正在测试的SDK功能。

支持重要的设备功能（Support important device features）
手动完成设备管理需要消耗大量时间，因此这是一个优秀的自动化系统的应该占的很大组成部分。 由于我们测试正在开发的产品，因此我们需要能够即时更改构建并将其部署到设备。 提取日志文件和崩溃转储对于自动化也非常重要，以便将调试测试失败过程能按流水线处理。

设计自动化（Designing automation）
通过这些目标，我们的团队需要一个提供必要的自动化和设备服务的系统，同时尽可能地避免与测试模块耦合。

这需要重新思考现有框架并创建一种新型的自动化生态系统。为了使自动化具有这种灵活性，我们需要自动化系统是精细的，模块化的，并且只有在确实需要测试某个功能时才需要外部服务，也就是说只有当某个功能不能从设备上的应用直接完成才会请求外部服务（例如挂起应用程序或操纵网络）。

原文转自：http://www.ltesting.net