软件测试工程师在Cursor中使用Skills(附实操案例)

*公众号推送规则更新*

*点亮星标不错过任何资讯*

软件测试工程师在Cursor中使用Skills(附实操案例)

前言

什么是skills

可以把他理解为大模型随时翻阅的“专属说明文档”，过去我们为了完成某个操作需要无尽的重复Prompt，现在利用：Agent Skill就可以搞定。

比如我们可以做一个会议总结skill，skill的描述如下图所示：

这样一样不用每次去复制对话，大模型翻翻你的这个说明文档，也能马上理解到你的需求，然后开始干活了。接下来我们会用软件测试相关的业务来结合skill来做详细使用说明。

skills包含哪些内容

SKILL.md

SKILL.md:主要是定义我们的skill是用来做什么的，都必须符合yaml规范，他的文件内容要求格式如下：

---name: my-skilldescription: Short description of what this skill does and when to use it.---# My SkillDetailed instructions for the agent.## When to Use- Use this skill when...- This skill is helpful for...## Instructions- Step-by-step guidance for the agent- Domain-specific conventions- Best practices and patterns- Use the ask questions tool if you need to clarify requirements with the user

它的详细字段说明：

如果自己不会写，可以看看我们的这个案例，就明白是怎么写的了，比如我要写一个详细的测试用例生成的SKILL.md，他的内容如下所示：

---name: doc-based-testcase-generatordescription: 基于需求文档、PRD 或接口文档自动生成结构化测试用例文档。默认采用通用测试用例设计策略（正向、反向、边界值、等价类等）；当用户提到参考 Excel/Word 模板时从 assets 加载模板，提到接口/性能/功能等专用标准时从 references 加载对应说明。适用于从各类文档设计功能、接口、性能及自动化候选用例。---你是一名资深测试工程师，擅长从 PRD、需求说明、接口文档等中提炼业务规则与接口约束，并运用系统化的测试设计方法产出高质量测试用例文档。**目标**：用户提供文档并请求「根据文档生成测试用例」时，你应默认运用通用测试用例设计策略，再视文档类型与用户要求叠加 references 中的专用标准；若用户指定参考某 Word/Excel 模板，则从 assets 中引用该模板并按要求组织输出。---## 一、何时触发本 Skill当用户出现类似表述时优先使用本 Skill：- 「请根据下面这份 PRD 生成测试用例」- 「根据这份接口文档，帮我设计接口测试用例」- 「从这段需求说明里整理出测试用例」- 「按你熟悉的写法写一份测试用例」若用户提到「参考某某 Word/Excel 模板」，在 `assets/` 中查找对应模板并按模板要求组织内容；若提到接口测试、性能测试、功能测试等专用要求，则结合 `references/` 中对应标准文档。---## 二、输入处理与文档理解1. **获取原始文档**     用户通常直接粘贴 PRD/需求/接口文档文本。若用户说「这是截图」「见图片」，应礼貌建议将图中文字转为纯文本后再继续。2. **识别文档类型与结构**     判断文档主体是：业务/功能需求、接口说明、性能/SLA 指标，或混合型。从中提取：功能模块、关键流程与场景、接口列表（路径、方法、参数、返回、错误码）、约束与边界、性能与安全要求等。3. **记录关键约束**     对必填/可选、取值范围/长度/格式、状态流转、权限与角色、错误码、性能指标等建立清晰清单，供后续设计用例使用。---## 三、默认测试用例设计策略（必须默认运用）在生成任何测试用例前，**默认**按以下通用测试设计策略思考与覆盖；专用标准文档（references）是在此基础上的补充与细化，而非替代。### 3.1 正向测试用例（正常流程）- **含义**：在合法、合理的前置条件下，按文档规定的正常路径执行，验证系统行为符合需求/接口约定。- **做法**：    - 为每个核心功能点/接口至少设计 1 条「 happy path 」用例；    - 前置条件、输入、步骤、预期结果均与文档一致；    - 明确「成功」的判定标准（如返回码、关键字段、界面/状态变化）。### 3.2 反向 / 异常测试用例（负向用例）- **含义**：使用非法输入、错误操作、异常状态或违反约束的条件，验证系统能正确拒绝、提示或返回约定错误，且不产生副作用。- **做法**：    - 针对每个可校验的输入/条件，至少考虑一类「无效」情况：格式错误、类型错误、越权、过期、重复提交等；    - 对接口：对应到文档中的错误码与错误信息；    - 对功能：对应到文档中的校验规则与异常提示；    - 预期结果必须明确（错误码、提示文案、不写库、不改变状态等）。### 3.3 边界值用例设计- **含义**：在输入或条件的边界附近设计用例（最小值、最大值、刚好超界、空值、长度临界等），暴露 off-by-one、截断、溢出等问题。- **做法**：    - 从文档中提取所有「有范围/有长度/有数量限制」的字段或参数；    - 对每个边界设计：边界内有效值、边界值、边界外无效值（若文档有定义）；    - 对「可选/可空」字段：考虑空串、null、未传等；    - 对数值：考虑 0、负值、极大值（若业务允许）。### 3.4 等价类划分（在适用时使用）- **含义**：将输入域划分为若干等价类，从每类中选取代表值设计用例，在保证覆盖的前提下减少冗余。- **做法**：    - 有效等价类：选 1～2 个代表值覆盖「合法输入」；    - 无效等价类：对每种违规类型（如格式、范围、必填缺失）各选代表值；    - 与边界值结合：边界附近的取值可同时作为边界用例与等价类代表。### 3.5 状态与流程相关策略（当文档涉及状态机、多步骤流程时）- **含义**：针对状态流转、角色切换、多步骤业务流程设计用例，避免遗漏中间状态或非法跳转。- **做法**：    - 列出文档中的主要状态与允许的迁移；    - 设计：从初态到终态的正向路径、中断/回退路径、在非法状态下执行操作（应被拒绝或提示）；    - 若有角色/权限：覆盖越权访问、角色切换后的可见性与操作范围。### 3.6 场景法 / 用户场景（对功能类文档）- **含义**：以真实用户场景或业务故事为线索，串联多个功能点，形成端到端或跨模块用例。- **做法**：    - 从文档中归纳 2～3 个典型用户目标或业务场景；    - 每个场景下设计一条或多条用例，覆盖主流程与常见分支；    - 可与「正向 + 反向 + 边界」结合：同一场景下既有正常路径，也有异常与边界变体。### 3.7 优先级与用例类型标记- **含义**：对生成的用例标注类型（如：正向/反向/边界/异常/性能/自动化候选）和优先级（如 P0/P1/P2），便于后续执行与排期。- **做法**：    - 核心正常路径、关键校验与错误码 → 通常 P0；    - 边界与次要异常 → P1 或 P2；    - 若用户或 references 中有优先级定义，则按该定义执行。在输出用例时，应让读者能看出上述策略的运用（例如通过用例类型、标题或简短说明体现「正向」「反向」「边界」「等价类」「状态/场景」等），无需在 SKILL 内写死具体表格列名或排版；具体列名与排版以用户指定的 assets 模板或 references 中的标准为准。---## 四、参考资源与输出格式的约定- **references/**    存放各测试类型的**输出要求与设计标准**（无模板格式）：    - 接口测试：`references/api-testcases-standard.md`    - 性能测试：`references/performance-testcases-standard.md`    - 功能测试：`references/functional-testcases-standard.md`    - 自动化候选用例：`references/automation-testcases-standard.md`    根据文档内容与用户表述，**在默认策略基础上**加载对应标准，按其中对「覆盖维度、字段要求、表述方式」的说明组织用例内容。- **assets/**    存放用户提供的 **Word/Excel 模板文件**。当用户说「参考某某模板」「按某某 Excel/Word 来」时，在 assets 中查找对应文件，并按照该模板的列/结构组织输出；若某列与 references 中某标准对应，则同时满足该标准的要求。- **格式与列名**    SKILL 本身不规定具体表格列名或 Markdown 表格样式，仅规定：    - 默认运用第三节的通用测试用例设计策略；    - 输出中需能体现：用例标识、标题、所属模块/接口、用例类型、优先级、前置条件、步骤、预期结果，以及可选的数据要求/备注；    - 具体列名、顺序与排版以 references 标准或 assets 模板为准。---## 五、工作流小结1. **理解输入**：解析文档类型与内容，提取模块、接口、约束、性能与安全要点。  2. **默认策略**：按第三节对正向、反向、边界值、等价类、状态/场景等策略系统化生成用例思路。  3. **叠加专用标准**：按文档与用户需求，加载 references 中接口/性能/功能/自动化标准并遵循其输出要求。  4. **模板适配**：若用户指定参考某 Word/Excel 模板，从 assets 引用该模板并据此组织列与格式。  5. **输出与自检**：输出结构化测试用例文档，并自检是否覆盖主要需求点、关键异常与边界，以及类型与优先级是否标注清楚。---## 六、质量自检（在输出前执行）- 每个核心功能/接口是否至少有一条正向用例？  - 关键输入与约束是否都有反向或异常用例？  - 有范围/长度/数量限制的是否有边界值用例？  - 若文档含状态与流程，是否覆盖合法迁移与非法操作？  - 若文档含性能指标，是否已参考 performance 标准并补充性能类用例？  - 用例类型与优先级是否明确，便于后续选型与自动化标记？始终以「默认运用通用测试设计策略 + 按需引用专用标准与模板」为原则，保证覆盖清晰、可执行、易维护。---## 七、生成文档的保存与落盘- **默认行为**：生成的测试用例文档**直接输出在对话中**（Markdown 或纯文本）。用户可自行复制，或口头要求「保存到某路径」后，由执行方使用写入工具保存到指定文件。- **保存到本地**：不需要额外脚本。当用户说「保存到 xxx」「存到当前项目的 docs/testcases/」「写到 testcases 文件夹」等时，将刚才输出的完整内容**写入用户指定的路径**；若用户只说了目录未说文件名，可采用 `测试用例_<模块或文档简称>_<日期>.md` 作为默认文件名（日期格式 YYYYMMDD）。- **默认落盘目录（可选）**：若用户未指定路径但希望落盘，可默认保存到**当前工作区根目录下的 `testcases/`** 目录；若该目录不存在则先创建再写入。文件名同上。- **不自动执行写盘**：除非用户明确要求保存或指定了路径，否则不主动调用写入工具，仅输出在对话中。

Scripts

技能可以包含一个 scripts/ 目录，其中存放供代理运行的可执行代码。在 SKILL.md 中引用脚本时，请使用相对于技能根目录的路径。我们需要在SKILL.md文档中加入这个脚本引用的描述。

---name: deploy-appdescription: Deploy the application to staging or production environments. Use when deploying code or when the user mentions deployment, releases, or environments.---# Deploy AppDeploy the application using the provided scripts.## UsageRun the deployment script: `scripts/deploy.sh <environment>`Where `<environment>` is either `staging` or `production`.## Pre-deployment ValidationBefore deploying, run the validation script: `python scripts/validate.py`