基于需求上下文知识增强的LLM辅助测试设计实践

2025全球软件质量&效能大会·深圳站基于需求上下文知识增强的LLM辅助测试设计实践李贺松|华为云TSELeader、测试技术专家全球软件质量&效能大会华为测试技术专家全球软件质量&效能大会01研发团队的心声02实践Al辅助测试设计面临的挑战我们的探索和实践实践对研发流程的改变全球软件质量&效能大会测试：需求总是简单几句话、规格也不清晰。我的时间都浪费在与产品和开发沟通和扯皮上，关键时刻还找不到人。每次现网出问题，所有的人都问我测试为什么没拦截到，我又变成背锅侠!开发：产品的需求写的不清不楚的，还经常改来改去。本来是架构该做的需求设计要让我来做，我还得做自测试，这不是测试该做的吗?留给我安静写代码的时间都不到一半。架构：那么大一个产品，就我一个架构师，每个月那么多需求要设计、功能、性能、安全、可靠性、体验都要考虑，我还要不要活了产品：几百上千条需求等着我分析、我白天还要见客户，这么简单的需求，架构、开发、测试还让我补这个补那个的，我要对产品竞争力和商业成功负责，我哪有那么多时间处理这么多细节的东西反串讲，线下沟通和澄清)占测试设计时间占比超过35%以上；全球软件质量&效能大会对于熟悉业务的研发人员(理解上下文)看来是显而易见的需求，对于新员工和大模型确是巨大挑战!基于以上原因，完全基于需求信息的AI辅助测试设计，平均采纳率一直在40%左右。如何获取高质量的上下文，成为AI辅助测试设计的关键突破路径。全球软件质量&效能大会关于需求上下文增强的路径选择思考2)消耗资源多2、直接将领域知识做成知识图谱进行检索?1)需投入领域专家定义本体模型(实体类型、关系约束)3)图数据库的成本较高3、直接将领域知识进行切片，以RAG的形式进行上下文知识检索?2.资源变更管理3.实例配置管理4.资源释放管理5.订单变更管理用例用例1用例2缺陷缺陷1缺陷…需求需求1特性21、通过特性关联的基线用例反向提取特性的功能点和功能模型2、需求与特性功能点的上下文关系分析4.扣减用户账号余额(包年包月)数据流：用户请求→订单系统→资源管理系V2或V3系统发送不同的请求(V2是创建委托、V3是创建委托系统增加新字段保存请求结果：APICTMRESOURCETENANT的F1、为什么不是需求?通过需求与特性的上下文关联分析，显著提升了大模型获取需求上下文知识的效率和质量，测试点的平均采纳率提升到70%以上特性1用例1缺陷缺陷1需求1需求…特性2需求②需求与特性上下文关联分析1、实例订购管理_函数服务不存在时创建实例_实例创建成2、实例订购管理_函数服务存在时创建实例_实例创建成3、资源变更管理_函数服务不存在时执行变更操作_变更操作成5、实例配置管理_函数服务不存在时配置API返回错误信息且6、实例配置管理_函数服务存在时配置API配置操作成功且状态记录正确9、函数服务存在性检查_网络类型不为V2_返回常规处理结果10、实例创建流程_资源租户为V2且函数服务不存在_实例创11、实例创建流程_资源租户为V3且函13、API配置流程_网络类型为V2且函数服务存在_配置操作成14、资源变更流程_资源租户为V2且函数服务不存在_变更操作成功且记录状态15、资源变更流程_资源租户为V3且函数服务不存在_变更操作成功且记录状态实践过程遇到的关键问题：1、同一份用例，每次提取的功能点和功能模型个数和颗粒度可能不一致，功能模型也可能存在结构差异2、同一个需求和相同的上下文信息，提取的测试点个数和颗粒度可能不一致3、不同服务，功能点和功能模型的原子粒度定义和边界不同，同一模型不能精准适配2、同一个需求连续多次生成测试点，然后去重取并集。关键术语标准化定义领域知识RAG产品手册/案例经验总结归因分析提取方法特性概述：…输入：交互规则：-状态机：…->…>…数据流：….-….>..测试点1、测试点2、..测试点n从特性基线用例中提取测试点的TOPN相关用例测试点n+TOPN相关用例测试点n的测试用例[用例标题]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.yaml1.本测试用例适用于验证Swagger文件导入功能在函数服务存在时的正确性2.测试环境应确保网络正常，平台服务正常运行3.测试过程中如遇异常，需记录具体错误信息并回滚测试环境1、需求的业务功能建模2、通过父特性的相关性用例辅助进行逻辑校验基于需求上下文增强的Al辅助测试设计整体方案特性1特性1用例1立立用例…需求需求1需求2缺陷缺陷1缺陷2缺陷…特性21、基于需求上下文知识增强，测试点的平均采纳率从不到40%左右提2、基于测试点的上下文知识增强(父特性的关联用例),由测试点生成测试用例的采纳率达到80%以上。需求上下文知识增强对测试点采纳率的提升效果全球软件质量&效能大会【存在的问题】1、当前测试人员在开展测试设计的时候往往需要与SE和开发反复澄清和沟通，沟通和澄清的时间占到测试设计时间的30%以上；2、当前需求的测试建议规格/建议往往写的比较简单，一个需求串讲完成以后不同的人对需求的理解程度不一样；3、当前的需求描述和设计文档中对需求上下文的分析不足，主要依赖开发和测试对业务知识的掌握情况。需求分解产品串讲需求上线测试反串讲测试设计【AI辅助测试设计带来的改变】1.在需求设计阶段，SE可以通过Al辅助生成的测试点快速获得需求设计质量的反馈，高效进行查漏补缺，提升设计质量的同时，可以高效生成高质量的测试建议；2.在需求串讲阶段：SE、DE、TSE通过对测试点的评审和补充，高效达成对需求理解的一致性，串讲和反串讲融合；3.在需求开发阶段：DE可以基于串讲环节明确的测试点进行需求自验证，提升需求开发质量；4.在测试设计阶段：TSE基于串讲环节明确的测试点进行详细的测试设计，可以显著减少与产品和架构的澄清和沟通，提升需求设计的效率和质量。需求分解产品串讲需求设计设计串讲+测试反串讲1、架构师(设计负责人)的评价@李贺松，感谢贺松下午2个多小时一直在线指导，今天fg串讲了5个需求，覆盖了下面三类场景：1、历史上下文质量差，但需求文档写的质量很高，生成的用例质量很高2、历史下文质量好，但需求文档质量写的差，生成的用例质量也高3、历史上下文质量差，需求文档质量写的也差，生成的用例质量巨差个人感觉：以前衡量需求文档写的质量好不好，很难量化。现在AI用例生成直接量化了