简介软件工程与生成式AI结合的实践研究资料源于Vector咨询在2025年技术日的专题分享面向汽车电子、嵌入式系统及工业自动化领域的需求工程师、测试工程师、安全与网络安全专家。内容聚焦GenAI在需求工程与测试中的落地路径涵盖基于SLM语义搜索与RAG技术的私有化部署、测试用例自动生成、边缘场景识别、冗余消除以及面向ISO 26262与ISO/SAE 21434的TARA分析与漏洞识别。包内为1个PDF文档大小1.77MB全文约23页配有Vector官方调研数据与多个行业案例示意便于对照CANoe、vTESTstudio、PREEvision等工具链理解AI辅助流程。资源已有96人浏览/学习适合正在探索AI驱动研发提效与安全合规的技术管理者及从业者可快速建立从需求一致性优化到测试覆盖增强的完整认知框架。GenAI虽能显著降本提速但工程师需作为“驾驶员”审查AI输出资料对AI治理与人工闭环机制亦有涉及。1. 生成式AI进入软件工程需求和测试为什么最先被改造一个很反直觉的现象是软件工程里最见不得人的两个环节——需求整理和测试设计——反而是生成式AI落地最快、ROI最明显的地方。这两个环节有一个共同特点产出物几乎全是文本。需求规格书是文本测试用例是文本断言代码也是文本而大语言模型在文本转化和结构化这件事上的能力已经明显超过大多数人的平均整理速度。传统做法里需求分析师要把会议纪要、产品说明、用户反馈人工整理成条目化的需求规格书测试工程师再把这些需求手工翻译成用例过程中信息损耗非常大。与其争论AI能不能替代工程师不如先把钱花在刀刃上让生成式AI把从白纸起草的成本压到接近零人只做审查、决策和补洞。下面按一条可复现的链路拆开讲——从模糊的原始诉求到可验收的需求条目从需求再到能真正跑起来的自动化测试用例最后落到怎么证明质量效率确实提升以及三个保证输出稳定的落地技巧。这套思路适合手里已经能调用生成式AI接口无论是商用大模型还是私有化部署的软件工程师、测试开发和质量负责人。2. 需求侧用生成式AI把模糊诉求变成可验收的需求规格书2.1 需求规格书的痛点在哪生成式AI的边界就在哪软件开发里最常见的返工不是代码写错而是需求理解错了。传统需求分析天然有一个工作量分配规律沟通占三成整理成文档占五成真正做业务规则分析只占两成。生成式AI能压缩的是整理成文档这五成——把它变成一次有约束的生成和校对但这个过程不是把素材丢给模型就完事。我一般把需求侧分成三个可落地的任务从原始素材生成需求条目、做需求可测试性检查、辅助变更影响分析。这三个任务都依赖同一个前提先有一份质量过得去的原始素材。会议纪要、用户反馈、竞品说明、原型图上的注释素材越具体生成结果越可回收。反过来如果只给一句做一个电商系统再强的模型也只会给你返回一堆教科书式的空话。记住这个边界模型负责把混乱的素材整理成结构化文本不负责替你做一个业务取舍。2.1.1 为什么优先做结构化需求而不是直接写代码常见的一种误区是把生成式AI直接接到代码生成上跳过需求环节。但从工程实践看需求阶段的返工成本最低、收益却最大——改需求规格书里的一句话成本和改上线代码里的一段逻辑差一个量级。在这个环节里引入AI产出物还能继续往下游复用需求条目里的验收标准就是后面测试用例生成的输入。这也是为什么这套思路要先从需求规格书开始而不是从代码生成开始。2.2 从原始素材到结构化需求条目一条可靠的提示词与调用链路下面是一段可以直接改用的参考脚本。它读取一段原始素材会议纪要或产品说明输出固定结构的JSON需求条目。代码按OpenAI兼容接口写换成任何本地私有化部署的同类型服务只需要改base_url和model。import json import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), # 任意 OpenAI 风格的服务都行 ) SYSTEM_PROMPT 你是资深需求分析师。把给定素材整理为需求规格书条目。 规则 1. 每条需求以 REQ-ID 开头REQ-001 递增。 2. 必须包含需求名称、用户故事、验收标准、优先级(P0/P1/P2)。 3. 验收标准必须可测试禁止出现“快速、友好、尽量、大约”等模糊词。 4. 只输出 JSON 对象格式为 {requirements: [...]}不做解释。 def extract_requirements(material_path: str): with open(material_path, encodingutf-8) as f: raw f.read() resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o), temperature0.2, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: raw}, ], ) data json.loads(resp.choices[0].message.content) return data.get(requirements, []) if __name__ __main__: for req in extract_requirements(meeting_notes.md): print(json.dumps(req, ensure_asciiFalse, indent2))代码逻辑分三段系统提示词固定了需求分析的角色和验收标准约束用户消息传入原始素材响应强制要求JSON格式再解析成列表。这里有个容易忽略的点——temperature0.2不是随便设的。需求提取是确定性任务温度太高模型会自由发挥编出一堆素材里根本不存在的规则温度太低又容易死板地逐字复述不做过关的归纳。0.2左右是一个通用值如果你发现模型总是漏掉重要约束可以再降到0。提示不要把整份会议纪要一次性塞进去。模型会把寒暄、争论过程和过期信息也整理成需求。常见做法是先让模型按议题把纪要切成几段再对每段分别做需求提取最后合并去重。合并时如果出现两条需求互相矛盾不要指望AI替你裁决这是需要产品负责人拍板的事。2.3 需求可测试性检查让AI先挑模糊词再给替换建议生成完需求条目之后只完成了一半。需求规格书真正值钱的地方在于可验收如果验收标准里带着体验好速度要快这类词到了测试阶段就又变回扯皮。可以写一个复核提示词把生成的需求条目喂回去要求AI完成三件事找出不可测试的表述、把模糊词替换成可度量的描述、标注每条验收标准是否满足可观测、可判定、可重复。可观测有明确的输入和输出不依赖主观感受。可判定同一份输出能被不同测试工程师给出相同结论。可重复同一条件下执行多次结果一致。暧昧表达可度量的替换方向响应要快在基础数据集下查询接口 P95 响应时间低于 500ms界面要友好核心操作三步内可完成按钮文案与用户用语一致尽量不丢数据写入成功响应后断电重启数据恢复率为 100%支持并发200 并发用户场景下错误率低于 0.1%无 5xx上面这张表同时可以作为人工检查的参考标准。实际做的时候我会把复核的提示词固定成团队规范每次生成需求都强制执行一轮让模型在输出的JSON里直接带一个testable: true/false字段。这样需求规格书就不再是一份看完就忘的文档而是能直接进测试设计管线的结构化数据。2.4 需求变更影响分析从人肉追踪矩阵到AI辅助清单需求变更流程是系统集成管理里最费人的环节。传统做法是维护一个需求追踪矩阵RTM用手工表格把需求、设计模块、代码文件和测试用例关联起来变更时靠人力一个个翻。生成式AI在这里的用法不是替代RTM表而是把变更描述翻译成影响清单。实际操作时把当前需求库的全部条目变更描述一起传给模型要求它输出一个JSON影响的REQ-ID列表、每条受影响需求的理由、需要回归验证的测试场景。相比纯靠人回忆这个做法能减少遗漏特别是那些一两周前刚拆分过的小需求人很容易忘记它们也受牵连。但要注意模型对代码模块之间的真实依赖其实没有感知它能做的是基于文本语义的相关性分析。要拿到靠谱的代码层影响面还是得配静态调用分析一起用。3. 测试侧从用例生成到缺陷预测的AI化改造3.1 测试用例生成的两种驱动方式以需求为准还是以代码为准测试设计传统上有黑盒和白盒两条路生成式AI在两边都能发力但失败模式完全不同。以需求驱动的生成输入是需求条目和验收标准输出是业务场景用例回答的是功能做得对不对以代码驱动的生成输入是被测函数和行为描述输出的是带断言的最小测试函数回答的是实现稳不稳。实际项目里我会两条线同时用先用需求驱动生成端到端的业务用例覆盖主流程和异常流再挑核心模块做代码驱动生成单测补边界。遇到安全测试需求时要做的是先让模型生成一份测试规则与边界清单再基于清单产出受限的验证用例而不是让模型直接给出绕过手段。这既是安全测试的规范要求也避免了模型胡编危险payload带来的合规风险。3.1.1 为什么代码驱动更适合从函数签名发散需求驱动生成的用例偏业务视角通常不会发现除数为零空指针传参这类实现层面的故障。代码驱动则可以从函数签名直接发散参数类型、默认值、文档里的约束、引用到的常量这些都是生成输入的一部分。缺点是对新写的、痛苦的代码容易生成橡皮鸭子用例——断言恒真、没有实际意义这也是后面质量闸门要解决的核心问题。3.2 从需求规格书生成业务用例把验收标准拆成Given/When/Then拿第2章产出的需求条目直接生成测试场景是整条链路里最省力的一步。提示词模板固定成如下结构每条验收标准拆成正常流、边界流、异常流三个场景每个场景用Given/When/Then描述且必须引用REQ-ID。你是资深测试设计师。以下是需求条目及其验收标准。 任务为每条验收标准生成测试场景列表。 每个场景必须包含 - 场景标题 - priority高/中/低 - Given: 前置条件与测试数据 - When: 操作步骤 - Then: 可观测的预期结果 约束 - 优先覆盖正常主流程和用户可感知的异常处理 - 不要为没写进需求的功能发明场景 - 输出格式为 JSON 数组 需求条目 {requirement_json}这段提示词的关键在最后的不要为没写进需求的功能发明场景。模型默认倾向把测试场景写得很饱满会自动脑补权限校验、超时重试这些内容。这些补充可能正确但会让需求覆盖统计失真也给了测试工程师一种用例很全面的错觉。生成完之后简单写个脚本统计每条需求对应用例数覆盖率低于1:3的条目比如只有1个用例的P0需求要先人工检视。3.3 从源代码生成可运行的pytest用例一个最小可跑通的方案对于工具类函数、纯逻辑模块代码驱动生成单元测试已经比较可靠。下面的脚本读取一个Python源文件抽取指定函数生成pytest用例并立即执行验证。import ast import subprocess import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) def generate_test_for_function(source_code: str, func_name: str) - str: prompt f根据给定函数源码生成 pytest 单元测试。 被测函数{func_name} 源码 {source_code} 要求 1. 用标准 assert 断言不用 pytest.raises 以外的插件。 2. 必须覆盖正常输入、边界输入、异常输入。 3. 如果函数依赖外部资源用 monkeypatch 注入假实现。 4. 只输出 python 代码不要输出解释和 markdown 代码围栏。 resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o), temperature0.2, max_tokens1500, messages[ {role: system, content: 你是资深测试开发输出可直接执行的 pytest 代码。}, {role: user, content: prompt}, ], ) generated resp.choices[0].message.content.strip() ast.parse(generated) # 语法不合法会抛异常用于触发重试 return generated if __name__ __main__: with open(calc.py, encodingutf-8) as f: src f.read() # 提取函数定义块这里简单用函数名定位实际应结合 ast 扫描 func_src src.split(def calculate_discount)[1].split(\n\n)[0] test_code generate_test_for_function(def calculate_discount func_src, calculate_discount) with open(test_calc.py, w, encodingutf-8) as f: f.write(test_code) subprocess.run([pytest, -q, test_calc.py], checkTrue)代码逻辑说明先拼一个带函数源码的提示词要求模型只输出代码拿到结果后先做一次ast.parse语法校验这一步能拦住模型漏写括号、混入markdown围栏这类低级的烂活最后落盘并调用pytest执行执行不通过就代表生成的用例质量不合格直接丢弃重来。参数设置上temperature0.2是为了让断言风格保持一致单次入门设定可以接受max_tokens1500足够覆盖大多数单函数用例生成超长函数时可以把这段代码封装成循环失败重试重试两次全是语法错误就放弃并在日志里标记。更稳的做法是先把被测函数运行时能拿到的依赖找出来再在提示词里写明这个函数依赖 db_conn请注入假对象模型生成的用例才会真的能通过执行这一关。3.4 生成用例的质量闸门过滤层级与可交付标准AI生成的测试用例不能直接进测试仓库这是原则问题。一层是语法一层是静态检查一层是运行最后才是人工评审。粗筛阶段把明显不能用的剔掉运行阶段能暴露断言恒真和mock过度人工评审则看的是用例价值——这条用例有没有测到人容易漏掉的风险点。过滤层级手段要拦掉的问题语法层ast.parse / py_compile生成代码里有markdown围栏、缺冒号、缩进错乱静态层flake8 / pylint 精选规则未使用的变量、空函数、过于宽泛的异常捕获运行层pytest 执行 coverage用例压根跑不过、断言恒真、覆盖率虚高评审层测试工程师抽检用例没有业务意义、与需求脱节、注释误导后人实际度量起来一个模块生成 100 条用例经过前两层过滤大概能留下 60 到 70 条跑通之后真正被接纳的往往是 30 到 50 条——这个水平正常剩下的废用例并不是完全浪费它们的价值在于帮测试工程师快速找到容易出错的函数相当于一份自动生成的体检报告。产出测试结论时只统计最终通过运行层和评审层的用例数不要拿生成总数去汇报。4. 度量与反馈怎么证明生成式AI真的提升了质量效率4.1 需求侧度量模糊度、产出耗时与变更匹配率没有度量就没有改进。需求侧重点看三个数需求模糊度、单条需求整理耗时、变更影响匹配率。需求模糊度可以量化成模糊词出现的频次在前后端各写一个脚本统计即可一版改动之后看这个数是升是降单条需求整理耗时需要人工记录基线比如之前一个迭代人工整理 40 条需求用了 3 天用AI辅助后同样的量用了多少时间这个对比必须在同一批人、同一批素材的前提下才有说服力。变更影响匹配率需要一个抽样评估办法挑出最近 10 次历史变更人肉标出真实受影响的需求范围再拿生成式AI跑一遍同样数据看它给出的影响清单里有多少被人工确认过。这个数能到 70% 以上就已经值得用因为人的纯手工回忆往往也只能到 80% 左右而AI的漏找率会显著低一些。指标计算口径关注原因需求模糊词密度模糊词数量 / 需求条目总数模糊词越少需求越接近可验收单条整理耗时从原始素材到审核通过的需求条目直观反映整理阶段提效幅度变更影响匹配率AI命中影响项 / 人工确认影响项反映AI辅助分析是否可依赖需求复用率直接采用的需求条目 / 生成条目总数反映提示词与素材质量4.2 测试侧度量有效用例率与缺陷检出率测试侧容易犯的错误是把生成了多少用例当成绩。真正该看的是用例有效率最终通过运行层和评审层被接纳的用例数除以生成总数。这个比例能反映提示词和过滤机制的健康度长期低于 30% 则要回头看是素材质量太差还是被测模块太烂导致AI也写不出有意义的东西。另一项是缺陷检出率严格一点说应该做平行对比选一个迭代同样的模块和测试周期一部分用例靠人工设计一部分靠AI生成后人工确认最后统计各自发现的有效缺陷数量。这个实验设计能直接回答AI生成用例和人工用例谁更能发现真实问题但要注意缺陷去重和评审标准必须统一不然数据没有可比性。仅从环节耗时看需求到可运行用例的转化时间普遍能压缩一半以上这部分在汇报里边际成本最低。4.3 把确认过的产出回流成提示词示例AI产出的稳定性很大程度上取决于提示词里有没有贴近团队业务的示例。做法是每个迭代结束后从人工确认过的高质量需求条目和测试用例里各挑 3 到 5 条作为few-shot示例写进下一轮的系统提示词里。这些示例比任何抽象规则都管用因为模型能学到的是团队真实使用的术语、命名习惯和细节把控标准。持续几个迭代之后生成结果会越来越贴近团队风格这就是度量反馈之外的第三个飞轮。5. 落地避坑让生成式AI稳定输出高质量结果的3个技巧5.1 用单次完整上下文替代多轮追问多轮对话是需求漂移的最大来源。模型每经过一轮对话都会把前面对话内容压缩进上下文用户中途补充的一句话可能把初始规则冲淡。正确的做法是每次生成都是一个无状态的独立请求把所有约束一次性写进系统提示词把素材切片并按议题逐段传入。这样同一份输入多次执行会得到基本一致的结果排查问题时也能精准定位是提示词还是素材的锅。如果某个场景实在需要一个多轮交互的工作流就把中间结果显式地保存成JSON下一轮把JSON作为结构化输入传回去而不是靠对话记忆。5.2 先要检查清单再要正式产出从头就让模型直接输出最终结果失败的代价太高。一个很简单的技巧先在提示词里要求模型输出一份检查清单确认之后再要求它基于这份清单生成正式需求或测试用例。例如生成测试用例前先让模型列出该函数需要覆盖的边界条件清单再基于这份清单生成断言。这样做有两个实际好处一是清单可以被工程师快速审查发现缺项时只需要改清单不需要和几十条用例较劲二是模型在自查过程中经常能补上第一轮遗漏的边界分支生成质量明显高于一步到位。5.3 用REQ-ID做需求和测试的双向可追溯校验最后也是最重要的一个技巧把需求规格书和测试用例用REQ-ID绑死。生成的每条测试场景都在元数据里带上它验证的REQ-ID需求变更时跑一个脚本扫出所有引用了被变更REQ-ID的测试用例自动标记为需要重设计。校验脚本可以简单到用grepgrep -rl REQ-001 --includetest_*.py tests/这个命令把涉及 REQ-001 的所有测试文件列出来人工确认这些用例是否需要随需求变更一起调整。双向可追溯的收益在需求变更频繁的项目里被放大人不用翻文档回忆哪条用例受了影响测试结论也总能指到具体的需求来源上。开发团队可以再进一步把这条校验逻辑做成CI门禁任何变更如果包含REQ-001的改动而没有对应更新测试用例流水线直接给出警告把质量和效率都固化在流程里。本文还有配套的精品资源点击获取
简介软件工程与生成式AI结合的实践研究资料源于Vector咨询在2025年技术日的专题分享面向汽车电子、嵌入式系统及工业自动化领域的需求工程师、测试工程师、安全与网络安全专家。内容聚焦GenAI在需求工程与测试中的落地路径涵盖基于SLM语义搜索与RAG技术的私有化部署、测试用例自动生成、边缘场景识别、冗余消除以及面向ISO 26262与ISO/SAE 21434的TARA分析与漏洞识别。包内为1个PDF文档大小1.77MB全文约23页配有Vector官方调研数据与多个行业案例示意便于对照CANoe、vTESTstudio、PREEvision等工具链理解AI辅助流程。资源已有96人浏览/学习适合正在探索AI驱动研发提效与安全合规的技术管理者及从业者可快速建立从需求一致性优化到测试覆盖增强的完整认知框架。GenAI虽能显著降本提速但工程师需作为“驾驶员”审查AI输出资料对AI治理与人工闭环机制亦有涉及。1. 生成式AI进入软件工程需求和测试为什么最先被改造一个很反直觉的现象是软件工程里最见不得人的两个环节——需求整理和测试设计——反而是生成式AI落地最快、ROI最明显的地方。这两个环节有一个共同特点产出物几乎全是文本。需求规格书是文本测试用例是文本断言代码也是文本而大语言模型在文本转化和结构化这件事上的能力已经明显超过大多数人的平均整理速度。传统做法里需求分析师要把会议纪要、产品说明、用户反馈人工整理成条目化的需求规格书测试工程师再把这些需求手工翻译成用例过程中信息损耗非常大。与其争论AI能不能替代工程师不如先把钱花在刀刃上让生成式AI把从白纸起草的成本压到接近零人只做审查、决策和补洞。下面按一条可复现的链路拆开讲——从模糊的原始诉求到可验收的需求条目从需求再到能真正跑起来的自动化测试用例最后落到怎么证明质量效率确实提升以及三个保证输出稳定的落地技巧。这套思路适合手里已经能调用生成式AI接口无论是商用大模型还是私有化部署的软件工程师、测试开发和质量负责人。2. 需求侧用生成式AI把模糊诉求变成可验收的需求规格书2.1 需求规格书的痛点在哪生成式AI的边界就在哪软件开发里最常见的返工不是代码写错而是需求理解错了。传统需求分析天然有一个工作量分配规律沟通占三成整理成文档占五成真正做业务规则分析只占两成。生成式AI能压缩的是整理成文档这五成——把它变成一次有约束的生成和校对但这个过程不是把素材丢给模型就完事。我一般把需求侧分成三个可落地的任务从原始素材生成需求条目、做需求可测试性检查、辅助变更影响分析。这三个任务都依赖同一个前提先有一份质量过得去的原始素材。会议纪要、用户反馈、竞品说明、原型图上的注释素材越具体生成结果越可回收。反过来如果只给一句做一个电商系统再强的模型也只会给你返回一堆教科书式的空话。记住这个边界模型负责把混乱的素材整理成结构化文本不负责替你做一个业务取舍。2.1.1 为什么优先做结构化需求而不是直接写代码常见的一种误区是把生成式AI直接接到代码生成上跳过需求环节。但从工程实践看需求阶段的返工成本最低、收益却最大——改需求规格书里的一句话成本和改上线代码里的一段逻辑差一个量级。在这个环节里引入AI产出物还能继续往下游复用需求条目里的验收标准就是后面测试用例生成的输入。这也是为什么这套思路要先从需求规格书开始而不是从代码生成开始。2.2 从原始素材到结构化需求条目一条可靠的提示词与调用链路下面是一段可以直接改用的参考脚本。它读取一段原始素材会议纪要或产品说明输出固定结构的JSON需求条目。代码按OpenAI兼容接口写换成任何本地私有化部署的同类型服务只需要改base_url和model。import json import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), # 任意 OpenAI 风格的服务都行 ) SYSTEM_PROMPT 你是资深需求分析师。把给定素材整理为需求规格书条目。 规则 1. 每条需求以 REQ-ID 开头REQ-001 递增。 2. 必须包含需求名称、用户故事、验收标准、优先级(P0/P1/P2)。 3. 验收标准必须可测试禁止出现“快速、友好、尽量、大约”等模糊词。 4. 只输出 JSON 对象格式为 {requirements: [...]}不做解释。 def extract_requirements(material_path: str): with open(material_path, encodingutf-8) as f: raw f.read() resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o), temperature0.2, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: raw}, ], ) data json.loads(resp.choices[0].message.content) return data.get(requirements, []) if __name__ __main__: for req in extract_requirements(meeting_notes.md): print(json.dumps(req, ensure_asciiFalse, indent2))代码逻辑分三段系统提示词固定了需求分析的角色和验收标准约束用户消息传入原始素材响应强制要求JSON格式再解析成列表。这里有个容易忽略的点——temperature0.2不是随便设的。需求提取是确定性任务温度太高模型会自由发挥编出一堆素材里根本不存在的规则温度太低又容易死板地逐字复述不做过关的归纳。0.2左右是一个通用值如果你发现模型总是漏掉重要约束可以再降到0。提示不要把整份会议纪要一次性塞进去。模型会把寒暄、争论过程和过期信息也整理成需求。常见做法是先让模型按议题把纪要切成几段再对每段分别做需求提取最后合并去重。合并时如果出现两条需求互相矛盾不要指望AI替你裁决这是需要产品负责人拍板的事。2.3 需求可测试性检查让AI先挑模糊词再给替换建议生成完需求条目之后只完成了一半。需求规格书真正值钱的地方在于可验收如果验收标准里带着体验好速度要快这类词到了测试阶段就又变回扯皮。可以写一个复核提示词把生成的需求条目喂回去要求AI完成三件事找出不可测试的表述、把模糊词替换成可度量的描述、标注每条验收标准是否满足可观测、可判定、可重复。可观测有明确的输入和输出不依赖主观感受。可判定同一份输出能被不同测试工程师给出相同结论。可重复同一条件下执行多次结果一致。暧昧表达可度量的替换方向响应要快在基础数据集下查询接口 P95 响应时间低于 500ms界面要友好核心操作三步内可完成按钮文案与用户用语一致尽量不丢数据写入成功响应后断电重启数据恢复率为 100%支持并发200 并发用户场景下错误率低于 0.1%无 5xx上面这张表同时可以作为人工检查的参考标准。实际做的时候我会把复核的提示词固定成团队规范每次生成需求都强制执行一轮让模型在输出的JSON里直接带一个testable: true/false字段。这样需求规格书就不再是一份看完就忘的文档而是能直接进测试设计管线的结构化数据。2.4 需求变更影响分析从人肉追踪矩阵到AI辅助清单需求变更流程是系统集成管理里最费人的环节。传统做法是维护一个需求追踪矩阵RTM用手工表格把需求、设计模块、代码文件和测试用例关联起来变更时靠人力一个个翻。生成式AI在这里的用法不是替代RTM表而是把变更描述翻译成影响清单。实际操作时把当前需求库的全部条目变更描述一起传给模型要求它输出一个JSON影响的REQ-ID列表、每条受影响需求的理由、需要回归验证的测试场景。相比纯靠人回忆这个做法能减少遗漏特别是那些一两周前刚拆分过的小需求人很容易忘记它们也受牵连。但要注意模型对代码模块之间的真实依赖其实没有感知它能做的是基于文本语义的相关性分析。要拿到靠谱的代码层影响面还是得配静态调用分析一起用。3. 测试侧从用例生成到缺陷预测的AI化改造3.1 测试用例生成的两种驱动方式以需求为准还是以代码为准测试设计传统上有黑盒和白盒两条路生成式AI在两边都能发力但失败模式完全不同。以需求驱动的生成输入是需求条目和验收标准输出是业务场景用例回答的是功能做得对不对以代码驱动的生成输入是被测函数和行为描述输出的是带断言的最小测试函数回答的是实现稳不稳。实际项目里我会两条线同时用先用需求驱动生成端到端的业务用例覆盖主流程和异常流再挑核心模块做代码驱动生成单测补边界。遇到安全测试需求时要做的是先让模型生成一份测试规则与边界清单再基于清单产出受限的验证用例而不是让模型直接给出绕过手段。这既是安全测试的规范要求也避免了模型胡编危险payload带来的合规风险。3.1.1 为什么代码驱动更适合从函数签名发散需求驱动生成的用例偏业务视角通常不会发现除数为零空指针传参这类实现层面的故障。代码驱动则可以从函数签名直接发散参数类型、默认值、文档里的约束、引用到的常量这些都是生成输入的一部分。缺点是对新写的、痛苦的代码容易生成橡皮鸭子用例——断言恒真、没有实际意义这也是后面质量闸门要解决的核心问题。3.2 从需求规格书生成业务用例把验收标准拆成Given/When/Then拿第2章产出的需求条目直接生成测试场景是整条链路里最省力的一步。提示词模板固定成如下结构每条验收标准拆成正常流、边界流、异常流三个场景每个场景用Given/When/Then描述且必须引用REQ-ID。你是资深测试设计师。以下是需求条目及其验收标准。 任务为每条验收标准生成测试场景列表。 每个场景必须包含 - 场景标题 - priority高/中/低 - Given: 前置条件与测试数据 - When: 操作步骤 - Then: 可观测的预期结果 约束 - 优先覆盖正常主流程和用户可感知的异常处理 - 不要为没写进需求的功能发明场景 - 输出格式为 JSON 数组 需求条目 {requirement_json}这段提示词的关键在最后的不要为没写进需求的功能发明场景。模型默认倾向把测试场景写得很饱满会自动脑补权限校验、超时重试这些内容。这些补充可能正确但会让需求覆盖统计失真也给了测试工程师一种用例很全面的错觉。生成完之后简单写个脚本统计每条需求对应用例数覆盖率低于1:3的条目比如只有1个用例的P0需求要先人工检视。3.3 从源代码生成可运行的pytest用例一个最小可跑通的方案对于工具类函数、纯逻辑模块代码驱动生成单元测试已经比较可靠。下面的脚本读取一个Python源文件抽取指定函数生成pytest用例并立即执行验证。import ast import subprocess import os from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), ) def generate_test_for_function(source_code: str, func_name: str) - str: prompt f根据给定函数源码生成 pytest 单元测试。 被测函数{func_name} 源码 {source_code} 要求 1. 用标准 assert 断言不用 pytest.raises 以外的插件。 2. 必须覆盖正常输入、边界输入、异常输入。 3. 如果函数依赖外部资源用 monkeypatch 注入假实现。 4. 只输出 python 代码不要输出解释和 markdown 代码围栏。 resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o), temperature0.2, max_tokens1500, messages[ {role: system, content: 你是资深测试开发输出可直接执行的 pytest 代码。}, {role: user, content: prompt}, ], ) generated resp.choices[0].message.content.strip() ast.parse(generated) # 语法不合法会抛异常用于触发重试 return generated if __name__ __main__: with open(calc.py, encodingutf-8) as f: src f.read() # 提取函数定义块这里简单用函数名定位实际应结合 ast 扫描 func_src src.split(def calculate_discount)[1].split(\n\n)[0] test_code generate_test_for_function(def calculate_discount func_src, calculate_discount) with open(test_calc.py, w, encodingutf-8) as f: f.write(test_code) subprocess.run([pytest, -q, test_calc.py], checkTrue)代码逻辑说明先拼一个带函数源码的提示词要求模型只输出代码拿到结果后先做一次ast.parse语法校验这一步能拦住模型漏写括号、混入markdown围栏这类低级的烂活最后落盘并调用pytest执行执行不通过就代表生成的用例质量不合格直接丢弃重来。参数设置上temperature0.2是为了让断言风格保持一致单次入门设定可以接受max_tokens1500足够覆盖大多数单函数用例生成超长函数时可以把这段代码封装成循环失败重试重试两次全是语法错误就放弃并在日志里标记。更稳的做法是先把被测函数运行时能拿到的依赖找出来再在提示词里写明这个函数依赖 db_conn请注入假对象模型生成的用例才会真的能通过执行这一关。3.4 生成用例的质量闸门过滤层级与可交付标准AI生成的测试用例不能直接进测试仓库这是原则问题。一层是语法一层是静态检查一层是运行最后才是人工评审。粗筛阶段把明显不能用的剔掉运行阶段能暴露断言恒真和mock过度人工评审则看的是用例价值——这条用例有没有测到人容易漏掉的风险点。过滤层级手段要拦掉的问题语法层ast.parse / py_compile生成代码里有markdown围栏、缺冒号、缩进错乱静态层flake8 / pylint 精选规则未使用的变量、空函数、过于宽泛的异常捕获运行层pytest 执行 coverage用例压根跑不过、断言恒真、覆盖率虚高评审层测试工程师抽检用例没有业务意义、与需求脱节、注释误导后人实际度量起来一个模块生成 100 条用例经过前两层过滤大概能留下 60 到 70 条跑通之后真正被接纳的往往是 30 到 50 条——这个水平正常剩下的废用例并不是完全浪费它们的价值在于帮测试工程师快速找到容易出错的函数相当于一份自动生成的体检报告。产出测试结论时只统计最终通过运行层和评审层的用例数不要拿生成总数去汇报。4. 度量与反馈怎么证明生成式AI真的提升了质量效率4.1 需求侧度量模糊度、产出耗时与变更匹配率没有度量就没有改进。需求侧重点看三个数需求模糊度、单条需求整理耗时、变更影响匹配率。需求模糊度可以量化成模糊词出现的频次在前后端各写一个脚本统计即可一版改动之后看这个数是升是降单条需求整理耗时需要人工记录基线比如之前一个迭代人工整理 40 条需求用了 3 天用AI辅助后同样的量用了多少时间这个对比必须在同一批人、同一批素材的前提下才有说服力。变更影响匹配率需要一个抽样评估办法挑出最近 10 次历史变更人肉标出真实受影响的需求范围再拿生成式AI跑一遍同样数据看它给出的影响清单里有多少被人工确认过。这个数能到 70% 以上就已经值得用因为人的纯手工回忆往往也只能到 80% 左右而AI的漏找率会显著低一些。指标计算口径关注原因需求模糊词密度模糊词数量 / 需求条目总数模糊词越少需求越接近可验收单条整理耗时从原始素材到审核通过的需求条目直观反映整理阶段提效幅度变更影响匹配率AI命中影响项 / 人工确认影响项反映AI辅助分析是否可依赖需求复用率直接采用的需求条目 / 生成条目总数反映提示词与素材质量4.2 测试侧度量有效用例率与缺陷检出率测试侧容易犯的错误是把生成了多少用例当成绩。真正该看的是用例有效率最终通过运行层和评审层被接纳的用例数除以生成总数。这个比例能反映提示词和过滤机制的健康度长期低于 30% 则要回头看是素材质量太差还是被测模块太烂导致AI也写不出有意义的东西。另一项是缺陷检出率严格一点说应该做平行对比选一个迭代同样的模块和测试周期一部分用例靠人工设计一部分靠AI生成后人工确认最后统计各自发现的有效缺陷数量。这个实验设计能直接回答AI生成用例和人工用例谁更能发现真实问题但要注意缺陷去重和评审标准必须统一不然数据没有可比性。仅从环节耗时看需求到可运行用例的转化时间普遍能压缩一半以上这部分在汇报里边际成本最低。4.3 把确认过的产出回流成提示词示例AI产出的稳定性很大程度上取决于提示词里有没有贴近团队业务的示例。做法是每个迭代结束后从人工确认过的高质量需求条目和测试用例里各挑 3 到 5 条作为few-shot示例写进下一轮的系统提示词里。这些示例比任何抽象规则都管用因为模型能学到的是团队真实使用的术语、命名习惯和细节把控标准。持续几个迭代之后生成结果会越来越贴近团队风格这就是度量反馈之外的第三个飞轮。5. 落地避坑让生成式AI稳定输出高质量结果的3个技巧5.1 用单次完整上下文替代多轮追问多轮对话是需求漂移的最大来源。模型每经过一轮对话都会把前面对话内容压缩进上下文用户中途补充的一句话可能把初始规则冲淡。正确的做法是每次生成都是一个无状态的独立请求把所有约束一次性写进系统提示词把素材切片并按议题逐段传入。这样同一份输入多次执行会得到基本一致的结果排查问题时也能精准定位是提示词还是素材的锅。如果某个场景实在需要一个多轮交互的工作流就把中间结果显式地保存成JSON下一轮把JSON作为结构化输入传回去而不是靠对话记忆。5.2 先要检查清单再要正式产出从头就让模型直接输出最终结果失败的代价太高。一个很简单的技巧先在提示词里要求模型输出一份检查清单确认之后再要求它基于这份清单生成正式需求或测试用例。例如生成测试用例前先让模型列出该函数需要覆盖的边界条件清单再基于这份清单生成断言。这样做有两个实际好处一是清单可以被工程师快速审查发现缺项时只需要改清单不需要和几十条用例较劲二是模型在自查过程中经常能补上第一轮遗漏的边界分支生成质量明显高于一步到位。5.3 用REQ-ID做需求和测试的双向可追溯校验最后也是最重要的一个技巧把需求规格书和测试用例用REQ-ID绑死。生成的每条测试场景都在元数据里带上它验证的REQ-ID需求变更时跑一个脚本扫出所有引用了被变更REQ-ID的测试用例自动标记为需要重设计。校验脚本可以简单到用grepgrep -rl REQ-001 --includetest_*.py tests/这个命令把涉及 REQ-001 的所有测试文件列出来人工确认这些用例是否需要随需求变更一起调整。双向可追溯的收益在需求变更频繁的项目里被放大人不用翻文档回忆哪条用例受了影响测试结论也总能指到具体的需求来源上。开发团队可以再进一步把这条校验逻辑做成CI门禁任何变更如果包含REQ-001的改动而没有对应更新测试用例流水线直接给出警告把质量和效率都固化在流程里。本文还有配套的精品资源点击获取
