1. 从“人肉”到“智造”我们为什么要自研AI测试用例平台测试用例的编写大概是所有测试工程师和开发工程师都绕不开的“体力活”之一。需求文档来了你得逐条分析绞尽脑汁去想各种正常、异常、边界场景然后一条条写成可执行的测试步骤和预期结果。这个过程枯燥、重复还特别容易遗漏。尤其是在敏捷开发、快速迭代的背景下需求变更频繁测试用例的维护成本高得吓人。我们团队也长期被这个问题困扰直到去年我们决定不再忍受这种低效的“人肉”模式开始着手自研一个AI辅助生成测试用例的平台。这个平台的核心目标非常明确将测试工程师从重复、机械的用例编写工作中解放出来让他们能更专注于更具创造性和挑战性的工作比如探索性测试、复杂业务逻辑的深度验证以及测试策略的制定。听起来很美好对吧但市面上不是已经有了一些AI测试工具吗为什么还要自研这正是我们项目启动前思考最多的问题。市面上的工具要么是通用型的代码生成助手对特定业务领域的测试场景理解不够深入要么是封闭的SaaS服务无法与我们内部复杂的CI/CD流水线、项目管理工具如Jira、TAPD以及测试管理平台深度集成。我们需要的是一个能“听懂”我们业务黑话、能“记住”我们历史测试经验、并且能无缝嵌入现有研发流程的“智能副驾驶”。我们的平台我们内部称之为“CaseCraft”不是一个简单的文本生成器。它更像是一个结合了领域知识图谱、大语言模型LLM和自动化测试框架的智能工作台。它接收的需求输入可以是自然语言描述的产品需求文档PRD、用户故事User Story甚至是产品经理随手画的草图经过OCR识别然后自动输出结构清晰、覆盖度广、可直接导入测试管理工具或转化为自动化脚本的测试用例集。接下来我就从我们是如何设计这个平台的核心架构、它具体是怎么工作的、我们在实践中踩过哪些坑以及它到底带来了多大价值这几个方面和大家详细聊聊。2. 平台核心架构如何让AI“懂业务”并“会测试”一个能用的AI测试工具和一个好用的AI测试平台差距就在于架构设计是否以“业务适配”和“流程融合”为核心。我们摒弃了那种直接调用公开大模型API然后做简单Prompt工程的轻量级思路因为那无法解决业务特异性和结果稳定性的问题。CaseCraft的架构分为四层数据与知识层、智能引擎层、应用服务层和集成对接层。2.1 数据与知识层平台的“记忆”与“常识”这是平台的基石。如果AI没有“记忆”那每次生成都是“从头开始”无法积累经验更无法保证符合团队规范。这一层我们构建了两个核心库历史用例知识库我们将过去几年积累的所有测试用例包括手工用例和自动化脚本进行了清洗、去重和结构化处理。这不是简单的文本存储而是进行了深度解析。我们提取了每个用例的“测试对象”如某个API接口、某个前端页面组件、“测试类型”功能、性能、安全、兼容性、“前置条件”、“测试步骤”、“预期结果”、“关联的需求ID”以及“历史执行结果”通过/失败以及失败时的Bug链接。这些数据经过脱敏和标注后形成了一个高质量的测试用例样本集用于后续的模型微调Fine-tuning和检索增强生成RAG。业务领域知识图谱这是让AI“懂业务”的关键。我们与业务分析师、产品经理合作将核心业务概念、实体、属性及其关系梳理出来。例如在一个电商系统中核心实体包括“用户”、“商品”、“订单”、“支付单”、“物流单”等。它们之间的关系是“用户”可以创建“订单”“订单”包含多个“商品”“订单”关联一个“支付单”和一个“物流单”。同时我们定义了每个实体的关键属性和业务规则比如“商品”有“库存”属性业务规则是“下单时库存必须大于0”。这套知识图谱以图数据库我们选用的是Neo4j的形式存储它能让AI在生成用例时准确地理解业务对象间的依赖关系从而生成逻辑连贯的测试场景而不是一堆孤立的操作步骤。2.2 智能引擎层平台的“大脑”这一层负责核心的生成、分析和决策。它由几个协同工作的模块组成需求理解与拆解模块它的任务是把一段模糊的自然语言需求转化为结构化的测试任务。例如产品需求说“用户可以在购物车页面修改商品数量并实时看到总价变化。”这个模块会识别出核心动作“修改数量”、核心对象“购物车页面”、“商品”、“总价”、预期效果“实时变化”以及隐含的校验点“总价计算正确性”。它依赖于自然语言处理NLP模型和前面提到的业务知识图谱。测试用例生成模块这是最核心的部分我们采用了“大模型微调 RAG 规则引擎”的混合模式。大模型基座我们选择了在代码和逻辑推理能力上表现突出的开源模型作为基座例如DeepSeek-Coder或Qwen-Coder。直接使用通用模型生成测试用例结果往往格式混乱、覆盖不全。微调Fine-tuning我们使用“历史用例知识库”中高质量、符合我们团队规范的用例数据对基座模型进行有监督微调。这让模型学会了我们喜欢的用例表述风格、步骤粒度我们要求步骤必须可操作如“点击‘修改数量’输入框”而非“修改数量”以及断言方式。检索增强生成RAG当收到一个新需求时系统会先从知识库中检索历史上类似需求或相同功能模块的测试用例。这些检索到的用例作为上下文Context和参考范例与大模型接收的新需求Prompt一起输入。这极大地提高了生成结果的相关性和准确性避免了模型“胡编乱造”。规则引擎这是保证用例“底线”的守卫。生成后的用例会经过一系列规则校验例如每个用例必须包含“前置条件”“测试步骤”必须是一个动词开头的可执行序列“预期结果”必须是一个可验证的断言对于涉及数值计算的场景必须包含边界值如0 最大值 超最大值用例。规则引擎会自动补全或修正不符合规范的条目。测试数据生成模块巧妇难为无米之炊好的测试用例需要配套的测试数据。这个模块能根据测试场景自动生成符合要求的测试数据。例如针对“用户注册”场景它能批量生成符合姓名、邮箱、手机号格式规则的测试数据并且能保证某些需要唯一性的字段如用户名不重复。它集成了像Faker这样的数据生成库并根据我们的业务实体规则进行了定制。2.3 应用服务层与集成对接层平台的“手脚”这一层提供了用户操作的界面和与外部系统交互的通道。Web操作界面我们提供了一个简洁的Web界面。测试工程师或开发工程师可以在这里粘贴需求文本、上传需求文档或者直接选择Jira上的某个Story ID。平台解析后会在界面右侧展示生成的测试用例列表用户可以逐条审阅、编辑、采纳或驳回。界面还提供了“一键补充异常流用例”、“根据代码变更diff生成增量用例”等便捷按钮。API服务所有核心能力都通过RESTful API暴露出来。这是实现自动化流程的关键。集成对接层这是平台价值的“放大器”。我们开发了与常用工具的插件或连接器与Jira/TAPD集成在Jira的需求页面可以有一个“生成测试用例”的按钮点击后CaseCraft会读取该需求的描述和评论生成用例后直接在该Jira issue下创建一个子任务列表或将用例链接附加上去。与GitLab/GitHub集成通过Webhook当新的Merge Request创建或代码Push时平台可以分析代码变更Diff智能推测受影响的功能点并生成针对性的回归测试用例建议。与TestRail/Xray等测试管理工具集成生成的用例可以直接推送至TestRail对应的测试套件中并自动关联需求形成可追溯的测试覆盖。与CI/CD流水线集成平台生成的用例其中一部分可以直接转化为自动化测试脚本的骨架如基于Pytest的Python脚本并注入到CI流水线中自动执行。3. 实战演练从需求到用例的完整工作流光讲架构可能有点抽象我通过一个我们电商平台的实际例子带大家走一遍完整的流程看看一个测试工程师的一天是如何被改变的。场景产品经理在Jira上提交了一个新需求“作为用户我希望在商品详情页看到一个‘好友拼单’的入口点击后可以邀请微信好友一起购买并享受拼单价。拼单成功后订单状态需更新为‘拼单成功’。”传统模式测试工程师小A收到需求后需要反复阅读需求自己脑补各种场景入口在哪里怎么邀请邀请链接形式拼单人数限制拼单价如何计算拼单失败怎么办超时怎么办然后花费1-2小时编写出十几条测试用例。CaseCraft模式触发小A在Jira的需求页面上点击了我们开发的插件按钮“AI生成用例”。需求解析CaseCraft通过Jira API抓取该需求的标题、描述、评论。智能引擎的需求理解模块开始工作识别出核心实体——“商品详情页”、“好友拼单入口”、“微信好友”、“拼单价”、“订单状态”。识别出核心动作——“点击入口”、“邀请”、“购买”、“更新状态”。识别出业务规则——“享受拼单价”、“拼单成功”。知识检索系统在历史知识库中检索与“分享”、“邀请”、“社交电商”、“价格计算”相关的历史用例。同时在业务知识图谱中查询“订单状态”的流转路径例如待支付 - 已支付 - 发货中 - 已完成 现在要新增“拼单成功”状态及其前置条件。用例生成结合检索到的知识和微调后的大模型生成初步的测试用例集。这个过程可能包括正常流用例用户A在商品详情页看到“好友拼单”按钮点击后生成邀请链接通过微信分享给好友BB点击链接进入商品页并成功支付A和B的订单均变为“拼单成功”状态并享受拼单价。异常流用例生成邀请链接后商品下架了B点击链接应提示“商品已失效”拼单人数已满新用户点击链接应提示“拼单已满员”发起拼单后24小时内未成团系统自动关闭拼单订单状态如何处理A或B中途取消订单对另一方的影响是什么边界与安全性用例拼单价是否低于成本价需要规则引擎结合商品成本数据判断邀请链接是否具有时效性、是否可被篡改是否涉及用户隐私信息微信头像、昵称的展示授权。UI与兼容性用例建议“好友拼单”按钮在不同屏幕尺寸下的展示在微信内浏览器与普通浏览器中的行为是否一致。规则校验与补全规则引擎检查生成的用例。发现“拼单价计算”相关的用例缺少边界值如原价100拼单价80测试2人、5人、上限人数的情况于是自动补充。发现“订单状态更新”的用例缺少后端API的验证点建议增加“验证数据库订单状态字段更新”的步骤。人工审阅与确认生成的用例列表呈现在小A面前。她可以快速浏览利用平台的“一键合并相似用例”、“标记优先级”、“编辑单条用例”等功能进行调整。她发现系统生成了一个“拼单成功后检查双方订单的物流信息是否独立生成”的用例她觉得很好这是她一开始没想到的。整个过程从点击按钮到获得一份覆盖全面、格式规范的初版用例集只用了不到5分钟。导入与执行小A点击“确认并导入TestRail”用例自动同步到测试管理平台并关联了Jira需求ID。她可以将其中一些流程固定的用例如“正常拼单流程”进一步转化为自动化脚本由平台提供脚本骨架她补充一些定位元素和断言细节即可。这个工作流不仅极大地提升了用例编写的效率更重要的是通过AI的“联想”能力和知识库的“记忆”能力显著提升了测试场景的覆盖度减少了对测试人员个人经验与临场思维的过度依赖降低了漏测风险。4. 踩坑实录自研路上我们遇到的“坑”与“坎”理想很丰满但自研之路绝非坦途。下面分享几个我们踩过的大坑希望对也想尝试的团队有所警示。4.1 坑一训练数据质量之殇——“垃圾进垃圾出”在项目初期我们急于求成直接把历史测试管理平台里所有的用例不管好的坏的、过时的还是有效的全部扔进去做模型微调。结果生成的用例惨不忍睹步骤描述口语化严重比如“搞一下那个按钮”预期结果模糊比如“应该没问题”甚至还出现了已经废弃的老业务流程的用例。我们的教训与解决方案数据清洗是重中之重必须投入人力。我们成立了一个临时小组制定了详细的《测试用例质量规范》然后对历史用例进行人工抽样审核和打标优质、合格、需改进、废弃。初期只选用“优质”和“合格”的用例作为训练集。建立持续的数据质量反馈闭环。在平台中我们增加了“用例质量评分”功能。当用户测试工程师在审阅AI生成的用例时他们的每一次编辑、采纳或驳回操作都被隐式地视为对生成结果的一次反馈。这些反馈数据会被收集起来用于后续模型的迭代优化。例如如果某个类型的用例被频繁编辑说明模型在这个场景下生成效果不好需要针对性补充训练数据。4.2 坑二对“智能”的过度期待与“幻觉”问题我们曾一度希望AI能完全独立产出100%可用的用例但很快被现实打脸。大模型固有的“幻觉”问题在测试场景下同样存在它会“创造”一些不存在的字段或者“臆想”一些不符合实际业务逻辑的操作流程。比如在生成一个银行转账用例时它可能会凭空增加一个“转账手续费优惠券”的输入项而我们的系统根本没有这个功能。我们的教训与解决方案明确人机协作的边界我们必须清醒认识到当前阶段AI是“辅助”而非“替代”。它的定位是“初级测试用例工程师”或“灵感生成器”负责完成80%的草稿工作而剩下的20%的审阅、修正、决策工作必须由人来完成。我们在产品设计上始终强调“人工审阅”是必不可少的一环。用RAG和规则引擎强力约束“幻觉”这就是为什么我们要下大力气构建“历史用例知识库”和“业务规则引擎”。RAG确保生成的内容有据可依尽可能从历史成功经验中寻找答案规则引擎则从逻辑和规范层面进行硬性校验把明显不合理、不符合规范的内容扼杀在摇篮里。对于关键业务场景我们甚至配置了“强规则”要求生成的用例必须引用某个特定的业务规则文档片段。4.3 坑三与现有流程的“排异反应”平台开发好了用例生成得又快又好但团队就是不爱用。原因在于它成了一个“孤岛”。工程师需要复制需求文本到平台生成后再复制结果回Jira和TestRail流程反而更割裂了。我们的教训与解决方案集成优先于功能在平台核心功能基本可用后我们立刻将大部分研发资源投入到“集成对接层”的开发中。正如前文所述我们开发了与Jira、GitLab、TestRail的深度集成插件。让工具去适应人而不是让人去适应工具。只有当AI能力能够无缝嵌入到工程师现有的、习惯的工作流中时它才能真正被用起来。关注用户体验细节生成的用例如何展示更利于审阅我们增加了对比视图左侧是AI生成的原稿右侧是用户编辑后的版本。编辑时是否方便我们支持了类似Word的富文本编辑和快捷键操作。是否支持批量操作我们提供了“全选采纳”、“按类型过滤”等功能。这些细节决定了工具的使用黏性。4.4 坑四效果衡量与ROI的模糊地带如何证明这个平台有价值仅仅说“提升了效率”是苍白的。老板会问提升了多少有没有数据有没有导致Bug逃逸率下降我们的教训与解决方案 我们建立了一套简单的度量体系效率指标统计使用平台生成用例的需求从需求就绪到用例编写完成的历史平均耗时与未使用平台的需求进行对比。我们内部统计的数据显示平均用例编写时间减少了约60%。质量指标对比使用平台和未使用平台的需求在测试阶段发现的Bug数量特别是那些因用例遗漏导致的Bug以及上线后线上缺陷的密度。我们发现对于业务逻辑复杂的需求使用平台后测试阶段发现的边界和异常场景Bug数量有显著增加这意味着测试覆盖更充分了。覆盖率辅助分析平台会尝试分析生成的用例对需求条目的覆盖情况并给出一个可视化的覆盖度报告虽然不能100%准确但可以作为测试人员查漏补缺的参考。 这些数据成为了我们持续投入和优化平台的最有力支撑。5. 平台带来的价值与未来演进思考经过近一年的迭代和团队磨合CaseCraft已经成为了我们测试和开发流程中不可或缺的一环。它的价值已经超出了最初的“提升效率”的预期。首先它成为了团队知识的“沉淀器”和“放大器”。所有通过平台生成和优化的用例经过人工确认后都会回流到历史知识库中。这意味着新员工可以通过平台快速学习到团队的测试思维和业务知识老员工优秀的测试设计经验得以固化并传承。知识不再只存在于个人的脑子里或零散的文档里。其次它改变了测试角色的重心。测试工程师们不再抱怨“总是在写重复的用例”他们更愿意花时间去设计复杂的异常场景、进行探索性测试、分析测试结果和驱动产品质量前移如在需求评审阶段就利用平台快速生成用例草案反向澄清需求歧义。测试工作的技术含量和成就感得到了提升。最后它促进了研发流程的标准化。因为AI需要结构化的输入才能产出好的结果这倒逼产品经理在编写需求时更加规范、清晰减少了模糊和二义性的表述。开发、测试、产品在对需求的理解上因为有了同一份AI生成的用例草案作为讨论基础沟通效率也提高了。关于未来我们还在持续探索从用例生成到脚本生成目前我们主要生成手工测试用例。下一步是提高将用例直接转化为可执行自动化测试脚本的准确率特别是针对前端UI和后端API的测试脚本骨架。基于缺陷反馈的自我进化我们正在尝试将线上缺陷Bug数据也接入系统。当一个Bug被认定为“测试用例遗漏”导致时系统可以分析这个Bug对应的功能和场景自动学习并补充相应的测试用例规则到知识库中实现“吃一堑长一智”的闭环学习。智能测试执行分析结合测试执行结果通过/失败平台能否分析出哪些模块、哪些类型的用例容易失败从而为测试资源分配和风险预警提供数据建议自研AI测试用例平台这条路投入不小挑战很多但回头看我们认为非常值得。它不仅仅是一个工具更是一种对高质量、高效率研发模式的投资和探索。对于正在被海量测试用例编写和维护工作困扰的团队如果条件允许不妨也尝试迈出第一步哪怕是从一个小的、垂直的业务场景开始实验。