测试计划与风险

知识点地图#

• 知识类别：测试计划、监控与基于风险的测试（测试管理家族；对照 ISTQB CTFL v4.0 大纲第 5 章 Test Management 的主题目录）。
• 解决什么问题：「测试」若只有用例没有计划，会陷入三件事——范围随时变、何时算测完没人说得清、有限时间没花在最可能出事的地方。
• 什么时候用到：接手一个版本要产出测试计划时；回答「还差多少可以发布」时；时间不够必须砍测试范围时；复盘「为什么漏测」时。
• 同族文档：测试基础与原则见《测试概念与原则》；缺陷的记录与跟踪见《缺陷生命周期与报告》；把计划自动化落地见《CI/CD 测试门禁》。

前置知识：测试层级（单元/集成/系统）与用例设计的基本概念。不需要项目管理背景——本文只讲测试视角的计划。

一、心智模型：计划是「决策记录」，不是填表#

很多团队把测试计划写成一份没人再看的 Word。换一个视角：测试计划是 一组提前做出的决策的书面化——测什么、不测什么、谁判「测完了」、 出事谁兜底。以后每条决策会被引用（发布评审时、漏测复盘时），它才是活的。

对照 ISTQB CTFL v4.0 大纲第 5 章的主题划分，测试管理活动分四块，本文 逐块展开：

二、测试计划文档的结构：八要素#

计划文档不必长，但八个要素缺一项就会在某个深夜反噬：

要素 2「不测什么」最容易被跳过，却最有价值：它把「没测到」变成「决定 不测」，漏测复盘时才有讨论的基准线。

三、进入/退出准则：把「差不多」变成可判定#

进入准则（Entry Criteria）：开始某级测试前必须满足的条件。 退出准则（Exit Criteria）：宣告该级测试完成必须满足的条件。

一组可直接抄的示例（Web 项目系统测试）：

进入准则：
  - 冒烟用例 100% 通过
  - 测试环境部署完成且版本号与需求基线一致
  - 本迭代用例集评审通过并入库

退出准则：
  - 计划用例执行率 100%（含被阻塞用例的豁免记录）
  - 通过率 >= 95%，且无未关闭的严重/致命缺陷
  - 缺陷修复后回归用例全部通过
  - 遗留缺陷清单经发布评审签字豁免

逐行解释两处最易错的地方：

• 「执行率 100%」与「通过率 >= 95%」是两个独立指标：执行率管覆盖（有没有测到），通过率管质量（测过的有多少对）。只看通过率时，跳过的用例根本不进入分母，进度会「虚假地好」。
• 「遗留缺陷豁免」必须可追溯：退出准则允许带伤发布，但每一条遗留缺陷要有等级、影响面与责任人。没有这条，退出准则会被「零缺陷幻觉」或「永远发布不了」两头夹死。

三个场景例子：

1. 真实工程场景（竞赛框架即计划骨架）：2023 年全国职业院校技能大赛软件测试赛项（GZ034）的任务权重表——任务 1 环境搭建及系统部署 5%、任务 2 单元测试 10%（编写应用程序、设计测试数据、编写单元测试报告）、任务 3 测试文档 10%（测试计划与总结报告）、任务 4 功能测试 25%——本身就是一份高度浓缩的测试计划：范围（四类任务）、退出准则（各任务评分点）、时间（480 分钟）齐备。第 6 节用它做完整拆解。
2. 开源项目：多数开源项目的 CONTRIBUTING.md 写着「PR 需通过 CI 且覆盖率不低于 X」——这就是进入准则的自动化形态，机器判定，无争议。
3. 反例：某团队退出准则写「主要功能可用」，上线后客服高峰——「主要」「可用」都不可判定，准则形同虚设。可判定的意思是：两个人独立判断会得到同一个结论。

四、测试监控：三个核心指标与一张进度表#

测试监控回答「现在进展到哪、还差多少」。三个核心指标：

第四个指标是风险暴露度（第 5 节定义），它与前三个的关系：前三个回答 「过程怎么样」，风险暴露度回答「剩下的缺口有多大」。

示例：迭代第 8 天的监控快照
  执行率 68%（58/85）  —— 按日均 10 条推算，还差 3 天，里程碑吻合
  首过通过率 74%       —— 低于往期 85%，提示需求理解偏差或代码质量下滑
  缺陷逃逸率 6%（上迭代 2%）—— 逃逸上升，提测质量下降，需反馈给开发侧
  风险暴露度 0.62      —— 高风险模块的用例还有 40% 未执行，第 5 节计算

监控的「控制」动作：指标异常时调整计划——加人、砍范围（按风险排序砍）、 改排期，三选一必须显式决策并记录，而不是默认滑向「上线前通宵」。

五、基于风险的测试：时间永远不够时怎么砍#

核心思想：测试优先级 = 失败概率 x 失败影响。给每个功能块打两个分 （通常 1-5），乘积排序，资源按序投入：

打分的依据必须可追溯：失败概率来自历史缺陷分布与代码变更量（改得多、 历史烂的模块概率高）；失败影响来自业务（资损 > 数据错误 > 体验问题）。 两个团队对同一模块打分差 3 分以上，说明对业务影响的理解有分歧——打分 过程本身的价值不亚于结果。

电商大促风险分级（完整场景）：大促前两周时间只够一轮全量回归，分级 决策长这样：

P0（大促链路，双人核对 + 每日回归）：下单、支付、优惠券叠加、库存展示
P1（大促间接受影响，全量一轮）：购物车、价格计算、订单列表
P2（与大促弱相关，变更才测）：商品详情改版部分、评价
P3（本轮不测，记录豁免理由）：后台运营配置页的 UI 细节

监控挂钩：P0 模块的风险暴露度每日晨会通报；任何 P0 缺陷立即触发
「是否缩小大促范围」的评审。

这段决策的要点：P3 不是「忘了测」而是「决定不测」且有记录——呼应第 2 节要素 2；P0 每日回归的频率本身由风险值决定，这就是「基于风险的测试调度」。

六、动手实践：用 GZ034 权重表拆解一份计划#

任务：把 GZ034 竞赛任务权重表当真实项目排期用：总共 480 分钟，为「任务 2 单元测试」与「任务 4 功能测试」分配内部时间与退出准则。

提示：

• 任务 2 = 480 x 10% = 48 分钟，任务 4 = 480 x 25% = 120 分钟，先把预算算死；
• 单元测试内部再切：读懂代码 / 设计测试数据 / 编写与执行 / 写报告，各占多少？
• 功能测试的退出准则必须是可判定句式（第 3 节）；
• 用第 5 节的风险表决定功能测试内部「哪些接口先测」。

参考实现（先自己写，再对照）：

任务 2 单元测试（预算 48 分钟）：
  读代码圈定可测函数        10 分钟   —— 不读代码设计的用例必然空转
  设计测试数据（等价类+边界）12 分钟   —— 数据先行，一次写全
  编写并执行                18 分钟   —— 留 20% 余量给环境/编译意外
  撰写单元测试报告           8 分钟   —— 竞赛评分点，报告不能挤占为零
  退出准则：每个函数至少 1 个正常 + 1 个边界用例执行完；报告含数据表与结果

任务 4 功能测试（预算 120 分钟）：
  风险排序（5 分钟）：下单/登录类 > 查询列表 > 排版细节
  用例执行按 P0 -> P2 推进，每 30 分钟核对一次执行率进度
  退出准则：P0 用例 100% 执行且通过；P2 允许豁免但记录原因

对照要点：参考答案的关键不是数字本身，是「预算先算死、准则先写死、执行 按风险排序」这三个动作——它们同样适用于你下一个版本的排期会。

七、坑点与自检#

自检清单：

• 当前版本的测试计划八要素齐全，且「不测什么」有明确清单
• 进入/退出准则全部可判定，有遗留缺陷豁免机制
• 监控看板同时有执行率、首过通过率、缺陷逃逸率
• 时间不够时的砍范围顺序已按风险值预先排定，而非临场拍板

练习#

1. 给你最近的课程/项目版本写一份一页纸测试计划，对照第 2 节八要素自查，特别写出「不测什么」。
2. 为你项目的五个核心功能打风险分（概率 x 影响），排序后对照实际测试投入，写三行差距分析。
3. 找一次「漏测」复盘（或假设一个），用缺陷逃逸率与风险暴露度重述这次复盘的结论。
4. 把第 6 节的 480 分钟预算换成你真实项目的一个迭代（如 5 个工作日），重做一遍时间分配。

参考与致谢#

• 主题目录对照依据 ISTQB Certified Tester Foundation Level (CTFL) v4.0 大纲第 5 章「Test Management」：https://www.istqb.org/ （仅作主题目录对照，未复制原文文本，正文全部为本仓库自己的表述与案例）。

下一步#

• 缺陷的记录、跟踪与报告规范：见《缺陷生命周期与报告》。
• 把计划的自动化检查（门禁）落地：见《CI/CD 测试门禁》。
• 测试层级与各层的完成准则差异：见《测试层级》。