导语：
计划写一个大模型赋能智能化测试的合集，分享一下各家先行者的案例，共同学习。目前网上大多数都是泛泛而谈，只是说可以借助大模型自动生成用例、脚本、数据、缺陷诊断等。但是具体怎么用，有哪些坑少有人能说出来，所以借助这个合集来分享些真正有价值的干货。本次拆解案例来自于2024年QECon大会北京站-趣丸科技。
为什么先做功能测试用例生成
这里面具体解释了功能测试用例的特性，以及大模型本身的优势，两者契合度相对于其他测试场景来说更高。
这是借助大模型生成测试用例的大致流程，以及过程中会遇到的难点。在流程上核心环境大致相同：
- 需求设计文档越清晰生成质量越好
- 结合测试人员提供的意见、生成规则、额外需求点等内容
- 整理组合成最终的提示词，交由大模型生成测试用例
技术难点：
- Token限制
- 有效性
（注：这是在去年通用大模型存在的一些欠缺，而随着模型技术发展，进一步支持长文本、推理思考等特性，这些问题都会被更好的解决，例如最近热门的DeepSeek R1）
使用方式：
- 稍有技术能力的公司会追求产品化，而非让测试人员直接与通用大模型对话
- 产品化方式分为两种模式：
- 聊天模式
- 生成模式
（综合对比后，聊天模式更符合现有交互方式。深入设计时，聊天模式可涵盖生成模式，例如首次输出采用固化的生成模式，用户对话后再基于内容调整输出）
聊天模式方案探索
整个方案涉及以下4个核心能力（模型能力提升后仍需产品优化）：
- 上下文管理
- 测试领域知识注入
- 意图识别与引导
- 结果校验与修正
实际使用结果不及预期，分析与改进方向：
- 用户习惯倾向于"自动生成"，而非主动对话（“能自动生成的就别让我再对话了，大家都懒嘛”）
生成模式方案落地
核心优势：
- 更符合用户"一键生成"的预期
- 减少交互成本
核心能力：
- 文档处理（需求解析与结构化）
- 数据召回（历史用例库匹配）
- 用例创建（提示词工程）
- 用例修改（迭代优化）
- 工程化结合（流程集成）
重点提示词示例：
- 用例创建模板（覆盖正向/异常场景、边界值等）
- 用例修改规则（优先级调整、步骤细化等）
落地效果
- 时效提升：用例生成效率提高60%+
- 采纳率提升：生成用例可直接使用率超75%
- 随着底座大模型能力增强（如长文本支持、多轮推理），效果将持续优化
关注公众号【关于那些的个人观点】，发送消息“智能化测试”，获取完整内容PDF
扫一扫
154
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
