天猫如何突破测试瓶颈?AI智能用例生成实践与挑战解析

天猫AI智能测试用例生成实践,通过规范需求、Prompt工程与RAG,提效75%,推动QA向“脑力型”转型。 #AI测试 #天猫技术 #效率提升

原文标题:从0到1:天猫AI测试用例生成的实践与突破

原文作者:阿里云开发者

冷月清谈:

天猫技术团队深入探索AI赋能测试领域,以智能测试用例生成为核心,旨在应对电商行业快速迭代、高人力成本和传统测试模式瓶颈等挑战。他们通过一套系统化的策略实现了用例生成的智能化,该策略包括“需求规范化、Prompt工程、知识库RAG、平台化集成以及AI Agent能力建设”
具体而言,团队优化了Prompt设计以引导大模型生成高质量用例,构建了包含基线用例和资损场景等在内的高质量知识库并利用AI Agent自动构建与维护,同时推动PRD(产品需求文档)的规范化以提升输入质量,最终将AI能力集成到用例管理平台。
实践结果显示,在导购、详情等C端业务,AI生成用例的采纳率可达85%以上;在导购场域和营销解决方案等中小型需求中,用例编写时间缩短75%,从2小时降至0.5小时,显著提升了工作效率。
尽管在PRD质量、视觉/交互稿支持以及复杂需求处理方面仍面临挑战,但天猫团队未来计划继续深化AI能力,实现全流程自动化,并推动QA角色从“体力劳动型”向“脑力劳动型”转型,聚焦于业务风险识别、策略制定和探索性测试,最终突破测试领域的“不可能三角”,实现更优的覆盖率、更快的速度和更低的成本

怜星夜思:

1、文章里提到天猫AI生成的测试用例在C端(导购、详情)采纳率高达85%以上,但B端(资金、供应链)却不到40%。大家觉得这是为什么呢?除了文章里说的PRD质量影响,还有哪些可能的原因?小公司碰到类似情况又该怎么提高AI用例的“靠谱度”?
2、天猫的实践告诉我们AI在测试领域潜力巨大,未来的QA可能要从“体力劳动型”转向“脑力劳动型”。那么问题来了,这种转型对我们测试工程师来说意味着什么?是挑战多还是机遇多?大家觉得未来我们最核心的竞争力或者说急需培养的技能会是哪些?
3、天猫这么大的平台能投入资源搞AI测试,咱们小公司或者个人开发者想尝试类似的技术,是不是就没戏了?有没有什么“平替”方案或者可以借鉴的“轻量级”策略,也能享受到AI辅助测试的好处呢?

原文内容

阿里妹导读


本文系统阐述了天猫技术团队在AI赋能测试领域的深度实践与探索,讲述了智能测试用例生成的落地路径。

一、背景

1.1 业界分析与思考

随着大模型的不断演进,测试行业基于AI也在做不同程度的探索,在agent智能体生成方面,基本使用的是prompt+RAG的方式,构建特定业务的需求分析/测试用例生成/数据构造智能体等。下述是以用例生成为例的一些业界方案和效果:

参考文章:QECon大会以及外部分享

对业界能力的分析,基本都是基于prompt+RAG做能力拓展,没有涉及对模型的微调。过程中存在着对需求解析,测试分析过程,知识库建设的差异化处理。基于对天猫技术业务的理解和发展趋势的判断,我们需要针对天猫技术不同行业特性,做用例生成差异化的处理,同时针对强依赖的输入产物(prd)做一定的规范化处理。

1.2 天猫行业特性

在瞬息万变的电商行业,业务迭代速度快,对产品质量要求日益提高。测试团队面临着以下挑战:

  • 版本节奏快,人力成本高快速的版本迭代要求测试团队投入大量精力,但同时面临人力成本控制的压力。

  • 传统测试模式的瓶颈测试用例的设计、维护和执行,尤其是针对复杂场景和边界条件,高度依赖测试工程师的经验和时间投入,效率和覆盖率存在提升空间。

当然在测试用例编写阶段,也存在着如下痛点:

  • 用例设计效率低人工编写测试用例耗时耗力,难以覆盖所有场景,尤其是异常和资损场景。

  • 需求理解偏差不同测试人员对需求的理解可能存在差异,导致用例设计的不一致性。

  • 知识沉淀不足基线用例、踩坑点、业务背景等知识的有效沉淀和复用机制不完善。

  • 人工成本高大量重复性、模式化的用例编写工作占用了QA大量的工作时间

同时经分析,现有业务特性差异较大,主要划分成5类业务类型,分别为:营销解决方案,导购场域,交易结算,多部门协作,中后台,如何针对不同业务类型做用例生成的适配和应用,也是面临的难题之一。

为应对上述挑战,我们的核心目标是通过AI技术,实现测试用例的智能化生成,并构建一个符合行业特性的测试流。

二、实施策略

2.1 用例生成思路

对于QA来说,我们需要通过一系列手段来保障业务的质量,同时探索业务的天花板,这一系列手段包括:围绕业务迭代的需求交付,需求理解->风险评估->用例设计->用例执行->缺陷追踪->集成/回归->发版/上线->反馈跟踪。

其中从用例设计到最终的回归约占据了QA 70%的时间,在当下对于质量要求高,版本节奏快,人力成本缩减的前提下,急需借助大模型来辅助测试设计,建设相关的智能化工具。整体思路如下:

2.2 具体实施方案

围绕AI用例生成的目标,制定了“需求规范化 + Prompt工程 + 知识库RAG + 平台化集成”的总体策略,并辅以Agent能力建设,提升日常知识库建设人效。

1.Prompt工程与流程优化通过精细化的Prompt设计,结合上下文信息,引导LLM生成高质量的测试用例。搭建端到端的用例生成Flow,将AI能力集成到现有工作流中。

2.高质量知识库构建系统性地沉淀业务背景、基线用例、特殊场景(踩坑点)、资损场景等,并结合RAG技术,提升AI生成用例的相关性和准确性。

3.需求规范化推动PRD规范化,提供标准化模板,提升需求输入的质量,从而提高AI生成用例的稳定性和覆盖率。

4.AI Agent赋能过程中迭代专门的AI Agent,用于知识库构建、PRD补全、知识库检查等,进一步降低人工成本,提升效率和质量。

5.平台化集成将AI能力集成至用例管理平台,实现平台化操作。

整体流程如下:

2.2.1 Prompt工程与流程

为了降低不同人员需求理解用例设计差异性,提升用例可读性和后期维护成本,当前prompt严格遵循该策略,包含:

1.基于前置功能用例和需求推导非功能用例,包含定义异常,资损等设计原则和具体案例,通过RAG和prompt的方式来增强用例设计的确定性

2.针对较复杂需求,可以自主拆分成业务模块,针对单模块通过test copilot进行对话式生成,并可以通过对话进行用例的修改。

3.支持各行业灵活定制行业特性和行业示例。

4.搭建从需求输入到用例输出的端到端AI用例生成Flow,根据行业标签,路由至行业知识库/prompt/行业示例等。

2.2.2 高质量知识库构建

针对如何提升RAG召回的精确性,我们确定了知识库建设的标准,通过知识库的动态检索,提升用例的覆盖率和采纳率,整体思路如下:

RAG部分详细内容如下:

1.知识库范围

a.测试用例:基线用例,特殊用例(踩坑点)等。

b.业务背景:领域术语、业务流程、用户故事等。

c.资损场景:触发条件、影响范围、测试重点等。

2.数据格式(结构化存储文本(纯文本,markdown,JSON格式),表格。

3.数据检索包括分块策略,召回策略、索引方法。

4.知识库维护数据清洗、去重,更新机制。

针对沉淀的内容,可通过业务域->功能模块->功能点进行拆分,利用关键词来召回最小单元的功能点,示例如下:

为了节省人工构建知识库的成本,还探索了知识库自动构建agent,可基于原始技术文档可以快速构建知识库,提取出业务术语,业务流程,核心功能点等。

对于当前切分不合理的知识库,通过agent进行重构,可有效提升知识库的切片效果。如下示例所示,原知识库单个功能描述被切分至多个无效片段——>而通过agent进行构建后,可对全文信息进行整合总结,单个片段内容更完整和结构化。

2.2.3 需求规范化

通过多轮需求测试,发现prd质量对用例生成的覆盖率影响较大,通过与PD合作,定义和推广标准化PRD模板,来进一步提升用例生成的稳定性。当前已在天猫APP多个业务域试点,并完成相关实践,通过标准化产出的prd测试结果如下:

  • AI生成的用例采纳率和AI用例覆盖率有明显提升;

  • 生成用例已初步区分用例模块,以及整体用例设计更完善,所有子模块用例均涉及;

需求规范化模板

规范表达,可被计算处理

规范化需求示例

AI生成用例





2.2.4 平台化集成

当前用例生成已集成至用例管理平台,提供可视化操作入口。支持Ai-Test和Test Copilot 两种形式。结合Test Copilot等工具,支持复杂需求模块化拆解与对话式用例生成。当前天猫技术质量也继续探索AI在数据构造、用例执行等更方面的应用,形成全流程自动化。

三、应用效果

1. 采纳率:在偏向于C端表现部分(如导购、详情)表现较好,采纳率可以达到85%以上,但在B端(如资金、供应链)表现一般,采纳率普遍不到40%。

2. 实际提效:在导购场域、营销解决方案领域中,中小型需求的用例编写时间从2小时缩短至0.5小时(节省75%)。

四、展望

目前在实践中主要问题还是集中在PRD质量不高;需求解析中对视觉稿,交互稿等无法支持,以及需求过于复杂的状态下,使用效果不佳。后续计划在AI能力深入,AI全流程自动化继续尝试。

在未来,能够实现AI智能自主运行,独立完成需求分析,用例生成,脚本构造和执行,上报需求缺陷,跟进质量闭环等流程。基于人工智能的理解,记忆,规划等,为QA角色带来新的转变。

我们需要从“体力劳动型”测试向“脑力劳动型”测试转型,将繁琐重复的工作交给AI,让QA聚焦于更具挑战性的领域:业务风险识别、测试策略制定、探索性测试以及用户体验深挖。未来在一定程度跳出覆盖率-成本-速度的不可能三角,实现更高的覆盖率,更快的速度和更低的成本。

原生 SQL 轻松实现多模态智能检索


传统 AI 开发需将数据从 OLTP 数据库迁移至专用向量库实现特征匹配,跨系统数据搬运会引发多环境数据冗余、版本混乱等核心问题。本方案基于阿里云 PolarDB 与阿里云百炼,融合 Polar_AI 智能插件,赋予数据库原生的 AI 能力。通过标准 SQL 语法直接调用多模态 AI 服务,高效完成图像特征提取与向量化处理。


点击阅读原文查看详情。


哈哈哈,天猫那是“钞能力”加“技术力”的双重buff,我们小公司不能硬刚。但咱可以“蹭”啊!现在大模型API服务都是按量付费,小公司完全可以把AI当成一个增强版的外包小助理来用。比如:
* 需求分析助手: 把PRD丢给AI,让它帮你找出可能的测试点、风险点。
* 用例生成辅助: 让AI生成用例的模板或者基础功能用例,人工再加工。
* 测试数据构造: 有些场景需要特定格式的测试数据,AI可以批量生成。
* 缺陷描述优化: 让AI润色(甚至初步分类)缺陷报告,提高沟通效率。
甚至可以尝试用AI做简单的测试脚本生成与维护。不需要投入大量研发资源,只需要合理利用现有的AI工具,把AI集成到日常工作中,就能有效提升局部效率。关键是“巧用”而非“硬上”,先解决最痛的那个点!

关于“B端采纳率低”这个问题,我个人觉得,B端业务通常逻辑更复杂,涉及到的前后链路、系统集成和数据一致性要求都远高于C端。比如资金交易,一个小小的逻辑漏洞可能导致 huge loss,所以对用例的严谨性、覆盖范围和边界场景考虑会极致得多。AI现在虽然能力强,但它依赖的还是已有的知识和模式。B端很多时候是定制化、业务规则多变,甚至有很多约定俗成的“潜规则”,这些AI可能还没法很好地学习和推理。小公司的话,我觉得可以先从AI辅助生成部分用例入手,比如通用功能、回归测试用例,减轻基础工作量,然后把人工重心放在AI暂时无法触及的复杂逻辑和资损用例上,逐步提升“靠谱度”。

B端和C端差别大着呢!C端用户行为模式相对比较“野”,AI可以从大量用户数据和常见操作中学习;B端业务呢,就是个逻辑怪兽,它的正确性往往依赖于各种精密的规则和上下游的联动,甚至很多逻辑根本不是纯粹的文字能描述清楚的,可能是一张复杂的状态机图、一堆专业术语交织出来的。AI目前还很难“理解”这种深层次的业务图谱。而且B端业务人员对于“信任”的需求更高,AI生成的用例要让他们完全信服,需要更高的准确性和更低的误报率。小公司想提高AI用例的“靠谱度”,我觉得可以在AI生成用例后,多引入同行评审机制,让有经验的QA去看AI的用例,补充缺失的、纠正不合理的,再把这些反馈作为强化学习的样本喂给AI,形成正向循环,这样AI才能越学越精。

楼上说的很对!B端的业务尤其像资金、供应链,它的核心特点是“严谨性”和“专业度”。C端可能更注重用户体验的多样性和迭代速度,而B端则要求“不出错”是第一位。AI生成用例,目前更多是基于自然语言的理解和已知模式的生成,它可能很难“创造性”地发现那些隐藏在业务深层逻辑中的bug,或者那些需要特定领域知识才能想到的极端边界场景。而且,B端的业务人员可能对AI的信任度还在建立中,人工复审的成本也高。小公司如果资源有限,可以考虑先让AI生成标准化的、重复性的用例(比如CRUD操作的用例),然后人工重点关注高风险、高价值的业务流程用例,进行交叉验证。还可以定期review AI生成用例的有效性,并反馈给模型进行优化。

说白了就是让我们从“码农”变“智囊”嘛!以前我们是质量的“守门员”,把住每一条测试用例;以后可能就是质量的“规划师”和“布道者”。最大的机遇就是把我们从重复的劳动中解放出来,可以去做更有挑战性、更有成就感的事情。挑战嘛,就是如果自己不学习进步,可能真的成为“时代的眼泪”。我觉得未来QA需要培养的技能,最重要的是高级批判性思维,能跳出常规思维去发现系统深层次的风险;其次是数据驱动的决策能力,不再是凭经验,而是能通过数据分析来优化测试策略、评估质量;还有探索性测试的艺术,因为AI再强,也无法替代人类的直觉和经验进行无边界探索。另外,掌握基本的AI工具使用和调优能力,让自己成为“驾驭AI”而非“被AI取代”的人,也非常重要!

关于“小公司如何搞AI测试”的问题,我觉得不是完全没戏!大公司有财大气粗的优势,能自研大模型做微调。但小公司可以走“借力打力”的路子。现在市面上有很多成熟的AI服务,比如各种大模型API(ChatGPT、文心一言、通义千问等),可以直接调用。小公司可以从最简单的痛点入手,比如利用AI来辅助需求文档的理解和提炼关键信息,生成初步的测试点清单;或者用AI来生成基础的、重复性的测试脚本片段,而不是要求它直接生成整个测试用例。另外,Prompt工程是通用的,即使是小公司,也可以投入精力去设计高质量的Prompt,这几乎是0成本的投入,但能极大提升AI输出的质量。先用这些“轻量级”的方式,慢慢积累经验和数据,等条件成熟再逐步深入。

谁说小公司就没戏了?大公司有大公司的玩法,小公司有小公司的智慧!天猫那种是“从0到1”的自研深度,我们小公司可以“从1到N”地应用现有技术。可以考虑以下“平替”策略:
1. 利用现有AI工具集成: 很多测试管理平台或CI/CD工具已经开始集成AI功能,或者有插件可以利用,比如一些自动化测试框架结合大模型API,可以试试。
2. Focus on Specific Pain Points: 别想着一步到位搞全流程。是不是用例编写最耗时?那就只用AI来辅助生成用例。是不是报告分析最麻烦?那就用AI辅助总结。
3. 开源社区和垂直模型: 关注开源的测试框架和AI模型,有些小而美的解决方案可能恰好适合特定业务。
4. 内部知识库构建: 即使没有强大的RAG系统,也可以人工维护一个结构化的知识库。把常见缺陷、核心业务流程等梳理清楚,作为AI的“喂料”,这也能提升AI的准确性。关键是从小处着手,持续优化