claude-howto 测试工程师 Subagent 实战指南基于 test-engineer.md 构建全面测试覆盖【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto本文以 claude-howto 仓库中日文版 Subagent 定义文件 ja/04-subagents/test-engineer.md 为骨架围绕「测试工程师子代理」的角色定位、调用流程、测试策略、覆盖率标准、输出格式与测试结构示例展开并结合本仓库真实的 Python 测试基础设施pytest 配置、fixture、构建工具测试用例进行源码级深化。读完本文你将掌握如何为一个 Claude Code 项目编写可复用的测试工程师 Subagent、如何设定合理的覆盖率门槛以及如何将其与仓库既有的 pytest 测试体系衔接落地。一、Test Engineer Agent 是什么在 Claude Code 中Subagent 是拥有独立上下文窗口、独立系统提示词与受控工具集的专用 AI 助手。claude-howto 仓库在 04-subagents/ 目录下提供了 9 个开箱即用的示例子代理其中Test Engineer测试工程师承担的是「编写全面测试、分析覆盖率、验证测试通过」的专职角色。其完整定义位于英文原文 04-subagents/test-engineer.md 及其日语翻译 ja/04-subagents/test-engineer.md。该 Subagent 的核心元数据frontmatter如下--- name: test-engineer description: Test automation expert for writing comprehensive tests. Use PROACTIVELY when new features are implemented or code is modified. tools: Read, Write, Bash, Grep model: inherit ---三个关键字段的含义name唯一标识符使用小写字母与连字符description自然语言描述「何时应被调用」。这里特意写入了Use PROACTIVELY根据 04-subagents/README.md 的说明这是促使 Claude 在新功能实现或代码修改后主动委派该子代理的关键措辞——当任务描述命中该说明时主代理会优先把测试工作交给它tools限定为Read, Write, Bash, Grep四个工具——既能读代码、写测试、跑命令又不至于放开不必要的权限model: inherit继承父会话的模型避免额外指定模型带来的开销与不一致。作为对比同目录下的 04-subagents/code-reviewer.md 只有Read, Grep, Glob, Bash无 Write专注分析不落盘而 04-subagents/implementation-agent.md 则有Read, Write, Edit, Bash, Grep, Glob含 Edit具备完整修改能力。Test Engineer 处于两者之间能写测试文件但不具备随意编辑业务代码的全部权限这种工具边界本身就是 04-subagents/README.md 所倡导的「从限制开始、按需扩展」权限策略的体现。二、调用流程被调用时的四个步骤Test Engineer 的系统提示词明确了被调用后的工作顺序分析需要测试的代码分析テストが必要なコード——先读代码弄清被测对象的输入输出与行为识别关键路径和边界情况クリティカルパスとエッジケースを特定する——找出认证、支付、数据处理等高风险路径以及空值、边界条件等易错点按项目规范编写测试プロジェクトの規約に従ってテストを書く——必须沿用项目既有的测试框架与命名约定而不是另起炉灶运行测试验证通过テストを実行して通ることを検証する——写完不算完必须实际执行测试并确认全部通过。这一「分析 → 识别 → 编写 → 验证」的闭环正是仓库自身测试工作流的缩影claude-howto 的 Python 测试全部集中在 scripts/tests/ 目录并由 scripts/pyproject.toml 统一驱动[tool.pytest.ini_options] testpaths [scripts/tests] asyncio_mode auto asyncio_default_fixture_loop_scope function python_files [test_*.py] python_functions [test_*] addopts -v从这段配置可以推断仓库的测试约定是测试文件必须以test_*.py命名如test_build_epub.py、test_build_website.py、test_check_cross_references.py、test_check_markdown_rendering.py测试函数必须以test_*开头测试目录固定在scripts/tests默认启用asyncio_mode auto说明其中存在异步测试用例addopts -v让测试输出保持详细模式便于在 CI 与本地同时观察进度。当 Test Engineer 被委派到这样一个项目时「按项目规范编写测试」就具体化为在 scripts/tests/ 下新增test_xxx.py使用 pytest 编写test_*函数而不是在项目里引入一套新的测试框架。三、测试策略五层覆盖模型Test Engineer 的测试策略定义了五个递进的层次这也是它判断「测试是否全面」的思维框架层次测试类型关注点1单元测试单个函数/方法在隔离环境下的正确性2集成测试组件之间的交互行为3端到端测试完整工作流的端到端正确性4边界情况边界条件、null 值、空集合5错误场景失败处理、非法输入这五层在 claude-howto 仓库中都能找到真实对应物单元测试如 scripts/tests/test_build_website.py 中TestHeadingToAnchor对heading_to_anchor的逐项断言Hello World → hello-world、标点剥离、Unicode 保留、emoji 剔除边界情况同一文件里TestDisambiguateUrl的test_case_insensitive_collision_disambiguated专门验证INDEX.md与README.md在大小写不敏感文件系统上映射到index.html时产生的冲突会被加后缀消解——这正是典型的边界条件用例错误场景TestVendorAssets::test_download_rejects_non_http_scheme用pytest.raises(ValueError, matchnon-HTTP URL)验证下载助手会拒绝file://等非 HTTP 协议属于对非法输入防御逻辑的针对性测试端到端测试TestBuildWebsite::test_smoke_build从build_website(config, logger, skip_vendorTrue)出发断言生成的index.html、文件夹索引、Mermaid 代码块转义、CDN 引用清零等多项产出相当于一次完整的构建冒烟测试。Test Engineer 正是依据这套五层模型来决定「测什么、测多深」从而避免只写「快乐路径」测试而漏掉边界与异常。四、测试要求五条硬性规范Test Engineer 编写测试时必须遵守以下要求使用项目既有测试框架Jest、pytest 等——不要为项目引入新框架保持技术栈一致每个测试都包含 setup/teardown——保证测试之间的隔离与可重复执行Mock 外部依赖——将网络请求、文件系统、第三方服务等外部依赖隔离让测试快速且确定用清晰描述说明测试目的——让每个测试用例的意图可读、可维护、可审查相关场景加入性能断言——当测试涉及性能敏感路径时对耗时或资源消耗设置断言。这些要求同样可以在仓库测试代码中找到印证。例如 scripts/tests/conftest.py 集中定义了共享 fixturepytest.fixture def tmp_project(tmp_path: Path) - Path: Create a minimal project structure for testing. readme tmp_path / README.md readme.write_text(# Test Project\n\nThis is a test.) # 创建章节目录、普通章节文件…… return tmp_pathSetup 的体现pytest.fixture装饰器在测试执行前自动构造被测环境生成最小目录树、用 PIL 生成测试用 PNG Logo这就是「每个测试自带 setup」的标准姿势Teardown 的体现tmp_path是 pytest 内置的临时目录 fixture测试结束自动清理无需手工删除外部依赖 Mock 的体现TestBuildWebsite用skip_vendorTrue跳过真实联网下载 Tailwind 与 Mermaid 资源的步骤只用本地 fixture 树完成渲染验证这正是「Mock 外部依赖」在构建类工具测试中的典型手法清晰描述仓库中大量使用docstring与test_语义化命名如test_internal_markdown_link_rewritten、test_anchor_preserved测试意图一目了然。五、覆盖率要求80% 底线与关键路径 100%Test Engineer 对覆盖率有明确的量化标准代码覆盖率最低 80%——这是全局底线关键路径认证、支付、数据处理要求 100%——高风险路径不允许存在未覆盖分支报告缺失的覆盖区域——测试交付时需明确指出哪些区域尚未覆盖为后续补测提供依据。需要说明的是80% 与 100% 是 Subagent 系统提示词中面向通用项目设定的默认阈值实际落地时应结合项目现状调整。claude-howto 仓库虽然没有在配置中写死覆盖率门槛但 scripts/pyproject.toml 中可以看到完整的质量工具链配套——RuffE/W/F/I/B/C4/UP/SIM/TCH/RUF/PTH/PL/PERF全量 lint 规则、Mypypython_version 3.11、Bandit安全扫描exclude_dirs [scripts/tests, ...]说明仓库对测试与静态检查是一视同仁纳入开发流程的。覆盖率评估的工作流还可参考仓库内的 01-slash-commands/unit-test-expand.md「扩展单元测试」斜杠命令它与 Test Engineer 形成互补分析覆盖率运行覆盖率报告定位未测试分支、边界情况与低覆盖区域识别缺口审查逻辑分支、错误路径、边界条件、null/空输入按项目框架写测试Jest/Vitest/MochaJS/TS、pytest/unittestPython、Go testing/testifyGo、Rust 内置测试框架Rust瞄准特定场景错误处理与异常、边界值min/max/empty/null、角角落落的极端情形、状态转移与副作用验证提升再次运行覆盖率确认可度量的提升。该命令还强调「只输出新的测试代码块遵循既有测试模式与命名约定」——与 Test Engineer 的「按项目规范编写测试」如出一辙两者可以串联使用先由 Test Engineer 搭建测试骨架再借助unit-test-expand持续补漏。六、测试输出格式每次交付的四个字段Test Engineer 每创建一个测试文件都必须按固定格式汇报保证结果可审计、可追踪File测试文件的路径让主代理与用户能定位到具体文件Tests测试用例的数量衡量交付规模Coverage预计覆盖率提升量化本次贡献Critical Paths覆盖了哪些关键路径确认高风险区域是否已覆盖。这种结构化输出与 Subagent 的工作机制完全吻合Subagent 运行在独立上下文窗口中最终只把蒸馏后的结果返回给主代理参见 04-subagents/README.md 中的架构图。因此输出格式越紧凑、字段越明确主代理整合信息、向用户汇报的成本就越低。七、测试结构示例Jest 风格的标准模板原文档给出了一个可直接复制的测试结构模板Jest 风格这是 Test Engineer 编写单元测试时的标准骨架describe(Feature: User Authentication, () { beforeEach(() { // Setup }); afterEach(() { // Cleanup }); it(should authenticate valid credentials, async () { // Arrange // Act // Assert }); it(should reject invalid credentials, async () { // Test error case }); it(should handle edge case: empty password, async () { // Test edge case }); });该模板的三个设计要点值得注意beforeEach/afterEach成对出现——对应「每个测试都要包含 setup/teardown」的要求一个it只验证一个行为——合法凭证、非法凭证、空密码三种场景拆成三个独立用例恰好覆盖了「快乐路径 错误场景 边界情况」注释锚点Arrange / Act / Assert——引导测试编写者遵循 AAA 结构让测试既好写也好读。在 Python 项目中同样的结构对应 pytest 的写法这也是仓库 scripts/tests/ 目录中大量存在的形态class TestAuthentication: def setup_method(self): # Setup或以 conftest.py 中的 fixture 替代 pass def teardown_method(self): # Cleanup pass async def test_authenticate_valid_credentials(self): # Arrange / Act / Assert pass def test_reject_invalid_credentials(self): # Test error case pass def test_handle_edge_case_empty_password(self): # Test edge case pass八、在 claude-howto 中的落地实践8.1 安装方式Test Engineer 属于示例 Subagent可通过以下任一方式部署详见 04-subagents/README.md方式一让 Claude 生成推荐Create a project-level subagent that runs tests and fixes failures. Give it access to Bash, Read, Edit, and Grep.方式二复制到项目目录使其仅对当前项目生效mkdir -p .claude/agents cp /path/to/04-subagents/test-engineer.md .claude/agents/方式三复制到用户目录使其对所有项目生效mkdir -p ~/.claude/agents cp /path/to/04-subagents/test-engineer.md ~/.claude/agents/8.2 与仓库测试体系的衔接部署后在 claude-howto 项目中可以这样使用它 Use the test-engineer subagent to add coverage for scripts/build_website.py Ask the test-engineer subagent to verify the new tests pass此时 Test Engineer 会用Grep/Read分析 scripts/build_website.py 与既有测试 scripts/tests/test_build_website.py识别出heading_to_anchor、relative_link、rewrite_links、replace_mermaid_blocks等纯函数的关键路径与边界大小写冲突、emoji、空目录、重复标题等遵循 pytest 约定在 scripts/tests/ 下新增test_*.py运行pytest可配合覆盖率工具验证全部通过并按「File / Tests / Coverage / Critical Paths」四字段汇报。8.3 组合使用建议Test Engineer 与仓库中的其他能力可以协同工作与 01-slash-commands/unit-test-expand.md 组合先由 Test Engineer 建立测试基线再用unit-test-expand持续针对未覆盖分支补测与 04-subagents/code-reviewer.md 组合Code Reviewer 负责「分析测试覆盖缺口」其职责之一就是 test coverage analysis见 04-subagents/README.mdTest Engineer 负责「落地补写」形成分析→执行的闭环与 06-hooks/pre-commit.sh 等钩子组合将测试运行接入提交前检查把覆盖率门槛固化到工作流中避免测试漂移。九、小结test-engineerSubagent 的价值在于把「写测试」这件事标准化、自动化、可量化它以五层测试策略决定覆盖范围以五条硬性要求保证测试质量以 80%/100% 的覆盖率标准设定量化底线以四字段输出格式保证结果可审计并以「分析 → 识别 → 编写 → 验证」的闭环确保交付物真实可用。在 claude-howto 仓库中这套方法论与 scripts/tests/ 目录下的 pytest 测试体系、scripts/pyproject.toml 的测试配置以及 01-slash-commands/unit-test-expand.md 的补测命令相互印证、无缝衔接是构建可持续测试文化的落地范本。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
claude-howto 测试工程师 Subagent 实战指南：基于 test-engineer.md 构建全面测试覆盖
claude-howto 测试工程师 Subagent 实战指南基于 test-engineer.md 构建全面测试覆盖【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto本文以 claude-howto 仓库中日文版 Subagent 定义文件 ja/04-subagents/test-engineer.md 为骨架围绕「测试工程师子代理」的角色定位、调用流程、测试策略、覆盖率标准、输出格式与测试结构示例展开并结合本仓库真实的 Python 测试基础设施pytest 配置、fixture、构建工具测试用例进行源码级深化。读完本文你将掌握如何为一个 Claude Code 项目编写可复用的测试工程师 Subagent、如何设定合理的覆盖率门槛以及如何将其与仓库既有的 pytest 测试体系衔接落地。一、Test Engineer Agent 是什么在 Claude Code 中Subagent 是拥有独立上下文窗口、独立系统提示词与受控工具集的专用 AI 助手。claude-howto 仓库在 04-subagents/ 目录下提供了 9 个开箱即用的示例子代理其中Test Engineer测试工程师承担的是「编写全面测试、分析覆盖率、验证测试通过」的专职角色。其完整定义位于英文原文 04-subagents/test-engineer.md 及其日语翻译 ja/04-subagents/test-engineer.md。该 Subagent 的核心元数据frontmatter如下--- name: test-engineer description: Test automation expert for writing comprehensive tests. Use PROACTIVELY when new features are implemented or code is modified. tools: Read, Write, Bash, Grep model: inherit ---三个关键字段的含义name唯一标识符使用小写字母与连字符description自然语言描述「何时应被调用」。这里特意写入了Use PROACTIVELY根据 04-subagents/README.md 的说明这是促使 Claude 在新功能实现或代码修改后主动委派该子代理的关键措辞——当任务描述命中该说明时主代理会优先把测试工作交给它tools限定为Read, Write, Bash, Grep四个工具——既能读代码、写测试、跑命令又不至于放开不必要的权限model: inherit继承父会话的模型避免额外指定模型带来的开销与不一致。作为对比同目录下的 04-subagents/code-reviewer.md 只有Read, Grep, Glob, Bash无 Write专注分析不落盘而 04-subagents/implementation-agent.md 则有Read, Write, Edit, Bash, Grep, Glob含 Edit具备完整修改能力。Test Engineer 处于两者之间能写测试文件但不具备随意编辑业务代码的全部权限这种工具边界本身就是 04-subagents/README.md 所倡导的「从限制开始、按需扩展」权限策略的体现。二、调用流程被调用时的四个步骤Test Engineer 的系统提示词明确了被调用后的工作顺序分析需要测试的代码分析テストが必要なコード——先读代码弄清被测对象的输入输出与行为识别关键路径和边界情况クリティカルパスとエッジケースを特定する——找出认证、支付、数据处理等高风险路径以及空值、边界条件等易错点按项目规范编写测试プロジェクトの規約に従ってテストを書く——必须沿用项目既有的测试框架与命名约定而不是另起炉灶运行测试验证通过テストを実行して通ることを検証する——写完不算完必须实际执行测试并确认全部通过。这一「分析 → 识别 → 编写 → 验证」的闭环正是仓库自身测试工作流的缩影claude-howto 的 Python 测试全部集中在 scripts/tests/ 目录并由 scripts/pyproject.toml 统一驱动[tool.pytest.ini_options] testpaths [scripts/tests] asyncio_mode auto asyncio_default_fixture_loop_scope function python_files [test_*.py] python_functions [test_*] addopts -v从这段配置可以推断仓库的测试约定是测试文件必须以test_*.py命名如test_build_epub.py、test_build_website.py、test_check_cross_references.py、test_check_markdown_rendering.py测试函数必须以test_*开头测试目录固定在scripts/tests默认启用asyncio_mode auto说明其中存在异步测试用例addopts -v让测试输出保持详细模式便于在 CI 与本地同时观察进度。当 Test Engineer 被委派到这样一个项目时「按项目规范编写测试」就具体化为在 scripts/tests/ 下新增test_xxx.py使用 pytest 编写test_*函数而不是在项目里引入一套新的测试框架。三、测试策略五层覆盖模型Test Engineer 的测试策略定义了五个递进的层次这也是它判断「测试是否全面」的思维框架层次测试类型关注点1单元测试单个函数/方法在隔离环境下的正确性2集成测试组件之间的交互行为3端到端测试完整工作流的端到端正确性4边界情况边界条件、null 值、空集合5错误场景失败处理、非法输入这五层在 claude-howto 仓库中都能找到真实对应物单元测试如 scripts/tests/test_build_website.py 中TestHeadingToAnchor对heading_to_anchor的逐项断言Hello World → hello-world、标点剥离、Unicode 保留、emoji 剔除边界情况同一文件里TestDisambiguateUrl的test_case_insensitive_collision_disambiguated专门验证INDEX.md与README.md在大小写不敏感文件系统上映射到index.html时产生的冲突会被加后缀消解——这正是典型的边界条件用例错误场景TestVendorAssets::test_download_rejects_non_http_scheme用pytest.raises(ValueError, matchnon-HTTP URL)验证下载助手会拒绝file://等非 HTTP 协议属于对非法输入防御逻辑的针对性测试端到端测试TestBuildWebsite::test_smoke_build从build_website(config, logger, skip_vendorTrue)出发断言生成的index.html、文件夹索引、Mermaid 代码块转义、CDN 引用清零等多项产出相当于一次完整的构建冒烟测试。Test Engineer 正是依据这套五层模型来决定「测什么、测多深」从而避免只写「快乐路径」测试而漏掉边界与异常。四、测试要求五条硬性规范Test Engineer 编写测试时必须遵守以下要求使用项目既有测试框架Jest、pytest 等——不要为项目引入新框架保持技术栈一致每个测试都包含 setup/teardown——保证测试之间的隔离与可重复执行Mock 外部依赖——将网络请求、文件系统、第三方服务等外部依赖隔离让测试快速且确定用清晰描述说明测试目的——让每个测试用例的意图可读、可维护、可审查相关场景加入性能断言——当测试涉及性能敏感路径时对耗时或资源消耗设置断言。这些要求同样可以在仓库测试代码中找到印证。例如 scripts/tests/conftest.py 集中定义了共享 fixturepytest.fixture def tmp_project(tmp_path: Path) - Path: Create a minimal project structure for testing. readme tmp_path / README.md readme.write_text(# Test Project\n\nThis is a test.) # 创建章节目录、普通章节文件…… return tmp_pathSetup 的体现pytest.fixture装饰器在测试执行前自动构造被测环境生成最小目录树、用 PIL 生成测试用 PNG Logo这就是「每个测试自带 setup」的标准姿势Teardown 的体现tmp_path是 pytest 内置的临时目录 fixture测试结束自动清理无需手工删除外部依赖 Mock 的体现TestBuildWebsite用skip_vendorTrue跳过真实联网下载 Tailwind 与 Mermaid 资源的步骤只用本地 fixture 树完成渲染验证这正是「Mock 外部依赖」在构建类工具测试中的典型手法清晰描述仓库中大量使用docstring与test_语义化命名如test_internal_markdown_link_rewritten、test_anchor_preserved测试意图一目了然。五、覆盖率要求80% 底线与关键路径 100%Test Engineer 对覆盖率有明确的量化标准代码覆盖率最低 80%——这是全局底线关键路径认证、支付、数据处理要求 100%——高风险路径不允许存在未覆盖分支报告缺失的覆盖区域——测试交付时需明确指出哪些区域尚未覆盖为后续补测提供依据。需要说明的是80% 与 100% 是 Subagent 系统提示词中面向通用项目设定的默认阈值实际落地时应结合项目现状调整。claude-howto 仓库虽然没有在配置中写死覆盖率门槛但 scripts/pyproject.toml 中可以看到完整的质量工具链配套——RuffE/W/F/I/B/C4/UP/SIM/TCH/RUF/PTH/PL/PERF全量 lint 规则、Mypypython_version 3.11、Bandit安全扫描exclude_dirs [scripts/tests, ...]说明仓库对测试与静态检查是一视同仁纳入开发流程的。覆盖率评估的工作流还可参考仓库内的 01-slash-commands/unit-test-expand.md「扩展单元测试」斜杠命令它与 Test Engineer 形成互补分析覆盖率运行覆盖率报告定位未测试分支、边界情况与低覆盖区域识别缺口审查逻辑分支、错误路径、边界条件、null/空输入按项目框架写测试Jest/Vitest/MochaJS/TS、pytest/unittestPython、Go testing/testifyGo、Rust 内置测试框架Rust瞄准特定场景错误处理与异常、边界值min/max/empty/null、角角落落的极端情形、状态转移与副作用验证提升再次运行覆盖率确认可度量的提升。该命令还强调「只输出新的测试代码块遵循既有测试模式与命名约定」——与 Test Engineer 的「按项目规范编写测试」如出一辙两者可以串联使用先由 Test Engineer 搭建测试骨架再借助unit-test-expand持续补漏。六、测试输出格式每次交付的四个字段Test Engineer 每创建一个测试文件都必须按固定格式汇报保证结果可审计、可追踪File测试文件的路径让主代理与用户能定位到具体文件Tests测试用例的数量衡量交付规模Coverage预计覆盖率提升量化本次贡献Critical Paths覆盖了哪些关键路径确认高风险区域是否已覆盖。这种结构化输出与 Subagent 的工作机制完全吻合Subagent 运行在独立上下文窗口中最终只把蒸馏后的结果返回给主代理参见 04-subagents/README.md 中的架构图。因此输出格式越紧凑、字段越明确主代理整合信息、向用户汇报的成本就越低。七、测试结构示例Jest 风格的标准模板原文档给出了一个可直接复制的测试结构模板Jest 风格这是 Test Engineer 编写单元测试时的标准骨架describe(Feature: User Authentication, () { beforeEach(() { // Setup }); afterEach(() { // Cleanup }); it(should authenticate valid credentials, async () { // Arrange // Act // Assert }); it(should reject invalid credentials, async () { // Test error case }); it(should handle edge case: empty password, async () { // Test edge case }); });该模板的三个设计要点值得注意beforeEach/afterEach成对出现——对应「每个测试都要包含 setup/teardown」的要求一个it只验证一个行为——合法凭证、非法凭证、空密码三种场景拆成三个独立用例恰好覆盖了「快乐路径 错误场景 边界情况」注释锚点Arrange / Act / Assert——引导测试编写者遵循 AAA 结构让测试既好写也好读。在 Python 项目中同样的结构对应 pytest 的写法这也是仓库 scripts/tests/ 目录中大量存在的形态class TestAuthentication: def setup_method(self): # Setup或以 conftest.py 中的 fixture 替代 pass def teardown_method(self): # Cleanup pass async def test_authenticate_valid_credentials(self): # Arrange / Act / Assert pass def test_reject_invalid_credentials(self): # Test error case pass def test_handle_edge_case_empty_password(self): # Test edge case pass八、在 claude-howto 中的落地实践8.1 安装方式Test Engineer 属于示例 Subagent可通过以下任一方式部署详见 04-subagents/README.md方式一让 Claude 生成推荐Create a project-level subagent that runs tests and fixes failures. Give it access to Bash, Read, Edit, and Grep.方式二复制到项目目录使其仅对当前项目生效mkdir -p .claude/agents cp /path/to/04-subagents/test-engineer.md .claude/agents/方式三复制到用户目录使其对所有项目生效mkdir -p ~/.claude/agents cp /path/to/04-subagents/test-engineer.md ~/.claude/agents/8.2 与仓库测试体系的衔接部署后在 claude-howto 项目中可以这样使用它 Use the test-engineer subagent to add coverage for scripts/build_website.py Ask the test-engineer subagent to verify the new tests pass此时 Test Engineer 会用Grep/Read分析 scripts/build_website.py 与既有测试 scripts/tests/test_build_website.py识别出heading_to_anchor、relative_link、rewrite_links、replace_mermaid_blocks等纯函数的关键路径与边界大小写冲突、emoji、空目录、重复标题等遵循 pytest 约定在 scripts/tests/ 下新增test_*.py运行pytest可配合覆盖率工具验证全部通过并按「File / Tests / Coverage / Critical Paths」四字段汇报。8.3 组合使用建议Test Engineer 与仓库中的其他能力可以协同工作与 01-slash-commands/unit-test-expand.md 组合先由 Test Engineer 建立测试基线再用unit-test-expand持续针对未覆盖分支补测与 04-subagents/code-reviewer.md 组合Code Reviewer 负责「分析测试覆盖缺口」其职责之一就是 test coverage analysis见 04-subagents/README.mdTest Engineer 负责「落地补写」形成分析→执行的闭环与 06-hooks/pre-commit.sh 等钩子组合将测试运行接入提交前检查把覆盖率门槛固化到工作流中避免测试漂移。九、小结test-engineerSubagent 的价值在于把「写测试」这件事标准化、自动化、可量化它以五层测试策略决定覆盖范围以五条硬性要求保证测试质量以 80%/100% 的覆盖率标准设定量化底线以四字段输出格式保证结果可审计并以「分析 → 识别 → 编写 → 验证」的闭环确保交付物真实可用。在 claude-howto 仓库中这套方法论与 scripts/tests/ 目录下的 pytest 测试体系、scripts/pyproject.toml 的测试配置以及 01-slash-commands/unit-test-expand.md 的补测命令相互印证、无缝衔接是构建可持续测试文化的落地范本。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
