返回质量体系与测试架构模块
Quality Architecture / Tutorial 23
测试资产工程与版本追溯教程
把零散文档升级为能跨版本取用、机器校验和人工裁决的测试证据链，为自动化与 AI 辅助测试打好共同地基。
01
测试资产不是一堆文件，而是一条证据链
上下游必须接得上资产流转
需求规则为什么要测
测试点与风险具体测什么
测试用例怎样执行
缺陷与评审发现了什么
版本总结留下什么
贯穿问题
某模块已有近百条用例，校验也全部通过，但新版需求逐条对照后，完整覆盖不足四成。问题不在用例数量，而在用例没有挂接需求规则，校验只能检查“已有内容是否正确”，看不见“应该存在但缺失的内容”。
资产工程的目标，是让每条结论都能回答来源、版本、责任和下一步，而不是让目录看起来很完整。
02
先把需求拆成可核对的规则
覆盖率的分母规则注册表最小字段
| 字段 | 用途 | 示例 |
|---|---|---|
| rule_id | 稳定引用规则 | REQ-V2-4.2.1 |
| version | 说明规则在哪版生效 | V2.0 |
| source | 保留原文位置 | 需求 §4.2.1 |
| statement | 写成可测试约束 | 无下载权限不得生成报告 |
| status | 确定、待确认、已删除 | 确定 |
| case_ids | 关联验证证据 | TC-081、TC-082 |
为什么规则先于用例
- 覆盖率有明确分母，不再用用例数量冒充覆盖。
- 需求变更时可以反查受影响的测试点和用例。
- 待确认项不会混进确定规则，减少按猜测写用例。
- 机器校验可以发现某个模块规则为空，而不是静默全绿。
03
把通用测试点和风险规则分开管理
基础覆盖 + 风险补漏两类资产各自解决什么
| 资产 | 内容 | 使用方式 |
|---|---|---|
| 通用测试点库 | 必填、唯一性、分页、空态、重复提交、权限四层 | 按功能形态匹配基础覆盖 |
| 风险规则库 | 触发条件、可能失效方式、建议方法与优先级 | 命中条件后补充风险用例 |
| 待确认清单 | 需求冲突、缺失数值、跨端口径差异 | 确认后回写规则与用例 |
规则不得臆造数值
需求只说“会话超时后重新登录”，就不能自行写成“30 分钟后失效”。测试点应写为“在配置的超时时长后访问受保护资源应被拒绝”，同时把具体时长列入待确认。
04
把历史缺陷提炼成可复用模式
防止换张脸复发缺陷到检查点的转换
| 缺陷现象 | 抽象模式 | 回归检查点 |
|---|---|---|
| 角色名称重复仍可保存 | 唯一性校验遗漏 | 新增与编辑都验证唯一；空格与大小写口径一致 |
| 完成状态仍可编辑 | 状态流转限制缺失 | 每个状态核对按钮、接口和数据可变更性 |
| 连续提交生成多条数据 | 重复提交未做幂等 | 连续点击、刷新重提、重复请求只生效一次 |
| 用户看到他人数据 | 权限数据范围错误 | 角色 × 数据归属矩阵覆盖列表、详情、操作与导出 |
模式库的结构
- 症状：用户实际看到什么。
- 可能成因：用于定位，不在未经确认时当事实。
- 易发场景：什么改动会再次触发。
- 测试设计建议：如何转成可执行检查点。
- 关联缺陷与验证版本：证明它从哪里来、何时有效。
05
用差异表驱动版本增量测试
先对照，再改用例版本差异三类
| 类型 | 处理 | 用例来源标识 |
|---|---|---|
| 新增 | 补规则、测试点和用例 | 新增 |
| 口径变更 | 反查旧用例并修订断言 | 修改 |
| 规则未变 | 确认仍适用后继续使用 | 复用 |
| 历史缺陷防复发 | 由模式库生成检查点 | 回归 |
| 功能删除或弱化 | 显式记录合理不覆盖 | 废弃 |
资产流转
新旧需求差异逐条列变化
覆盖核对规则→测试点→用例
人工裁决覆盖/部分/不覆盖
补齐与校验缺口关闭后提测
“合理不覆盖”也要留结论。它与忘记测试的区别，就是有明确规则、版本和裁决记录。
06
七类交付物围绕同一条主线
不是七份孤立文档交付物与责任
| 交付物 | 回答的问题 | 必须关联 |
|---|---|---|
| 测试点清单 | 测什么 | 规则、风险 |
| 风险清单 | 哪里可能出错 | 测试点、回归检查点 |
| 测试用例 | 怎样验证 | 规则、测试点、来源 |
| 冒烟清单 | 版本是否值得继续测 | 主用例 P0 编号 |
| 评审记录 | 哪些问题被发现和修订 | 用例、决议、行动项 |
| 待确认清单 | 哪些口径尚未确定 | 需求章节、影响用例 |
| 版本总结 | 结果与下一版行动 | 前六类产物统计 |
交付前先对账
测试点数量、风险关闭情况、用例来源分布、冒烟编号、评审修订和总结中的统计必须互相对得上。数字对不上，通常意味着追溯链已经断了。
07
机器查确定性问题，人判断业务语义
双层质量门禁机器适合检查
| 门禁 | 硬问题 |
|---|---|
| 完整性 | 模块存在用例却没有规则或测试设计 |
| 需求追溯 | 确定规则没有任何用例证据 |
| 冲突 | 用例违背需求数值、枚举或权限约束 |
| 格式与去重 | 编号重复、弱标题、必填字段缺失、疑似重复 |
| 分布 | 优先级或来源分布异常，仅作为复核信号 |
人工必须判断
| 问题 | 原因 |
|---|---|
| 场景是否真正有价值 | 脚本只能看到字段，理解不了业务损失 |
| 优先级是否准确 | 比例不是标准答案，必须结合风险 |
| 待确认如何裁决 | 需要产品、开发和业务证据 |
| 哪些资产值得长期保留 | 临时规则进入公共库会制造噪声 |
08
先取用，再把验证过的经验回填
资产会越用越准资产流转
版本开始查规则与模式库
测试设计匹配并裁剪
执行评审记录有效与误报
版本结束回填新增资产
回填准入
- 至少在真实任务中被验证，不把一次性猜测放进公共资产。
- 说明适用范围和不适用范围，避免跨项目误用。
- 关联来源缺陷、需求或评审证据。
- 修改公共规则时运行历史样本回归，防止旧能力退化。
09
为一个旧版本补齐资产链
练习与检查清单练习
- 选择一个已有用例但追溯不完整的模块。
- 把当前需求拆成规则注册表，并标出待确认项。
- 从历史缺陷提炼至少 3 个模式和回归检查点。
- 做一次新旧版本差异表与覆盖核对表。
- 补齐缺口后运行完整性、冲突、去重和格式检查。
- 输出版本总结，明确取用、修改、回归与废弃的资产。
完成检查
规则是覆盖率分母
用例可追溯到版本与来源
待确认项有负责人和结论
校验能发现缺失而非只发现错误
交付物数字互相一致
回填资产经过真实验证