功能测试助手

写测试用例为什么总是很痛

开发完一个功能，面对空白的测试用例表格，很多人会卡住：功能点拆到什么程度合适？用例写多了浪费时间，写少了又怕漏掉关键路径。手工整理 Excel 报告更是重复劳动——表头样式、列宽、冻结行，这些机械操作占用的往往比思考测试策略的时间还多。

function-testing 技能的目标是把这部分工作标准化。你只需要提供需求文档、接口说明或 PR 描述，它会按一套固定的流程产出可直接使用的测试用例和 Excel 报告。

技能如何工作

整个流程分为四个步骤：

1. 分析输入材料：识别你提供的材料类型（PRD、接口文档、代码变更等），提取与测试相关的关键信息。
2. 提取功能点：把功能拆解为可独立验证的最小单元，并为每个功能点标注优先级。
3. 设计测试用例：按场景覆盖 checklist 设计用例，包括正向流程、异常处理、边界值、状态切换和数据一致性。用例遵循以下原则：

- 去重：不重复验证同一断言，不拆分单步操作为多条用例。
- 粒度控制：同一机制不分散为多条用例；不仅要验证存在性，还要验证数据正确性与状态联动。
- 优先级分级：P0 只覆盖「出错了用户一定会发现或造成线上事故」的场景；P1 覆盖影响体验但不致命的场景；P2 是有空再测的极端边界。

1. 生成 Excel 报告：输出包含三个工作表的报告——测试概述、功能点清单、测试用例，并自动应用样式规范（加粗深色表头、冻结首行、ID 列窄、步骤与结果列宽）。

适用边界与注意点

• 输入质量决定输出质量：如果你提供的材料本身描述模糊，提取出的功能点也会跟着模糊。建议至少给出明确的需求描述或接口定义。
• 用例数量克制：这个技能有意控制用例数量，避免过度拆分。它假设开发自测为主，没有专职测试，因此 P0/P1 覆盖的是高价值场景，不是穷尽所有可能性。
• 场景覆盖是按需的：checklist 中的兼容性、数据一致性等项并非强制全选，技能会根据功能重要性和风险判断是否需要覆盖。
• 不替代自动化测试：产出的是测试用例与报告，不是可执行的自动化脚本。真正的回归仍需配合自动化测试框架。