# Whatsup是怎么做测试的


看到了一篇关于 whatsup 是如何做测试的文章，尽管里面有一些拍领导彩虹屁的嫌疑，不过还是可以让我们了解到 meta(whatsup 属于 meta)内部整体质量保障架构的情况。翻译了一下，供大家参考。原文地址: https://automationhacks.io/2023-10-18-how-whatsapp-tests-software

我正在思考 WhatsApp 团队如何测试其应用程序以及全球其他团队可以从他们的测试工程实践中学到什么。这也是很多人问我的一个经常性问题，所以让我们来揭开一些面纱，好吗？

### 测试方法

我在 2021 年底到 2023 年中期的一年半时间里，作为 WhatsApp 测试自动化团队的成员，在他们伦敦办公室工作，我有幸近距离观察了一个拥有 20 亿多用户的应用程序是如何进行测试的。

WhatsApp 测试自动化团队负责开发测试基础设施、工具和框架，以便让开发人员为 WhatsApp 客户端（尤其是 Android、iOS、Web 和桌面应用程序）编写高效的测试。这是整个组织测试策略的关键部分。

在某些方面，这些方法与其他面向消费者的移动应用程序相似，具有测试金字塔的各个典型层次。WhatsApp 团队倾向于使用许多开源工具来编写自动化测试，但也使用许多内部元工具和基础设施来加强整个测试策略。WA 的测试方法也与元应用程序有很大的不同。

在本文中，我将讨论两个关键因素，这些因素促成了自动化的强大文化。

- 框架和基础设施
- 支持这一文化的团队和角色

让我们深入探讨一下吧 🏊

### 测试框架

首先，让我们看看测试金字塔的不同层次，以及使用了哪些不同的工具和框架。

对于移动框架，自动化测试在测试金字塔的各个层次上进行编写，使用了大量的 Espresso 和 XCUITests，相对较少的 E2E 测试。

**Android**

- Unit tests: JUnit, Roboelectric
- UI tests: Espresso
- Screenshot tests: Screenshot tests for Android (read more about this here 🔗)
- E2E tests: Jest-based internal E2E testing framework

**iOS**

- Unit tests: XCTest
- UI tests: XCUI Tests
- Snapshot tests: Probably similar to GitHub - uber/ios-snapshot-test-case: Snapshot view unit tests for iOS
- E2E tests: Jest-based internal E2E testing framework

**测试基础设施**

WhatsApp 依靠许多内部元基础设施来进行设备测试和持续集成（CI）需求。

**代码覆盖率**

- 内部基础设施用于收集单元测试和 UI 测试的代码覆盖率
- 内部看板用于可视化代码覆盖率的趋势和指标

**版本控制**

- Git
- Mercurial

**Test Runner**
内部自研 Test Runner

**设备和模拟器**
内部系统

**Build**

- Android：Gradle，iOS：Xcode
- Buck2

**测试报告**

- 内部日志基础设施
- Scuba 中的测试监控
- 内部报告基础设施

**持续集成（CI**
内部 CI

**测试服务**

- 测试选择
- 测试建议
- 使用 Sapienz 进行 Monkey 测试
- 使用 Infer 进行静态分析

在收集这个列表时，我意识到 Meta（前 Facebook）是一家拥有令人敬畏的工程文化的公司，他们会将许多内部工具的博客开放源代码，并对其进行讨论。如果您想了解他们的测试方法的其他想法，我建议您关注 DevInfra 博客，并查看 GitHub 项目，以进一步了解如何在您自己的团队中采用其中的一些方法。

### 一大堆工具和框架 🧑‍🍳

令人着迷的是，有这么多丰富的工具和框架，都由可扩展的基础设施支持。因此，工程师们花费较少的时间来维护这些工具或解决基础设施问题，而是将重点放在编写测试上，知道只要按照推荐的实践编写测试，测试就会运行和扩展。

您可能还注意到，大多数这些工具在许多公司和初创企业中都得到了使用，也有开源解决方案来解决这些问题。

只是在 Meta，多年来通过大量的工程时间对内部工具进行了优化，并且它们相互之间非常好地集成，形成了一个生态系统。要理解所有这些并不是一件很容易的事情，而测试自动化基础设施团队有幸置身其中。

### 那么，WhatsApp 是如何“真正”测试其软件的呢？

在这一点上，您可能会想，WhatsApp 使用一堆工具来实现自动化测试，也许会想知道这些不同的团队和工程师是如何组织起来的。

让我们看看测试设置和涉及的主要角色。

### 工程师负责编写自动化测试

在 WhatsApp，开发人员自己编写大部分自动化测试。

他们编写应用程序代码，包括单元测试、UI 测试，有时还会编写一些端到端（E2E）测试。我之前在这个文化实践上写过一篇简短的笔记，如果感兴趣，可以在这里阅读。

这里，我主要指的是移动工程师，因为 WhatsApp 作为一款聊天应用程序，客户端占据了很大的比重。还有一些服务器团队也遵循类似的理念，他们自己编写测试。

在某种程度上，这是相当好的，因为工程师对他们的测试负责，并且对于任何 SEV（生产事故），他们自然会有动力编写适当级别的自动化测试来覆盖他们的代码并减轻任何风险。

我没有看到在特性团队中有任何专门的自动化团队，他们由 SDET（软件测试工程师）或 SET（软件工程师测试）人员来负责编写自动化测试，这在初创公司和许多其他公司中通常很常见。

这种做法引发了一些自然的问题：

- 这种方法有什么一级和二级影响？
- 那么工具和基础设施怎么办？难道没有人来维护吗？
- 与由专门的测试专家编写的测试相比，由工程师编写的测试质量更高吗？

嗯，您对此提出质疑是完全正确的。

**优点 👍**

- 其中一个好处是通常会编写很多自动化测试。
  - 如果这些测试质量不好（即易失效和不可靠），基础设施本身会负责将其从执行中移除，并通过任务系统通知作者。
- 另一个好处是没有专门的质量保证团队来编写所有的自动化测试。
- 工程师不需要担心构建工具和基础设施，只需利用现有的东西来编写测试。
- 易失效的测试能够更快地修复（因为有更多的工程师关注这个问题）。
- 工程师更好地理解测试实践，而在这种情况下，“质量是每个人的责任”不仅仅是挂在墙上的海报，而是有实际意义的。

缺点 👎

- 有时测试断言不够健壮。
- 测试中有很多重复的代码，没有太多关注如何构建正确的抽象。由于工程师认为编写测试只是完成任务清单中的另一个任务以发布功能，他们并不特别注意构建良好的可重用抽象。
- 编写了许多易失效和不稳定的测试用例。

### 基础设施团队构建测试工具和框架

在 WhatsApp，有多个基础设施团队负责这项工作。

他们的任务是全面考虑测试策略，深入和广泛地思考。这些团队不编写测试，但是他们帮助构建足够级别的测试基础设施和工具，以支持开发人员编写他们的测试。

他们非常关心和关注应用程序的质量，并构建解决方案，使开发人员的工作更轻松。他们被视为测试自动化的领军者和专家，开发团队依赖他们提供指导，并为其特定需求构建任何专门的解决方案。他们还编写内部文档和测试自动化课程等教育资料。

从我的观点来看，有这样一支专门的团队的需求非常明确。

为什么呢？

很高兴你问到了。😉

一个被指派负责功能开发和自动化测试的开发人员几乎没有时间构建可扩展的系统性测试解决方案。基础设施开发人员不需要担心编写测试或日常功能交付，他们可以专注于构建工具（无论其针对的测试精度如何）。由于他们为不止一个团队构建工具，这也会导致更好、更通用的解决方案，可以广泛适用。

关键的要素是领导团队的支持和认可，以确保获得支持和资金。如果没有这一点，这样的团队无法繁荣发展，在 WhatsApp，我们很幸运地拥有非常强大的领导者支持这个团队。

### Prod Ops 团队支持基础设施团队

尽管基础设施开发人员是优秀的软件工程师，其中一些人之前在全职移动端和后端软件开发方面有背景，但他们很少来自纯测试背景（QA 或 SDET）。

他们知道如何构建基础设施和工具解决方案，但对于与功能团队建立深入联系以了解 SDLC 的所有细枝末节或花费大量时间尝试不同的测试框架和方法，他们了解得并不深入。

Prod Ops 团队填补了这个特定的空白。这个团队由被称为 TQS（Technical Quality Specialists）的工程师组成。

从某种程度上说，这个团队类似于传统的质量保证团队，负责在整个产品中领导质量计划。这个团队中也有一些 Android/iOS 开发人员。

他们负责一系列重要的活动。

- 他们是探索性测试的专家，并深入了解产品和流程。他们会关注产品中的重点领域，确保在测试和质量方面发生正确的事情，比如频道、头像等功能。
- 他们通过以下方式支持基础设施和功能团队：
  _ 进行测试设计并建议测试用例，并根据价值对其进行优先级排序
  _ 通过删除冗余用例，确保测试套件健康
  _ 支持生产测试和实验
  _ 对客户问题进行分类和反馈给产品团队，并主导缺陷分类
  _ 构建对质量状态的有见地的看板
  _ 他们有时也编写自动化的端到端测试，并帮助分析测试的易失效性
  他们是一个有价值且核心的团队，拥有互补的技能，使 WhatsApp 的质量文化得以发挥作用，并且在我看来，他们是将整个系统紧密联系在一起并使这种设置能够良好运作的重要纽带。这个团队的质量计划也得到了强有力的领导支持。

### 在功能团队中设置一个测试负责人

除了上述团队之外，WhatsApp 还指定了每个功能团队中的一名工程师担任测试负责人角色，负责审查当前季度的测试计划，找出测试覆盖不足的领域，并鼓励开发人员为这些领域编写测试。

他们还与测试自动化团队保持同步，了解当前正在开发的工具和功能的专业知识，并在自己的团队内推动对它们的认识。

他们建立了定期的会议机制，测试负责人会展示他们的计划，收集反馈，然后回去推动执行。整个项目由 WhatsApp 内部的一位领导型软件工程师管理。

在我看来，团队内部产生这样的思想领导力，是确保 WhatsApp 对质量的承诺得以维持，以及确保稳定发布的关键因素。

### 总结

总结一下：

- WhatsApp 利用自动化测试来推动质量和测试覆盖率
- WhatsApp 的工程师自己编写测试
- 测试自动化团队帮助构建基础设施和工具，以支持工程师
- Prod Ops QA 通过领导质量计划来支持基础设施和功能团队
- 开发人员在测试工程方面拥有专业知识的思想领导力有助于推动这一切
- 强有力的领导支持这些团队，并将他们配备有才华的高级工程师，有助于朝着正确的方向推动工作。

你是否注意到所有这些团队和功能都致力于实现更快地发布高质量的代码的共同目标？测试自动化和质量是庞大的领域，需要很多细微之处和技能，以确保正确的战略投入进入开发工作流程中。

总之，关注质量和领导层在实现这些设置方面的投资不是个别个体的事情，而是需要整个团队的共同努力。

希望这对你有帮助。如果对此有任何想法或问题，请在评论中告诉我。