测试工程师Skill：让 AI 以测试专家身份，帮你把单元、集成、E2E 测试一次补齐
- 角色清晰：它不是通用聊天助手，而是被设定为「软件测试专家」的角色型技能，专门负责单元测试、集成测试、E2E 测试的设计与落地。
- 流程可控：内置 5 阶段交互流程（识别对象 → 制定策略 → 设计用例 → 渐进式生成 → 执行与报告），一次只问一个问题，不会一口气抛出一堆问题。
- 有工程纪律：单元测试覆盖率目标 80% 以上，遵循 AAA 模式与「一测试一职责」，输出测试金字塔与覆盖率报告。
- 能接入工作流：可作为研发工作流的「阶段 6：测试」节点，测试失败时还能把问题反馈回实现阶段或需求阶段。
- 会记住项目背景：优先读取
steering/structure.md、steering/tech.md、steering/product.md等项目内存文件，让测试代码贴合现有架构与技术栈。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 测试工程师Skill |
| 技能英文名 | test-engineer |
| 技能ID | 13453 |
| 角色定位 | 软件测试专家（单元 / 集成 / E2E / 性能 / 安全 / 可访问性 / 视觉回归） |
| 权限范围 | Read、Write、Edit、Bash、Glob、Grep |
它解决什么问题
写业务代码时，测试往往是最容易被压缩的环节：需求紧、排期短、测试用例靠临时想、覆盖率说不清、E2E 脚本维护成本高。结果是「能跑就行」，回归风险被留到上线后暴露。这个技能的价值在于把「测试怎么做」变成一套标准化流程：先确定测什么，再定测试金字塔，再设计正常/异常/UI 状态/可访问性四类用例，最后逐文件生成、逐项执行、输出覆盖率与质量指标。
一键安装的思路与步骤
- 安装前提：需要一个支持「AI 技能（Skill）」机制的环境，通常是能加载技能包、并允许技能调用工具（读文件、写文件、执行命令）的开发环境。本技能声明了 Read / Write / Edit / Bash / Glob / Grep 六项工具权限，因此安装它的环境必须能授权这些能力，否则生成测试文件、执行测试命令都会失败。
- 定位技能：在技能市场或技能库中按技能ID
13453或英文名test-engineer检索，也可以直接用中文名「测试工程师」搜索。具体市场入口与检索方式以官方说明为准。 - 一键安装：在技能详情页点击安装/启用按钮，确认工具权限后即可完成挂载。安装命令、CLI 参数、是否需要登录账号等细节，以官方说明为准，本文不臆造具体命令。
- 验证是否生效：安装后在会话中输入一句带触发词的话，例如「帮我给登录模块写单元测试」「出一份 test plan」「用 TDD 方式实现这个函数」。若技能正常加载，你会看到它输出的会话开始消息「🧪 启动 Test Engineer 代理」，并抛出第一个问题：「请告诉我创建测试的对象是什么」。
- 验证工具权限：让它做一次「读取项目目录结构」的动作（例如列出目录、读取配置文件），确认 Read / Glob / Grep 权限可用；再让它执行一次测试命令，确认 Bash 权限可用。
提示：如果你所在的项目里已有
steering/目录，安装后第一次使用前建议先把structure.md、tech.md、product.md补齐，技能会自动读取它们，生成的测试代码与团队约定一致的概率会明显提高。
该技能的主要功能和特点
1. 三类核心测试明确分工
- 单元测试：对象是单个函数、方法、类；要求快速、独立、确定性；覆盖率目标 80% 以上。
- 集成测试：对象是多个模块、外部 API、数据库；使用真实依赖关系验证协作；覆盖主要集成点。
- E2E 测试：对象是整个应用；验证真实用户场景；覆盖主要用户流程。
- 此外还覆盖性能测试（负载、压力、峰值）、安全测试（漏洞扫描、渗透测试）、可访问性测试（WCAG 合规）、视觉回归测试（UI 变更检测）。
2. 覆盖主流技术栈的框架选型建议
- 前端 JavaScript/TypeScript：Jest、Vitest、React Testing Library、Vue Testing Library、Cypress、Playwright、Puppeteer、Storybook。
- 后端：Node.js 的 Jest / Vitest / Supertest，Python 的 Pytest / unittest / Robot Framework，Java 的 JUnit / Mockito / Spring Test，C# 的 xUnit / NUnit / Moq，Go 的 testing / testify / gomock。
- E2E：Cypress、Playwright、Selenium WebDriver、TestCafe、Nightwatch.js。
- 技能在给出建议时会说明「为什么选它」，例如前端单元测试选 Vitest 是因为快、原生 ESM、与 Jest 兼容。
3. 内置 TDD / BDD / AAA 方法论
TDD 的 Red-Green-Refactor 三步、BDD 的 Given-When-Then 表达、AAA（Arrange-Act-Assert）结构都会直接体现在生成的测试代码里，而不是只停留在口头建议。
4. 测试金字塔与覆盖率目标量化
技能会给出明确的比例建议（例如单元 60%、集成 30%、E2E 10%），并输出覆盖率目标（如单元 85%、集成覆盖主要 API 端点、E2E 覆盖主要流程），执行后给出语句 / 分支 / 函数 / 行四个维度的覆盖率明细，并列出「未覆盖代码」及补充建议。
5. 项目内存对齐（steering 机制）
开始任务前会强制读取 steering/structure.md（架构模式、目录组织、命名约定）、steering/tech.md（技术栈、框架、技术约束）、steering/product.md（业务背景、目标用户、核心功能）。如果存在 EARS 格式的需求文档（docs/requirements/srs/、功能需求、非功能需求、用户故事），也会一并参考，保证测试用例可追溯到需求。测试完成后，它会把测试框架、覆盖率工具、E2E 工具、测试数据策略、CI 集成方式写回 steering/tech.md，形成团队共享记忆。
6. 与研发工作流深度集成
技能明确承担「阶段 6：测试」：开始时用 musubi-workflow next testing 转移到测试阶段，通过后用 musubi-workflow next deployment 流转到部署阶段；失败时用 musubi-workflow feedback testing implementation -r "测试失败：发现bug" 回到实现阶段，或用 musubi-workflow feedback testing requirements -r "发现需求不一致" 回流到需求阶段。这让「测试不通过」变成一条有明确路由的流程，而不是一句口头抱怨。
7. 自然语言驱动的浏览器 E2E
借助 musubi-browser CLI，可以用自然语言直接跑浏览器测试：交互模式操作浏览器；musubi-browser run "打开登录页面，输入用户名，点击登录按钮" 直接执行一段自然语言描述的流程；musubi-browser script ./e2e-tests/login-flow.txt 执行脚本文件；musubi-browser compare expected.png actual.png --threshold 0.95 做截图比对；musubi-browser generate-test --history actions.json --output tests/e2e/login.spec.ts 从操作历史反向生成 Playwright 测试。这一步把「录制—回放」变成了「说人话—生成可维护代码」。
8. 渐进式文件生成，避免一次性输出过大
技能明确要求逐个生成并保存测试文件、每完成一个就报告进度（如「[1/N] 完成」），超过 300 行的大文件要拆分。这既方便用户中途看到成果，也避免上下文溢出导致整体失败。
9. 开箱即用的代码模板
内置 React 组件测试（Vitest + React Testing Library）、自定义 Hook 测试、API 集成测试（Supertest + Prisma）、E2E 测试（Playwright）四类模板，并覆盖正常情况、异常情况、UI 状态、可访问性四组用例。Python 项目推荐用 uv 管理环境（uv venv、uv add --dev pytest pytest-cov pytest-mock、uv run pytest --cov=src --cov-report=html）。
10. 五项测试原则
快速、独立、可重复、自我验证、及时——这五条被写进技能的工作准则，生成的测试天然规避「测试之间互相依赖」「时好时坏的 Flaky Test」。
如何使用该技能？
整体是一套「7 个问题 + 5 个阶段」的对话式流程，一次只问一个问题，回答完才进入下一问。
第 1 步：唤起技能并回答 7 个问题
输入一句带触发词的话（testing、unit tests、integration tests、E2E tests、test cases、test coverage、test automation、test plan、test design、TDD、test-first），技能就会进入角色。你需要依次回答：
- 测试对象是什么（特定功能、模块、新实现代码、现有代码、整个项目）
- 测试类型（单元 / 集成 / E2E / 全部）
- 使用的技术栈（语言、框架）
- 当前使用的测试框架（没有的话由它推荐）
- 当前测试覆盖率（不清楚可跳过）
- 测试目的（缺陷检测 / 防回归 / TDD / 支撑重构）
- 特别想覆盖的用例（边界、错误、性能等）
示例输入：「测试对象是用户认证功能，前端 React + TypeScript，后端 Node.js + Express，目前没有任何测试，目的是防止回归。」
第 2 步：确认测试策略
技能会输出一份策略文档，内容包括测试对象分析（具体到文件路径，例如 src/features/auth/LoginForm.tsx、src/api/routes/auth.routes.ts）、测试金字塔比例、覆盖率目标、推荐框架及理由、分阶段实施计划、测试数据策略（Fixture / Factory / Mock）。你只需要回复「可以」或提出修改。
第 3 步：确认测试用例清单
用例会被拆成四类：正常情况（Happy Path）、异常情况（Error Cases）、UI 状态（加载中禁用按钮、显示加载指示器、输入框禁用）、可访问性（表单标签、aria-live 错误通知、键盘可提交）。集成测试和 E2E 用例会单独列出并编号。这份清单就是后续代码的「验收标准」。
第 4 步：批准并观察渐进式生成
技能会先给出「计划生成的测试文件清单」（通常 10–15 个文件），得到批准后逐个生成并保存，每个文件报告行数与进度。典型结构为 tests/setup.ts、tests/fixtures/users.fixture.ts、tests/utils/testHelpers.ts，加上与源码并置的 *.test.tsx / *.test.ts、tests/integration/*.test.ts、e2e/auth/*.spec.ts。
第 5 步：查看执行结果与覆盖率报告
技能会执行测试并输出结果，例如测试套件 12 个全部通过、45 个用例全部通过、耗时约 8 秒、覆盖率 87.5%（目标 80%），并给出语句 / 分支 / 函数 / 行的覆盖率明细，以及「未覆盖代码」位置（如 useAuth.ts 第 78–82 行的网络超时处理）和补充测试建议。
第 6 步：查看质量指标表与下一步建议
输出会包含测试覆盖率、用例数、平均执行时间、失败测试数、Flaky 测试数等指标，并给出把测试接入 CI/CD（GitHub Actions / GitLab CI）、提高覆盖率、扩展 E2E 流程、进入性能测试阶段的建议。
第 7 步：自动更新项目内存
技能会把本次确定的测试框架、测试类型、覆盖率工具、E2E 工具、测试数据策略、CI 集成方式写入 steering/tech.md（按其文档策略，同时生成对应日文版本）。下次其他角色或你自己再开工时，这些约定已经是「项目记忆」的一部分。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装 / 使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 测试工程师Skill（test-engineer） | 角色型 AI 测试专家 | 测试策略、用例设计、单元/集成/E2E 代码生成、覆盖率报告、工作流阶段集成、项目内存对齐 | 通过技能市场按ID或名称安装，需授权读写与命令执行权限；使用为对话式问答 | 需要从 0 到 1 建立测试体系，或给遗留代码补测试 | 优势：有方法论（TDD/BDD/AAA）、有量化目标、有失败回流机制；不足：需要认真回答 7 个问题，无法「一句话出全部测试」 |
| 通用 AI 编程助手（IDE 内对话） | 通用编码助手 | 代码补全、解释、临时生成测试片段 | 安装 IDE 插件即可，门槛低 | 临时补一两个小函数测试 | 优势：随手可用；不足：缺少测试策略与金字塔规划，覆盖率和用例分类容易缺失，不会自动写项目记忆 |
| 传统测试框架手写（Jest / Pytest / Playwright 等） | 底层工具库 | 提供断言、运行器、覆盖率、浏览器自动化 | 需自行搭环境、配置、编写 | 长期工程化项目 | 优势：完全可控、生态成熟；不足：设计与编写成本全在人工，用例分类、边界条件容易遗漏 |
| 录制回放型 E2E 工具 | 低代码自动化测试 | 录制用户操作自动生成脚本 | 门槛低，但脚本易碎、维护成本高 | 稳定的核心流程冒烟测试 | 优势：非技术同学也能上手；不足：脚本与页面强耦合，重构后大面积失效，缺少单元/集成层配套 |
选择建议：如果你只是想让 AI 帮你补一个小函数的测试，通用助手的成本最低；如果你想建立一套「有策略、有分层、有覆盖率、有回流」的测试体系，或用自然语言驱动 E2E，本技能更合适。两者的价格、额度与授权方式以官方说明为准。
该技能的典型应用场景与实际体验情况
场景一：新项目从零建立测试体系（技术负责人视角）
痛点：项目刚起步，所有人都默认「先写功能、测试以后补」，结果测试永远排在最后。
使用方式：把整个项目作为测试对象，测试类型选「全部」，技术栈说明前后端语言与框架，覆盖率留空，测试目的选「防止回归」。技能会先给出测试金字塔比例和各层框架选型理由，再分层产出用例与代码。
实际体验：最有价值的是「先定策略再写代码」这一步，避免了上来就堆一堆零散测试。需要注意的是，7 个问题必须认真回答，尤其是「测试对象」要尽量给到具体模块名甚至文件路径，回答越模糊，策略越泛。
场景二：后端 API 集成测试补齐（后端工程师视角）
痛点：接口靠 Postman 手测，参数校验、401/403/400 分支到底有没有覆盖说不清。
使用方式：指定测试对象为「认证 API」，类型选「集成」，说明 Node.js + Express + Prisma。技能会输出端点级用例，例如「正确凭据返回令牌」「错误密码返回 401」「不存在用户返回 401」「无效邮箱格式返回 400」「密码过短返回 400」「无令牌访问返回 401」「无效令牌返回 403」「过期令牌返回 403」。
实际体验：用例清单本身就是一份接口验收文档，评审时可以直接拿它对齐。注意集成测试会用到真实数据库，务必确认测试库与开发库隔离，技能的建议里也是用独立测试数据库并在用例前后做清理。
场景三：用自然语言跑 E2E 并反向生成脚本（测试 / 前端视角）
痛点：E2E 脚本写了三个月，改一次页面选择器就大面积红，维护成本高得让人放弃。
使用方式：先用 musubi-browser 的交互模式手动走一遍流程，保存操作历史；再用 musubi-browser generate-test --history actions.json --output tests/e2e/login.spec.ts 生成 Playwright 代码；视觉变更用 musubi-browser compare 做截图比对，阈值设为 0.95。
实际体验：上手门槛非常低，「打开登录页面，输入用户名，点击登录按钮」这种描述就能跑，适合快速验证主流程。注意生成的脚本仍要人工 Review 选择器稳定性，截图比对阈值也要按页面波动程度调整，否则容易出现误报。
场景四：遗留项目补测试并沉淀团队规范（团队协作视角）
痛点：老代码没有测试，没人敢重构；不同人写的测试风格各异，没有统一约定。
使用方式：先让技能读取 steering/ 下的三个文件了解架构与技术约束，再针对核心模块分批补测试；完成后技能会把测试框架、覆盖率阈值、E2E 工具、Mock 策略、CI 集成方式写回 steering/tech.md。
实际体验：这是长期收益最大的一种用法——测试代码风格与项目约定一致，而不是「AI 味」的另一套写法。注意如果项目里还没有 steering 文件，技能会建议你先初始化项目内存，建议照做，否则对齐效果会打折。
该技能能为用户带来的价值
效率层面：把一个模块从「没有测试」推进到「用例齐全、覆盖率达标、报告可读」，传统方式往往需要半天到一天，且在写用例、搭环境、调试断言之间反复切换。技能把这条链路压缩成一次结构化对话，测试文件逐个生成、执行结果直接给出覆盖率明细。
质量层面：通过强制区分正常 / 异常 / UI 状态 / 可访问性四类用例，把最容易漏的边界条件和错误分支显式化；通过「一测试一职责」「无测试间依赖」「确定性」等准则，从源头减少 Flaky Test；通过 80% 覆盖率目标与四维覆盖率明细，让「测试写得好不好」从主观感受变成可核对的数字。
门槛层面：不需要你先成为 Playwright 专家或 Pytest 专家。框架选择、目录组织、命名约定、Mock 策略、夹具与工厂模式，技能都会给出带理由的推荐；E2E 甚至可以先用自然语言跑通，再反向生成可维护代码。
流程层面：作为研发工作流的阶段 6，它让测试拥有明确的入口（next testing）和出口（next deployment），失败时还能精确回流到实现或需求环节，而不是笼统地「打回去重做」。项目内存回写机制则让这份规范沉淀下来，成为团队资产而非一次性输出。
长期价值：测试代码是重构的前提。有了可回归的测试网，团队才敢做技术债清理、框架升级、模块拆分这些高收益高风险的动作。
常见问题 FAQ
Q1：这个技能怎么安装？需要提前准备什么？
在支持 AI 技能机制的环境中，按技能ID 13453 或英文名 test-engineer 检索并一键启用即可。安装前需确认环境能授予 Read / Write / Edit / Bash / Glob / Grep 六项权限，否则无法生成测试文件与执行测试命令。具体安装入口、命令与授权方式以官方说明为准。安装后输入「帮我写单元测试」这类触发语，看到「🧪 启动 Test Engineer 代理」即表示生效。
Q2：这个技能是收费的吗？
技能本身的功能范围以其官方说明为准，本文不提供价格信息。建议在技能详情页查看授权与计费说明。需要注意的是，它生成的测试会用到项目里的测试框架（如 Jest、Vitest、Pytest、Playwright），这些开源框架本身不需要额外付费，但 CI 运行时长等基础设施成本需要你自行评估。
Q3：它适合谁用？前端还是后端？
适合三类人：一是需要从零搭建测试体系的技术负责人；二是要给接口补集成测试、给组件补单元测试的开发工程师；三是负责 E2E 与回归验证的测试工程师。技术栈上它覆盖前端（JS/TS + React/Vue 生态）、后端（Node.js、Python、Java、C#、Go）和 E2E（Cypress、Playwright、Selenium、TestCafe、Nightwatch.js），不存在只能用于某一端的问题。
Q4：它会不会不问清楚就一口气生成一堆测试文件？
不会。技能明确要求「一次只问一个问题」并等待回答，共 7 个问题；之后先给测试策略让你确认，再给用例清单让你确认，再给文件清单让你确认，最后才逐个生成并报告进度。如果你希望更快，可以在回答时一次性把测试对象、技术栈、测试类型说清楚，减少来回轮次。
Q5：和直接用 IDE 里的 AI 助手写测试相比，差别在哪？
差别主要在「有没有方法论和闭环」。通用助手擅长补一段测试代码，但很少会先给你测试金字塔比例、覆盖率目标、用例分类和 CI 集成方案，也不会把结论写回项目记忆，更不会在测试失败时把问题精确回流到实现或需求阶段。如果你只是补一个小函数，通用助手更快；如果你要建体系、控覆盖率、做长期维护，本技能更合适。