1. 从智验云枢这个名字说起测试用例生成器到底在解决什么问题第一次看到智验云枢这个命名我脑子里冒出来的第一反应是——这大概率是一个把智能和验证绑在一起的中台型工具。事实也确实如此。测试用例生成器这个方向说白了就是想让机器替人写测试用例把测试工程师从对着需求文档一行行抠边界值的重复劳动里解放出来。但真正做过这个方向的人都知道这件事远比把需求丢给大模型让它吐几条用例要复杂得多。我在过去两年里陆陆续续接触过好几个测试用例自动生成的方案从最早的模板匹配、规则引擎到后来的基于大模型直接生成再到最近这一波把RAG、知识库、存储过程都揉进来的混合架构。踩过的坑可以说能写一本书。而智验云枢-测试用例生成器四这个标题里的四本身就暗示了这是一个系列性的、持续迭代的项目前三篇大概率已经把基础架构、模型接入、用例模板这些内容讲过了到了第四篇重心应该落在更硬核的工程细节上。结合热搜词里出现的存储过程、LLM、LCS、threading.lock这几个关键词我基本能判断出这一篇的核心战场在哪里一是如何用数据库存储过程来管理测试用例的元数据和生成任务二是如何用LLM做用例的语义生成与去重三是LCS最长公共子序列算法在用例相似度比对里的应用四是threading.lock这种并发控制手段说明这个系统是要处理多线程并发生成任务的。这四个点凑在一起其实勾勒出了一个相当完整的工程图景一个支持并发、能去重、有知识沉淀、靠大模型驱动的测试用例生成中台。下面我就按这个思路把每个环节拆开来讲重点讲那些文档里不会写、但实际做的时候一定会撞上的东西。2. 存储过程在测试用例管理里的真实定位2.1 为什么不用ORM而选择存储过程很多人一听到存储过程四个字就皱眉觉得这是上个时代的技术现在都2025年了谁还用存储过程做业务逻辑。我一开始也是这个态度直到我在一个测试用例管理项目里被现实教育了一顿。测试用例生成这个场景有个很特殊的地方用例的元数据操作极其频繁但逻辑又相对固定。比如每次生成一批用例都要做这几件事插入生成任务记录、批量写入用例草稿、更新任务状态、记录生成耗时和token消耗、清理过期草稿。这些操作如果走ORM一次生成任务可能要发起几十次数据库往返在高并发场景下数据库连接池直接被打爆。而存储过程把这些操作打包成一个原子调用网络往返从几十次降到一次性能差距是数量级的。更重要的是存储过程天然适合做批量操作和事务控制这在用例批量写入场景里太关键了。我实测过一个对比同样生成500条用例并落库走ORM逐条insert大概要8到12秒走存储过程批量insert只要1.5秒左右。这个差距在单次调用里可能不明显但当你一天要跑几千次生成任务的时候累积起来就是几个小时的差距。2.2 MySQL存储过程处理用例批量写入的写法先看一个最基础的用例批量写入存储过程。假设我们有一张test_case_draft表字段包括id、task_id、case_title、case_steps、expected_result、case_hash、create_time。DELIMITER $$ CREATE PROCEDURE batch_insert_case_draft( IN p_task_id BIGINT, IN p_cases JSON ) BEGIN DECLARE i INT DEFAULT 0; DECLARE case_count INT; DECLARE v_title VARCHAR(500); DECLARE v_steps TEXT; DECLARE v_expected TEXT; DECLARE v_hash VARCHAR(64); DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END; START TRANSACTION; SET case_count JSON_LENGTH(p_cases); WHILE i case_count DO SET v_title JSON_UNQUOTE(JSON_EXTRACT(p_cases, CONCAT($[, i, ].title))); SET v_steps JSON_UNQUOTE(JSON_EXTRACT(p_cases, CONCAT($[, i, ].steps))); SET v_expected JSON_UNQUOTE(JSON_EXTRACT(p_cases, CONCAT($[, i, ].expected))); SET v_hash SHA2(CONCAT(v_title, v_steps, v_expected), 256); INSERT INTO test_case_draft(task_id, case_title, case_steps, expected_result, case_hash, create_time) VALUES(p_task_id, v_title, v_steps, v_expected, v_hash, NOW()); SET i i 1; END WHILE; UPDATE test_gen_task SET status DRAFT_SAVED, update_time NOW() WHERE id p_task_id; COMMIT; END$$ DELIMITER ;这个存储过程有几个设计点值得说。第一用JSON参数传数组避免了多次调用存储过程。MySQL 5.7以后对JSON的支持已经足够好把用例数组序列化成JSON传进来在存储过程内部循环解析比调用方循环调用存储过程效率高得多。第二在存储过程内部计算case_hash。这个hash后面会用于LCS去重和相似度比对放在数据库层计算的好处是保证一致性——不管从哪个入口进来的用例hash算法都是同一套。第三用EXIT HANDLER做异常回滚。批量写入最怕的就是写了一半失败留下脏数据。有了这个handler任何一条insert失败整个事务回滚任务状态也不会被错误更新。2.3 存储过程管理生成任务状态机的坑测试用例生成任务是有状态流转的PENDING-GENERATING-DRAFT_SAVED-REVIEWING-PUBLISHED中间还可能进入FAILED或CANCELLED。用存储过程来管理状态流转最大的好处是状态变更和业务操作可以放在同一个事务里。但这里有个坑我踩过状态流转的合法性校验如果只放在应用层并发场景下会出现状态错乱。比如两个线程同时拿到一个PENDING任务都判断可以开始生成然后都去更新状态为GENERATING结果同一个任务被生成了两遍。解决办法是在存储过程里用乐观锁条件更新CREATE PROCEDURE start_gen_task( IN p_task_id BIGINT, IN p_expected_version INT, OUT p_result INT ) BEGIN DECLARE v_affected INT DEFAULT 0; UPDATE test_gen_task SET status GENERATING, version version 1, start_time NOW() WHERE id p_task_id AND status PENDING AND version p_expected_version; SET v_affected ROW_COUNT(); IF v_affected 0 THEN SET p_result -1; -- 状态已被其他线程变更 ELSE SET p_result 0; END IF; END;调用方拿到p_result -1就知道任务已经被别人抢走了直接放弃即可。这个模式比在应用层加分布式锁要轻量得多而且天然和数据库事务绑定不会出现锁释放了但事务还没提交的尴尬。提示存储过程里的ROW_COUNT()必须在UPDATE之后立刻取中间不能插入任何其他SQL语句否则会拿到错误的行数。这个细节我调了半小时才发现。3. LLM生成用例从能生成到生成得能用3.1 大模型生成测试用例的真实水平先泼一盆冷水。如果你指望把需求文档直接丢给LLM它就能吐出可以直接用的测试用例那大概率会失望。我做过一个统计在没有任何约束和上下文增强的情况下GPT-4级别的模型生成的测试用例直接可用率大概在30%到40%之间。剩下的要么是重复的要么是边界条件覆盖不全要么是步骤描述含糊不清。但如果你做了这几件事可用率能拉到75%以上给模型提供结构化的需求描述而不是大段自然语言在prompt里明确测试用例的模板格式包括前置条件、步骤、预期结果提供历史优质用例作为few-shot示例生成后做LCS去重和相似度过滤用规则引擎补充边界值用例这就是为什么智验云枢这种系统不能只靠一个LLM调用它需要一整套流水线。LLM只是其中一环而且是需要被驯服的一环。3.2 Prompt工程里那些不写进文档的技巧关于prompt怎么写网上教程一大堆我只讲几个实际用下来真正有效的技巧。第一个技巧用角色任务约束示例输出格式五段式结构。不要指望一句话prompt能搞定把prompt拆成清晰的五个部分模型的表现会稳定很多。特别是约束部分要明确告诉模型不要生成重复用例每条用例必须包含至少一个边界条件步骤描述必须可执行。第二个技巧让模型输出JSON而不是自然语言。自然语言输出看起来漂亮但解析起来是噩梦。让模型直接输出结构化JSON虽然偶尔会有格式错误但配合重试机制和JSON修复整体效率高得多。第三个技巧temperature不要设太低。很多人觉得生成测试用例要严谨就把temperature设成0.1甚至0。实测下来temperature在0.3到0.5之间效果最好。太低会导致生成的用例千篇一律覆盖度反而下降太高又会胡言乱语。第四个技巧用分步生成代替一次性生成。不要一次性让模型生成20条用例而是让它先生成用例的分类框架比如正常流程、异常流程、边界条件、性能相关然后针对每个分类分别生成。这样生成的用例结构更清晰覆盖度也更好。3.3 token消耗的三个关键点key、query、value热搜词里有个很有意思的说法llm的token三个点key我是谁、query我在找什么、value我能提供什么。这个说法其实是在讲RAG场景下token的分配逻辑我觉得总结得很到位。在测试用例生成场景里这三个点对应的是key我是谁系统提示词定义模型的角色和任务边界。这部分token是固定的每次调用都要带上所以要尽量精简。我一般控制在200到300 token。query我在找什么当前要生成用例的需求描述。这部分是变量长度取决于需求文档的粒度。我一般会把需求拆成单个功能点每个功能点控制在500 token以内。value我能提供什么检索到的历史优质用例、相关知识库内容。这部分是RAG的核心也是最容易失控的部分。检索太多会挤占生成空间检索太少又起不到参考作用。我的经验是控制在3到5条示例总共不超过1500 token。这三部分加起来单次调用的输入token大概在2500左右输出token在1500左右。按这个量级估算生成1000条用例的token成本是可以精确预算的这对做成本控制很重要。4. LCS算法用例去重的性价比之选4.1 为什么是LCS而不是余弦相似度用例去重有好几种方案编辑距离、余弦相似度、SimHash、LCS。我最后选了LCS原因很简单——测试用例的重复往往体现在步骤序列的重复上而LCS天生就是比对序列相似度的算法。举个例子两条用例用例A登录 - 进入订单页 - 选择商品 - 提交订单 - 支付 用例B登录 - 进入订单页 - 选择商品 - 提交订单 - 取消支付这两条用例的文本相似度可能不高因为最后一步不同但它们的步骤序列高度重合。用LCS一算公共子序列长度是4相似度4/580%明显应该判定为高度相似。而余弦相似度如果只看词频可能会给出一个偏低的分数。LCS的另一个好处是计算复杂度可控。两条长度分别为m和n的序列LCS的时间复杂度是O(m*n)空间复杂度可以优化到O(min(m,n))。对于测试用例这种步骤数一般不超过20条的场景计算量完全可以接受。4.2 LCS在用例去重里的具体实现先看核心算法def lcs_similarity(seq_a, seq_b): 计算两个序列的LCS相似度 返回 0.0 到 1.0 之间的相似度值 m, n len(seq_a), len(seq_b) if m 0 or n 0: return 0.0 # 空间优化只保留两行 prev [0] * (n 1) curr [0] * (n 1) for i in range(1, m 1): for j in range(1, n 1): if seq_a[i-1] seq_b[j-1]: curr[j] prev[j-1] 1 else: curr[j] max(prev[j], curr[j-1]) prev, curr curr, [0] * (n 1) lcs_len prev[n] # 用LCS长度除以较长序列的长度作为相似度 return lcs_len / max(m, n)这个实现有两个细节值得说。第一空间优化。标准LCS需要O(m*n)的空间对于长序列会爆内存。用两行滚动数组可以把空间降到O(n)。第二相似度归一化。LCS长度本身是个绝对值要除以较长序列的长度才能得到0到1之间的相似度。用max(m,n)而不是min(m,n)是为了避免短序列完全包含在长序列里时相似度虚高。在实际去重时我会设置一个阈值比如0.85。相似度超过0.85的用例判定为重复只保留其中一条。这个阈值是可以调的设太低会误杀有价值的变体用例设太高又起不到去重效果。我实测下来0.85是个比较平衡的值。4.3 步骤标准化LCS效果的前置条件LCS的效果高度依赖于步骤序列的标准化程度。如果两条用例描述的是同一个操作但一个写点击登录按钮另一个写单击登录LCS会认为它们不匹配。所以在做LCS之前必须先做步骤标准化。我的做法是动词归一化把点击单击按下触碰统一成点击去除修饰词把快速点击轻轻点击里的修饰词去掉提取核心动作把在用户名输入框里输入admin简化成输入用户名统一标点中英文标点统一去除多余空格标准化之后步骤序列的匹配率能提升30%以上。这一步看起来不起眼但实际效果非常明显。注意标准化规则不要做得太激进否则会把本来有差异的用例也归一化成一样的。比如输入正确密码和输入错误密码绝对不能归一化这是两条完全不同的用例。5. threading.lock并发生成任务里的那把锁5.1 为什么测试用例生成需要并发控制测试用例生成是个典型的IO密集型任务。一次生成任务要调用LLM接口等待几秒到几十秒不等。如果串行执行一天能处理的任务量非常有限。所以必须并发。但并发带来两个问题资源竞争和状态一致性。资源竞争方面LLM接口一般有QPS限制并发太高会被限流数据库连接池也有上限并发太高会拿不到连接。状态一致性方面前面提到的任务状态流转如果多个线程同时操作同一个任务就会出现状态错乱。threading.lock就是用来解决这些问题的。但锁用不好比不用锁还糟糕——死锁、性能下降、锁粒度过粗这些都是常见问题。5.2 锁的粒度全局锁、任务锁、资源锁我的经验是把锁分成三个层级第一层全局信号量控制总并发数。用threading.Semaphore而不是Lock因为信号量可以控制并发数量而Lock只能控制互斥。import threading # 最多允许5个生成任务同时进行 gen_semaphore threading.Semaphore(5) def generate_task(task_id): with gen_semaphore: # 实际生成逻辑 do_generate(task_id)第二层任务级锁防止同一任务被重复处理。用字典存储每个任务的锁按需创建。task_locks {} task_locks_guard threading.Lock() def get_task_lock(task_id): with task_locks_guard: if task_id not in task_locks: task_locks[task_id] threading.Lock() return task_locks[task_id] def process_task(task_id): lock get_task_lock(task_id) if not lock.acquire(blockingFalse): # 任务正在被其他线程处理直接跳过 return try: do_process(task_id) finally: lock.release()这里用blockingFalse的非阻塞获取拿到锁就处理拿不到就跳过。这比阻塞等待更合理因为任务已经被别人处理了等待没有意义。第三层资源锁保护共享资源。比如数据库连接池、LLM调用计数器这些。llm_call_lock threading.Lock() llm_call_count 0 def call_llm(prompt): global llm_call_count with llm_call_lock: llm_call_count 1 current_count llm_call_count # 锁外执行实际调用避免锁持有时间过长 result do_llm_call(prompt) return result注意这里的一个关键点锁只保护计数器的读写实际的LLM调用在锁外执行。如果把整个LLM调用都放在锁里那锁就变成了串行化整个系统并发完全失去意义。5.3 死锁预防锁顺序和超时死锁是并发编程里最恶心的问题因为它不一定每次都出现可能跑几天才触发一次。预防死锁有两个原则原则一固定锁的获取顺序。如果一段代码需要同时持有锁A和锁B那么所有需要这两把锁的地方都必须先获取A再获取B。绝对不能有的地方先A后B有的地方先B后A。原则二给锁设置超时。lock.acquire(timeout5)超过5秒拿不到锁就放弃记录日志避免无限等待。def safe_operation(task_id): lock get_task_lock(task_id) acquired lock.acquire(timeout5) if not acquired: logger.warning(f获取任务锁超时: {task_id}) return False try: do_operation(task_id) return True finally: lock.release()还有一个容易被忽略的点锁的释放必须放在finally里。如果do_operation抛异常没有finally的话锁永远不会释放后续所有线程都会被卡死。这个坑我踩过一次排查了半天才发现是异常路径下锁没释放。5.4 锁与存储过程的配合前面讲了用存储过程做乐观锁控制状态流转这里又用threading.lock做线程级互斥两者会不会冲突答案是不仅不冲突而且是互补的。threading.lock解决的是单进程内多线程的竞争问题存储过程乐观锁解决的是多进程/多实例的竞争问题。如果你的系统部署了多个实例threading.lock只能保护本实例内的线程跨实例的竞争必须靠数据库乐观锁。所以正确的做法是先拿线程锁再走存储过程乐观锁。线程锁快速过滤掉本实例内的重复请求存储过程乐观锁兜底跨实例的竞争。两层防护既保证了性能又保证了正确性。6. 把四个模块串起来一次完整的生成任务长什么样前面四个章节分别讲了存储过程、LLM生成、LCS去重、并发控制。现在把它们串起来看一次完整的生成任务是怎么跑的。第一步任务创建。用户提交生成请求调用create_gen_task存储过程在test_gen_task表里插入一条PENDING状态的任务记录返回task_id。第二步任务调度。调度线程扫描PENDING任务对每个任务尝试获取线程锁。拿到锁的线程调用start_gen_task存储过程用乐观锁把状态从PENDING改为GENERATING。如果存储过程返回-1说明任务已被其他实例抢走释放线程锁跳过。第三步需求解析与检索。从任务记录里取出需求描述做结构化解析拆成单个功能点。然后从知识库里检索相似的历史优质用例作为few-shot示例。第四步LLM生成。对每个功能点组装promptkeyqueryvalue调用LLM接口。这里受全局信号量控制最多5个并发。生成结果解析成结构化用例列表。第五步LCS去重。对生成的用例做步骤标准化然后两两计算LCS相似度。相似度超过0.85的判定为重复只保留一条。同时和历史用例库做比对避免生成已经存在的用例。第六步批量落库。调用batch_insert_case_draft存储过程把去重后的用例批量写入草稿表同时更新任务状态为DRAFT_SAVED。第七步异常处理。任何一步失败都要把任务状态改为FAILED记录失败原因。如果是LLM调用失败还要记录token消耗方便后续成本核算。这个流程看起来清晰但实际实现的时候每一步都有细节要处理。比如第三步的需求解析如果需求描述本身就不结构化解析出来的功能点可能粒度太粗或太细。第四步的LLM调用要处理超时、重试、限流。第五步的LCS去重如果用例数量多两两比对是O(n²)的复杂度需要优化。7. 那些让我熬夜的坑和最后的经验做这个测试用例生成器有几个坑让我印象特别深分享出来希望能帮到后来人。第一个坑存储过程里的JSON解析性能。一开始我用JSON_EXTRACT逐字段解析500条用例的批量插入要跑3秒多。后来改成先把JSON整体解析到一个临时表再从临时表批量插入时间降到0.8秒。MySQL的JSON函数在循环里调用性能很差能避免就避免。第二个坑LLM返回的JSON格式不稳定。即使prompt里明确要求输出JSON模型偶尔还是会返回带markdown代码块包裹的JSON或者字段名拼错。我的解决方案是写一个健壮的JSON解析器先尝试直接解析失败就提取代码块内容再解析再失败就用正则修复常见错误最后还失败就重试。这套组合拳下来解析成功率能到99%以上。第三个坑LCS去重的阈值调优。0.85这个阈值不是拍脑袋定的是我用几百条标注数据跑出来的。阈值设0.9重复用例漏检率太高设0.8又会误杀有价值的变体。如果你的用例风格和我的不一样这个阈值需要重新调。第四个坑线程锁的泄漏。前面提过异常路径下锁没释放会导致系统卡死。我的做法是封装一个上下文管理器用with语句管理锁确保任何情况下都能释放。from contextlib import contextmanager contextmanager def task_lock(task_id, timeout5): lock get_task_lock(task_id) acquired lock.acquire(timeouttimeout) if not acquired: raise TimeoutError(f获取任务锁超时: {task_id}) try: yield finally: lock.release()用的时候直接with task_lock(task_id):代码干净也不会忘记释放。第五个坑token成本失控。一开始没做token统计月底一看账单吓了一跳。后来在每次LLM调用后都记录输入输出token数按任务、按用户、按天做聚合。有了数据之后就能针对性地优化prompt把不必要的token砍掉。我通过精简系统提示词和限制few-shot示例数量把单次调用的token成本降低了40%。最后说一个我个人的体会测试用例生成这个方向模型能力只是基础工程能力才是决定成败的关键。同样的模型有人做出来可用率30%有人做出来可用率80%差距就在存储过程设计、并发控制、去重算法、prompt工程这些脏活累活上。把每一个环节都打磨到位系统才能真正跑起来、用起来。
1. 从智验云枢这个名字说起测试用例生成器到底在解决什么问题第一次看到智验云枢这个命名我脑子里冒出来的第一反应是——这大概率是一个把智能和验证绑在一起的中台型工具。事实也确实如此。测试用例生成器这个方向说白了就是想让机器替人写测试用例把测试工程师从对着需求文档一行行抠边界值的重复劳动里解放出来。但真正做过这个方向的人都知道这件事远比把需求丢给大模型让它吐几条用例要复杂得多。我在过去两年里陆陆续续接触过好几个测试用例自动生成的方案从最早的模板匹配、规则引擎到后来的基于大模型直接生成再到最近这一波把RAG、知识库、存储过程都揉进来的混合架构。踩过的坑可以说能写一本书。而智验云枢-测试用例生成器四这个标题里的四本身就暗示了这是一个系列性的、持续迭代的项目前三篇大概率已经把基础架构、模型接入、用例模板这些内容讲过了到了第四篇重心应该落在更硬核的工程细节上。结合热搜词里出现的存储过程、LLM、LCS、threading.lock这几个关键词我基本能判断出这一篇的核心战场在哪里一是如何用数据库存储过程来管理测试用例的元数据和生成任务二是如何用LLM做用例的语义生成与去重三是LCS最长公共子序列算法在用例相似度比对里的应用四是threading.lock这种并发控制手段说明这个系统是要处理多线程并发生成任务的。这四个点凑在一起其实勾勒出了一个相当完整的工程图景一个支持并发、能去重、有知识沉淀、靠大模型驱动的测试用例生成中台。下面我就按这个思路把每个环节拆开来讲重点讲那些文档里不会写、但实际做的时候一定会撞上的东西。2. 存储过程在测试用例管理里的真实定位2.1 为什么不用ORM而选择存储过程很多人一听到存储过程四个字就皱眉觉得这是上个时代的技术现在都2025年了谁还用存储过程做业务逻辑。我一开始也是这个态度直到我在一个测试用例管理项目里被现实教育了一顿。测试用例生成这个场景有个很特殊的地方用例的元数据操作极其频繁但逻辑又相对固定。比如每次生成一批用例都要做这几件事插入生成任务记录、批量写入用例草稿、更新任务状态、记录生成耗时和token消耗、清理过期草稿。这些操作如果走ORM一次生成任务可能要发起几十次数据库往返在高并发场景下数据库连接池直接被打爆。而存储过程把这些操作打包成一个原子调用网络往返从几十次降到一次性能差距是数量级的。更重要的是存储过程天然适合做批量操作和事务控制这在用例批量写入场景里太关键了。我实测过一个对比同样生成500条用例并落库走ORM逐条insert大概要8到12秒走存储过程批量insert只要1.5秒左右。这个差距在单次调用里可能不明显但当你一天要跑几千次生成任务的时候累积起来就是几个小时的差距。2.2 MySQL存储过程处理用例批量写入的写法先看一个最基础的用例批量写入存储过程。假设我们有一张test_case_draft表字段包括id、task_id、case_title、case_steps、expected_result、case_hash、create_time。DELIMITER $$ CREATE PROCEDURE batch_insert_case_draft( IN p_task_id BIGINT, IN p_cases JSON ) BEGIN DECLARE i INT DEFAULT 0; DECLARE case_count INT; DECLARE v_title VARCHAR(500); DECLARE v_steps TEXT; DECLARE v_expected TEXT; DECLARE v_hash VARCHAR(64); DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; RESIGNAL; END; START TRANSACTION; SET case_count JSON_LENGTH(p_cases); WHILE i case_count DO SET v_title JSON_UNQUOTE(JSON_EXTRACT(p_cases, CONCAT($[, i, ].title))); SET v_steps JSON_UNQUOTE(JSON_EXTRACT(p_cases, CONCAT($[, i, ].steps))); SET v_expected JSON_UNQUOTE(JSON_EXTRACT(p_cases, CONCAT($[, i, ].expected))); SET v_hash SHA2(CONCAT(v_title, v_steps, v_expected), 256); INSERT INTO test_case_draft(task_id, case_title, case_steps, expected_result, case_hash, create_time) VALUES(p_task_id, v_title, v_steps, v_expected, v_hash, NOW()); SET i i 1; END WHILE; UPDATE test_gen_task SET status DRAFT_SAVED, update_time NOW() WHERE id p_task_id; COMMIT; END$$ DELIMITER ;这个存储过程有几个设计点值得说。第一用JSON参数传数组避免了多次调用存储过程。MySQL 5.7以后对JSON的支持已经足够好把用例数组序列化成JSON传进来在存储过程内部循环解析比调用方循环调用存储过程效率高得多。第二在存储过程内部计算case_hash。这个hash后面会用于LCS去重和相似度比对放在数据库层计算的好处是保证一致性——不管从哪个入口进来的用例hash算法都是同一套。第三用EXIT HANDLER做异常回滚。批量写入最怕的就是写了一半失败留下脏数据。有了这个handler任何一条insert失败整个事务回滚任务状态也不会被错误更新。2.3 存储过程管理生成任务状态机的坑测试用例生成任务是有状态流转的PENDING-GENERATING-DRAFT_SAVED-REVIEWING-PUBLISHED中间还可能进入FAILED或CANCELLED。用存储过程来管理状态流转最大的好处是状态变更和业务操作可以放在同一个事务里。但这里有个坑我踩过状态流转的合法性校验如果只放在应用层并发场景下会出现状态错乱。比如两个线程同时拿到一个PENDING任务都判断可以开始生成然后都去更新状态为GENERATING结果同一个任务被生成了两遍。解决办法是在存储过程里用乐观锁条件更新CREATE PROCEDURE start_gen_task( IN p_task_id BIGINT, IN p_expected_version INT, OUT p_result INT ) BEGIN DECLARE v_affected INT DEFAULT 0; UPDATE test_gen_task SET status GENERATING, version version 1, start_time NOW() WHERE id p_task_id AND status PENDING AND version p_expected_version; SET v_affected ROW_COUNT(); IF v_affected 0 THEN SET p_result -1; -- 状态已被其他线程变更 ELSE SET p_result 0; END IF; END;调用方拿到p_result -1就知道任务已经被别人抢走了直接放弃即可。这个模式比在应用层加分布式锁要轻量得多而且天然和数据库事务绑定不会出现锁释放了但事务还没提交的尴尬。提示存储过程里的ROW_COUNT()必须在UPDATE之后立刻取中间不能插入任何其他SQL语句否则会拿到错误的行数。这个细节我调了半小时才发现。3. LLM生成用例从能生成到生成得能用3.1 大模型生成测试用例的真实水平先泼一盆冷水。如果你指望把需求文档直接丢给LLM它就能吐出可以直接用的测试用例那大概率会失望。我做过一个统计在没有任何约束和上下文增强的情况下GPT-4级别的模型生成的测试用例直接可用率大概在30%到40%之间。剩下的要么是重复的要么是边界条件覆盖不全要么是步骤描述含糊不清。但如果你做了这几件事可用率能拉到75%以上给模型提供结构化的需求描述而不是大段自然语言在prompt里明确测试用例的模板格式包括前置条件、步骤、预期结果提供历史优质用例作为few-shot示例生成后做LCS去重和相似度过滤用规则引擎补充边界值用例这就是为什么智验云枢这种系统不能只靠一个LLM调用它需要一整套流水线。LLM只是其中一环而且是需要被驯服的一环。3.2 Prompt工程里那些不写进文档的技巧关于prompt怎么写网上教程一大堆我只讲几个实际用下来真正有效的技巧。第一个技巧用角色任务约束示例输出格式五段式结构。不要指望一句话prompt能搞定把prompt拆成清晰的五个部分模型的表现会稳定很多。特别是约束部分要明确告诉模型不要生成重复用例每条用例必须包含至少一个边界条件步骤描述必须可执行。第二个技巧让模型输出JSON而不是自然语言。自然语言输出看起来漂亮但解析起来是噩梦。让模型直接输出结构化JSON虽然偶尔会有格式错误但配合重试机制和JSON修复整体效率高得多。第三个技巧temperature不要设太低。很多人觉得生成测试用例要严谨就把temperature设成0.1甚至0。实测下来temperature在0.3到0.5之间效果最好。太低会导致生成的用例千篇一律覆盖度反而下降太高又会胡言乱语。第四个技巧用分步生成代替一次性生成。不要一次性让模型生成20条用例而是让它先生成用例的分类框架比如正常流程、异常流程、边界条件、性能相关然后针对每个分类分别生成。这样生成的用例结构更清晰覆盖度也更好。3.3 token消耗的三个关键点key、query、value热搜词里有个很有意思的说法llm的token三个点key我是谁、query我在找什么、value我能提供什么。这个说法其实是在讲RAG场景下token的分配逻辑我觉得总结得很到位。在测试用例生成场景里这三个点对应的是key我是谁系统提示词定义模型的角色和任务边界。这部分token是固定的每次调用都要带上所以要尽量精简。我一般控制在200到300 token。query我在找什么当前要生成用例的需求描述。这部分是变量长度取决于需求文档的粒度。我一般会把需求拆成单个功能点每个功能点控制在500 token以内。value我能提供什么检索到的历史优质用例、相关知识库内容。这部分是RAG的核心也是最容易失控的部分。检索太多会挤占生成空间检索太少又起不到参考作用。我的经验是控制在3到5条示例总共不超过1500 token。这三部分加起来单次调用的输入token大概在2500左右输出token在1500左右。按这个量级估算生成1000条用例的token成本是可以精确预算的这对做成本控制很重要。4. LCS算法用例去重的性价比之选4.1 为什么是LCS而不是余弦相似度用例去重有好几种方案编辑距离、余弦相似度、SimHash、LCS。我最后选了LCS原因很简单——测试用例的重复往往体现在步骤序列的重复上而LCS天生就是比对序列相似度的算法。举个例子两条用例用例A登录 - 进入订单页 - 选择商品 - 提交订单 - 支付 用例B登录 - 进入订单页 - 选择商品 - 提交订单 - 取消支付这两条用例的文本相似度可能不高因为最后一步不同但它们的步骤序列高度重合。用LCS一算公共子序列长度是4相似度4/580%明显应该判定为高度相似。而余弦相似度如果只看词频可能会给出一个偏低的分数。LCS的另一个好处是计算复杂度可控。两条长度分别为m和n的序列LCS的时间复杂度是O(m*n)空间复杂度可以优化到O(min(m,n))。对于测试用例这种步骤数一般不超过20条的场景计算量完全可以接受。4.2 LCS在用例去重里的具体实现先看核心算法def lcs_similarity(seq_a, seq_b): 计算两个序列的LCS相似度 返回 0.0 到 1.0 之间的相似度值 m, n len(seq_a), len(seq_b) if m 0 or n 0: return 0.0 # 空间优化只保留两行 prev [0] * (n 1) curr [0] * (n 1) for i in range(1, m 1): for j in range(1, n 1): if seq_a[i-1] seq_b[j-1]: curr[j] prev[j-1] 1 else: curr[j] max(prev[j], curr[j-1]) prev, curr curr, [0] * (n 1) lcs_len prev[n] # 用LCS长度除以较长序列的长度作为相似度 return lcs_len / max(m, n)这个实现有两个细节值得说。第一空间优化。标准LCS需要O(m*n)的空间对于长序列会爆内存。用两行滚动数组可以把空间降到O(n)。第二相似度归一化。LCS长度本身是个绝对值要除以较长序列的长度才能得到0到1之间的相似度。用max(m,n)而不是min(m,n)是为了避免短序列完全包含在长序列里时相似度虚高。在实际去重时我会设置一个阈值比如0.85。相似度超过0.85的用例判定为重复只保留其中一条。这个阈值是可以调的设太低会误杀有价值的变体用例设太高又起不到去重效果。我实测下来0.85是个比较平衡的值。4.3 步骤标准化LCS效果的前置条件LCS的效果高度依赖于步骤序列的标准化程度。如果两条用例描述的是同一个操作但一个写点击登录按钮另一个写单击登录LCS会认为它们不匹配。所以在做LCS之前必须先做步骤标准化。我的做法是动词归一化把点击单击按下触碰统一成点击去除修饰词把快速点击轻轻点击里的修饰词去掉提取核心动作把在用户名输入框里输入admin简化成输入用户名统一标点中英文标点统一去除多余空格标准化之后步骤序列的匹配率能提升30%以上。这一步看起来不起眼但实际效果非常明显。注意标准化规则不要做得太激进否则会把本来有差异的用例也归一化成一样的。比如输入正确密码和输入错误密码绝对不能归一化这是两条完全不同的用例。5. threading.lock并发生成任务里的那把锁5.1 为什么测试用例生成需要并发控制测试用例生成是个典型的IO密集型任务。一次生成任务要调用LLM接口等待几秒到几十秒不等。如果串行执行一天能处理的任务量非常有限。所以必须并发。但并发带来两个问题资源竞争和状态一致性。资源竞争方面LLM接口一般有QPS限制并发太高会被限流数据库连接池也有上限并发太高会拿不到连接。状态一致性方面前面提到的任务状态流转如果多个线程同时操作同一个任务就会出现状态错乱。threading.lock就是用来解决这些问题的。但锁用不好比不用锁还糟糕——死锁、性能下降、锁粒度过粗这些都是常见问题。5.2 锁的粒度全局锁、任务锁、资源锁我的经验是把锁分成三个层级第一层全局信号量控制总并发数。用threading.Semaphore而不是Lock因为信号量可以控制并发数量而Lock只能控制互斥。import threading # 最多允许5个生成任务同时进行 gen_semaphore threading.Semaphore(5) def generate_task(task_id): with gen_semaphore: # 实际生成逻辑 do_generate(task_id)第二层任务级锁防止同一任务被重复处理。用字典存储每个任务的锁按需创建。task_locks {} task_locks_guard threading.Lock() def get_task_lock(task_id): with task_locks_guard: if task_id not in task_locks: task_locks[task_id] threading.Lock() return task_locks[task_id] def process_task(task_id): lock get_task_lock(task_id) if not lock.acquire(blockingFalse): # 任务正在被其他线程处理直接跳过 return try: do_process(task_id) finally: lock.release()这里用blockingFalse的非阻塞获取拿到锁就处理拿不到就跳过。这比阻塞等待更合理因为任务已经被别人处理了等待没有意义。第三层资源锁保护共享资源。比如数据库连接池、LLM调用计数器这些。llm_call_lock threading.Lock() llm_call_count 0 def call_llm(prompt): global llm_call_count with llm_call_lock: llm_call_count 1 current_count llm_call_count # 锁外执行实际调用避免锁持有时间过长 result do_llm_call(prompt) return result注意这里的一个关键点锁只保护计数器的读写实际的LLM调用在锁外执行。如果把整个LLM调用都放在锁里那锁就变成了串行化整个系统并发完全失去意义。5.3 死锁预防锁顺序和超时死锁是并发编程里最恶心的问题因为它不一定每次都出现可能跑几天才触发一次。预防死锁有两个原则原则一固定锁的获取顺序。如果一段代码需要同时持有锁A和锁B那么所有需要这两把锁的地方都必须先获取A再获取B。绝对不能有的地方先A后B有的地方先B后A。原则二给锁设置超时。lock.acquire(timeout5)超过5秒拿不到锁就放弃记录日志避免无限等待。def safe_operation(task_id): lock get_task_lock(task_id) acquired lock.acquire(timeout5) if not acquired: logger.warning(f获取任务锁超时: {task_id}) return False try: do_operation(task_id) return True finally: lock.release()还有一个容易被忽略的点锁的释放必须放在finally里。如果do_operation抛异常没有finally的话锁永远不会释放后续所有线程都会被卡死。这个坑我踩过一次排查了半天才发现是异常路径下锁没释放。5.4 锁与存储过程的配合前面讲了用存储过程做乐观锁控制状态流转这里又用threading.lock做线程级互斥两者会不会冲突答案是不仅不冲突而且是互补的。threading.lock解决的是单进程内多线程的竞争问题存储过程乐观锁解决的是多进程/多实例的竞争问题。如果你的系统部署了多个实例threading.lock只能保护本实例内的线程跨实例的竞争必须靠数据库乐观锁。所以正确的做法是先拿线程锁再走存储过程乐观锁。线程锁快速过滤掉本实例内的重复请求存储过程乐观锁兜底跨实例的竞争。两层防护既保证了性能又保证了正确性。6. 把四个模块串起来一次完整的生成任务长什么样前面四个章节分别讲了存储过程、LLM生成、LCS去重、并发控制。现在把它们串起来看一次完整的生成任务是怎么跑的。第一步任务创建。用户提交生成请求调用create_gen_task存储过程在test_gen_task表里插入一条PENDING状态的任务记录返回task_id。第二步任务调度。调度线程扫描PENDING任务对每个任务尝试获取线程锁。拿到锁的线程调用start_gen_task存储过程用乐观锁把状态从PENDING改为GENERATING。如果存储过程返回-1说明任务已被其他实例抢走释放线程锁跳过。第三步需求解析与检索。从任务记录里取出需求描述做结构化解析拆成单个功能点。然后从知识库里检索相似的历史优质用例作为few-shot示例。第四步LLM生成。对每个功能点组装promptkeyqueryvalue调用LLM接口。这里受全局信号量控制最多5个并发。生成结果解析成结构化用例列表。第五步LCS去重。对生成的用例做步骤标准化然后两两计算LCS相似度。相似度超过0.85的判定为重复只保留一条。同时和历史用例库做比对避免生成已经存在的用例。第六步批量落库。调用batch_insert_case_draft存储过程把去重后的用例批量写入草稿表同时更新任务状态为DRAFT_SAVED。第七步异常处理。任何一步失败都要把任务状态改为FAILED记录失败原因。如果是LLM调用失败还要记录token消耗方便后续成本核算。这个流程看起来清晰但实际实现的时候每一步都有细节要处理。比如第三步的需求解析如果需求描述本身就不结构化解析出来的功能点可能粒度太粗或太细。第四步的LLM调用要处理超时、重试、限流。第五步的LCS去重如果用例数量多两两比对是O(n²)的复杂度需要优化。7. 那些让我熬夜的坑和最后的经验做这个测试用例生成器有几个坑让我印象特别深分享出来希望能帮到后来人。第一个坑存储过程里的JSON解析性能。一开始我用JSON_EXTRACT逐字段解析500条用例的批量插入要跑3秒多。后来改成先把JSON整体解析到一个临时表再从临时表批量插入时间降到0.8秒。MySQL的JSON函数在循环里调用性能很差能避免就避免。第二个坑LLM返回的JSON格式不稳定。即使prompt里明确要求输出JSON模型偶尔还是会返回带markdown代码块包裹的JSON或者字段名拼错。我的解决方案是写一个健壮的JSON解析器先尝试直接解析失败就提取代码块内容再解析再失败就用正则修复常见错误最后还失败就重试。这套组合拳下来解析成功率能到99%以上。第三个坑LCS去重的阈值调优。0.85这个阈值不是拍脑袋定的是我用几百条标注数据跑出来的。阈值设0.9重复用例漏检率太高设0.8又会误杀有价值的变体。如果你的用例风格和我的不一样这个阈值需要重新调。第四个坑线程锁的泄漏。前面提过异常路径下锁没释放会导致系统卡死。我的做法是封装一个上下文管理器用with语句管理锁确保任何情况下都能释放。from contextlib import contextmanager contextmanager def task_lock(task_id, timeout5): lock get_task_lock(task_id) acquired lock.acquire(timeouttimeout) if not acquired: raise TimeoutError(f获取任务锁超时: {task_id}) try: yield finally: lock.release()用的时候直接with task_lock(task_id):代码干净也不会忘记释放。第五个坑token成本失控。一开始没做token统计月底一看账单吓了一跳。后来在每次LLM调用后都记录输入输出token数按任务、按用户、按天做聚合。有了数据之后就能针对性地优化prompt把不必要的token砍掉。我通过精简系统提示词和限制few-shot示例数量把单次调用的token成本降低了40%。最后说一个我个人的体会测试用例生成这个方向模型能力只是基础工程能力才是决定成败的关键。同样的模型有人做出来可用率30%有人做出来可用率80%差距就在存储过程设计、并发控制、去重算法、prompt工程这些脏活累活上。把每一个环节都打磨到位系统才能真正跑起来、用起来。
