---
title: "测试用例审核怎么做？需求覆盖、边界条件与预期结果"
source: https://www.iowill.com/blog/2026/11/test-case-review/
date: 2026-11-13
updated: 2026-11-13
tags: [测试用例, 自动化测试, 软件工程, 软件测试]
categories: [编程开发]
---

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

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

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

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

## 用例审核需要哪些依据

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

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

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

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

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

| 需求 | 本例至少需要考虑的验证点 | 只测成功路径会遗漏什么 |
| --- | --- | --- |
| R1：提交快照与排序 | 提交后改筛选、修改源字段；解析后比较记录和值及顺序 | 任务读取了执行期间的新值 |
| R2：数量限制 | 0、1、4999、5000、5001条 | 达到上限被错误拒绝，超限被静默截断 |
| R3：格式 | 列名顺序、BOM、逗号、引号、字段内换行 | 文件能打开，但内容被拆列或损坏 |
| R4：提交与不覆盖 | 写入中无正式文件，成功后结果完整；目标冲突不覆盖 | 半成品被当作成功，已有文件丢失 |
| R5：取消 | 写入中取消、提交前后竞争，终态唯一 | 显示已取消却仍生成正式文件 |
| R6：活动任务限制 | 连续点击、失败或取消后的再次开始 | 并发写入或活动标记无法释放 |
| R7：失败与清理 | 写入错误、清理失败及残留提示 | 失败原因丢失，残留文件未说明 |

以上是审核起点，不能据此宣称已经覆盖所有输入、平台或安全风险。[NASA的双向追踪说明](https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695427/SWE-052+-+Bidirectional+Traceability)支持将需求联系到测试及验证材料；表中的具体场景由本文教学需求推导，不是NASA提供的CSV用例。

![从需求检查测试输入操作和预期结果再反查验证依据的原创示意](https://img.iowill.com/file/%E7%BC%96%E7%A8%8B%E5%BC%80%E5%8F%91/test-case-review/body1.png)

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

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

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

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

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

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

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

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

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

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

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

| 模糊预期 | 更可检查的表达 |
| --- | --- |
| 取消成功 | 取消被受理并完成收尾后进入已取消，未生成本任务正式文件 |
| 原文件正常 | 预置目标文件内容保持不变，并报告目标冲突 |
| 失败提示友好 | 明确说明写入失败；清理失败时说明本任务残留位置 |
| 数据一致 | 解析后记录ID、字段值和顺序与提交时保存的期望快照一致 |

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

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

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

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

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

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

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

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

![模糊取消用例修改为具有同步点操作断言和执行状态的原创对照示意](https://img.iowill.com/file/%E7%BC%96%E7%A8%8B%E5%BC%80%E5%8F%91/test-case-review/body2.png)

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

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

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

[Google的审查指南](https://google.github.io/eng-practices/review/reviewer/looking-for.html#tests)提醒审查者检查测试是否有效，包括实现损坏时它是否会失败。对本例，可以检查：

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

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

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

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

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

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

| 记录项 | 本例示范 |
| --- | --- |
| 审核依据 | 教学需求v1及候选设计v1 |
| 问题 | 缺少上限允许场景；取消触发时机不可控制 |
| 处理 | 补充5000条用例；设计同步点并保留待实现状态 |
| 复核结论 | 已核对用例文本，执行条件仍待实现 |
| 执行状态 | 未执行，不计入通过用例 |

用例审核通过表示测试设计满足本次审核条件，不等于实现通过测试。进入执行后，还要保存实际结果、环境、版本和失败证据；代码修改后的既有行为保护可参考本站[回归测试与AI Agent文章](https://www.iowill.com/blog/2026/11/regression-testing-ai-agents/)。

## 参考资料

-   [ISTQB CTFL Syllabus v4.0.1：静态测试、评审与测试设计](https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf)
-   [NASA Software Engineering Handbook：SWE-052 Bidirectional Traceability](https://swehb.nasa.gov/spaces/SWEHBVD/pages/102695427/SWE-052+-+Bidirectional+Traceability)
-   [Google Engineering Practices：审查测试的有效性](https://google.github.io/eng-practices/review/reviewer/looking-for.html#tests)
-   [Python标准库：csv](https://docs.python.org/3.12/library/csv.html)

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