semantic-assert
在测试中判断页面或返回结果是否满足语义要求
实现思路与验证边界 →JEV GUIDE
Jev + Playwright 语义测试：用自然语言检查页面状态
当提示语可以有多种正确说法，逐字比较会让测试变得脆弱。semantic-assert 提供另一条路径：先捕获状态，再判断一句明确的验收条件是否成立。这里拆解已核对的源码，并给出未运行的测试设计示例。
哪些测试值得加入语义判断？
适合检查“错误消息是否解释了失败原因”或“提示是否告诉用户下一步”。金额计算、按钮数量、订单状态码和权限边界仍应由确定性断言验证。模型只看到捕获的状态；页面写着付款成功，不代表支付服务已经记账。
| 检查对象 | 建议方式 | 证据位置 |
|---|---|---|
| 总价是否等于各项之和 | 普通计算断言 | 业务数据 |
| 错误说明是否提供下一步 | 语义断言辅助 | 错误区域的文本与状态 |
| 表单是否真正保存 | 接口断言 + UI 检查 | 持久化结果与页面反馈 |
从捕获状态到测试结果
该项目把核心 Judge 与 Playwright 适配器分开。核心接收 JSON 状态和自然语言条件；TypeSafe provider 返回判断值，Judge 在代码里应用阈值。Playwright 适配器负责页面捕获和报告集成。
源码会在条件未满足、且仍有时间时重新捕获状态。静态响应可用 timeoutMs: 0 做单次评估；动态页面需要明确的超时与轮询间隔。不要无限重试，直到随机拿到一次通过。
设计一个最小验收样本
以下为编辑设计的合成测试，不是 Jev 实际输出。将固定文案替换为不同但等价的表达，检查测试是否仍能识别可操作的错误说明。
| 合成输入 | 人工预期 | 观察点 |
|---|---|---|
| “上传失败：文件超过 10 MB，请压缩后重试。” | 提供原因及下一步 | 清楚的正例 |
| “发生错误。” | 没有提供可操作的下一步 | 模糊负例 |
| “文件已保存。”但接口返回 500 | 业务失败 | 语义通过也不能覆盖接口失败 |
| 错误区域为空、页面仍在加载 | 等待或捕获失败 | 不把缺失状态送成正常结果 |
接到 Playwright 流程时保留什么？
先用普通断言确认目标区域出现，再捕获与当前条件有关的文本和状态。对捕获内容脱敏后再交给 provider。一个判断条件尽量只问一件事，避免把“成功、无错、完整、好看”塞到一起。
- 先验证状态捕获、报告和失败路径；FakeProvider 返回脚本指定结果，不能证明真实语义判断有效。
- 记录模型标识、问题版本、捕获状态、原始判断值、阈值及轮询次数，便于比较回归。
- 只在状态确实可能变化时重试；将真实 provider 的调用次数和延迟纳入测试预算。
- 保留失败时的页面证据；不要把低置信判断压成没有解释的 pass/fail。
如何决定阈值与发布门槛？
先人工标注正例、负例及边界例，再在固定模型和问题版本上比较误放行与误拦截。阈值是你的验收策略，不是正确率承诺。建议先作为报告中的辅助结果；涉及资金、数据丢失或权限的发布条件必须保留确定性验证。
如果同一状态重复判断会翻转，先检查条件是否含糊、捕获是否缺少上下文，再决定阈值。不能用反复调用挑选一个满意结果替代校准。
常见问题
能代替截图对比吗？不能据此推断。本文流程核对的是状态捕获与语义条件，像素布局、颜色和间距需要对应的视觉测试证据。
测试一定要联网吗？假的 provider 可离线检查测试流程；使用 Jev 做真实判断需要调用服务，捕获数据会发送给所选 provider。本站未安装或运行该项目。
接着看这些项目
继续阅读
02 / JEV GUIDE
Jev API 入门：第一个请求与响应检查
用一个合成故障报告了解 Jev API 请求，查看 state、questions、Bearer 鉴权和响应检查步骤，附可下载 JSON 示例。
阅读指南 →08 / JEV GUIDE
Jev 浏览器自动化：Playwright 与 Computer Use 如何分工
从 DOM 或无障碍树提取候选，让 Jev 选择动作，再由 Playwright 或 Computer Use 执行；解释回放、置信度与页面变化的边界。
阅读指南 →18 / JEV GUIDE
Jev 写作质量检查：用规则评审 Markdown 与技术文档
用 slop-grader 将写作要求拆成逐行判断和全文评分。学习自定义规则、离线语法检查、误报复核与保留原意的修改流程。
阅读指南 →