Dropbox每天会进行近35,000次构建，执行数百万个自动化测试用例。其中有一些测试可能会由于代码变更而执行失败，有一些执行失败的测试用例无法重现。因为Dropbox的测试规模很大，手动禁用失败的测试用例、回滚错误的代码提交以及通知测试所有者是很困难的。于是，Dropbox开发了Athena，目的是为了自动化这些操作。Athena可以将测试的失败用例通知给测试所有者，并检测和隔离失败的测试。它不会回滚错误的代码提交。
代码提交从基本的“预提交”测试开始，与主分支合并后进行“后提交”测试。后提交测试的成本比较高，包括UI和端到端测试。这一类测试会因为时间、日期和基础设施等环境因素发生失败，也有可能会因为并发性和随机数生成等代码固有特点而发生失败。Dropbox之前有一个轮班团队负责回滚这些变更。InfoQ联系了Dropbox的软件工程师Utsav Shah，了解更多有关Athena的细节。
Athena使用一种多步骤算法来确定一个测试用例是否存在问题。在一个周期内失败多次的后提交测试将被标记，并且允许代码通过。失败的测试将继续运行，以便确定失败是因为故障还是因为糟糕的代码导致的。Athena还可以指出导致测试失败的代码提交位置。该系统通过自动隔离这类测试减少了Dropbox的运行开销。Shah指出，Athena被用来“监控Dropbox所有服务（后端、前端）的大部分测试，不过还没有被用来监控桌面或移动应用程序的测试。”
Dropbox使用了持续集成（CI），尽管不同服务的部署策略不同。Shah表示：
Dropbox的后端服务由很多特定团队负责，还有一个主要的Web应用程序在支撑dropbox.com。我们要求所有相关的测试用例都是绿色的，非活动站点/实验性服务除外。一些服务所有者选择了持续部署，而另一些则喜欢手动部署。
Athena提供了一个用户界面用来监控服务的状态，为开发者提供可见性，Shah解释说:
我们显示每个测试用例的进度指标，以及它们基于不同代码提交的执行结果。每个测试用例都有一个对应的消息，指出哪个代码提交处于平分线状态，以及可能会导致测试失败的下界和上界。如果进度紧急，他们可以自己捕获并解决问题。
那么如何监控Athena系统呢？Shah说，在这方面需要做更多的工作：
我们有一组单元测试，它们使用内部CI系统的一个虚拟版本来捕获业务逻辑中的回归问题，比如平分线中的bug。我们针对CI系统进行集成测试，验证API的保证机制，这样可以捕获大多数问题。
Dropbox的服务编排系统可以自动生成警报，捕捉很多基本问题。不过我们还没有对Athena进行实时监控。除非CI系统出现了问题，否则系统通常可以正常工作，我们大多数人都已经知道这种情况了。当某些上游API运行缓慢并且出现超时时，由于缺乏监控，有时会出问题，因此我们正在考虑添加一些基本警报来捕捉这些问题。
Athena功能路线图中包含了自动回滚错误的代码提交和桌面测试。由于存在内部依赖关系，目前还没有将其开源的计划。
原文链接：
Athena: Automated Build Health Monitoring at Dropbox Engineering