📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

本⽂⾯向软件测试⼯程师，介绍如何⽤「基于⽂档的测试⽤例⽣成 Skill」从 PRD、需求说明、接⼝ ⽂档中快速产出结构化、可落地的测试⽤例，以及其设计思路与使⽤⽅式。

⼀、为什么需要这样⼀个 Skill？ 

测试⼯程师的⽇常⾥，有⼀类⼯作既⾼频⼜耗时：拿到需求⽂档或接⼝⽂档之后，把其中的业务规 则、接⼝约束、边界条件拆解成⼀条条可执⾏的测试⽤例。痛点往往包括：

• ⽂档⻓、模块多：⼈⼯逐段提炼容易漏掉边界和异常场景。

• ⽤例设计⽅法不统⼀：不同⼈习惯不同，有的偏正向、有的缺反向和边界，质量参差。

• 接⼝ / 功能 / 性能写法不⼀：接⼝要关注参数和错误码，功能要关注流程和状态，性能要关注负载 和指标，混在⼀起容易顾此失彼。

• 想按公司模板输出：希望⽣成结果能直接对接到现有的 Word/Excel ⽤例模板，减少⼆次整理。 

本 Skill 的⽬标就是：你提供⼀份需求或接⼝⽂档（⽂本），AI 在固定「测试设计策略 + 专⽤标准」 下，输出⼀整套结构化测试⽤例⽂档；你可以直接复制使⽤，或要求保存到指定⽬录，也可以让输出 对⻬⾃⼰在 assets ⾥放的 Word/Excel 模板。

⼆、这个 Skill 是什么？ 

名称：doc-based-testcase-generator （基于⽂档的测试⽤例⽣成器） 

本质：⼀个可在 Cursor 等环境中加载的 Claude Skill。它由⼀份主说明（ SKILL.md ）和若⼲参考 ⽂档（ references/ ）组成，规定了：

1. 何时触发：当你说「根据这份⽂档⽣成测试⽤例」「根据 PRD/接⼝⽂档写测试⽤例」等时，会按 本 Skill 的规则⼯作。

2. ⽤什么⽅法设计⽤例：默认采⽤⼀套通⽤测试⽤例设计策略（正向、反向、边界值、等价类、状态 与流程、场景法等），保证覆盖维度统⼀。

3. 不同类型如何细化：通过 references/ 下的专⽤标准⽂档，对接⼝测试、功能测试、性能测 试、⾃动化候选⽤例分别约定「要覆盖什么、怎么写」。

4. 输出格式从哪来：不写死表格列名；若你提到「参考某某 Word/Excel 模板」，则从 assets/ ⽬ 录读取对应模板，按模板结构组织输出。 

也就是说：你负责提供⽂档和需求，Skill 负责「⽤什么策略 + 按什么标准」⽣成⽤例，并⽀持对⻬你 的模板。 

三、适⽤场景与输⼊输出 

3.1 适⽤场景 

• 拿到 PRD、需求说明、⽤⼾故事 后，需要快速出⼀版功能测试⽤例。 

• 拿到 接⼝⽂档（OpenAPI、Markdown、表格等） 后，需要系统化设计接⼝测试⽤例（参数、错 误码、鉴权、幂等等）。

• 需求或设计中有 性能指标、SLA、压测要求 时，需要补充性能测试⽤例（场景、负载、通过标 准）。 

• 希望在⼀批⽤例中标出适合做⾃动化的，⽅便后续做⾃动化选型与排期。 

• 希望⽣成结果按公司现有 Word/Excel ⽤例模板的列和结构输出，便于直接导⼊⽤例库。 

3.2 输⼊ 

• 主输⼊：需求⽂档 / PRD / 接⼝⽂档的可复制⽂本。直接粘贴到对话中即可；若是截图，Skill 会建 议你将图中⽂字转为⽂本再使⽤。 

• 可选补充： 

  ◦ ⼝头说明侧重点，如「重点做接⼝测试」「要包含性能⽤例」「标出⾃动化候选」； 

  ◦ 或「参考 assets ⾥的某某模板」。

3.3 输出

• 形式：⼀份结构化测试⽤例⽂档（Markdown，含表格或分级列表），直接出现在对话中。 

• 内容：按模块/接⼝/场景分节，每条⽤例包含：⽤例编号、标题、模块/接⼝、⽤例类型、优先级、 前置条件、测试步骤、预期结果，以及可选的数据要求/备注。

• 落盘：默认不⾃动保存；若你说「保存到 xxx ⽬录」或「存到 testcases ⽂件夹」，会写⼊指定路 径，⽆需额外脚本。 

四、核⼼能⼒⼀：通⽤测试⽤例设计策略

Skill 规定：在⽣成任何测试⽤例之前，必须先按⼀套通⽤测试设计策略思考与覆盖。这样保证即使⽤ ⼾没有细说「要正向还是反向」，输出也会系统化。下⾯是策略概要，⽅便你对照⾃⼰平时的设计习 惯。 

策略	含义	典型做法
正向测试⽤例	合法前置条件 + 正常路 径，验证符合需求/接⼝ 约定	每个核⼼功能/接⼝⾄少 1 条 happy path；前置、输⼊、步 骤、预期与⽂档⼀致。
反向 / 异常测试⽤例	⾮法输⼊、错误操作、 异常状态，验证系统正 确拒绝且⽆副作⽤	每个可校验点⾄少⼀类⽆效情况（格式错误、越权、重复提 交等）；接⼝对应错误码，功能对应校验提⽰。
边界值⽤例设计	在范围、⻓度、数量的 边界附近设计⽤例	提取⽂档中所有有范围/⻓度/数量限制的字段；设计边界 内、边界值、超界、空值、0/负值/极⼤值等。
等价类划分	将输⼊域划类，每类取 代表值，减少冗余	有效等价类取 1〜2 个代表；⽆效等价类按违规类型各取代 表；可与边界值结合。
状态与流程	针对状态机、多步骤流 程设计合法与⾮法迁移	列出状态与允许迁移；设计正向路径、中断/回退、⾮法状 态操作；有⻆⾊时覆盖越权。
场景法 / ⽤⼾场景	以⽤⼾故事串联多模 块，做端到端⽤例	归纳 2〜3 个典型场景；每场景下主流程 + 分⽀；可与正向/ 反向/边界结合。
优先级与类型标记	便于执⾏与排期	核⼼路径与关键校验标 P0；边界与次要异常标 P1/P2；并 标⽤例类型（正向/反向/边界/异常/性能/⾃动化候选）。

输出时，会通过⽤例类型、标题或说明体现上述策略的运⽤，⽅便你评审和补充。 

五、核⼼能⼒⼆：专⽤标准（接⼝ / 功能 / 性能 / ⾃动化） 

通⽤策略解决「⽤什么⽅法想⽤例」；专⽤标准解决「某类测试要覆盖哪些维度、怎么写清楚」。 Skill 通过 references/ 下的四个⽂档来约定，你在对话⾥提到对应类型时，会叠加这些要求。 

5.1 接⼝测试（ api-testcases-standard.md ） 

• 必须覆盖：

  ◦ 请求与参数：正常请求、必填缺失、类型/格式错误、边界值、可选参数不传/传空/传有效值；

  ◦ 响应与错误码：成功响应结构、⽂档中每个错误码⾄少 1 条⽤例、⾮法请求不返回 200；

  ◦ 鉴权与权限：未带鉴权、鉴权⽆效/过期、越权访问；

  ◦ 幂等与并发（若⽂档有）：重复提交、超并发/限流。 

• 表述要求：每条⽤例写清接⼝路径+⽅法、请求关键取值、预期 HTTP 状态码与响应/错误码；数据 依赖在前置或数据要求中说明。 

5.2 功能测试（ functional-testcases-standard.md ） 

• 必须覆盖： 

  ◦ 业务流程与⽤⼾场景：主流程、分⽀与异常流程、端到端场景； 

  ◦ 状态与⻆⾊：合法/⾮法状态迁移、本⻆⾊允许操作与越权； 

  ◦ 界⾯与交互（若适⽤）：必填与校验、多步骤与回退； 

  ◦ 数据与依赖：前置条件写清数据状态，跨模块时说明需校验的关联数据。

• 表述要求：⽤例标题可概括「谁在什么条件下做什么、预期什么」；步骤可执⾏、可验证；预期与 需求/PRD ⼀致且可验收。 

5.3 性能测试（ performance-testcases-standard.md ） 

• 必须覆盖： 

  ◦ 指标与基线：响应时间、吞吐量/QPS、资源与容量（若⽂档有）； 

  ◦ 场景类型：基准、稳态负载、峰值/尖峰、⻓时间稳定性；

  ◦ 瓶颈与退化：阶梯加压、降级与限流（若⽂档有）。 

• 表述要求：场景名称能看出「场景类型 + ⽬标指标」；写清负载定义（并发、QPS、时⻓）、环境 与数据量级、通过标准（如 P99 RT、成功率）；可选观察要点（CPU、内存、错误⽇志等）。 

5.4 ⾃动化候选⽤例（ automation-testcases-standard.md ） 

• 适合⾃动化：稳定可重复、⾼执⾏频率、断⾔明确、接⼝或可脚本化、依赖可构造。 

• 不适合或低优先：强主观/探索性、⼀次性/低频、环境或数据难以⾃动化、变更频繁。

• 输出：在⽤例类型或备注中标注「⾃动化候选」或「建议⾃动化」；可选补充建议实现⽅式、断⾔ 要点、数据与环境要求。 

以上四份⽂档都不规定具体表格列名或排版，只规定覆盖维度和表述要求；列名与排版由你指定的 assets 模板或团队约定决定。

六、如何使⽤：操作步骤

步骤 1：准备⽂档内容 

将需求⽂档、PRD 或接⼝⽂档中需要覆盖测试的部分复制成纯⽂本。若是 Word/PDF/截图，请把关键 内容粘贴到对话中（截图会建议转为⽂字）。

步骤 2：发起请求 

在对话中说清意图并粘贴内容，例如： 

• 「请根据下⾯这份需求⽂档，帮我⽣成测试⽤例。」 然后另起⼀段粘贴⽂档正⽂。 可选地加⼀句： 

• 「重点做接⼝测试」→ 会叠加接⼝标准。 

• 「要包含性能测试」→ 会叠加性能标准。 

• 「标出适合⾃动化的⽤例」→ 会叠加⾃动化标准并做标记。 

• 「按我们公司的 Excel 模板来」/「参考 assets ⾥的 xxx 模板」→ 会按 assets 中对应模板组织 列与结构。

步骤 3：查看与保存 

• 测试⽤例⽂档会直接输出在对话中，你可复制到 Word/Excel/语雀等使⽤。 

• 若需要落盘，说⼀句即可，例如： 

  ◦ 「把这份测试⽤例保存到当前项⽬的 testcases/ ⽂件夹。」 

  ◦ 「保存为 docs/测试⽤例_⽤⼾中⼼需求_20250305.md 。」 

⽆需写脚本；若只给⽬录未给⽂件名，会使⽤默认命名： 测试⽤例_<模块或⽂档简称>_<⽇期 >.md 。 

七、输出与保存的约定 

• 默认：仅输出在对话中，不⾃动写⽂件。

• 保存：只有在你明确要求保存或给出路径时，才会将刚才输出的内容写⼊指定路径；若⽬录不存在 会先创建。 

• 不依赖脚本：保存完全通过对话中的「保存到 xxx」+ 写⼊⼯具完成，⽆需额外脚本。

⼋、Skill 的⽬录结构与可扩展性 

doc-based-testcase-generator/
├── SKILL.md                    # 主说明：触发条件、通用策略、工作流、保存约定
├── references/                 # 各测试类型的「输出要求与设计标准」
│   ├── api-testcases-standard.md
│   ├── performance-testcases-standard.md
│   ├── functional-testcases-standard.md
│   └── automation-testcases-standard.md
├── assets/                     # 你放置 Word/Excel 用例模板的目录
│   └── README.md               # 说明模板放置方式
└── docs/                       # 本文档等说明材料

• references/：可⾃⾏增改。例如增加「安全测试⽤例标准」「兼容性测试标准」等，并在 SKILL.md 中说明何时引⽤。 

• assets/：放⼊你实际使⽤的 .docx、.xlsx 模板；对话中提及「参考某某模板」时，会从此⽬录查 找并按要求组织输出。 

• 格式：Skill 不写死表格列名，列名与排版以 references 的表述要求 + assets 模板为准，便于适配 不同团队规范。 

九、⼩结：给测试⼯程师的⼏点建议 

1. 把⽂档整理成可粘贴的⽂本：这是当前版本下效果最好的⽅式；截图可转为⽂字后再⽤。 

2. 说清侧重点：需要接⼝/性能/⾃动化标记时，在请求⾥提⼀句，会⾃动加载对应标准。 

3. ⽤好模板：把公司或项⽬常⽤的 Word/Excel ⽤例模板放到 assets/ ，⽣成时说明「参考某某模 板」，可减少⼆次整理。 

4. ⽣成后做⼀次⼈⼯评审：AI 按策略和标准覆盖，但业务细节、环境差异仍需你确认；可重点看边界 与异常是否贴合实际、优先级是否合理。 

5. 需要落盘时说⼀句即可：⽆需脚本，直接「保存到 xxx」就能写⼊指定路径。

十、实操过程视频&生成的登录用例文档

实操过程录屏展示:

实操登录测试用例并保存到本地的用例excel:

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​​

​