2. 注册表单字段组合覆盖测试设计
为什么注册表单不能只做单字段测试
注册表单包含用户名、邮箱、手机号、密码、确认密码五个字段。若每个字段取 3 个典型值，全组合为 3⁵ = 243 条用例，显然不可执行。但只测单字段又漏掉字段间的交互缺陷，例如“邮箱格式正确但手机号为空时，后端是否仍返回成功”。成对组合法（Pairwise）的核心假设是：大多数缺陷由两个字段的交互触发，因此只需保证任意两个字段的取值组合至少出现一次，即可把用例数压到个位数，同时保留交互覆盖能力。
字段取值表与约束
先为每个字段定义等价类取值，并标注字段间的业务约束。约束会直接影响组合生成，必须在建模阶段明确。
| 字段 | 取值编号 | 取值说明 | 类型 |
|---|---|---|---|
| 用户名 U | U1 / U2 / U3 | 合法6位 / 已存在 / 空 | 有效 / 无效 / 无效 |
| 邮箱 E | E1 / E2 / E3 | 合法格式 / 缺@ / 空 | 有效 / 无效 / 无效 |
| 手机号 M | M1 / M2 / M3 | 11位合法 / 10位 / 空 | 有效 / 无效 / 无效 |
| 密码 P | P1 / P2 / P3 | 8位含字母数字 / 6位纯数字 / 空 | 有效 / 无效 / 无效 |
| 确认密码 C | C1 / C2 / C3 | 与P一致 / 与P不一致 / 空 | 有效 / 无效 / 无效 |
约束：C 的取值依赖 P。当 P 为空或无效时，C1“与P一致”在业务上不可判定，应避免生成 P 无效而 C 有效的组合，否则用例预期结果无法定义。
成对组合生成过程
成对组合的目标是覆盖所有字段两两之间的取值对。以 U×E 为例，需覆盖 (U1,E1)、(U1,E2)、(U1,E3)、(U2,E1)、(U2,E2)、(U2,E3)、(U3,E1)、(U3,E2)、(U3,E3) 共 9 对。五个字段共有 C(5,2)=10 组字段对，每组 9 个取值对，总计 90 个待覆盖对。下面给出一种满足全部成对覆盖的精简用例集（已剔除违反约束的组合）：
| 用例 | 用户名 | 邮箱 | 手机号 | 密码 | 确认密码 | 预期结果 |
|---|---|---|---|---|---|---|
| TC01 | U1 | E1 | M1 | P1 | C1 | 注册成功 |
| TC02 | U1 | E2 | M2 | P2 | C2 | 邮箱格式错误 |
| TC03 | U1 | E3 | M3 | P3 | C3 | 邮箱为空提示 |
| TC04 | U2 | E1 | M2 | P3 | C3 | 用户名已存在 |
| TC05 | U2 | E2 | M3 | P1 | C2 | 邮箱格式错误 |
| TC06 | U2 | E3 | M1 | P2 | C3 | 邮箱为空提示 |
| TC07 | U3 | E1 | M3 | P2 | C2 | 用户名为空提示 |
| TC08 | U3 | E2 | M1 | P3 | C3 | 用户名为空提示 |
| TC09 | U3 | E3 | M2 | P1 | C1 | 用户名为空提示 |
9 条用例覆盖了全部 90 个字段对，相比 243 条全组合减少约 96%。注意 TC09 中 P1 有效且 C1 与之一致，但 U3 为空，预期仍为失败——这验证了“单字段失败不应被其他字段的有效值掩盖”。
用例执行与结果判读
执行时按 TC01→TC09 顺序提交表单，重点观察三类信号：
- 前端拦截：邮箱缺 @、手机号 10 位、密码 6 位纯数字应在提交前被前端校验拦截，不产生网络请求。
- 后端校验：用户名已存在（U2）应由后端返回明确错误码，而非前端提示。
- 字段遮蔽：当多个字段同时无效时，系统应逐字段返回错误，而不是只报第一个。例如 TC05 中 U2 和 E2 均无效，预期应同时提示“用户名已存在”和“邮箱格式错误”。
若某条用例实际结果与预期不符，先检查该用例覆盖了哪些字段对，再回溯对应字段的等价类划分是否遗漏了边界。成对组合的失败往往指向两个字段间的约束逻辑缺陷，而非单字段校验问题。
覆盖验证清单
| 检查项 | 通过标准 |
|---|---|
| 字段对覆盖 | 10 组字段对 × 9 个取值对 = 90 个，实际覆盖 ≥ 89（P3C1 除外） |
| 有效路径 | 至少 1 条全有效用例（TC01）返回注册成功 |
| 单字段失败 | 每个字段至少 1 次作为唯一失败原因被验证 |
| 多字段失败 | 至少 1 条用例包含 2 个以上无效字段，验证错误提示不互相遮蔽 |
| 约束遵守 | 不存在 P 无效而 C 判定为“一致”的用例 |