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在商品详情页看到“好友拼单”按钮；点击后生成邀请链接；通过微信分享给好友B；B点击链接进入商品页并成功支付；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测试用例平台这条路，投入不小，挑战很多，但回头看，我们认为非常值得。它不仅仅是一个工具，更是一种对高质量、高效率研发模式的投资和探索。对于正在被海量测试用例编写和维护工作困扰的团队，如果条件允许，不妨也尝试迈出第一步，哪怕是从一个小的、垂直的业务场景开始实验。
