DEV Community

Cover image for Apidog Test Suites: A Smarter Way to Automate API Testing
Preecha
Preecha

Posted on

Apidog Test Suites: A Smarter Way to Automate API Testing

当项目中 endpoint 测试用例和测试场景不断增加时，逐个管理和运行它们的成本会急剧上升。本应保障质量的自动化测试，反而可能自身成为维护负担。

立即试用 Apidog

传统上，团队都是手动选择测试用例。一旦项目积累了大量用例和场景，手动决定哪些需要包含、哪些需要用于回归测试，就会变成繁重且重复的工作。

Apidog Test Suites 采用了一种不同的方法。与其死板地存储 ID，不如让一个 suite（套件）存储一组过滤规则——例如按文件夹、标签、优先级或它们的组合。

每次运行前，suite 都会自动组合符合这些规则的所有测试用例和测试场景。你只需专注于编写测试和应用标签；新的测试资产会被自动识别，并流入你的 CI/CD 流水线，实现真正的无人值守持续集成。

test suites in Apidog

随后，所有执行结果都会汇总到一份聚合报告中，便于分析和故障排除。

创建并编排你的第一个 Test Suite

创建 suite。 将 Apidog 更新到最新版本后，打开 Tests 模块，找到 Test Suite 部分，点击旁边的 ... 菜单并选择 Create Test Suite。

creating a new test suite in Apidog

命名。 在弹窗中输入一个描述性名称，并设置优先级或标签等选项。这样就会创建一个空的 test suite。

name test suites in Apidog

添加内容。 一个 test suite 可以包含单个的 endpoint 测试用例，或者由多个测试步骤组成的测试场景。

designing test suites in Apidog

添加测试内容：Static 与 Dynamic

当你点击 Add Endpoint Test Case 或 Add Test Scenario 时，可以选择 Static 或 Dynamic 模式。这个选择决定了 suite 如何决定运行内容，以及后续需要多少维护工作。

adding test content to test suite

Static 模式 会锁定要运行的确切项目集合：系统会存储所选用例的唯一 ID。如果后续在同一个文件夹中添加了新用例，或者移动了现有用例，suite 的执行范围也不会改变。每次运行都是确定性的。

static mode in Apidog test suite

Dynamic 模式 存储的是过滤规则而不是用例 ID，例如：

  • 某个文件夹下的所有用例
  • 所有带有 semantic-valid 标签的用例
  • 所有 P0 优先级的测试场景

dynamic mode in Apidog test suite

setting up dynamic test suites rules

每次运行时，系统都会根据这些规则重新扫描项目，并包含当前符合规则的所有内容。任何文件夹、标签或优先级符合规则的测试用例或场景都会被自动包含——无需手动更新列表。

Static 与 Dynamic 模式：如何选择？

没有哪种模式是绝对更好的；它们服务于不同的需求。正确的选择取决于你希望 suite 随时间如何表现：

  • Static 适用于范围严格、专用的测试（例如固定的回归测试集）——可预测性更强，每次运行结果完全相同。
  • Dynamic 适用于持续迭代和“自动纳入”回归或冒烟测试——规则只需设置一次，suite 会自动保持同步，大大减少了维护工作。
维度 Static 模式 Dynamic 模式
核心逻辑 存储特定的用例 ID 存储过滤规则（文件夹、标签、优先级等）
内容随时间变化 固定不变，除非你手动修改 随着符合规则的用例添加或移除而自动更新
维护成本 较高；必须手动添加新用例 较低；规则设置一次，运行时自动保持同步
典型用途 Bug 修复验证、核心路径稳定性、兼容性测试 全量回归、冒烟测试、发布验收

执行顺序与高级配置

添加内容后，你可以通过拖拽来重新排列编排列表中的项目。

对于每个执行项（例如测试场景），右侧的选项可以让你更精细地控制其运行行为。

advanced config in test suites

有两个值得了解的选项：

  • On Error —— 决定当某个步骤失败时，是继续执行、跳过本轮，还是停止整个运行。
  • Iterations —— 将整个 suite 运行多次，用于进行简单的稳定性检查。

这些选项结合在一起，将 test suite 从静态的用例集合转变为可控的执行流。

test suite on errors

运行 Test Suites

一旦 suite 设置完成，你可以通过多种方式运行它——从本地手动运行到基于云的自动化——具体取决于你所处的阶段和环境。

在本地运行 Test Suites

最直接的途径是：点击 Apidog 客户端中的 Run。它在你的本地机器上执行，适合在开发和调试期间进行小型、快速的检查。在运行配置中，你可以切换运行环境，并设置运行完成后的通知。

creating a new test suite in Apidog0

运行完成后，Apidog 会在 UI 中生成一份测试报告。它会按照执行顺序列出每个 endpoint 测试用例和测试场景，并附带清晰的通过/失败状态。你可以打开单个项目查看更多详情。

creating a new test suite in Apidog1

通过 CLI 运行 Test Suites

对于大型测试集或无头（headless）环境（例如没有 GUI 的服务器），Apidog CLI 是更好的选择——它将 Apidog 的测试执行能力带到了任何终端。

要在命令行中运行 suite：

  1. 安装 Apidog CLI 并确保其为最新版本。
  2. 打开 test suite 的 CI/CD 标签页，复制生成的命令：

creating a new test suite in Apidog2

将该命令粘贴到你的终端中。它遵循以下模式，你的 access token 和 test suite ID 会自动填充：

npx apidog-cli@latest test-suite-run -t <ACCESS_TOKEN> -s <TEST_SUITE_ID>
Enter fullscreen mode Exit fullscreen mode

你可以获得与 UI 中相同的流程和结果。

creating a new test suite in Apidog3

运行完成后，当前目录中会创建一个 apidog-reports/ 文件夹，其中包含 HTML 格式的测试报告。

creating a new test suite in Apidog4

该命令也是 CI/CD 集成的基础模块。你可以将其插入到 Jenkins、GitLab CI 或 GitHub Actions 中，在代码合并等关键节点触发回归测试。例如，一个最小化的 GitHub Actions 作业：

name: API regression
on:
  pull_request:
jobs:
  apidog:
    runs-on: ubuntu-latest
    steps:
      - name: Run Apidog test suite
        run: npx apidog-cli@latest test-suite-run -t ${{ secrets.APIDOG_TOKEN }} -s <TEST_SUITE_ID>
Enter fullscreen mode Exit fullscreen mode

通过定时任务（Scheduled Tasks）运行 Test Suites

Apidog 还支持定时任务（Scheduled Tasks）。要进行设置，打开 test suite 的 Scheduled Tasks 标签页，创建任务，并设置其运行计划和运行环境。

creating a new test suite in Apidog5

与本地运行不同，定时任务必须在自托管的 Runner 上运行。

Runner 是一个轻量级程序，你的团队可以将其部署在内部服务器上。在 Runner 上运行定时任务可以避免因本地机器关机或无法访问而导致的失败，并且你可以利用服务器的资源来运行更大型的测试。

配置定时任务后，Apidog 会在指定时间在 Runner 上运行 test suite，并上传运行历史记录和报告。你还可以配置失败通知，以便在出现问题时迅速通知相关人员。

总结

静态编排能将专用测试的范围严格限定；动态编排则让回归测试套件随项目自动增长，无需持续的手动更新。结合本地运行、CLI 集成和定时任务，test suites 可以完美融入你工作流程的每个阶段——从开发期间的快速检查，到 CI/CD 中的自动化回归，再到生产环境的定时检查。

要了解有关 test suites 的更多信息，请访问 Apidog 文档。试着创建你的第一个 test suite，编排你现有的测试，逐步构建一个可持续的自动化回归体系。

Top comments (0)