上个月做迭代计划的时候我把团队里两位测试开发的排期从“本周完成50条用例编写”改成了“搭一个能自动产出用例的生成器”。当时有人觉得我在画饼——用例这种靠经验堆出来的东西怎么可能用模型批量替代一个月后我们的接口用例量从460条涨到2100多条漏掉的边界场景反而比之前更少。这篇文章不聊概念只讲我怎么把DeepSeek接进测试开发流程以及从“写用例”切换到“设计生成系统”时真正卡脖子的是哪些事。先说结论测试开发的核心工作正在从“人肉生成用例”变成“搭建一个能持续生成高质量用例的机制”。这不是把用例这件事取消了而是把它变成了一种系统能力。文章后面我会把架构设计、提示词工程、结果校验、踩坑记录全部拆开讲适合正在做测试平台建设、自动化测试框架维护或者想引入大模型但不知道从哪下手的团队参考。1. 先想明白为什么“写用例”正在变成“设计生成系统”1.1 用例生产的成本结构变了传统测试用例的生产路径基本是“需求分析 - 测试设计 - 手工编写 - 评审 - 维护”这条链路。一个人一天能产出多少条有效用例我的实测经验是状态机复杂一点的模块一天20到30条已经算高质量简单接口的增删改查一天能写80条但大部分是重复劳动。用例生产的成本几乎全在“人”身上所以质量不稳定、进度不可预测、边界场景经常漏。DeepSeek这类模型介入之后情况完全不同。生成一条用例的边际成本趋近于零真正稀缺的不再是“写”的动作而是三件事怎么描述被测系统让模型理解业务语义。怎么定义“好用例”的标准让模型按标准生产。怎么校验生成结果把不合格的挡在门外。这三件事本质上就是系统设计问题。所以我说“不再写用例而是设计生成系统”不是说人不用懂业务了而是人的精力从逐条书写转向了规则定义、模板设计、质量评估和闭环优化。1.2 工作内容的迁移从“点工”到“造管道的人”传统模式下测试开发的价值取决于个人经验谁在这个业务待得久谁能想到更刁钻的边界场景谁的用例质量就高。这带来一个很现实的问题经验沉淀在个人脑子里人一走用例质量就断崖式下跌。生成系统改变的是这个沉淀方式。我们要把“老测试的经验”翻译成系统可理解的东西历史缺陷记录、字段边界规则、业务状态流转约束、异常路径清单。这些东西写进提示词模板、进校验规则、反馈到生成器里模型就能稳定产出过去只有资深测试才写得出来的用例。我团队里一个刚转正半年的同事在理解了这个思路之后独立搭了一个针对订单状态流转的用例生成模块。她做的事是梳理订单从创建到关闭的全部状态节点和触发条件再把这些约束写成生成规则。模型在她的规则框架下批量产出组合用例她负责审核和回填错误样本。她的产出效率已经超过了我团队里工作五年的老测试。1.3 一个观念转变生成系统不是“自动写用例”是“自动生产用例的机制”很多人一听“AI生成用例”第一反应是“让模型给我整几个测试点”。如果只是这种用法那它跟搜索引擎没有本质区别生成结果零散、不可维护、质量不可控。我理解的生成系统是一套完整机制输入侧能自动获取需求文档、接口定义、历史缺陷、页面元素信息。生成侧把输入组织成模型能理解的上下文按模板批量产出用例。校验侧通过规则和模型双重校验过滤无效输出。反馈侧把人的修正意见回填到模板和示例中让系统越用越准。打个比方以前我们是流水线上的装配工一个一个地拧螺丝现在我们是设计流水线的人要关心传送带速度、零件规格、质检标准和返修通道。螺丝还是那些螺丝但工作性质完全不同了。2. 生成系统的整体架构我从零搭的五层结构2.1 五层结构拆解我落地的生成系统从下到上分五层每一层职责单一替换成本低层级职责核心组件业务语义层管理和组织被测系统的领域知识OpenAPI文档、字段字典、状态机描述、需求模板上下文组装层把业务语义转成模型可用的上下文文档解析器、切片器、检索模块、上下文模板模型调用层负责与DeepSeek通信OpenAI SDK封装、重试机制、超时控制、令牌统计结果解析与校验层把模型输出转成结构化用例并校验JSON解析器、Schema校验、字段存在性检查、规则引擎用例落库与执行层把通过校验的用例写入现有体系并触发执行测试平台API、用例库、执行结果回传这套分层不是我一开始就设计出来的是踩了几天坑之后重构的结果。最开始我写了一个“一把梭”脚本从读文档到生成用例全在一个函数里结果改一处崩一片。分层之后最大的收益是换模型、换知识来源、换校验规则都只动对应层其他层不用管。2.2 为什么我选API接入而不是本地部署DeepSeek有两种接入方式一是调用官方API二是在自己的机器上部署开源权重模型。我最终选了API接入理由是成本更低。本地部署如果要用一个效果够好的模型至少需要两张工业级显卡还不算运维成本API按量付费对于测试用例生成这种“每天跑几次”的场景开销完全可以忽略。长上下文能力。用例生成经常需要把整份接口文档塞进去API服务的上下文窗口更大处理起来更从容。维护成本趋近于零。本地部署要处理模型版本升级、显存优化、并发排队这些都是纯IT运维工作对测试团队来说是额外负担。数据敏感的团队可以走本地部署路线用Ollama或者vLLM这类框架把模型跑起来架构上只需要替换模型调用层。但我要提醒一句本地部署的效果阈值比API高很多小参数模型在复杂业务理解上会明显吃力你需要花大量时间做提示词调优。如果业务场景不复杂先从API试起是更务实的路线。2.3 关键设计决策独立服务别往测试平台里塞最开始有人建议我直接把生成能力写成测试平台的一个插件我拒绝了。原因是测试平台的核心是“用例管理和执行”它的数据模型、权限体系、审核流程都是围绕这个目的设计的。生成系统是“内容生产机制”它需要频繁迭代提示词、实验不同模型参数、观察生成质量这些诉求跟测试平台的稳定性要求是冲突的。我的做法是把生成系统做成一个独立服务对外只暴露两个接口提交生成任务、查询生成结果。服务内部自己管知识库、模型调用和校验逻辑生成结果通过接口批量导入测试平台。这样两边互不干扰测试平台该稳定稳定生成系统该折腾折腾。3. 核心难点一让模型真正“懂”被测系统3.1 上下文不是越多越好而是“整得越干净越好”我见过不少团队做类似事情第一版就把所有资料一股脑塞给模型接口文档、需求说明、数据库表结构、线上故障复盘全堆在Prompt里。结果模型输出一堆似是而非的用例看起来专业实际没有针对被测系统本身下功夫。原因很简单模型推理是注意力机制上下文里的无关信息越多相关信息的权重就越低。正确做法是把“系统知识”先加工成高密度的结构化上下文我把它分成四类接口信息路径、方法、参数类型、必填项、枚举值、取值范围。业务规则状态流转条件、权限约束、单据编号规则、唯一性约束。历史缺陷这个模块以前在哪些场景出过问题。需求意图这个功能解决了什么问题给谁用。其中历史缺陷这一项效果出奇地好。我把线上过去一年关于订单模块的典型缺陷整理成二十多条结构化描述塞进提示词之后模型生成的用例里“防回归”的比例明显上升很多用例直接对标历史线上事故场景。3.2 提示词模板的演进过程我第一版提示词只有三行“你是资深测试工程师请为以下接口生成测试用例。”生成结果能用但水准极不稳定——有些用例质量很高有些完全是废话。后来我把提示词改成了结构化模板包含五个部分角色定义不是简单“资深测试”而是“有五年经验的后端测试专家熟悉接口测试和状态机分析”。任务说明要生成什么级别接口级/业务级/场景级的用例。系统上下文上面说的四类结构化知识。输出格式严格输出JSON数组每个元素包含用例编号、前置条件、测试步骤、预期结果、优先级。质量约束比如“必须包含正常路径、异常路径、边界值”和“预期结果必须可验证禁止出现‘系统正常运行’这类模糊描述”。这是最终版的模板骨架你是某电商平台的后端测试专家有五年接口自动化测试经验。 请基于以下接口定义和业务规则生成覆盖正常、异常、边界三类场景的测试用例。 [接口文档] POST /api/order/create 参数userId (long, 必填), skuId (long, 必填), quantity (int, 必填, 1-999), couponId (long, 可选) [业务规则] 1. 用户未登录时返回401。 2. quantity超过999时返回错误码40001。 3. 同一用户对同一sku的未支付订单最多存在3笔超过则返回错误码40002。 4. couponId仅当订单金额超过100元时可用。 [输出格式] JSON数组每个用例包含 - id: 用例编号 - name: 用例名称一句话描述场景 - preconditions: 前置条件 - steps: 测试步骤字符串数组 - expected: 预期结果必须具体可验证 - level: P0/P1/P2 [质量约束] 1. 必须覆盖正常、异常、边界三类场景。 2. 必须覆盖所有业务规则。 3. expected必须具体禁止出现“系统正常”类模糊描述。这套模板跑下来的效果比初版提升了不止一个档次。关键不在于措辞多华丽而在于你给了模型多少“判断依据”。3.3 少样本示例2条好例子胜过10条规则模板跑出来的用例已经能用了但离“资深测试手写水平”还有距离主要集中在预期结果写得不够精确。比如规则2说“quantity超过999时返回错误码40001”模型生成的预期结果是“系统提示数量错误”能这么写的原因是模型在用自己的常识补全业务细节而它并不清楚这个模块的真实表现。解法就是少样本示例。我在模板里固定放2到3条由资深测试手写的高质量用例模型会模仿示例的粒度、措辞和结构。放三条示例之后“预期结果模糊”的问题基本消失。这个改动的成本几乎为零收益却非常明显。少样本示例需要持续迭代。每当我发现模型在某一类场景上稳定偏差就去找一条最典型的人工修正用例替换或补充进示例区。过去一个月我的示例区从2条涨到了8条生成质量的提升是肉眼可见的。4. 核心难点二生成结果的校验回路4.1 为什么必须建一套“守卫机制”刚开始搭系统的时候我犯了一个认知错误——觉得模型生成的东西只要“看起来对”就能用。结果第一批导入用例库的500条用例里有17%存在逻辑硬伤比如调用接口时传了必填参数之外的乱值、前置条件和业务规则冲突、预期结果写的根本不是接口真实行为。这让我意识到生成系统的关键不在生成在“闸门”。模型一定会犯错区别只是犯错密度高低。合格的系统必须把错误挡在入库之前而不是靠人去逐条二审。所以校验层不是可选项是必选项。4.2 三层校验我最终实施了三层校验每一层解决一类问题第一层语法和结构校验。模型返回的内容先做JSON解析再按输出格式模板做字段级校验。缺失字段、类型错误、JSON截断在这一层直接打回。这一层拦掉了大约6%的输出。第二层上下文一致性校验。校验用例里的每个参数名、枚举值、业务规则编号是否和被测系统定义匹配。比如接口文档里只有quantity这个参数模型生成了amount在这一层就会被拦截。这一层拦掉约5%的输出。第三层规则交叉校验。我有意把历史缺陷场景和业务规则固化成了可检查的规则库。用例一旦覆盖到规则库里的场景就检查生成结果是否和规则表述一致。比如规则写明“未登录返回401”模型生成“未登录返回200登录状态异常”这一层直接拦截。三层校验必须在生成系统的校验层里自动化执行不能依赖人工。我在实践中发现人工审核在连续审核20条用例后就开始走神这是人类注意力的问题不是责任心的问题。4.3 实测中常见的四类错误与修复策略我把校验层拦下来的错误数据做了分类统计发现集中在四类错误类型出现频率根因修复策略字段名称幻觉高模型用常识补全了不存在的字段将接口参数定义注入上下文启用字段存在性校验业务规则反转中对“超过X则拒绝”理解成“超过X才放行”在提示词中强化规则编号增加否定式规则校验预期结果模糊高没有目标值参考模型自行发挥增加少样本示例锁定预期结果措辞粒度场景重复冗余中对同一个边界条件从不同角度反复生成生成后按场景特征去重只保留优先级最高的用例这四类问题靠提示词优化能解决一部分但真正可靠的防线是自动化校验。我现在的策略是提示词负责“提高好的比例”校验层负责“挡住坏的进门”两边缺一不可。5. 一个真实案例的完整拆解接口用例自动生成5.1 输入与前置处理我挑一个我们实际跑通的模块来说明订单创建接口。输入是OpenAPI文档加一份两页的业务规则说明。OpenAPI文档是标准JSON格式字段齐全天然适合自动解析。业务规则说明是产品经理写的Word转PDF结构混乱需要先人工整理一遍。所以前置处理有两步从OpenAPI文档里抽取接口的基础定义路径、方法、请求参数、参数类型、必填性、枚举值。把业务规则说明改写成结构化条目每条对应一个具体约束。这一步目前还必须人工做也是我后面想重点优化的环节。模型从来不会主动读原始文档它只能“读”你组织好的上下文。所以上下文组装层的价值就在这里把人类写的各种格式的文档统一翻译成模型喜闻乐见的结构化文本。5.2 生成器核心实现生成器核心就是一个Python服务流程是读接口定义 - 组装提示词 - 调用DeepSeek - 解析结果 - 三层校验 - 写库。核心调用代码大致是from openai import OpenAI client OpenAI( api_keyyour_api_key, base_urlhttps://api.deepseek.com ) def generate_cases(interface_context): prompt build_prompt(interface_context) # 组装上下文 模板 少样本示例 resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: SYSTEM_TEMPLATE}, {role: user, content: prompt} ], temperature0.3, max_tokens4096, response_format{type: json_object} ) content resp.choices[0].message.content return validate_and_parse(content) # 三层校验几个参数我固定做了设置temperature设0.3保证输出稳定max_tokens设到4096防止长文档场景下输出被截断response_format强制JSON输出减少解析阶段的脏数据。这些都是被踩坑之后才定下来的后面会细讲。5.3 效果数据针对订单创建接口旧方式下团队用两天写了60条用例覆盖核心流程、异常参数和常规边界。换成生成系统后我们用了两小时完成上下文准备十分钟跑完生成产出212条候选用例经过三层校验后保留183条人工复核后最终入库165条。覆盖范围扩大到包括所有枚举值组合、规则交叉场景和历史缺陷回归场景。这里要说清楚一个关键点最终录用的165条里大约20条是以前团队无论如何都不会主动设计的场景因为那些组合在想象中太“巧”了。比如“同一用户对同一sku有2笔未支付订单时再提交第3笔然后取消其中1笔继续提交第4笔是否放行”这种状态机场景。模型按规则穷举的时候没有被经验束缚反而更容易踩到这些刁钻角落。5.4 这套方案的边界这套方案也不是万能的。我在实际操作中遇到三类明显做不好的场景强业务状态机。涉及复杂状态流转的业务订单、审批流、账务模型对状态前置条件的理解经常出偏差需要人工在上下文里提供精确的状态流描述。多接口串联场景。模型擅长单接口分析但在多接口协作场景下单-支付-回调-查询容易丢失链路上下文。需求语义模糊的功能。业务本身描述不清模型只能在模糊中产出模糊用例这锅不能甩给模型得先找产品经理把需求讲清楚。面对这些边界场景我的策略是不强行自动化先把单接口场景跑稳再逐步向场景链路和复杂业务延伸。6. 接入DeepSeek时踩过的几个坑6.1 推理模型多轮对话的上下文回传问题我们一开始除了deepseek-chat还测试了deepseek-reasoner来做复杂业务分析。reasoner在深度推理上确实更强但有个使用限制多轮对话时上一轮的推理内容必须原样回传给API否则接口直接返回400错误。一开始我们的Agent工具跑到第三轮就报错日志里提示“thinking mode下必须把reasoning_content传回去”。查了半天才发现是轮次切换时丢了这个字段。这个问题对用完即弃的单次请求没影响但凡是做多轮回归、场景式追问都必须把reasoning_content完整保留并回传否则服务不可用。这不是DeepSeek独有的问题很多带推理链的模型都有类似设计。接入的时候一定先读清楚官方文档里关于多轮对话的参数要求别等到线上报错才排查。6.2 JSON输出残缺和长内容截断第一个版本用默认max_tokens生成复杂接口的用例集时经常出现输出明显断在半截的情况。因为单次生成30条用例用例多了之后token消耗远超预期模型还没写完后半部分就被截断了。解决方法是双管齐下一是把max_tokens调到4096给足生成空间二是把生成任务拆小不再让模型一口气生成30条而是按场景类别分批每批只生成8到10条。拆批的副作用是可能出现重复用例但这个问题用去重模块就能解决整体收益还是正的。6.3 上下文过大、超时和限流第三个坑出现在上下文组装层。我用一份包含三十多个接口的完整模块文档作为上下文时发现模型响应时间飙升部分请求直接超时还触发了限流。排查下来的原因是上下文过长导致推理时间增加吞吐量下降。修复方式是按接口维度切片每次生成只针对单个接口上下文只包含该接口的定义和全局共享的业务规则摘要。响应时间从平均25秒降到8秒左右生成质量反而提升了——因为模型注意力不会被无关接口干扰。另外批量生成时一定要做并发控制。我用了简单的请求队列加指数退避重试效果稳定。不需要上多复杂的消息队列脚本可控执行就够了。6.4 敏感数据与合规问题测试场景经常涉及用户信息、订单流水等敏感字段。请工程化使用的读者务必注意不要把脱敏后的真实数据直接塞进提示词更不要在生产环境用未经脱敏处理的数据调用外部API。我的做法是在上下文组装层加了一道字符替换规则身份证号、手机号、银行卡号一律用固定的模拟数据替换替换关系单独存表。这样既保留数据的格式特征长度、前缀、校验位规则又不泄露真实信息。这块没有太多技术含量但必须在系统上线前做好别等合规审计上门再补救。7. 给测试开发团队和个人的落地建议7.1 团队落地的节奏建议我建议团队不要一上来就追求“全业务线自动化生成用例”那样的项目大概率会烂尾。比较稳妥的节奏是选一个接口定义完整、业务规则清晰、历史缺陷记录齐全的模块做试点。先人工整理上下文知识库跑通“单接口自动生成 - 校验 - 入库”的完整闭环。统计生成用例的采用率、缺陷覆盖率复盘模板和校验规则的问题迭代两到三轮。把跑通的模式复制到其他模块逐步推进。过程中最容易翻车的地方是试点模块选“太有挑战性”。我见过有人一上来就选订单状态机这种高复杂度业务结果生成质量上不去项目组直接否定整个方案。选一个简单靠谱的模块先跑出成绩比一开始就啃硬骨头明智得多。7.2 个人技能转型方向对测试开发个人来说这个变化确实是冲击也是机会。只会机械执行用例编写的人价值会快速缩水能设计生成系统的人价值在快速上升。我梳理了四个最值得投入的方向上下文工程知道怎么把业务知识转化成模型能高效利用的结构化上下文。这是最稀缺的能力远比会写几句提示词重要。校验系统设计能设计自动化规则把模型输出的错误拦截在入库之前。这是保证生成系统可靠性的核心。评估体系建设能回答“生成质量到底好不好”这个问题而不是凭感觉说“看起来不错”。经典测试功底这一条反而更重要了因为只有真正懂测试设计的人才能设计出教模型做测试设计的模板和示例。基本功不扎实的人用上大模型也只会产出垃圾。另外我一直建议团队里的人保持手写用例的能力。当生成系统跑出来的用例规模足够大时必须有人能分辨哪些是金子哪些是噪音这种判断力只能来自扎实的测试基本功没法靠工具替代。我现在带新人的方法也变了。不再要求他们背各种面试题里的理论和框架而是让他们从“给生成器挑错”开始入门分析模型生成的用例为什么不好、缺了什么维度、怎么通过修改上下文和校验规则来修正。这个过程既练了测试基本功又练了大模型应用能力。从结果看这批新人的成长速度明显快于过去从“照着需求手写用例”入门的同学。如果你也想在团队里做类似的事我的建议是从一个你最熟悉的模块开始用周末两天把第一版跑通不用追求完美先让系统产出第一批用例然后你拿去做人工审核。那个时刻你自然会看到这套方案的潜力和问题后面怎么迭代方向会清晰得多。