lanyuanxiaoyao
b8810f1182
- 引入 typed target 判别联合，支持 http 与 command 两种 checker - expect 重构为有序规则数组，按配置顺序快速失败并生成结构化 failure - 新增 command runner，支持 exec + args 本地命令执行 - 引入全局并发限制 maxConcurrentChecks 和 size 解析 (KB/MB/GB) - HTTP/command 各自独立 expect pipeline，应用领域默认成功语义 - SQLite schema、API、Dashboard 全链路调整为 checker 通用契约 - 补充完整测试覆盖（192 tests），更新 README 与示例配置
129 lines
6.4 KiB
Markdown
129 lines
6.4 KiB
Markdown
## Purpose
|
||
|
||
定义 HTTP 拨测中响应体校验方法集（contains/regex/json/css/xpath）、操作符系统和响应头校验的行为规范。
|
||
|
||
## Requirements
|
||
|
||
### Requirement: 响应体多种校验方法
|
||
系统 SHALL 支持对 HTTP 响应体进行五种可组合的校验方法：contains（子串）、regex（正则）、json（JSONPath）、css（CSS 选择器）、xpath（XPath）。这些方法 MUST 配置在 `expect.body` 有序数组中。
|
||
|
||
#### Scenario: contains 子串匹配
|
||
- **WHEN** HTTP target 配置 `expect.body: [{contains: "healthy"}]`，且响应体包含 `"healthy"`
|
||
- **THEN** 系统 SHALL 判定该 body 规则通过
|
||
|
||
#### Scenario: contains 不匹配
|
||
- **WHEN** HTTP target 配置 `expect.body: [{contains: "healthy"}]`，且响应体不包含该文本
|
||
- **THEN** 系统 SHALL 判定 matched 为 false，并记录该规则的 failure.path
|
||
|
||
#### Scenario: regex 正则匹配
|
||
- **WHEN** HTTP target 配置 `expect.body: [{regex: '"status"\\s*:\\s*"ok"'}]`，且响应体匹配该正则
|
||
- **THEN** 系统 SHALL 判定该 body 规则通过
|
||
|
||
#### Scenario: regex 不匹配
|
||
- **WHEN** HTTP target 配置 regex body 规则，且响应体不匹配该正则
|
||
- **THEN** 系统 SHALL 判定 matched 为 false，并记录该规则的 failure.path
|
||
|
||
#### Scenario: json JSONPath 等值匹配
|
||
- **WHEN** HTTP target 配置 `expect.body: [{json: {path: "$.status", equals: "ok"}}]`，且响应 JSON 中 `$.status` 值为 `"ok"`
|
||
- **THEN** 系统 SHALL 判定该 body 规则通过
|
||
|
||
#### Scenario: json JSONPath 值不匹配
|
||
- **WHEN** HTTP target 配置 json body 规则，且提取值不符合期望
|
||
- **THEN** 系统 SHALL 判定 matched 为 false，并记录包含 JSONPath 的 failure.path
|
||
|
||
#### Scenario: json 解析失败
|
||
- **WHEN** HTTP target 配置了 json body 规则但响应体不是合法 JSON
|
||
- **THEN** 系统 SHALL 判定 matched 为 false
|
||
|
||
#### Scenario: css 选择器匹配
|
||
- **WHEN** HTTP target 配置 `expect.body: [{css: {selector: "div#health", equals: "OK"}}]`，且 HTML 中存在 `div#health` 元素文本为 `"OK"`
|
||
- **THEN** 系统 SHALL 判定该 body 规则通过
|
||
|
||
#### Scenario: css 选择器匹配属性值
|
||
- **WHEN** HTTP target 配置 css 规则带 `attr: "content"` 用于提取属性，且属性值匹配期望
|
||
- **THEN** 系统 SHALL 判定该 body 规则通过
|
||
|
||
#### Scenario: css 选择器无匹配元素
|
||
- **WHEN** HTTP target 配置了 css 选择器但 HTML 中无匹配元素
|
||
- **THEN** 系统 SHALL 判定 matched 为 false
|
||
|
||
#### Scenario: xpath 表达式匹配
|
||
- **WHEN** HTTP target 配置 `expect.body: [{xpath: {path: "/root/status/text()", equals: "ok"}}]`，且 XML 中 `/root/status` 节点文本为 `"ok"`
|
||
- **THEN** 系统 SHALL 判定该 body 规则通过
|
||
|
||
#### Scenario: xpath 表达式无匹配节点
|
||
- **WHEN** HTTP target 配置了 xpath 表达式但 XML 中无匹配节点
|
||
- **THEN** 系统 SHALL 判定 matched 为 false
|
||
|
||
### Requirement: 多种 body 校验方法 AND 组合
|
||
系统 SHALL 支持在 `expect.body` 数组中同时配置多种 body 校验方法，所有方法均通过时 matched 方为 true。
|
||
|
||
#### Scenario: 多种方法全部通过
|
||
- **WHEN** HTTP target 的 `expect.body` 数组依次配置 contains、json、regex，且全部通过
|
||
- **THEN** 系统 SHALL 判定 matched 为 true
|
||
|
||
#### Scenario: 多种方法任一失败
|
||
- **WHEN** HTTP target 的 `expect.body` 数组第一条 contains 不通过，后续还有 json 规则
|
||
- **THEN** 系统 SHALL 判定 matched 为 false，且不再检查后续 json 规则
|
||
|
||
### Requirement: 操作符系统
|
||
系统 SHALL 支持对提取值和文本值使用以下操作符进行比较：equals（默认等值）、contains（子串包含）、match（正则匹配）、empty（空值判断）、exists（存在性判断）、gte/lte/gt/lt（数值比较）。
|
||
|
||
#### Scenario: 标量值隐式 equals
|
||
- **WHEN** 配置的期望值为标量（字符串/数字/布尔/null），如 `equals: "ok"`
|
||
- **THEN** 系统 SHALL 使用 equals 操作符，对实际值做严格相等比较
|
||
|
||
#### Scenario: 显式 contains 操作符
|
||
- **WHEN** 配置 `{contains: "success"}`，且实际值包含 `"success"`
|
||
- **THEN** 系统 SHALL 判定该规则通过
|
||
|
||
#### Scenario: 显式 match 操作符
|
||
- **WHEN** 配置 `{match: '\\d+\\.\\d+\\.\\d+'}`，且实际值匹配该正则
|
||
- **THEN** 系统 SHALL 判定该规则通过
|
||
|
||
#### Scenario: empty 操作符判断为空
|
||
- **WHEN** 配置 `{empty: true}`，且实际值为空数组 `[]`
|
||
- **THEN** 系统 SHALL 判定该规则通过
|
||
|
||
#### Scenario: empty 操作符判断非空
|
||
- **WHEN** 配置 `{empty: false}`，且实际值为 `[1, 2]`
|
||
- **THEN** 系统 SHALL 判定该规则通过
|
||
|
||
#### Scenario: exists 操作符判断存在
|
||
- **WHEN** 配置 `{exists: false}`，且实际值不存在
|
||
- **THEN** 系统 SHALL 判定该规则通过
|
||
|
||
#### Scenario: gte 数值比较
|
||
- **WHEN** 配置 `{gte: 10}`，且实际值为 `15`（数字）
|
||
- **THEN** 系统 SHALL 判定该规则通过
|
||
|
||
#### Scenario: gt/lt 数值比较
|
||
- **WHEN** 配置 `{gt: 0, lt: 1000}`，且实际值为 `500`
|
||
- **THEN** 系统 SHALL 对同一字段进行多操作符复合比较，全部通过则该规则通过
|
||
|
||
### Requirement: 响应头校验
|
||
系统 SHALL 支持通过 `expect.headers` 配置对 HTTP 响应头进行键值规则校验，header 名称匹配 MUST 不区分大小写。
|
||
|
||
#### Scenario: 响应头匹配
|
||
- **WHEN** HTTP target 配置 `expect.headers: {"Content-Type": {contains: "application/json"}}`，且响应包含该 header 且值匹配
|
||
- **THEN** 系统 SHALL 判定 headers 阶段通过
|
||
|
||
#### Scenario: 响应头不匹配
|
||
- **WHEN** HTTP target 配置 `expect.headers: {"Content-Type": {equals: "application/json"}}`，且响应 header 值为 `"text/html"`
|
||
- **THEN** 系统 SHALL 判定 matched 为 false
|
||
|
||
#### Scenario: 响应头缺失
|
||
- **WHEN** HTTP target 配置了某个 header 但响应中不存在该 header
|
||
- **THEN** 系统 SHALL 判定 matched 为 false
|
||
|
||
### Requirement: 结构化 expect 失败信息
|
||
系统 SHALL 在任一 expect 规则失败时生成结构化 failure，用于标识失败阶段、规则路径、期望值、实际值和可读错误信息。
|
||
|
||
#### Scenario: body 规则失败信息
|
||
- **WHEN** HTTP target 的 `expect.body[1].json` 规则失败
|
||
- **THEN** failure SHALL 包含 kind=`mismatch`、phase=`body`、path 指向 `expect.body[1]`，并包含 message
|
||
|
||
#### Scenario: actual 值截断
|
||
- **WHEN** 失败规则的实际值超过系统允许记录的摘要长度
|
||
- **THEN** 系统 MUST 截断 actual 摘要，而不是持久化完整响应体或命令输出
|