没有人希望他们的应用程序出现错误，这可能会导致公司损失数百万美元。 添加这 5 个测试实践可以防止它发生在你身上。
给大家讲个故事吧。。。
当我进入现在的公司时，受到了很大的震撼。 在三个不同技术中心雇用的 500 名工程师中，雇用的 QA 工程师总数为零。对我来说，这是一个全新的概念，从以前的公司在 Scrum 开发团队中有一个或两个专门的 QA到现在零个。我习惯于让队友检查我的分支并添加自动化测试、API 测试，或针对各种边界测试用例和业务流程对其进行手动测试。现在没有那个人了，我该怎么办？ 在入职期间，我们收到了明确的指示，应该遵循测试金字塔：
- 编写大量单元测试
- 编写一些集成测试
- 如果该功能足够重要，则编写 E2E 测试以涵盖用户的使用场景。
- 手动测试该功能
对于我在团队中的第一个任务，我应该在注册对话框（应用程序的一个非常重要的部分）中进行一些更改。在完成手头的任务后，我进行了一些重构以使代码更干净，遵循了测试金字塔。
- 写了单元测试
- 写了集成测试
- 写了一个 e2e 测试
在那之后，用多个边界测试用例手动测试了这个特性。最后的结果呢？ 我破坏了应用程序中几乎所有对话框中的 CSS。 当然，幸运的是，正在处理的对话没有这个问题——它很棒。因此，在任职的早期，就意识到测试金字塔不起作用。决定将更多检查集成到 CI/CD 流水线中，以确保像我这样的新加入者不会轻易破坏生产。但它不会阻止开发人员通过增加 Core Web Vitals 来降低应用程序的 SEO 排名。 为此，我们需要进行性能测试。
性能测试
更好的性能和转化率之间存在明显的相关性。 这是有道理的，应用程序加载得越快，用户就可以越早与之交互并购买东西。
谷歌更进一步，提高了性能更好的网站的 SEO 排名。 它根据这 3 个指标对性能进行排名。
- FID（首次输入延迟）
- LCP（最大内容绘制）
- CLS（累积布局偏移）
我不打算详细介绍这些指标中的每一个，但你可以在 Google 的官方文档中阅读所有相关信息。我们关心的是确保我们在发布功能时不会降低这些指标。为实现这一点，我们使用推荐的工具 Lighthouse CI（它由核心谷歌成员维护）一旦将 CI 库集成到流水 线中，编写性能测试就非常简单了。
变异测试
说到我们必须编写很多的测试用例……单元测试已经存在了一段时间。它们处于老派金字塔的底部。 被认为是最重要的，因为它们运行速度快且编写成本低。（在今天的 Cloud Run 基础设施中可能不再是这种情况）。但是我们如何确保测试基础设施中最重要的部分按预期运行？如果一些测试是误报怎么办？ 它们在终端和 CI 中显示为绿色，但要么被跳过，要么更糟：它们写得不好，没有测试被测函数的结果。变异测试是问题的解决方案。 它们的工作方式与正常测试略有不同。 通常，会测试某些东西是否按预期工作，但是变异测试测试某些东西在它应该的时候失败了。让我们考虑一个简单的求和函数。
一个变异测试用例库，将通过这个函数，分析 AST 并找到它可以改变函数的所有地方。例如，它定位 + 运算符，并可以将其更改为不同的运算符，如减号、乘法等。然后库运行这个函数的所有测试，并且因为它改变了运算符，所以它预计至少有一个测试失败。 如果他们都通过了，那就意味着变异测试还活着，而且手上的测试套件很糟糕。可以稍后检查变异、调试和改进代码。冲洗并重复，直到对单元测试感到满意，并且由于运行变异测试非常昂贵，不必将它添加到 CI 流水线中，但可以有一个异步过程每隔一个月执行一次，以检查完整性单元测试。
可视化测试
还记得我文章开头的故事吗？ 好吧，如果我们有适当的视觉测试，那肯定不会发生。顾名思义，这些测试确保在视觉上一切都与页面一致。可以为每种类型的页面编写测试，使用的库将启动该页面并截取屏幕截图。 然后它会将该图像与来自 master 分支的图像进行比较，并询问你它发现的更改是有意还是错误。通过将可视化测试集成到CI 流水线中，你将不再因为可能会破坏不同页面中的设计而害怕接触通用组件。当涉及应用程序的 CSS 部分时，它们会给你最大的信心。但是，视觉测试的缺点是当涉及交互时它做得不好。如果必须单击按钮或滚动到页面底部，引入交互性也会增加易碎性。
特性测试
特性测试是当今开发的支柱。 将集成测试添加到应用程序不再是最佳实践，因为尝试模拟前端应用程序时，最好的结果总是在像真实用户一样进行测试时获得。将不同的组件集成在一起并在终端中测试结果并不是我们真正想要的，这些基本上是带有额外步骤（如模拟、存根等）的单元测试。我们希望组件在浏览器中独立启动，并且像用户一样与之交互。这是通过组件测试实现的。你选择的库启动一个仅包含组件的单页应用程序。可以看到真实用户看到的内容。
你可以使用不同属性或根本不配置属性来安装组件，并测试默认行为。
然后随心所欲地与组件进行交互，同时在浏览器中查看结果。如果你喜欢编写 TDD，这也是开发组件的好方法。不必为了查看小组件的运行情况而启动整个项目，可以利用组件测试库并在那里查看它。如果组件是重要用户使用场景的一部分，那么在组件经过隔离测试后，还可以添加 E2E 测试。但要注意 E2E 测试，通常它们会带来很多问题：
- 它们很慢
- 它们依赖后端服务来动态呈现内容
- API 可能具有比 E2E 库超时时间更显着的延迟。
- 你肯定会多次测试用户使用场景的同一部分。
- 我们遇到了上面所有的问题以及其他更多问题，并且应用了一些实践来至少减少不稳定的数量：
- 并行运行E2E 测试套件。
- 通过模拟 cookie 或 URL 参数在测试中实现了跳过功能。 示例：?SKIP_LOGIN_FUNCTIONALITY=true，模拟登录用户（仅在测试环境中）。
- 我们通过创建自己的记录实时响应的模拟服务器来模拟我们的整个 API。
你可能认为模拟整个后端可能会破坏 E2E 测试的目的。 但我们利用契约测试可以保证这一点
契约测试
我们发现所有中断的最常见原因是 API 响应与前端应用程序预期的不同。通常，当另一个微服务中的计算失败并且网关返回未定义或完全跳过响应中的键时，就会发生此错误。现在，前端应用程序，即数据的消费者，声明一个契约并在每个端点中说明它期望什么响应以及什么值，更重要的是每个值必须是什么类型。当然，有些值仍然可以为空。你还在契约中声明，如果有多个 API 或者正在使用的服务是使用多个微服务的后端服务。然后将契约保存在测试库中，我们选择了 PACT，对于每个后端 PR，它都会针对该合同运行提供者的输出。 如果它不遵守合同，则 PR 将被阻止。
