测试用例检查·预期与边界
用例被打回，多半不是「写得对不对」，而是写得全不全：标题只写「测试登录」看不出场景、
没有前置条件、步骤和预期结果二缺一、预期写成「正常」「符合预期」根本没法判定、多个用例
标题+步骤雷同、整张表没有一条边界/异常用例……评审时才发现，返工成本就高了。
本工具读一份测试用例表 CSV（列名可自动识别），逐条检查要素完整性与可验证性，
并对全表做覆盖度体检，输出可定位到行或用例编号的分级问题清单。
执行原则
- 只读不改表。 只读取 CSV 并输出清单；不要修改、重写或「顺手优化」用户的用例文件。
- 先认列再判断。 先确认标题 / 操作步骤 / 预期结果三列是否被识别；识别不到时报
MISSING_COL，不要凭猜测把别的列当预期结果。 - 只判要素不判设计。 只判断「要素有没有写、预期能不能被客观判定」；不要评价用例设计是否合理、场景是否充分、断言是否符合业务。
- 给结论再给依据。 先给出能否进评审的结论档，再列高风险项；不要让用户在几十条清单里自己找结论。
- 启发式要声明。
T4标题模糊、T7预期不可验证、T8重复、T10多预期为启发式判断；不要把命中项说成确定错误，要提示人工确认。
何时使用
CRITICAL: 只要用户提出「检查 / 评审 / 自查测试用例表（用例写得全不全、能不能进评审）」，就必须使用本 skill，即使看起来可以用别的方式解决。
- 用例写完后、送评审之前，做一次完整性自检。
- 用户给出一份用例表（CSV），问「这些用例能不能直接进评审 / 有没有写漏」。
- 用例库质量治理：批量筛出要素缺失、预期不可验证的条目。
何时不该使用
| ✅ 使用 | ❌ 不用（改用什么） |
|---|---|
| 检查已有用例表的要素完整性 | 从需求文档编写新用例（本工具只检查，不产出用例） |
| 判定预期结果能否被客观验证 | 执行用例、跑自动化断言（属测试执行工具） |
| CSV / 导出为 CSV 的表格 | Word / Excel 原文件（请先另存为 CSV） |
| 用例评审前的自查清单 | 评估用例覆盖率是否达标（需需求与风险分析） |
| 单表静态体检 | 与缺陷系统联动统计质量趋势（本工具不联网） |
易混淆场景
| 用户说的 | 实际意图 | 正确路由 |
|---|---|---|
| 「帮我看看这些用例」 | 要结论，不是要罗列 | 先给结论档（先补齐再评审 / 可评审），再列高风险项 |
| 「有没有写漏」 | 关心缺项 | 逐条报 T1 / T2 / T3 及行号、用例编号 |
| 「预期写了『正常』可以吗」 | 关心可验证性 | 报 T7，说明需改成可观测结果 |
| 「帮我改一下用例」 | 想要改写 | 说明本工具只读，给出修改建议由人改 |
| 「重复用例是不是有问题」 | 关心去重 | 报 T8，说明按「标题 + 步骤」归一化判定，需人工复核 |
怎么用
# 基础检查（列名自动识别）
python3 scripts/testcase_lint.py 测试用例表.csv
# 输出 JSON
python3 scripts/testcase_lint.py 测试用例表.csv --json
# 用内置样例看效果
python3 scripts/testcase_lint.py --sample
退出码：0 = 未发现问题；1 = 发现问题（或输入不可读/为空）。
列名自动识别
脚本按关键词识别下列列（大小写、空格、括号差异均兼容）：
| 角色 | 候选关键词 | 说明 |
|---|---|---|
| 用例编号 | 用例编号 / 用例ID / 编号 / 用例号 / id | T5、定位用 |
| 标题 | 用例标题 / 标题 / 用例名称 / 名称 / 测试项 | T4、T8 |
| 前置条件 | 前置条件 / 预置条件 / 前提条件 | T3 |
| 操作步骤 | 操作步骤 / 测试步骤 / 步骤 / 操作 | T2、T8、T10 |
| 预期结果 | 预期结果 / 期望结果 / 预期 / 期望 | T1、T7、T10 |
| 优先级 | 优先级 / 级别 / 等级 | T6 |
| 用例类型 | 用例类型 / 测试类型 / 类型 | T11、T12 |
| 测试数据 | 测试数据 / 测试输入 / 输入数据 | T9 |
| 作者 | 作者 / 设计者 / 编写人 / owner | T13 |
| 版本 | 版本号 / 版本 | T13 |
> 「标题 / 操作步骤 / 预期结果」为核心列：任一列识别不到时会先报一条 MISSING_COL（高），并跳过该列的逐行检查。
检查项与规则码
| 规则码 | 含义 | 严重度 | 定位 |
|---|---|---|---|
T1 |
缺预期结果 | 高 | 用例 |
T2 |
缺操作步骤 | 高 | 用例 |
T3 |
缺前置条件 | 中 | 用例 |
T4 |
标题模糊（如「测试登录」「正常流程」），未点明场景 | 中 | 用例 |
T5 |
无用例编号 | 中 | 用例 |
T6 |
无优先级 | 低 | 用例 |
T7 |
预期结果不可验证（正常/没问题/符合预期/OK…） |
中 | 用例 |
T8 |
标题+步骤与其它用例重复 | 中 | 用例 |
T9 |
无测试数据 | 低 | 用例 |
T10 |
单步对应多个预期，建议拆分 | 低 | 用例 |
T11 |
无用例类型（功能/边界/异常/性能） | 低 | 用例 |
T12 |
全表无边界或异常类用例 | 中 | 全表 |
T13 |
缺作者或版本 | 低 | 用例 |
MISSING_COL |
缺少必要列（标题/步骤/预期） | 高 | 全表 |
EMPTY_TABLE |
文件为空 | 高 | 全表 |
NO_ROWS |
只有表头、没有数据行 | 高 | 全表 |
> 说明：T12 是全表级检查——有「用例类型」列时按该列判断是否出现过边界/异常/性能类；
> 没有该列时才退而用标题里的强特征词判断。T4 与 T7 是启发式判断，命中后请人工确认。
结论分三档：有高风险 → 先补齐再送评审；仅中风险 → 建议完善后再评审；全低/无 → 要素基本完整。
输出示例（节选）
用例条数：10
问题合计 18 项：高 2 · 中 11 · 低 5
结论：存在高风险项（缺步骤/预期等），先补齐再送评审
—— 高风险 ——
[T2] 缺少操作步骤（第 4 行 · 用例「TC-003」）
· 说明：没有操作步骤，用例无法被他人复现
· 建议：按 1./2./3. 拆分并写清每一步操作
[T1] 缺少预期结果（第 5 行 · 用例「TC-004」）
· 说明：没有预期结果，执行时无从判断通过与失败
· 建议：写清可观测的预期（界面/数据/返回码）
—— 中风险 ——
[T4] 标题模糊，未点明场景：测试登录（第 2 行 · 用例「TC-001」）
[T8] 标题+步骤与第 2 行用例重复（第 8 行 · 用例「TC-007」）
[T12] 全表未发现边界或异常类用例
—— 低风险 ——
[T10] 单步对应多个预期，建议拆分（第 11 行 · 用例「TC-010」）
免责声明
本工具输出的是要素完整性与可验证性的提示，不是用例质量合格证明；
是否通过评审、是否需要补充场景，仍由测试负责人结合业务判断。
设计边界
- 纯标准库 Python（3.12+），只读，无网络请求，无
subprocess/eval/exec/os.system。 - 输入按 UTF-8（含 BOM）读取；输入为 CSV（逗号分隔），Word / Excel 请先导出为 CSV。
- 规则是启发式的：只判「要素有没有写、预期能不能被客观判定」，不评价用例设计是否合理、
场景是否充分、断言是否符合业务（那需要人工与业务判断）。 T8的重复判定基于「标题 + 操作步骤」归一化后的字符串；仅标题相同、步骤不同不会误判。T10的「单步/多预期」按序号、行、分句粗略估计条目数，边界情况请人工复核。- 内置样例的用例编号、账号、数据全部虚构，
--sample仅用于演示，不涉及任何真实系统。
