测试用例审核怎么做？需求覆盖、边界条件与预期结果

测试用例审核，是检查测试用例本身是否正确、有效、可执行。 它也常被称为用例评审：依据需求和相关约束，核对准备测什么、用什么输入、怎样操作、什么结果算符合要求。

执行测试会运行软件并记录实际结果；审核用例主要阅读和讨论测试设计。用例写得完整，不等于程序已经通过测试；程序暂时没有失败，也不等于用例覆盖了重要要求。

ISTQB CTFL v4.0.1第3章将测试用例列为可以静态检查的工作产物。下面用作者编写的“批量导出CSV”案例说明审核方法；需求、用例、状态和图示均为虚构教学材料，尚未执行对应应用，不是测试通过报告。

用例审核需要哪些依据

审核时应同时拿到已确认的需求版本、验收条件、相关接口或设计约束，以及准备执行的用例。只看一张用例表，很难判断“期望成功”到底有没有依据。

本例采用教学需求v1：提交成功时冻结当前筛选结果及字段值，按ID升序导出；1–5000条允许创建任务，0条与超限拒绝；输出约定字段和编码的CSV；临时写入、成功提交正式文件且不覆盖已有文件；支持提交前取消；同一窗口一个活动任务；失败时报告并处理本任务临时文件。

审核者可以包括测试人员、开发者和确认业务规则的人。个人项目也可以自行核对，但同一个人既写实现又写用例时，需要格外检查预期是否只是照搬了实现。

从需求检查覆盖，不用用例数量代替

一项需求可能对应多个用例，一个场景也可能同时涉及多项要求。建立对应关系的目的是定位遗漏，并非追求每一格都有一个编号。

以上是审核起点，不能据此宣称已经覆盖所有输入、平台或安全风险。NASA的双向追踪说明支持将需求联系到测试及验证材料；表中的具体场景由本文教学需求推导，不是NASA提供的CSV用例。

原创教学示意：覆盖关系说明测什么；实际执行记录才说明发生了什么。

前置条件和操作步骤必须能复现

下面这个用例不足以执行：

1
2
3

名称：测试导出上限
步骤：准备大量数据，点击导出。
预期：正常处理。

“大量”是多少、是否符合筛选条件、是否已有任务，都没有定义。审核后可以改成：

1
2
3
4
5
6
7
8

用例：TC-R2-5001
依据：教学需求v1，R2
前置：隔离数据集中恰好有5001条符合当前筛选；窗口无活动任务。
      目标目录为本用例专用空目录。
操作：提交一次导出请求，等待请求处理结束。
预期：明确提示超出上限；不创建导出任务；
      专用目录中没有本次产生的正式文件或临时文件。
执行结果：未执行。

5000条的用例应独立确认允许创建任务；不能只测5001条后就认定边界正确。这里的“独立”是指条件与结果可区分，不要求一定拆成不同文件或不同会议条目。

测试数据必须写明筛选后的数量。数据库总共5001条、当前只有10条匹配筛选，不满足这个用例的前置条件。

预期结果应来自需求，避免“结果正常”

“导出成功”可以展开为可观察结果：正式CSV存在、可按约定格式解析、记录和值与提交快照一致、顺序正确，以及本任务临时文件按约定处理。

对于CSV不能简单把文本行数当记录数。name字段如果含有换行，一个逻辑记录可能占多个文本行。应使用符合约定的CSV解析方式比较字段值；BOM和字节级编码要求另行检查。具体示例可参考Python csv标准库文档，其文件打开方式和引用处理说明适用于Python实现，不代表所有消费端行为完全相同。

如果需求没有决定取消后的文件处理，审核者应提需求问题。不能先按照现有代码补一个预期，再把测试通过当成需求已经确认。

异常和竞争用例需要可控制的触发方式

取消不能只靠“手快一点”

“导出时随便点取消”无法稳定覆盖关键时机。候选设计允许测试通过同步点暂停在正式提交前，发送取消，再放行；另一个场景在完成权已被取得后发送取消，检查终态不被改写。

这里的同步点是测试方案建议，尚未实现。用固定等待100毫秒替代同步，不保证任务真的处于目标阶段。若现有产品没有可观察或可控制的状态，应记录可测试性缺口，而不是假装已经覆盖竞争窗口。

失败注入不能造成真实数据损失

用专用测试目录和可控写入适配器模拟写入失败、目标冲突及清理失败。不要为了制造磁盘满而填满生产磁盘，也不要拿真实账号目录验证删除逻辑。

注入底层错误只能证明应用在该错误响应下的处理，不能代替目标操作系统、真实文件系统或真实磁盘条件的兼容验证。测试报告需要区分这些范围。

原创用例对照：右侧是建议的测试设计，标记为未执行，不表示真实测试已经通过。

自动化测试还要审核断言和模拟边界

自动化脚本也是审核对象。只断言返回值为True，可能漏掉文件内容错误；只检查某函数被调用一次，也未必证明用户需要的结果成立。

Google的审查指南提醒审查者检查测试是否有效，包括实现损坏时它是否会失败。对本例，可以检查：

• 期望值是否独立：不要调用被测导出函数生成期望文件，再与它自己比较。
• 断言是否覆盖结果：除了任务返回值，还核对文件、解析后数据和最终状态。
• 模拟是否绕开关键风险：若把提交文件的函数完全模拟成成功，就没有验证真实无覆盖语义。
• 环境是否隔离：每个用例使用专用输出位置，失败后保留必要证据，避免前次文件误导判断。

AI生成的用例也按这些依据审核。文字多、场景名称丰富或脚本能运行，都不能单独证明它们有效；发现预期与业务规则冲突时，应回到需求确认。

审核发现问题后如何修改与复核

一条审核意见应说明具体位置、缺口及依据，例如：

TC-R2只有5001条的超限场景，缺少R2规定的5000条允许场景。补充该边界，并明确期望是允许创建任务，不能用“正常”代替。

作者修改后，复核者核对新增用例的输入、步骤和预期，再检查是否引入新的冲突。记录可以保持轻量：

用例审核通过表示测试设计满足本次审核条件，不等于实现通过测试。进入执行后，还要保存实际结果、环境、版本和失败证据；代码修改后的既有行为保护可参考本站回归测试与AI Agent文章。

参考资料

• ISTQB CTFL Syllabus v4.0.1：静态测试、评审与测试设计
• NASA Software Engineering Handbook：SWE-052 Bidirectional Traceability
• Google Engineering Practices：审查测试的有效性
• Python标准库：csv

资料核对日期：2026年11月9日。所有示例用例均未执行；审核清单为作者建议，不宣称满足某项认证、覆盖所有风险或替代实际测试。