2024软件测试面试刷题，这个小程序（永久刷题），靠它快速找到工作了！（刷题APP的天花板）-CSDN博客文章浏览阅读2.3k次，点赞85次，收藏11次。你知不知道有这么一个软件测试面试的刷题小程序。里面包含了面试常问的软件测试基础题，web自动化测试、app自动化测试、接口测试、性能测试、自动化测试、安全测试及一些常问到的人力资源题目。最主要的是他还收集了像阿里、华为这样的大厂面试真题，还有互动交流板块……
我正在思考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，我们很幸运地拥有非常强大的领导者支持这个团队。
