回归测试

在改进或更新应用程序时，验证这些变更不会对现有功能产生负面影响至关重要。回归测试包括执行一系列测试，以确保修改后的组件能够与应用程序的其余部分无缝集成，而不会引入新的缺陷，这些缺陷通常称为回归。

对于 API，回归测试包括确认对 API 或其环境的更改不会对依赖组件产生不利影响。这些测试可以在任何变更之后执行，从错误修复到功能添加均可。回归测试通常涵盖各种 API 元素，包括：

状态码 - 确认针对不同请求类型返回适当的状态码。

JSON schema - 验证响应结构和格式是否符合 API 规范。

响应时间 - 确保 API 响应时间保持在可接受范围内。

响应主体 - 检查响应内容和结构是否符合预期。

头部 - 验证响应头部是否存在且准确。

可以使用 Apidog CLI 等自动化工具在部署代码更新之前运行回归测试，防止破坏性变更进入生产环境。此外，你可以使用 Collection Runner 安排测试，以持续监控结果，从而深入了解 API 的可靠性。

要在 Apidog 中为你的应用程序设置集成测试，请使用以下框架：

API 请求：测试的基本单元是 API 请求。每个请求通过调用一个 API 端点来测试特定功能。了解更多关于发送请求的信息。

请求前/后置处理器：对于每个请求，你可以添加脚本、断言、提取变量和数据库操作，以测试和验证响应码、头部、主体数据等。了解更多关于添加请求前/后置处理器的信息。

测试场景：当你需要连续发送多个请求、构建连续测试场景，或使用不同测试数据重复请求时，可以创建一个测试场景并向其中添加必要的请求。了解更多关于测试场景的信息。

环境：发起 API 请求时，通常需要在开发、测试和生产环境之间切换。Apidog 可以方便地向不同环境发送请求——你只需点击并在界面右上角选择所需环境即可。了解更多关于创建和使用环境的信息。

模拟服务器：使用模拟服务器来模拟其他系统。你可以测试应用程序如何与其他 API 和系统交互，而无需连接到实际资源。相反，你可以使用 Apidog 设置一个模拟服务器，通过接收请求并返回响应来模拟真实 API 服务器的行为。了解更多关于设置模拟服务器的信息。

在 Apidog 中设置集成测试后，你可以通过以下方式运行它们：

手动：你可以运行单个请求，或运行一个测试场景以获取测试报告。了解更多关于运行测试场景的信息。

计划自动化：你可以设置“计划任务”，以在指定时间自动运行已配置的自动化测试场景，获取任务执行结果，并满足计划测试和回归的需求。了解更多关于计划任务的信息。

CI/CD Pipeline：你可以使用 Apidog CLI 将测试场景作为常规应用程序构建流程的一部分来运行。每次代码推送后执行你的测试套件，并在 Apidog 中查看测试报告。了解更多关于 CI/CD 集成的信息。