2.3-软件测试

Create by fall on 26 Sep 2022
Recently revised in 26 Sep 2025

测试

The more your tests resemble the way your software is used, the more confidence they can give you.

为什么编写测试

为了保证代码能按照预期方式进行执行

什么情况下编写测试价值更高

• 通用的组件内部
• 目标明确
• 作为基础设施

什么情况下不宜测试过多

• 需求经常变动的业务场景

测试的类型

• 单元测试：检查给定函数、类或组合式函数的输入是否产生预期的输出或副作用
• 集成测试：检查组件是否正常挂在渲染、组件之间是否可以互动，以及表现是否符合预期，验证它们在整个系统中的正确性和互操作性。导入了更多的代码，更复杂，需要更多的时间执行。
• 端到端测试：端到端测试是一种自动化测试方式，用于测试一个系统的完整流程，从用户界面到后端系统，确保所有组件和系统都能够正确地协同工作。它模拟用户的真实行为，包括用户输入和系统响应，测试整个系统的交互、一致性和可靠性。

单元测试

测试函数的业务逻辑和逻辑正确性。

代码覆盖率 100%只能保证代码的每个语句、分支都被运行过了，不能确保所有执行结果都符合预期。

为了验证小的、独立的代码单元是否按预期工作。

单元测试通常适用于独立的业务逻辑、组件、类、模块或函数，不涉及 UI 渲染、网络请求或其他环境问题。

比如在 vue 中，需要对组合式函数进行编写测试，react 中，则是 use 开头的 hooks

单元测试的质量好坏可以通过代码覆盖率来判断，而代码覆盖率由四部分组成：

• 语句覆盖率（Statement Coverage） 用于衡量被测试代码中每条语句的执行覆盖情况
• 行覆盖率（Line Coverage） 用于衡量被测试代码中每行代码的执行覆盖情况，不包含空行和注释等
• 函数覆盖率（Function Coverage） 用于衡量被测试代码中每个声明函数的执行覆盖情况
• 分支覆盖率（Branch Coverage） 用于衡量被测试代码中每一个判定分支的执行覆盖率

组件测试

测试这个组件做了什么，而不是测试它是怎么做到的。

从粒度的角度来看，组件测试位于单元测试之上，可以被认为是集成测试的一种形式。

组件测试应该像用户那样点击一个元素，而不是编程式地与组件进行交互。

• 对于视图：根据 prop 和插槽断言渲染是否正确
• 对于交互：断言渲染的更新是否正确或触发的事件是否正确响应了用户输入事件。

应避免的做法

不要去断言一个组件实例的私有状态或测试一个组件的私有方法。测试实现细节会使测试代码太脆弱，因为当实现发生变化时，它们更有可能失败并需要更新重写。

组件的最终工作是渲染正确的 DOM 输出，所以专注于 DOM 输出的测试提供了足够的正确性保证（如果你不需要更多其他方面测试的话），同时更加健壮、需要的改动更少。

不要完全依赖快照测试。断言 HTML 字符串并不能完全说明正确性。应当编写有意图的测试。

如果一个方法需要测试，把它提取到一个独立的实用函数中，并为它写一个专门的单元测试。如果它不能被直截了当地抽离出来，那么对它的调用应该作为交互测试的一部分。

端到端测试（E2E）

模拟用户实际使用时，用户的体验如何。

E2E 测试重点是多页面的应用表现，针对你的应用在生产环境下进行网络请求。他们通常需要建立一个数据库或其他形式的后端，甚至可能针对一个预备上线的环境运行。

端到端测试通常会捕捉到路由、状态管理库、顶级组件（常见为 App 或 Layout）、公共资源或任何请求处理方面的问题。如上所述，它们可以捕捉到单元测试或组件测试无法捕捉的关键问题。

• 模拟用户操作：通过模拟用户的操作，测试系统在用户界面上的响应和交互是否正确。
• 测试系统功能：测试系统的各项功能是否按照预期运作，包括输入数据、处理逻辑和输出结果。
• 验证数据一致性：测试数据在不同组件和系统之间的传输和存储是否一致。
• 测试系统可靠性：测试系统的鲁棒性和稳定性，例如测试系统在负载高峰时的表现。
• 环境模拟：测试系统在不同环境下的表现，例如测试系统在生产环境和开发环境的表现是否一致。
• 监控和报告：监控测试结果，及时发现和报告问题，并跟踪问题的解决情况。

端到端测试不导入任何应用的代码，而是完全依靠在真实环境中浏览整个应用来测试你的应用。

参考文章

作者（文章名称）	连接
vue官方文档	https://cn.vuejs.org/guide/scaling-up/testing.html