fetch_wechat_article.py，Playwright/隔离 Chrome 失败后使用 HTML fallback；正文非空，未出现“环境异常”。146ccf71ab8bfa8cc51b6af9a3a0d8e2763c94402a77ae5c8a8ed26663550170作者： TikTok Eng-Testing × 复旦大学软件工程实验室 最近，团队推出了面向测试自动化的 NL2Test Agent：QA在测试过程中， 只需用自然语言描述测试场景，Agent 就能自动生成可运行的回归测试用例，让测试资产沉淀更加高效。 目前已在多条业务线部署，从反馈来看，这个方向已经跑通：85.4% 的生成用例被集成到 CI/CD 工作流中；新增用例里，平均值约25%来自 Agent 生成，个别业务团队峰值可达 50%+ ，且比例仍在持续提升；Agent用户月活率达到 30.7% ；工具平均每双周为部门节省约 30 人天投入。 回头看，NL2Test Agent 能够真正被 QA 用起来，不仅仅是因为模型能力提升，更关键的是我们在场景选择和工程设计上做对了几类取舍。 NL2Test Agent 架构图 选对场景：不是替代 QA，而是做好“用例转译” 我们没有让 Agent 直接替代 QA 完成测试设计，而是选择了一个边界更清晰、确定性更高的任务：将 QA 用自然语言描述的测试场景，转化为可运行的回归测试用例。 这类任务本质上是从“测试意图”到“可执行用例”的转译。QA 负责描述测试目标和业务判断，Agent 负责生成符合框架规范、可以自动执行的用例。由于输入和输出都有相对明确的约束，它更适合作为 LLM Agent 的落地切入点。 另外，这个场景的业务价值也很明确：QA 基于前端 App 操作流程撰写测试场景并不难，真正耗时的是识别背后的后端 API，并编写面向 API 的自动化用例。NL2Test Agent 借助测试流量自动提取相关 API，再结合自然语言场景生成可执行用例，正好补上了这一环。 换句话说，Agent 没有替代 QA 的判断，而是降低了 QA 将测试意图沉淀为自动化资产的成本。 全流程无人干预比单点智能更重要 我们意识到，Agent 在真实工作流里的价值，不取决于某一次模型调用是否足够准确，而取决于它能否把任务从头到尾自动完成。 测试用例生成是一个多阶段流程：请求识别、依赖分析、参数处理、断言生成、代码生成，每一步都可能出错。如果某个环节失败后需要 QA 介入排查和修复，Agent 带来的效率收益就会被迅速抵消。 NL2Test Agent 的核心设计目标不是让每一步都生成“最优答案”，而是让整条链路具备足够强的容错能力。对于模型输出中的不确定或不合法结果，系统会通过结构校验、异常内容丢弃等方式处理，确保后续阶段可以继续执行。 这种设计的重点是先形成稳定闭环：哪怕初版用例不够完美，也要尽可能自动生成一个可运行结果。因为只有当 QA 不需要频繁介入，Agent 才能真正融入日常测试流程。 能用程序解决的问题，就不要用 LLM 我们没有把所有环节都交给 LLM。LLM 适合处理语义理解和模糊判断，比如将业务步骤映射到具体请求，或根据测试意图推断预期结果；但对于字段查找、schema 校验、值匹配、请求过滤、参数替换、断言校验这类精确操作，程序更可靠，也更容易验证。 在 NL2Test Agent 中，我们尽量让 LLM 只处理需要理解和推理的部分，把规则明确、结果可校验的环节交给确定性逻辑。 这样做的结果是，模型的不确定性被限制在必要范围内，系统整体也更稳定、更可控。 把 LLM 任务拆小，小到可以校验 我们没有把测试用例生成设计成一次端到端的大模型调用。端到端生成看起来简单，但工程上很难控制：一旦结果出错，很难定位问题发生在哪个环节；前面的错误也容易被带到后续步骤里，最终放大成不可运行的用例。 NL2Test Agent 将生成流程拆成多个更小的任务，例如请求匹配、依赖关系提取、断言意图识别、受约束代码生成等。每次 LLM 调用只负责产出一个小的结构化结果，并在进入下一阶段前完成校验。 这样做是为了让每一步都可检查、可修正、可追踪。相比一次性生成完整用例，拆小任务更有利于控制质量，也能减少错误在链路中的扩散。 给模型必要的信息，而不是塞入完整流量 更多上下文不等于更好效果。原始测试流量中有大量噪声，包括静态资源、轮询请求、重复流量、时间戳、trace id、诊断字段和运行时临时字段。这些信息很容易干扰模型判断。 在调用 LLM 前，NL2Test Agent 会先治理流量：过滤无关请求，摘要响应结构，突出候选字段，并排除不稳定字段。 核心原则是：上下文不是越多越好，而是越相关越好。 对 Agent 来说，给模型必要且干净的证据，比把完整流量全部塞进去更重要。 用明确约束限制模型输出，而不是只靠自然语言指令 只靠 Prompt 告诉模型“不要编造字段”“不要生成不存在的变量”，并不可靠。LLM 仍然可能生成不存在的字段、变量名、请求标识，甚至编造辅助函数。 在这个问题上，NL2Test Agent 不会单纯依赖模型“自觉”遵守指令，而是给它明确的 schema 和允许集合，例如合法的请求标识、候选字段、支持的断言类型、已有变量名等。模型输出后，系统会继续做约束校验。 对于超出约束的输出，系统不会直接接受。只有在存在唯一、确定性的修复方式时，才会自动修复；否则就直接丢弃，避免不可靠内容进入后续链路。 这让模型输出从“自由生成”变成“受控生成”，也让整个 Agent 系统更容易校验和维护。 优先生成稳定断言，而不是追求断言数量 在回归测试里，断言不是越多越好。所谓稳定断言，是指断言对象与业务结果直接相关，并且在多次执行中保持相对一致，不会因为正常的运行时变化而频繁波动。否则，即使业务逻辑没有问题，用例也可能误报失败，反而降低 QA 对自动化测试的信任。 NL2Test Agent 的策略是，只针对业务相关、可重复验证、结果相对稳定的字段生成部分断言。对于目标缺失、语义不明确或明显依赖运行时状态的断言，系统会选择移除，而不是为了“看起来完整”强行保留。 我们的判断是：回归测试首先要稳定可信。相比丰富但脆弱的断言，少而准、能长期稳定运行的断言更有实际价值。 此工作是与复旦大学计算与智能创新学院 CodeWisdom 团队董震老师合作完成，并被 ISSTA 2026 接收 Haozhen You, Jingjing Wang, Qiang Li, Xin Peng, and Zhen Dong. 2026. Industrial Practice of LLM-based Test Case Carving and Assertion Generation. In Proceedings of the 35th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA).
标签： #主题/AI-Agent #主题/软件测试 #主题/质量保障 #主题/Agent工程 #场景/公众号长文 #节点/NL2Test #节点/确定性校验 #节点/稳定断言 #节点/测试资产沉淀