[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. 产品形态嵌在页面里的 Workee3.1 浏览器插件入口目前LLM Test Case Tool 以 Google 插件的方式加载在浏览器中并展示在任意 Web 页面。用户在阅读 PRD 时即可在页面右下角调用 Workee 工具。我们选择这种形态主要是考虑到 QA 的需求分析动作本身就发生在 PRD 页面里。用户不需要离开正在阅读的页面也不需要手动复制大段 PRD 内容AI 能基于当前页面内容直接工作。3.2 核心功能入口工具现在以“轻对话 一键化”的方式提供能力。功能作用典型输出当前页面一句话摘要快速判断页面主题一句话总结摘要提取核心内容主要目的、关键要点、结论大纲理清页面结构Mermaid / XMind疑点发现需求问题疑点清单、影响、建议测试点生成测试设计大纲P0/P1/P2 测试点脑图用例生成可执行用例前置条件、步骤、预期结果UAT 用例生成验收用例英文 P0 critical path多页面分析融合多份材料跨页面总结、测试分析历史会话与模型切换回看历史、选择模型会话记录、模型选择4. 整体架构4.1 六个核心模块从实现角度看我们把系统拆成六个核心模块。这里的“模块”不是严格的后端分层而是从用户请求到结果产出的完整链路。模块职责浏览器插件负责入口、页面交互、功能按钮、会话展示、模型选择和多页面选择内容抽取模块读取当前页面标题、URL、正文、表格、图片和附件信息上下文构建模块清洗页面内容、压缩长文档、融合图片信息构造成模型输入任务编排模块根据用户点击的功能选择对应任务模板模型服务模块统一承接模型调用、鉴权、缓存、限流、错误处理和用量统计结果渲染与导出模块将模型输出转换成 Markdown、Mermaid、XMind、Excel、图片或 UAT 结果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-loopAI 生成初稿QA 做判断这个工具的定位不是“让 AI 直接替 QA 做决定”而是把重复整理、初稿生成和格式转换交给 AI。我们的流程是AI 生成初稿 → 用户审核 → 用户修改 Prompt 或结果 → 再生成 / 导出 / 保存用户可以介入的位置包括选择功能入口。修改 Prompt。调整生成结果。编辑 Mermaid 源码。选择是否导出 XMind / Excel / 图片。回看历史会话。这样可以兼顾效率和人工判断。10. 多页面分析单个 PRD 页面往往不够完整。真实测试分析经常需要同时参考 PRD、技术方案、接口文档、设计稿、评审补充和历史变更说明。因此工具提供多页面分析能力。用户可以把多个相关页面加入同一次分析让模型基于更完整的上下文做摘要、疑点、测试点或用例生成。多页面分析的关键不是简单拼接页面而是要做上下文组织。首先需要标记每个页面的标题和 URL。其次需要区分主需求、补充说明和设计材料。然后需要合并重复信息并保留冲突信息。最后在输出中尽量标注来源方便用户回到原始页面确认。11. 模型与成本控制我们考虑到的一个现实收益是后端统一接入公共模型服务。相比每个人都在自己的 AI 工具里直接调用高级模型统一模型服务可以做几件事集中调用所有请求通过统一后端服务进入模型调用链路。模型选择统一入口用户可以在前端切换模型后端负责承接调用不需要每个人单独配置模型服务。缓存复用对相同页面的摘要、大纲等低变化结果可以做缓存减少重复调用。权限与限流根据用户、团队或功能控制调用权限和频率。用量可观测统计不同功能、不同模型、不同用户的调用量为后续成本优化提供依据。这也是为什么它比“每个人自己用 Cursor / Codex”更适合规模化推广。12. 质量保障LLM 工具最怕的是看起来能用但输出质量不可控。因此我们从几个方面约束输出质量。Prompt 约束每个功能都有独立 Prompt并明确角色、输入、输出格式和质量要求。优先级约束尤其是测试点和用例生成必须控制 P0 数量避免所有内容都被标成最高优先级。格式校验 对于 Mermaid、JSON、Excel 等结构化输出需要做格式校验避免前端渲染或导出失败。用户确认输出默认是初稿最终仍由 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 把更多时间投入到判断、设计和风险识别中。