单元测试用例设计助手

为一个函数、接口或模块设计系统的单元测试用例集：等价类与边界分析、异常路径覆盖、参数化用例表与断言要点，附交付前覆盖自查清单。

自由如风最新版本 0.1.0更新于 2026-11-08下载 0 次

SKILL.md

1	---
2	name: "test-case-designer"
3	description: "为一个函数、接口或模块设计系统的单元测试用例集：等价类与边界分析、异常路径覆盖、参数化用例表与断言要点，输出可直接落地的测试清单。当用户要求写单元测试、补充测试用例、评审测试覆盖是否充分、或解释'这个函数该测什么'时使用。"
4	---
5
6	# 单元测试用例设计助手
7
8	把一个函数、接口或模块的测试需求变成一套结构完整、可直接落地的单元测试用例集：正常路径、边界值、异常路径、幂等与并发一个不漏。纯指令技能，不带任何脚本，不联网，不写文件；所有分析与用例表都在对话中完成，最终交付的是用例清单与断言要点，不是直接生成的测试代码文件。
9
10	## 触发时机
11
12	满足以下任一条件即进入本技能：
13
14	- 用户给出一段代码（函数/方法/接口处理函数），要求"写单元测试"或"该测哪些情况"；
15	- 用户已有部分测试，要求补充遗漏的用例或评审覆盖是否充分；
16	- 用户要求把若干散乱的测试整理成系统的用例矩阵（参数化表）；
17	- 用户要求为需求文档中的验收标准倒推测试用例（TDD 前置设计）。
18
19	## 工作流程
20
21	### 第一步：被测对象确认（缺项先问，不要猜）
22
23	1. 被测对象：明确到函数签名——名称、入参类型与含义、返回值、抛出的异常；
24	2. 依赖与隔离：入参之外它依赖什么（数据库、网络、时钟、随机数、全局状态）？哪些需要在用例设计中标注"须打桩/mock"；
25	3. 测试框架：目标框架是什么（JUnit / pytest / Jest / Go test / xUnit）？这决定参数化写法与断言风格，但用例设计本身与框架无关；
26	4. 验收口径：有没有需求文档或注释里写明的预期行为？行为不明确的分支要标记出来向用户确认，而不是自行定义预期。
27
28	### 第二步：用例空间分析（核心步骤）
29
30	按以下五层逐层扫描，每层至少过一遍：
31
32	1. 等价类划分：每个入参划分有效等价类与无效等价类（如：空串、单字符、常规值、超长值、非法字符、错误类型）；
33	2. 边界值分析：对每个有"范围感"的入参，取边界两侧——0、1、最大值-1、最大值、最大值+1、空集合、单元素集合、恰好满容量；
34	3. 组合与交互：多入参之间的约束组合（如"开始时间必须早于结束时间"），挑代表组合而非全笛卡尔积；
35	4. 异常路径：逐个异常分支——非法输入抛什么、外部依赖失败时什么行为、中途失败是否留下脏状态；
36	5. 行为属性：幂等性（调用两次结果一致）、无副作用、顺序无关性、时间相关性（时钟、超时）——凡声明过的属性都要有对应用例。
37
38	### 第三步：用例表编制
39
40	每个用例必须四要素齐全：编号、输入、预期输出、断言要点。断言要点写清楚"断言什么才算通过"——只断言不抛异常的用例视为不合格；对异常路径要断言异常类型与关键信息，不能只 try-catch 吞掉。
41
42	### 第四步：覆盖自查
43
44	交付前对照自查清单逐项打勾（见下节），缺项补用例而不是放宽标准。
45
46	## 检查清单（交付前逐项确认）
47
48	1. 每个入参至少有：1 个正常值用例 + 1 个边界用例 + 1 个非法值用例（非法值若被类型系统排除则注明"类型层已拦截"）；
49	2. 每个显式 `throw`/错误返回分支至少有 1 条对应用例；
50	3. 空输入（空串、空集合、null/None）有专门用例，且预期行为与用户确认过；
51	4. 每条用例的断言能独立判断通过与否，不依赖用例执行顺序，用例之间不共享可变状态；
52	5. 需要打桩的依赖已逐个列出，并写明桩的行为（返回什么/抛什么）；
53	6. 用例名可读：一眼能看出"测什么场景、预期什么"（推荐 `被测行为_条件_预期` 命名式）；
54	7. 没有为凑覆盖率的"断言恒真"用例（如只断言 `result is not None` 而不断言内容）。
55
56	## 输出模板
57
58	最终交付固定用以下结构：
59
60	```
61	【被测对象】
62	<函数签名> —— 一句话说明行为契约
63	依赖与桩：<需要 mock 的依赖及桩行为，或"无外部依赖">
64
65	【用例矩阵】
66	\| 编号 \| 场景 \| 输入 \| 预期输出 \| 断言要点 \|
67	\|---\|---\|---\|---\|---\|
68	\| T01 \| 正常路径 \| … \| … \| 断言返回值等于… \|
69	\| T02 \| 边界：空输入 \| … \| … \| 断言… \|
70	\| T03 \| 异常：非法入参 \| … \| 抛 ValueError \| 断言异常类型与消息含… \|
71
72	【桩与前置条件】
73	- <依赖 A>：桩返回 <…>，用于覆盖 <T05/T06>
74	- <前置状态>：…
75
76	【待确认项】
77	- <分支 X 的预期行为需求未明确，建议：…>
78
79	【覆盖说明】
80	- 已覆盖：等价类 / 边界 / 异常 / 幂等（逐层勾选）
81	- 明确不覆盖及原因：如集成行为、性能，归集成测试
82	```
83
84	## 红线条款
85
86	以下情形必须停下来说明，不得交付：
87
88	1. 禁止为行为不明的分支编造预期值——先标记为待确认项请用户定夺，而不是把猜测写进断言；
89	2. 禁止交付只测正常路径的用例集——异常与边界用例缺失时不得声称"测试已覆盖"；
90	3. 禁止断言恒真——凡不能失败用例（`assert True`、只捕获不断言）一律不得出现在交付中；
91	4. 禁止用例之间隐式依赖执行顺序——任何用例单独运行都必须通过；
92	5. 禁止在用例中硬编码环境相关值（本机路径、具体日期时钟、机器相关随机数）——须注入或打桩；
93	6. 禁止为凑覆盖率把私有实现细节写成用例——单元测试断言对外契约行为，不锁定实现；
94	7. 禁止把集成/端到端关注点混入单元用例集——涉及真实数据库、网络的行为明确划出并说明归属。

文件内容是平台检查时读出的文本，只供查看。平台不会运行包里的任何脚本或程序。