FlowCheck 编辑器整改复盘｜用一个健康检查验证断言、变量提取和版本冲突

本文依据 2026 年 11 月 10 日的本地验证记录整理，写作使用了 AI 辅助。

我把健康检查用例中 $.status 的期望值从 ok 改成 down，点击保存，页面提示成功。执行后，报告里一条检查通过，另一条失败。HTTP 状态码是 200，响应里的 status 是 ok，与我配置的 down 不一致。

今天我用自己注册的 FlowCheck 账号新建了一个「健康检查练习」，借它重新走一遍第一轮用例编辑器整改。这个练习用的是项目自带的 Articles Demo API，响应很简单，方便我把注意力放在规则怎么保存、怎么执行，以及出错后页面会做什么。

GET /health
HTTP 200
{"status":"ok"}

期望值的类型从表单一路带到数据库

第一轮整改把「输入了什么」和「它是什么类型」分开。以前看到一个输入框里的 1，很难从界面判断保存出去的值是什么。现在我可以明确选择「数字」或「文本」，编辑器保存时再按这个选择转换。

表单里输入的内容	选择的类型	请求体里的期望值
1	数字	{"expected":1}
1	文本	{"expected":"1"}

我单独验证了这两个转换结果，再跑后端比较函数确认数字 1 和字符串 "1" 比较失败。这组类型实验和下面的健康检查用例是两件事。健康接口的 status 字段本身是字符串。

在浏览器里保存健康检查用例时，我把期望值选为文本并输入 ok。我先查看保存请求的 Payload，确认发出去的是 "expected":"ok"，再只读查询 PostgreSQL，确认 cases.steps 里对应的 JSONB 值类型是 string。

这比单看页面上的「保存成功」多了两份证据。我能知道 parseExpectedValue() 转换出的值是什么，也能确认这个值经过 API 校验后以什么类型存进数据库。

保存一条规则和通过一条规则是两次检查

保存时，页面通过 buildCaseSubmission() 整理表单，FastAPI 校验请求与项目归属，然后把步骤配置写入 PostgreSQL。把 $.status 的期望值写成 down 时，这仍是一条格式有效的检查规则，所以可以保存。

执行时，Worker 拿到 HTTP 响应，分别判断状态码和 JSON 字段。我的报告里出现了下面两条结果。

检查规则	期望	实际	结果
HTTP 状态码	200	200	通过
JSON 字段 $.status	down	ok	失败

当前执行器汇总了步骤里所有断言的结果。只要有一条失败，该步骤和整次运行就会标为 failed。这个例子让我理解了报告为什么需要同时显示检查对象、期望值和实际值。看到「运行失败」以后，我还能追到具体是哪一条规则失败。

提取器怎样把第一步的结果交给第二步

我在第 1 步里加了一个名为 health_status 的提取项。第一次只填名称，页面提示「取值位置不能为空」，浏览器网络面板也没有出现保存请求。补上取值位置 $.status 后，PUT 的 Payload 包含了完整提取规则，运行报告显示提取值是 ok。

接着我把第 1 步的期望恢复为 ok，并配置第 2 步再次请求 GET /health。第二步的字段断言从 $.status 读取实际值，期望值则填成 {{health_status}}。

步骤	实际发生的事
第 1 步	请求成功，从自己的响应中读取 $.status，把 ok 保存为本次运行的 health_status。
第 2 步	用第 1 步的 health_status 得到期望值 ok，再从自己这次请求的响应里读取实际值 ok。

这里的两个写法对应两个数据来源。$.status 指向当前响应里的字段，{{health_status}} 引用本次运行中已经存下来的变量。源码中，步骤通过且提取成功后才会调用 context.update(extracted)，所以提取步骤需要排在引用步骤之前。当天实测的是正确顺序，反过来的情况是我读代码后的推演。

保存失败时，页面要告诉我该改哪里

我把第 2 步的路径改成 //bad，切回第 1 步再点保存。这次浏览器确实发出了 PUT，后端返回了 422，错误位置是 body.steps.1.request.path。页面自动切到第 2 步，并把焦点放在路径输入框上。

steps.1 里的 1 是从零开始的数组下标，所以对应页面上的第 2 步。编辑器把后端字段路径映射回表单控件，我可以直接修正路径。像漏填取值位置这样的错误，表单可以在提交前提示。遇到由 API 校验发现的问题，页面会根据返回的位置带我找到对应的输入框。

我随后恢复了合法路径，连续保存两次。响应里的用例 id 相同，第二次的 version 比第一次大 1。id 表示正在编辑哪条用例，version 表示这次编辑基于哪个版本。

为了看旧版本提交会怎样，我用同一个账号在 A、B 两个标签页打开同一用例。A 先保存成功，B 带着旧版本提交，收到 409。B 刚填的描述还留在输入框里。这次验证覆盖的是「A 已保存，B 随后提交」的顺序。页面保留输入后，我还能先复制刚填的内容，再重新加载核对别处改了什么。

这次留下的一个小问题

409 提示里的「请重新加载」出现了两次。我沿着调用看了一下，后端的错误消息已经写了这句话，前端的 describeError() 又补了一次操作提示。这条文案问题是在复测里发现的，记录下来供后续处理。

下一次我准备从点击「执行用例」开始，跟踪浏览器提交的运行请求，看看一条用例的配置如何变成 Worker 真正执行的任务。