[QA]插件式测试用例生成工具：LLM Test Case Tool 的设计与实现

一句话介绍：QA 在需求分析和测试设计中常用的能力沉淀到浏览器插件里：用户在阅读 PRD 时，可以直接在页面右下角调用 Workee，完成摘要、大纲、疑点、测试点、测试用例、UAT 用例和多页面分析。

1. 背景：为什么还需要这个工具

我们前期也基于 Cursor / Codex 做过测试分析能力沉淀，例如通过 skill 固化测试点和用例生成规范。这个方式对个人效率提升很明显，但在更大范围使用时，我们发现仅依赖个人 AI 工具仍然会遇到一些实际问题。

1.1 规模化成本与使用门槛较高

我们公司也给个人都开通了 AI 账号，所以现在都是用本地 skill 去生成测试用例，但是去年，用例生成是用的插件方式，这个也适合没开通cursor 账号又想提效的公司。LLM Test Case Tool 则把高频测试分析能力做成低门槛、低成本、可在 PRD 页面内直接使用的一键能力。
考虑到我们希望更多 QA、开发、产品同学都能低成本使用这类能力，因此需要一个更统一的产品入口和后端模型服务。

1.2 不同需求场景需要不同粒度的分析能力

在实际使用中，不同角色、不同阶段对同一份需求的关注点并不一样。

阶段 用户常见问题 更适合的能力
刚打开页面 这页主要讲什么？ 一句话摘要
需求评审前 结构是否清楚？有什么疑点？ 大纲、疑点
测试设计阶段 应该测哪些点？优先级怎么分？ 测试点
执行准备阶段 用例怎么写得可执行？ 测试用例
验收交付阶段 哪些是必须验收的核心路径？ UAT 用例
基于这个观察，我们没有把工具设计成“一次性生成所有结果”，而是拆成多个可选择的分析能力。用户可以根据当前需求理解深度和产出目标，选择合适的功能。

1.3 统一后端模型服务可以降低成本

我们现在的做法不是再造一个聊天机器人，而是把高频 QA 分析能力产品化，并通过统一后端模型服务集中承接模型调用、缓存、限流、权限和用量统计。
这样既保留了用户在页面内一键使用 AI 的体验，也让大规模使用时的成本更可控。

2. 建设目标

LLM Test Case Tool 的目标，是引入 LLM Test Case 自动生成能力，将下面这条链路产品化和自动化，同时保留人工审核空间：

PRD 审阅 → 测试点提取 → 用例生成 → 审核保存/导出 → UAT 交付
具体来说，我们希望解决四件事：

降低需求理解成本
用户打开 PRD 或技术文档后，可以快速获得当前页面的一句话摘要、结构化摘要和大纲。

提升测试设计效率
工具可以基于当前页面内容，自动生成疑点、测试点、测试用例和 UAT 用例，减少重复性的初稿整理工作。

保留人工判断
AI 负责生成初稿和结构化分析，QA 负责审核、调整和确认。工具不替代 QA，而是降低 QA 做初步分析和用例整理的成本。

降低模型使用成本
统一后端模型服务承接调用链路，相比每个人都在个人 AI 工具里直接调用高级模型，更容易做缓存、限流、权限和用量统计。

3. 产品形态：嵌在页面里的 Workee

3.1 浏览器插件入口

目前，LLM Test Case Tool 以 Google 插件的方式加载在浏览器中，并展示在任意 Web 页面。用户在阅读 PRD 时，即可在页面右下角调用 Workee 工具。

我们选择这种形态，主要是考虑到 QA 的需求分析动作本身就发生在 PRD 页面里。用户不需要离开正在阅读的页面，也不需要手动复制大段 PRD 内容，AI 能基于当前页面内容直接工作。

3.2 核心功能入口

工具现在以“轻对话 + 一键化”的方式提供能力。

4. 整体架构

4.1 六个核心模块

从实现角度看，我们把系统拆成六个核心模块。这里的“模块”不是严格的后端分层，而是从用户请求到结果产出的完整链路。

4.2 请求链路

Web 页面浏览器插件—>内容抽取—>上下文构建—>任务编排—>模型服务—>结果渲染与导出

模型服务层不是简单转发请求，而是整个工具成本治理的核心,采用 openAI 格式，用户在前端模型切换入口中选择；后端负责统一承接所选模型的调用链路，并处理鉴权、缓存、限流、错误处理和用量统计。

5. 任务编排：

不要一次性把所有事情都丢给模型，一个常见做法是把完整 PRD 丢给模型，然后要求它一次性生成完整测试用例。这个方式并不是完全不可用，但在真实需求分析里不够稳定。

主要原因不是模型不会写用例，而是不同阶段需要的输出粒度不同：

• 刚打开页面时，用户可能只想知道“这页在讲什么”
• 需求评审前，用户更关心结构大纲和潜在疑点
• 测试设计阶段，用户需要系统化测试点
• 执行准备阶段，用户才需要详细测试用例
• 面向业务验收时，用户可能只需要 P0 级 UAT 用例
  因此，我们把 QA 工作拆成多个稳定任务，让用户按需触发，也可以逐步串联。
  页面内容读取
  → 页面摘要
  → 页面大纲
  → 疑点识别
  → 测试点生成
  → 测试用例生成
  → UAT 用例生成
  这样做的好处是，每一步的输入、Prompt、输出格式和质量要求都更明确。

6. 核心能力与 Prompt 设计

这一部分是工具最关键的地方。我们不是只做一个聊天框，而是把每个高频 QA 任务都沉淀成稳定功能，并为每个功能配置独立 Prompt。

6.1 一句话摘要

功能说明

页面打开后，工具默认生成当前页面的一句话摘要。这个功能看起来简单，但可以帮助用户快速确认 AI 是否读对页面，也可以作为后续上下文压缩的第一步。

Prompt 示例

请阅读当前页面内容，用一句话概括页面的核心主题。 要求：1.只输出一句话。2.使用中文。3.覆盖页面的主要目的和核心结论。4.不要展开分析过程。

输出示例

该页面介绍某某功能的背景、目标、核心流程和测试关注点。

6.2 摘要

功能说明

摘要不是简单复述页面，而是帮助 QA 快速建立测试上下文。它通常需要覆盖主要目的、关键要点、业务影响、技术依赖、风险点和后续关注问题。

Prompt 示例

请阅读当前页面内容，用一句话概括页面的核心主题。 要求：1.只输出一句话。2.使用中文。3.覆盖页面的主要目的和核心结论。4.不要展开分析过程。

6.3 大纲

功能说明

大纲功能将页面内容转换成思维导图结构，适合用 Mermaid 或 XMind 表达。它的核心价值是帮助用户快速看到页面模块、逻辑层级和关键路径。

Prompt 示例

请为当前页面生成一份结构清晰的思维导图大纲。 要求：1.使用 Mermaid graph LR 横向布局。2.结构为：根节点（需求/页面名）→ 功能模块 → 核心功能点 → 关键逻辑描述。3.配色规则：仅使用边框色区分层级，标签简洁，建议15字以内。4.纯净要求：禁止输出无关的装饰性节点或标签。5.内容要求：全面覆盖页面的核心模块、关键交互和底层逻辑脉络。6.输出要求：直接输出 Mermaid 代码，不要输出分析过程。

大纲生成后，我们支持以下操作：
下载 XMind
下载图片
转换成 Excel
编辑 Mermaid 源码
源码编辑很重要，因为 AI 生成的大纲通常需要用户微调节点名称、删除不相关内容或调整层级。

6.4 疑点

功能说明

疑点识别是 QA 价值很高的一步。它不是判断“这个需求是否写得好”，而是从测试和评审角度找出可能影响实现、测试和验收的问题。

Prompt 示例

请仔细审查当前页面内容，找出其中表述不严谨、逻辑矛盾、 数据缺失或未定义的术语等疑点。 请像一个挑剔的产品经理或测试人员一样“找茬”，并列出你的发现和建议。 审查角度：1.表述严谨性2.逻辑一致性3.数据完整性4.术语定义5.可实施性6.UI/图片与文字描述是否一致 输出要求：1.按问题类型分组。2.每个疑点说明问题、影响和建议。3.不要编造页面中不存在的信息。

常见疑点包括术语与范围定义不清、流程逻辑不完整、数据规则缺失、异常处理不足、权限与角色边界不明确、UI 与交互细节缺失。

6.5 测试点

功能说明

测试点是从需求到用例的桥梁。它不是最终测试用例，而是测试设计大纲，适合用 Mermaid 或 XMind 展示。

Prompt 示例

请从资深 QA 角度，全面分析当前页面的需求 Markdown 和相关图片（设计稿/截图）。 要求：1.深度拆解：结合图文细节，挖掘 P0 核心路径、P1 分支逻辑、P2 UI 规范及异常边界。2.优先级分布控制：P0 必须是极少数核心路径，数量严格控制在总数的20%以内。 绝大部分测试点应标注为 P1 或 P2。3.结构要求：使用 Mermaid graph LR。 层级为：根节点 → 功能模块 → 测试分类（UI/交互/逻辑/异常）→ 详细测试点。4.命名规范：测试点必须是完整的验证语句。 禁止输出无关的装饰性标签或节点。5.标注优先级：使用（P0）/（P1）/（P2）。6.输出要求：直接输出 Mermaid，不要输出分析过程。

6.6 测试用例

功能说明

测试用例生成必须结构化。每条用例都应该包含前置条件、执行步骤和预期结果，确保用户可以直接执行或进一步修改。
推荐字段包括模块、用例名称、优先级、用例类型、前置条件、执行步骤、预期结果、备注和来源。

Prompt 示例

你是一个极其严谨的资深 QA。请基于当前页面的 Markdown 需求 and 图片设计稿，生成覆盖度100%且极其详尽的测试用例。 必须严格遵守以下 Mermaid graph LR 结构（层级不可随意增减）： ```mermaid graph LR root["需求名称"]-->mod1["功能模块1"]mod1-->point1["金额门槛"]point1-->case1["【优先级】【测试用例】用例名称"]case1-->pre1["前置条件：<br/>1.xxx"]case1-->step1["执行步骤：<br/>1.xxx"]step1-->res1["预期结果：<br/>1.xxx"]root-->mod2["功能模块2"]mod2-->point2["角色权限"]point2-->case2["【优先级】【测试用例】用例名称"]case2-->pre2["前置条件：<br/>1.xxx"]case2-->step2["执行步骤：<br/>1.xxx"]step2-->res2["预期结果：<br/>1.xxx"]重要：每个节点的 ID 必须全局唯一（如 mod1,mod2,case1,case2），禁止重复使用相同的 ID！ 要求：1.结构与覆盖：严格按【需求->模块->测试点->用例】层级展开。必须100%覆盖 PRD 中所有功能模块。每个模块必须先在内部拆解为细粒度测试点，再在最终输出中收敛为多个简短测试点短标题。每个测试点必须至少生成1条用例。用例规模需随 PRD 详尽程度正向展开。2.优先级分布控制（核心要求）：-【P0】：仅限核心业务的核心路径（Happy Path）。总比例必须严格控制在20%以内。-【P1/P2】：分支路径、UI 规范、异常边界。总比例应占80%以上。3.深度分析与方法论：针对每个测试点，必须组合应用【等价类、边界值、场景法、流程图法、错误推断法】设计用例。针对不同场景（APP/PC,Buyer/Seller 等）进行交叉验证。涉及 abtest 需验证白名单及流量分流。将每类相近验证意图收敛为一个测试点短标题，并在其下展开具体测试用例。4.测试点命名规范：使用简短中文短标题，不要使用完整句；不要使用"测试点："前缀；不要使用"验证/检查/确认/当...时/是否/应该"等词；推荐形式为对象/规则/状态/维度/机制，例如"金额门槛"、"默认值展示"、"角色权限"、"状态回写"、"重试机制"、"幂等处理"；反例："验证金额低于门槛时优惠券不可用"、"检查默认值是否正确展示"。5.术语与语言规则：整体用中文叙述。PRD/页面中的真实 UI 文案、字段名、状态值、接口名、参数名、key、路径、代码标识符保留原文，不要翻译。测试点优先使用中文短标题；用例标题中文为主，仅保留必要的原文术语。英文术语优先放在步骤和预期中；同一术语保持一种写法，不要中英混用。如果一句话英文过多，请改写为中文概括，只保留关键原文术语。输出前检查是否误译固定术语，或让单句出现过多英文。6.优先级规则：P0/P1/P2 仅用于测试用例节点。测试点、前置条件、执行步骤、预期结果不要写任何优先级标记。输出前自检并删除字段节点中的优先级。7.命名与描述：用例节点必须以 【P级别】【测试用例】 开头。各节点描述必须详尽，使用完整句子。禁止输出"Seller Bot"、"NEW"、"Status"等任何无关的装饰性标签或节点。执行步骤需包含操作路径，预期结果需包含 UI 状态、数据校验及业务逻辑断言。8.输出前请自检：-每个测试点是否为短标题，而非完整验证句。-测试点是否与某条子用例高度重复；若重复，请继续缩短并抽象。-测试点下是否优先形成2-5条同类用例。-用例名称是否承担具体条件和结论，避免与测试点重复表达。9.格式规范：标签（前置条件、执行步骤、预期结果）后必须紧跟<br/>换行。文本用双引号包裹，禁止使用英文方括号[]，请务必使用中文全角括号【】。10.纯净输出与自查提问：-首先直接输出 Mermaid 代码块。-在 Mermaid 之后，增加一个 ### 💡 QA 澄清与风险点 章节：请基于 o1 的深度推理，列出3-5个你认为需求中描述模糊、逻辑可能冲突或需要用户进一步补充信息的地方。例如："图片中的 X 按钮在 Markdown 文档中未提及，请确认其功能"或"AB 实验的 C 场景边界逻辑不清晰，建议补充"。-不要输出冗长的自我分析过程，仅输出 Mermaid 和上述澄清章节。

6.7 UAT 用例

功能说明

UAT 用例不是完整测试集，而是给产品、开发、业务方或地区团队快速验收的关键路径集合。它的重点是收敛，只保留 P0 critical path。

Prompt 示例

You are an extremely rigorous Senior QA.Based on the Markdown requirements and image designs of the current page,generate HIGHLY DETAILEDP0(Critical Path)test cases in ENGLISH.Requirements:1.Only generate P0 critical path UAT test cases.2.Focus on business acceptance,not internal implementation details.3.Each testcasemust include Test Case Name,Preconditions,Steps,and Expected Results.4.Use clear English that PM,Dev,and local teams can understand.5.Do not generate low-priority edge cases.6.Do not invent requirements that are not supported by the page.

输出特点
使用英文或目标语言，因为我们公司的 local 不会中文。
表达更贴近业务用户
避免过多内部技术细节
只覆盖核心验收路径

7. Prompt 模板化方法

这个工具最核心的工程能力之一，是 Prompt 模板化。不能让用户每次自己写 Prompt，也不能把所有任务共用一个 Prompt。

7.1 模板拆分

我们按任务维护不同 Prompt 模板：

模板 对应功能
summary_prompt 摘要
outline_prompt 大纲
question_review_prompt 疑点
test_point_prompt 测试点
test_case_prompt 测试用例
uat_case_prompt UAT 用例
multi_page_prompt 多页面分析

7.2 模板需要约束什么

一个稳定的 Prompt 模板通常需要约束五件事：

角色约束
例如：你是一个极其严谨的资深 QA。

输入说明
例如：以下内容来自当前页面的 Markdown、表格和图片设计稿。

输出结构
例如：摘要、疑点列表、Mermaid、表格或结构化用例。

质量约束
例如：不要编造需求中没有的信息，缺失信息必须列入疑点。

格式约束
如果要生成 Mermaid、Excel 或 JSON，就必须严格约束输出格式，避免后续解析失败。

7.3 为什么要允许用户编辑 Prompt

截图中的测试点和用例功能，在点击后会展示 Prompt，用户可以修改后再生成。这个设计很重要，因为不同团队、不同业务、不同阶段，对输出会有不同要求。

例如：
有的团队重视接口校验
有的团队重视 UI 回归
有的团队重视多语言文案
有的团队重视权限和数据一致性
固定模板保证基础质量，允许编辑保证灵活性。

8. 输出格式与渲染

LLM Test Case Tool 的输出不是单一文本，而是根据不同任务使用不同格式。

输出格式 适用场景 说明
Markdown 摘要、疑点、用例说明 适合阅读和编辑
Mermaid 大纲、测试点、用例脑图 适合渲染成结构图
XMind 大纲、测试点 适合测试设计沉淀和评审
Excel 测试点、测试用例 适合执行和协作
图片 大纲截图、脑图截图 适合分享
结构化 JSON 前后端解析 适合稳定渲染和导出
其中 Mermaid / XMind 是比较关键的一层。模型先生成结构化 Mermaid，再由前端渲染成脑图，并支持用户放大、下载图片、下载 XMind、转换 Excel 和编辑源码。

9. Human-in-the-loop：AI 生成初稿，QA 做判断

这个工具的定位不是“让 AI 直接替 QA 做决定”，而是把重复整理、初稿生成和格式转换交给 AI。

我们的流程是：

AI 生成初稿 → 用户审核 → 用户修改 Prompt 或结果 → 再生成 / 导出 / 保存
用户可以介入的位置包括：

选择功能入口。
修改 Prompt。
调整生成结果。
编辑 Mermaid 源码。
选择是否导出 XMind / Excel / 图片。
回看历史会话。
这样可以兼顾效率和人工判断。

10. 多页面分析

单个 PRD 页面往往不够完整。真实测试分析经常需要同时参考 PRD、技术方案、接口文档、设计稿、评审补充和历史变更说明。

因此工具提供多页面分析能力。用户可以把多个相关页面加入同一次分析，让模型基于更完整的上下文做摘要、疑点、测试点或用例生成。

多页面分析的关键不是简单拼接页面，而是要做上下文组织。

首先，需要标记每个页面的标题和 URL。

其次，需要区分主需求、补充说明和设计材料。

然后，需要合并重复信息，并保留冲突信息。

最后，在输出中尽量标注来源，方便用户回到原始页面确认。

11. 模型与成本控制

我们考虑到的一个现实收益，是后端统一接入公共模型服务。

相比每个人都在自己的 AI 工具里直接调用高级模型，统一模型服务可以做几件事：

集中调用
所有请求通过统一后端服务进入模型调用链路。

模型选择统一入口
用户可以在前端切换模型，后端负责承接调用，不需要每个人单独配置模型服务。

缓存复用
对相同页面的摘要、大纲等低变化结果，可以做缓存，减少重复调用。

权限与限流
根据用户、团队或功能控制调用权限和频率。

用量可观测
统计不同功能、不同模型、不同用户的调用量，为后续成本优化提供依据。

这也是为什么它比“每个人自己用 Cursor / Codex”更适合规模化推广。

12. 质量保障

LLM 工具最怕的是看起来能用，但输出质量不可控。因此我们从几个方面约束输出质量。

1. Prompt 约束：每个功能都有独立 Prompt，并明确角色、输入、输出格式和质量要求。
2. 优先级约束：尤其是测试点和用例生成，必须控制 P0 数量，避免所有内容都被标成最高优先级。
3. 格式校验： 对于 Mermaid、JSON、Excel 等结构化输出，需要做格式校验，避免前端渲染或导出失败。
4. 用户确认：输出默认是初稿，最终仍由 QA 审核、调整和确认。

13. 关键工程难点

13.1 页面内容抽取
不同网站的页面结构差异很大。正文、表格、图片、折叠内容、附件链接都可能影响模型理解。内容抽取需要尽量保留语义结构，而不是简单拿纯文本。

13.2 长文档压缩
PRD 很容易超过模型上下文长度。上下文构建模块需要区分核心需求、补充说明、历史记录和低价值内容，避免把模型上下文浪费在无关信息上。

13.3 图片与设计稿理解
很多测试点来自设计稿和截图，例如按钮状态、字段展示、错误提示、权限入口等。工具需要把图片信息纳入模型输入，而不是只分析文字。

13.4 Mermaid 稳定生成
Mermaid 对语法比较敏感。模型输出中如果包含特殊字符、重复节点、非法换行，都可能导致渲染失败。因此需要在 Prompt 和后处理层都做约束。

13.5 导出格式一致性
同一份测试点可能要导出为 XMind、图片或 Excel。不同格式对层级、字段、换行和样式要求不同，需要统一中间结构，避免各自转换导致结果不一致。

14. 总结

LLM Test Case Tool 的核心价值，不是把聊天机器人换一个壳，也不是让模型一次性完成所有测试工作。

我们真正做的是三件事：

把 QA 高频需求分析动作拆成稳定任务。
把每个任务沉淀成可复用的 Prompt 模板和输出格式。
把模型能力接入浏览器插件和统一后端服务，让更多人可以低门槛、低成本地使用。
最终，这个工具不是让 QA 少思考，而是把重复整理、初稿生成、格式转换这类工作交给 AI，让 QA 把更多时间投入到判断、设计和风险识别中。