在持续集成中自动化 API 测试
在界面中构建好的场景可以原样在您的流水线中运行。本指南讲的是如何规模化地使用它。
- 一个 Pro 或 Enterprise 套餐。
- 一个组织令牌（
rstk_…），放入您 CI 的密钥保管库中。（从控制台自助创建该令牌的 功能即将推出。）
RESTORM_TOKEN=$RESTORM_TOKEN restorm \ --open ./api.restorm \ --run "Tests de fumée" \ --headless \ --all-logs \ --out run.log \ --param baseUrl=$BASE_URL退出码 0 = 成功，1 = 场景失败，2 = 调用参数错误，3 = 权限被拒绝。
需要一个虚拟显示环境
Section titled “需要一个虚拟显示环境”Restorm 是一个桌面应用：即使不显示窗口，它也需要一个显示服务器。在 Linux runner 上，
请在命令前加上 xvfb-run -a。
xvfb-run -a restorm --open ./api.restorm --run "Tests de fumée" --headless永远不要把密钥写进项目里。请用环境变量这种密钥来源来声明敏感变量；由您 CI 的保管库注入，Restorm 负责读取。请参阅密钥。
env: API_TOKEN: ${{ secrets.API_TOKEN }}按环境参数化
Section titled “按环境参数化”两种互补的做法：
- 一个类型为
environment的场景参数：--param Env=staging。 同一个场景可以针对任意目标运行。 - 普通参数：
--param baseUrl=…、--param tenant=…。
类型转换遵循参数的声明类型，而一次无法完成的转换会立刻让启动失败， 而不是带着错误的取值继续执行。请参阅 变量与数据。
--out run.log 会实时写入日志。请把它作为构件发布出来，包括作业失败的时候 ——
恰恰是那种时候它最有用。
- uses: actions/upload-artifact@v4 if: always() with: name: journal-restorm path: run.log编写在 CI 中易读的场景
Section titled “编写在 CI 中易读的场景”有几个习惯，会在凌晨三点冒出一个红色作业时带来天壤之别：
- 写清楚断言消息。断言动作的
message字段就是最终出现在日志里的内容：请在里面写明期望是什么。 - 在关键步骤记录日志。 如果不加
--all-logs，只有 Log 动作的条目会被输出： 它就是您的叙事主线。 - 优先用模式校验，而不是逐字段断言。 把
模式校验 的
errors输出接到一个 Log 上：您就能得到一份精确的违规清单。 - 在关键的
else输出上接 Throw，让退出码如实反映失败。 - 在不稳定的网络调用外围套上 Retry，而不是容忍时好时坏的测试。请参阅 控制。
把清理逻辑接到主场景的 done 端口上：done 会等待整个子图执行完毕。请参阅
端口与连线。
需要知道的陷阱
Section titled “需要知道的陷阱”| 陷阱 | 解决办法 |
|---|---|
| 作业停下来等待输入 | 用 --param 提供全部参数；在 headless 模式下无法向任何人提问 |
| Toast 动作没有显示 | 这是正常的：它在 headless 模式下不起作用。请改用 Log |
| MCP 服务器没有出现 | 这是有意为之：没有真实显示环境时它永远不会启动 |
退出码 3 | 令牌或套餐的问题 —— 消息会说明是四种情况中的哪一种 |
| 项目文件位置变了 | --open 接受相对于仓库的路径：请保持它是相对路径 |
GitHub Actions 与 GitLab CI 的流水线示例见 headless 执行与 CI。