用 Streamlit + AutoGen + DeepSeek 落地智能测试用例生成器

如果把这篇文章只当成一个“AI 生成测试用例”的 Demo，会低估它。原文真正抓住的，是测试工作里最浪费人但又很难彻底自动化的一段：需求一改就要重写、边界条件容易漏、多人协作时格式和口径常常失控。

所以这套 Streamlit + AutoGen + DeepSeek 组合，更像一个测试设计加速器，而不是自动测试平台。

文章开头用了很多行业数据去描述现状，本质都在说明同一个问题。传统测试用例编写不是技术门槛特别高，而是机械劳动太多、覆盖质量不稳定、后续维护太重。像文中提到的这些数字，其实已经把痛点说透了：

• 大量时间耗在机械编写和反复修改上
• 边界值漏测会直接转成生产缺陷
• 需求一变，用例就会成批返工

这也是为什么“让模型写几条用例”本身不是重点。重点在于，能不能把需求理解、草稿生成、格式整理、边界补全这条链路做成一个稳定闭环，让测试工程师把时间从机械输入转回质量判断。

原文没有把三个技术名词堆在一起就算结束，而是给了一个还算清晰的职责切分。

Streamlit 负责把能力做成一个有人能真正使用的工作台。它接住需求输入、高级选项、结果展示和导出操作。这个选择很务实，因为很多内部工具最后不是败在模型，而是败在入口太像脚本，导致只有作者自己会用。

AutoGen 负责把流程拆开，而不是把所有事都扔给一次对话。原文把它当成流程调度层去用，我觉得是对的。生成测试用例这件事，一旦涉及需求理解、结构化输出、规则校验、人机协同，就已经不适合靠“一次提示词”硬顶。

DeepSeek 在这里承担的是中文语义理解和格式化生成能力。文章里还比较了成本，给出过 0.01 元 / 千 Token 这类数字，本意也很明确：这类场景里，模型不只是要“会写”，还得在成本和速度上足够实用。

换句话说，这个方案真正的价值不在于某个单点组件，而在于它把交互、流程和生成分开了。分开之后，系统才有调试空间。

原文中我最想保留的部分，是那些“看起来不酷，但决定系统能不能用”的硬规则。比如它明确要求：

1. 严格按指定数量生成测试用例
2. 确保每个用例 ID 唯一
3. 用统一的 Markdown 格式输出
4. 覆盖关键功能路径和边界条件
5. 未指定数量时给出默认范围

这些要求非常像传统软件工程里的 schema 和校验器。它们的意义不是限制模型发挥，而是把“什么算合格结果”从人脑里的隐性标准，变成程序能检查的显性规则。

一个最小可用的校验器，大概就该长成这样：

import re
from collections import Counter

def audit_cases(markdown: str, expected_count: int) -> list[str]:
    issues: list[str] = []
    ids = re.findall(r'用例ID[:：]\\s*([A-Z0-9_\\-]+)', markdown)

    if len(ids) != expected_count:
        issues.append(f'数量异常：期望 {expected_count}，实际 {len(ids)}')

    duplicated = [case_id for case_id, count in Counter(ids).items() if count > 1]
    if duplicated:
        issues.append(f'ID 重复：{", ".join(duplicated)}')

    if '边界条件' not in markdown and '异常场景' not in markdown:
        issues.append('缺少边界或异常场景说明')

    return issues

这段代码不复杂，但思路很重要。模型负责生成，人来判断业务风险，系统负责拦掉格式和结构层面的明显问题。没有这一层，生成器就只是个演示工具。

原文后半段其实已经意识到这一点了，所以才会继续往历史记录、评审辅助、版本回溯、diff 对比这些方向走。很多人看 Demo 只看“90 秒生成一批用例”这种速度数字，但真正会决定能不能长期用的，反而是更无聊的东西：

• 每次生成有没有版本记录
• prompt 和规则是不是可追溯
• 人工评审意见能不能沉淀
• 新旧版本用例能不能对比
• 生成成本、失败率、时延有没有监控

这些能力一旦缺位，系统就会停在“偶尔挺惊艳，但出问题没法查”的阶段。原文最后把未来扩展方向放到多模态输入、多模态输出和功能创新上，我觉得可以有，但顺序上治理层应该先于花样能力。

如果把本文压成一个判断，我会这么说：这类生成器不适合被宣传成“AI 自动做测试”，更适合被定义成“AI 协助测试设计”。它擅长的是把大量重复但仍需格式和规则约束的劳动压缩掉，让测试工程师把精力放回用例价值、覆盖边界和风险判断。

也正因为如此，它的成败不主要取决于界面是不是更好看，Agent 是不是更多，模型是不是更新，而取决于三件更基础的事：规则是否写清楚，校验是否做扎实，评审是否进闭环。这三件事在，系统就可能继续长；不在，再快的生成速度也只会制造新的维护负担。