研发需求与测试用例追溯

1客户嘴上要的

「用大模型从需求文档自动生成测试用例，减少测试工程师的工作量。」

—— 主机厂电子电气研发部

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 6 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周看审核和漏测记录

   • 跟质量部的过程工程师、测试经理、一个系统需求工程师坐下来，以车身控制器的一个项目为例，翻上一次 ASPICE 过程审核的报告和近半年的问题单。
   • 审核报告里，追溯相关的不符合项最多：需求到用例的追溯缺失、变更后用例没有同步更新。问题单里，有 6 个台架或实车阶段发现的问题，根因都是「需求改了，对应用例没改，测试照旧版跑过了」。
   • 再看工具：需求在需求管理工具里，用例在测试管理工具里，两边的关联靠手工维护，抽查 200 条需求，有 80 条找不到关联用例。
   • 真问题不是「写用例慢」，是「需求和用例的追溯关系断了，变更影响靠人找」。成功标准改为：试点项目需求到用例的追溯覆盖率从 60% 提到 95%；一次需求变更的影响分析时间从 3 天降到 1 天。
   • 踩坑别以用例生成数量为指标。数量多，评审和维护的负担更大。
2. 2

   第 2 周数据和流程

   • 数据：需求管理工具里的系统需求和软件需求、测试管理工具里的用例和执行结果、信号数据库（如 DBC 文件）、变更请求记录。
   • 和质量部的过程工程师确认：AI 建立的追溯关系只能作为建议，由需求工程师或测试工程师确认后才写入工具，确认记录保留，以满足审核要求。
   • 数据安全：研发文档属于核心机密，模型部署在公司内网。和信息安全部书面确认。
3. 3–4

   第 3–4 周原型：追溯补全 + 变更影响分析

   • 追溯补全：对没有关联的需求和用例，按语义、信号名、功能模块给出候选关联，工程师逐条确认。
   • 变更影响分析：需求变更时，列出直接关联的用例，以及通过信号或功能间接受影响的用例，说明原因。
   • 用例生成作为第三步：只对确认没有用例覆盖的需求生成用例草稿，使用项目已有用例的格式和信号名。
   • evals：用这个项目过去 6 个月的 15 次真实需求变更回放，比较系统给出的受影响用例和当时实际修改的用例。标准：召回率 ≥ 90%；每次多给出的无关用例不超过 10 个。
4. 5

   第 5 周测试工程师上手

   • 测试工程师用系统处理两次真实需求变更。反馈：「要能按测试台架分组显示，因为台架时间要提前约」「参数类变更只影响边界值用例」。加上。
   • Demo 给研发总监和质量部：试点项目的追溯覆盖率、两次变更的影响分析时间，由测试经理讲。
5. 6

   第 6 周交接交接

   • 交给测试部的一名测试工具负责人：维护追溯规则、新项目的数据导入、工具版本升级后的接口。
   • 和质量部一起把「变更影响分析」写进需求变更流程，作为变更评审的输入。

4这个案例教给你的可复用判断