2025QECon全球软件质量效能大会：基于需求上下文知识增强的LLM辅助测试设计实践

QECon2025全球软件质量&效能大会

·深圳站2025

GLOBAL

SOFTWARE

QUALITY

&EFFICIENCY

CONFERENOE

SHENZHENZHAN基于需求上下文知识增强的LLM

辅助测试设计实践李贺松|华为云

TSE

Leader、测试技术专家联合作者：韩维斌李贺松华

为

测

试

技

术

专

家华为技术PaaS

服务产品部测试TMG

主任、TSEG

Leader,华为智能化测试TMG

成员，主要负责产品部的测试工程和技术能力规划和演进，当前重点聚焦AI辅助测试领域的探索和实践，包括Al辅助测试设计、AI辅助测试代码生成、AI

辅助失败用例分析、API

自主遍历测试等。QECon全球软件质量&效能大会QECon全球软件质量&效能大会01

研发团队的心声02

实践Al辅助测试设计面临的挑战我们的探索和实践实践对研发流程的改变目录CONTENTS研发团队的心声全球软件质量&效能大会888QE

研发人员的心声测试：需求总是简单几句话、规格也不清晰。我的时间都浪费在与产品和开发沟通和扯皮上，关键时刻还找不

到人。每次现网出问题，所有的人都问我测试为什么没拦截到，我又变成背锅侠!开发：产品的需求写的不清不楚的，还经常改来改去。本来是架构该做的需求设计要让我来做，我还得做自测试，这不是测试该做的吗?留给我安静写代码的时间都不到一半。架构：那么大一个产品，就我一个架构师，每个月那么多需求要设计、功能、性能、安全、可靠性、体验都要

考虑，我还要不要活了产品：几百上千条需求等着我分析、我白天还要见客户，这么简单的需求，架构、开发、测试还让我补这个补

那个的，我要对产品竞争力和商业成功负责，我哪有那么多时间处理这么多细节的东西啊。每个角色都一本难念的经!QE

高昂的团队沟通和协作成本在需求分析和测试设计阶段，与产品、架构、开发针对需求的沟通和澄清(包括需求串讲/

反串讲，线下沟通和澄清)占测试设计时间占比超过35%以上；需求分析&测试设计耗时分布需求分析和澄清35%大模型加持下，团队间的沟通和协作能带来什么改变?Al辅助测试设计关键挑战全球软件质量&效能大会888QE

AI

辅助测试设计面临的问题和挑战对于熟悉业务的研发人员(理解上下文)看来是显而易见的需求，对于新员工和大模型

确是巨大挑战!1、一句话需求多，缺乏需求设计2、图片型需求3、设计质量差，规格不清晰4、缺少上下文影响分析基于以上原因，完全基于需求信息的AI

辅助测试设计，平均采纳

率一直在40%左右。如何获取高质量的上下文，成为AI辅助测试

设计的关键突破路径。我们的思考和实践全球软件质量&效能大会888

关于需求上下文增强的路径选择思考1、直接将领域知识进行模型微调

(SFT)?1)训练周期长，DevOPS模式下，领域知识迭代比较快2)消耗资源多3)灵活性差，切换基模型要重训练，很难灵活切换到最优的基模型上2、直接将领域知识做成知识图谱进行检索?1)需投入领域专家定义本体模型(实体类型、关系约束)2)对领域知识的质量要求较高，非结构化文档语义解析、标注和训练成本较大3)图数据库的成本较高3、直接将领域知识进行切片，以RAG

的形式进行上下文知识检索?1)领域知识大多非结构化，且质量参差不齐2)基于成本考虑，内部部署的模型有Token

数限制3)太多非结构化的领域上下文知识会耗散模型的注意力，很难精准检索并增强需求上下文有没有可以兼顾质量、效率和成本的方案?**功能点”实例订购管理”的功能模型：输入：用户选择的实例规格、计费模式(包年包月或按需)、企业项目、资源名称等参数输出：订购成功或失败提示信息交互规则：1.检查所选商品是否在售2.验证用户输入参数的合法性3.生成订购订单4.扣减用户账号余额(包年包月)5.创建实例资源状态机：待订购→订购中>订购成功/失败数据流：用户请求→订单系统→资源管理系统→用户反馈“需求与“实例订购管理”的交互过程在实例订购管理中，当用户选择实例规格、计费模式等参数时，系统需要检查当前指定的资源租户是V2或V3系统根据资源租户类型准备请求参数，如获取region、委托服务账号opsvcff、token等系统发送不同的请求(V2是创建委托、V3是创建委托&授权)系统增加新字段保存请求结果：APICTMRESOURCETENANT

的FGAGENCY,映射到APIMGR.SMRESOURCETENANTNFO的FGAGENCY,

取值格式为sting,取值范围为缺省、false、true1、通过特性关联的基线用例反向

提取特性的功能点和功能模型2、需求与特性功能点的上下文关系分析2.资源变更管理3.实例配置管理4.资源释放管理5.订单变更管理XX

服务特性树特性1用例用例1

用例2

用例…缺陷缺陷1缺陷2缺陷…需求需求1需求2需求…

特性2特性…基于特性树的需求上下文知识增强特性的主要功能点：1.实例订购管理1、为什么不是需求?2、为什么不是设计文档?3、为什么不是用户指导手册?QE

为什么选择基线用例而不是其它特性①特性功能点和功能模型需求

②需求与特性上下文关联分析③提取需求的功能点、功能模型、测试对象→测试点测试点1、测试点2、

.…XX服务特性树特性1用例用例1

用例2

用例…缺陷缺陷1缺陷2缺陷…需求需求1需求2需求…特性2特性…1、实例订购管理_函数服务不存在时创建实例_实例创建成功且状态记录正确2、实例订购管理_函数服务存在时创建实例_实例创建成功且状态记录正确3、资源变更管理_函数服务不存在时执行变更操作_变更操作成功且状态记录正确4、资源变更管理_函数服务存在时执行变更操作_变更操作成功且状态记录正确5、实例配置管理_函数服务不存在时配置API返回错误信息且提示内容正确6、实例配置管理_函数服务存在时配置API

配置操作成功且状态记录正确7

、函数服务存在性检查_网络类型为V2且函数服务存在_返回成功状态8、函数服务存在性检查_网络类型为V2

且函数服务不存在_返回失败状态9、函数服务存在性检查_网络类型不为V2_返回常规处理结果10、实例创建流程_资源租户为V2

且函数服务不存在_实例创建成功且记录状态11、实例创建流程_资源租户为V3

且函数服务不存在_实例创建成功且记录状态12

、API配置流程_网络类型为V2且函数服务不存在_返回错误信息且提示内容正确13、API

配置流程_网络类型为V2且函数服务存在_配置操作成功且状态记录正确14、资源变更流程_资源租户为V2且函数服务不存在_变更操作成功且记录状态15、资源变更流程_资源租户为V3且函数服务不存在_变更操作成功且记录状态

由需求生成测试点的思维链过程通过需求与特性的上下文关联分析，显著提升了大模型获取需求上下文知识的效率和质量，测试点的平均采纳率提升到70%以上实践过程遇到的关键问题：1、同一份用例，每次提取的功能点和功能模型个数和颗粒度可能不一致，

功能模型也可能存在结构差异2、同一个需求和相同的上下文信息，提取的测试点个数和颗粒度可能不一致3、不同服务，功能点和功能模型的原子粒度定义和边界不同，同一模型不能

精准适配QE如何提升模型生成功能模型和测试点的遵从度?Prompt

OptimizerRLHF功能点/功能模型测试点/测试对象规范/领域术语1、特性功能点提取和功能建模

-示例效果

你是一个XX

领域服务的资深TSE,

您的任务x.…功能点定义：

XX…功能模型定义：XX提取方法1、先根据特性描述对描述相同的用例进行聚类合并2、基于聚类后的用例信息，深度思考并提取特性的功能点及其功能模型3、根据提取的功能点，对特性做一句话概述：

输出格式如下：特性的主要功能点：

…

,

…

,

…

,**功能点”.."的功能模型：输入

：QE

通过关键术语的标准化定义提升模型遵从度1、将功能点、功能模型、测试对象、测试点等关键术语做标准化定义并纳入提示词2、同一个需求连续多次生成测试点，然后去重取并集。提升模型遵从度的关键手段提示词优化模型微调(SFT)关键术语标准化定义领域知识RAG多

轮

对

话产品手册/案例经验总结归因分析维度/命中率分析交互规则：-状态机：

…->…>

…

数据流：

….-

….>

….**功能点”…."的功能模型：[用例标题]API导入与管理_导入Swagger

文件_函数服务存在时导入成功[用例详细]前置步骤1.用户登录PaaS平台2.

创建一个函数服务，命名为test-func3.准备一个包含API定义的Swagger

文件，命名为test-api.yaml测试步骤步骤1:上传Swagger

文件输入：选择文件test-api.yaml,

点击上传按钮预期结果1:文件上传成功，显示上传完成提示步骤2:检查导入状态输入：进入API导入页面，查看导入状态预期结果2:显示导入成功，状态为"成功",无错误提示步骤3:验证API信

息输入：进入API

列表页面，查看导入的API预期结果3:显示导入的API

信息，包括路径、方法、请求参数等，与Swagger

文件定义一致后置步骤1.删除创建的函数服务test-func2.删除上传的Swagger

文件test-api.yaml备

注1.本测试用例适用于验证Swagger

文件导入功能在函数服务存在时的正确性2.测试环境应确保网络正常，平台服务正常运行3.测试过程中如遇异常，需记录具体错误信息并回滚测试环境XX服务特性树特性1需求需求1需求2需求…用例用例1

用例2

用例…特性2特性…测试点1、测试点2、

.

.测试点n从特性基线用例中提取测

试

点

的TOPN

相关用例测

试

点n

+TOPN相关用例测试

点n

的测试用例

由测试点生成测试用例的思维链过程通过提取测试点的相关性用例，在试点服务成功将LLM

辅助生成用例的采纳率提升到80%+1、需求的业务功能建模2、通过父特性的相关性用例辅助进行逻辑校验3、测试模式库，测试对象，测试方法和场景条件的组合的规则匹配QE

如何提升测试用例的业务逻辑正确性?基于需求上下文增强的Al

辅助测试设计整体方案需求需求1需求2需求….缺陷缺陷1缺陷2缺陷…⑤用例关联需求，基线化用例回合特性树特性2特性…

1、构筑全链路专家反馈

2、打造数据飞轮XX

产品/服务特性树特性1基线用例用例1用例2用例

…④基于测试点和特性级相似用例生成测试用例专家反馈测试用例

LLM①基于特性关联用例&用户手册

提取特性功能点和功能模型专家反馈LLM

特性功能建模③基于需求的功能模型生成测试点专家反馈测试点

LLM②基于需求信息和特性功能点&功能模型进

行需求与特性上下文关联分析和功能建模专家反馈需求上下文分

析和功能建模立LLM

→QE

实践效果1、基于需求上下文知识增强，测试点的平均采纳率从不到40%左右提升至70%+。2、基于测试点的上下文知识增强(父特性的关联用例),由测试点生成测试用例的采纳率达到80%以上。需求上下文知识增强对测试点采纳率的提升效果80%70%70%60%50%40%40%30%20%10%0%没有上下文

有上下文全球软件质量&效能大会实践对研发流程的改变888QE

未结合AI

辅助测试设计能力之前的需求交付流程【存在的问题】1、当前测试人员在开展测试设计的时候往往需要与SE和开发反复澄清和沟通，沟通和澄清的时间占到测试设计时间的30%以上；2、当前需求的测试建议规格/建议往往写的比较简单，一个需求串讲完成以后不同的人对需求的理解程度不一样；3、当前的需求描述和设计文档中对需求上下文的分析不足，主要依赖开发和测试对业务知识的掌握情况。需求分解产品串讲需求设计

设计串讲需求开发和自测需求上线需求验证测试反串讲测试设计【AI

辅助测试设计带来的改变】1

.在需求设计阶

段

，SE

可以通过Al辅助生成的测试点快速获得需求设计质量的反馈，高效进行查漏补缺，提升设计质量的同

时，可以高效生成高质量的测试建议；2.在需求串讲阶段：SE、DE、TSE

通过对测试点的评审和补充，高效达成对需求理解的一致性，串讲和反串讲融合；3.在需求开发阶段

：DE

可以基于串讲环节明确的测试点进行需求自验证，提升需求开发质量；4.在测试设计阶

段

：TSE

基于串讲环节明确的测试点进行详细的测试设计，可以显著减少与产品和架构的澄清和沟通，提升需

求设计的效率和质量。需求分解

产品串讲需求设计

设计串讲+测试反串讲需求开发和自测需求上线需求验证测试设计Al辅助测试设计与需求设计和串讲流程深度融合，使能研发协作效率和体验提升1、AI辅助测试设计能力：把串讲和反串讲结合在一起，提高了工作效率，一次性把需求讨论澄清，避免浪费跟开发、产品经理、架构讨论扯皮的时间2、还帮我们把测试方案直接生成了，节省了手工慢慢编写的时间994+-2025-05-2016:303、SL

(开发代码)的评价QE

研发团队对Al

辅助测试设计的评价以下仅代表我个人感受：个人感觉：以前衡量需求文档写的质量好不好，很难量化。现在AI用例生成直接量化了(功能、性能、安全、可靠性、运维),写的差的ut根本就一点不能用，通过这个促进研发整体设计意识和能力的提升。另外高质量的需求文档能让架构师和测试节约很多

评审时间。短期阵痛：存量需求的历史上下文整改，以及基于存量需求的小的增补特性，研发需要更加清晰描述出需求文档，要比以前多花

xx%时间写文档。不过流程熟悉后整个团队效率会提升。FG

后续的需求，我打算用这个Al用例质量在串讲之前卡个点。然后调研一下fg这边的研发人员的反馈，配合松哥持续提升效率。2025-05-2016:282、TSE

(测试责任人)的反馈Al辅助测试设计有助于帮助简化迭代过程(可合并需求串讲和反串讲流程),有利于

迭代快速上线。生成用例的准确性高，有利于开发和测试迅速对齐测试场景，甚至

可补充遗漏场景。可在安全域推广@李贺松，感谢贺松下午2个多小时一直在线指导，今天fg串讲了5个需求，覆盖了下面三类场景：1、

历史上下文质量差，但需求文档写的质量很高，生成的用例质量很高2、历史下文质量好，但需求文档质量写的差，生成的用例质量也高3、历史上下文质量差，需求文档质量写的也差，生成的用例质量巨差1、架构师(设计负责人)的评价2025-04-2418:36关于未来能力规划的思考全球软件质量&效

能

大

会感谢聆听关注公众号作为企业第三方专业人力提升培训服务供应商，秉承互联共成长的理念，恪守客户实际业务需求为第一优先级的本职。我们公司定位于专业、专注、全方位服务于IT研发中心，产品、技术、工具、团队管理方向的培训课程；有公开课，定制内训，在线课，T技术峰会一站式采购等产品；更多的从客户需求角度出发，匹配更适合团队学习的资讯和课程推荐；更好的为客户服务，有专业的培训顾问，对整个IT行业峰会，讲师情况，课程方向都有比较深的了解。公开课

微咨询云计算专业

IT

技

术培训服务供应商产品经理持续运维质量管理大数据数据库前端开发5大服务课程方向为企业人才培养需求提供多方位的讲师课程推荐，在线学习质量把关，资料学习推荐及直播课堂服务。在线

课程技术

峰会内训

定制智盟创课www.zmeng测试开发组织管理敏捷开发架构设计开发编程咨询电话软件研发效能权威指南

大模型时代的软件工程QECon

持续输出AI4SE

案例篇已发布10篇，抢先订阅

编写进行中20+篇案例关注QE公众号

回复“DORA2024”获取报告关注QE

公众号回复“工具指南”获取书籍链接立即参与案例持续收录中个前沿案例实用软件研发质效工具指南汇聚行业系用软件研发质效工具指南一书籍推荐一测试和研发领域的“百科全书”ENGIWEERING

PRODUCTTMITYDEFINITVEGUIDE软件研发效能

权威指南主编

茹

娟腥

张

乐副主编陈题石需蜂吴酸龙余超

LP

张眸MODERN

SOFTWARETESTINGDEFLNTTIVEGUDE现代软件测试技术

权威指南购买链接威代指南件软件研发效能权威指南测技禾+na

版t⁰

图拿上服性专项测试(含全链路压测、混沌工程、性能测试等)数据驱动测试与精准测试智能化测试的创新实践Al时代下的安全测试自动化测试工具开发LLM赋能下测试管理与流程再造质效度量：从洞察到智能化AI原生应用的质量评测研发数据治理与质效提升多智能体助力效能提升(含MCP、A2A应用)平台工程(设计驱动的质效内建)Vibe

Coding模式下代码质效大模型在研发提效中的深度实践大模型驱动的DevOps工具链大模型时代的质量体系和文化建设2场2小时闭门会2场3小时深度工作坊2025全球软件质量&效能大会10/31-11/1北京-希尔顿逸林酒店09/12-13上海-明捷万丽酒店下一站上

海

站北

京

站

45%研发关键技术能力进阶专场

大数据平台与架构实践

出海与云原生

高可用架构

大前端前沿技术

大前端架构实践

业务架构数据治理数据库架构SECon2025全球软件工程技术大会2025

GLO

B

A

L

SOF

T

WA

RE

ENG

IN

EERING

CON

FE

REN

C

E

Data+Al

的探索与实践

AI重塑研发工作流

AI模型安全与伦理

Agent

模式的探索与实践模型应用主流架构模式：大模型+小模型55%AI

模型应用核心能力提升专场6月20-21日深圳11月21-22日上海RAG

与生成式AI行业应用大模型高效训练与微调多模态与生成式AI应用大模型行业创新应用AI时代的数据架构模型部署与优化AI前沿论文解读查看官网AI产品创新案例征集征集最具突破性、影响力与商业价值的Al产品创意案例，并同步开放宣传海报、宣传视频征集通道打造行业Al产品标杆宣发盛宴!详情咨询征集目标展示前沿Al产品创意汇聚全球Al领域“技术+场景”

双突破的标杆案例搭建资源平台联动300+行业头部企业，为优秀Al产品提供曝光、

市场合作机会征集内容创

意

海

报需突出Al产品核心价值设计风格兼具科技感与产品力创

意

视

频时长1-3分钟，需包含产品DEMO演示、用户场景故事线

技术突破解读(4K分辨率，

MP4格式优先)从需求洞察、商业模式设计到产品全生命周期管理，随着AI的深度渗透，正重新定义产品创新的边界与可能性。诚邀各行业优秀产品案例议题，共同探讨“传统产品根基与Al重构的双向赋能”,推动产品力在传承与变革中持续进化。◆

与产品力领航者碰撞思想，在传统经验沉淀与Al创新实践中寻找平衡点◆深度链接技术、商业与用户研究领域资源，构建跨代际产品生态网络◆输出方法论与实战案例，推动行业认知升级，持续放大个人P势能◆与产品力领航者碰撞思想，在传统经验沉淀与Al创新实践中寻找平衡点◆

深度链接技术、商业与用户研究领域资源，构建跨代际产品生态网络◆

输出方法论与实战案例，推动行业认知升级，持续放大个人IP势能为何参与?议题期待期待您的真知灼见

共筑产品力新未来!产品力领航者大会ThePowerofProducts

LeadershipConfere