⚡

测试Skill testing

本技能提供全面的软件测试解决方案，涵盖测试策略制定、自动化框架搭建、测试驱动开发（TDD）实施、单元/集成/端到端测试编写、覆盖率分析、CI/CD集成以及使用Playwright进行Web应用测试。适用于开发人员、测试工程师和DevOps团队，旨在提升代码质量、确保软件可靠性和加速交付流程。关键词：软件测试，自动化测试，TDD，测试覆盖率，CI/CD，Playwright，单元测试，集成测试，端到端测试，测试策略。

测试 0 次安装 2 次浏览 更新于 2/28/2026

name: testing description: 全面的测试专项技能，涵盖测试策略、自动化、TDD方法论、测试编写和Web应用测试。适用于设置测试基础设施、编写测试、实施TDD工作流、分析覆盖率、将测试集成到CI/CD中，或使用Playwright测试Web应用程序。采用框架无关的方法，并通过参考文件提供特定框架的指导。 author: Joseph OBrien status: unpublished updated: ‘2025-12-23’ version: 1.0.1 tag: skill type: skill

测试

此技能提供全面的测试能力，包括测试策略、自动化设置、测试驱动开发（TDD）、测试编写最佳实践、覆盖率分析、CI/CD集成以及使用Playwright进行Web应用程序测试。

何时使用此技能

  • 为项目设置测试基础设施时
  • 创建测试策略和测试计划时
  • 编写单元、集成或端到端测试时
  • 实施TDD/测试优先开发时
  • 分析测试覆盖率和质量时
  • 将测试集成到CI/CD流水线时
  • 使用Playwright测试Web应用程序时
  • 调试测试失败或提高测试可靠性时
  • 编写测试夹具、模拟数据或工厂函数时
  • 模拟外部依赖（API、数据库、文件系统）时
  • 组织测试文件结构和测试套件时
  • 测试异步代码、Promise或事件驱动行为时
  • 为UI组件实施快照测试时
  • 配置测试覆盖率阈值时

此技能的作用

  1. 测试策略：设计全面的测试策略（单元、集成、端到端）
  2. 测试自动化：设置测试框架和自动化工具
  3. TDD方法论：实施测试驱动开发工作流（红-绿-重构）
  4. 测试编写：编写专注、可维护的测试，并采用正确的模式
  5. 覆盖率分析：分析和改进测试覆盖率
  6. CI/CD集成：将测试集成到持续集成流水线中
  7. Web应用测试：使用Playwright测试Web应用程序
  8. 测试质量：提高测试的可靠性和可维护性

测试策略

测试金字塔

推荐分布：

  • 单元测试：70% - 快速、隔离，测试单个函数
  • 集成测试：20% - 测试组件交互
  • 端到端测试：10% - 测试完整的用户工作流

测试类型：

  • 功能测试（正常路径、边界情况、错误处理）
  • 非功能测试（性能、安全、可访问性）
  • 回归测试（防止破坏性变更）
  • 冒烟测试（关键路径验证）

框架选择

JavaScript/TypeScript：

  • Jest、Vitest、Mocha用于单元/集成测试
  • Playwright、Cypress用于端到端测试
  • React Testing Library用于组件测试

Python：

  • pytest用于单元/集成测试
  • Selenium、Playwright用于端到端测试
  • unittest用于标准库测试

Java：

  • JUnit用于单元测试
  • TestNG用于集成测试
  • Selenium用于端到端测试

Go：

  • 内置测试包
  • Testify用于断言

Rust：

  • 内置测试框架
  • Cargo test用于运行测试

测试驱动开发（TDD）

TDD是一种设计技术，而不仅仅是测试技术。它通过小而规范的步骤产生设计更好、更易维护的代码。

核心原则

先写测试，后写代码。始终如此。 TDD迫使你思考：

  • 我需要什么行为？
  • 我怎么知道它有效？
  • 最简单的实现是什么？

三大定律（永不违反）

  1. 不编写生产代码，除非先有一个失败的测试
  2. 只编写足够的测试来证明一个失败
  3. 只编写足够的代码来通过该测试

红-绿-重构循环

阶段1：红 - 编写失败的测试

  1. 编写一个定义所需行为的测试
  2. 运行测试 - 验证它失败
  3. 验证它因正确的原因失败（不是语法错误）
  4. 不要编写实现代码

阶段2：绿 - 最小化实现

  1. 编写最少的代码使测试通过
  2. 抵制添加额外功能的冲动
  3. 运行测试 - 验证它通过
  4. 如果测试仍然失败，修复实现（而不是测试）

阶段3：重构 - 清理代码

  1. 消除代码重复（DRY原则）
  2. 改进命名以提高清晰度
  3. 将复杂逻辑提取到函数中
  4. 运行所有测试 - 必须始终保持通过
  5. 检查更改行的测试覆盖率

重构之后，为下一个行为开始新的红阶段。

测试编写模式

准备-执行-断言（AAA）

结构：

  1. 准备：设置测试数据和条件
  2. 执行：执行被测试的代码
  3. 断言：验证预期结果

示例：

describe('用户服务', () => {
  it('应使用有效数据创建用户', async () => {
    // 准备
    const userData = { email: 'test@example.com', name: '测试用户' };

    // 执行
    const result = await userService.createUser(userData);

    // 断言
    expect(result).toHaveProperty('id');
    expect(result.email).toBe(userData.email);
  });
});

给定-当-那么（BDD风格）

结构：

  1. 给定：初始上下文/先决条件
  2. 当：触发行为的动作/事件
  3. 那么：预期结果

测试组织

文件结构：

项目/
├── src/
│   └── components/
│       └── User.jsx
├── tests/
│   ├── unit/
│   │   └── User.test.jsx
│   ├── integration/
│   │   └── UserAPI.test.js
│   └── e2e/
│       └── user-flow.spec.js
├── jest.config.js
└── playwright.config.js

覆盖率分析

覆盖率目标

推荐阈值：

  • 行覆盖率：80%+
  • 函数覆盖率：80%+
  • 分支覆盖率：80%+
  • 语句覆盖率：80%+

关键路径：

  • 关键业务逻辑始终追求100%覆盖率
  • 身份验证和授权
  • 支付处理
  • 数据验证

覆盖率缺口

常见缺口：

  • 错误处理路径
  • 边界情况
  • 边界条件
  • 集成点

改进策略：

  • 识别未测试的代码路径
  • 为错误场景添加测试
  • 测试边界情况和边界条件
  • 提高集成测试覆盖率

CI/CD集成

测试流水线

阶段：

  1. 单元测试：快速反馈，每次提交时运行
  2. 集成测试：在拉取请求时运行
  3. 端到端测试：在合并到主分支前运行
  4. 性能测试：在主分支上运行

质量门禁：

  • 所有测试必须通过
  • 覆盖率必须达到阈值
  • 无关键安全问题
  • 性能基准达标

使用Playwright进行Web应用程序测试

辅助脚本

此技能在scripts/目录中包含Python辅助脚本：

  • with_server.py - 管理服务器生命周期（支持多个服务器）。始终先使用--help查看用法。

    # 单服务器
python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py

# 多服务器（例如，后端 + 前端）
python scripts/with_server.py \
  --server "cd backend && python server.py" --port 3000 \
  --server "cd frontend && npm run dev" --port 5173 \
  -- python your_automation.py

决策树：选择你的方法

用户任务 → 是静态HTML吗？
    ├─ 是 → 直接读取HTML文件以识别选择器
    │         ├─ 成功 → 使用选择器编写Playwright脚本
    │         └─ 失败/不完整 → 视为动态应用（如下）
    │
    └─ 否（动态Web应用） → 服务器是否已在运行？
        ├─ 否 → 运行：python scripts/with_server.py --help
        │        然后使用辅助脚本 + 编写简化的Playwright脚本
        │
        └─ 是 → 先侦察后行动：
            1. 导航并等待网络空闲
            2. 截图或检查DOM
            3. 从渲染状态识别选择器
            4. 使用发现的选择器执行操作

Playwright最佳实践

  • 将捆绑的脚本视为黑盒 - 使用--help查看用法，然后直接调用
  • 使用sync_playwright()进行同步脚本
  • 完成后始终关闭浏览器
  • 使用描述性选择器：text=、role=、CSS选择器或ID
  • 添加适当的等待：page.wait_for_selector()或page.wait_for_timeout()
  • 关键：在动态应用上检查前等待page.wait_for_load_state('networkidle')

示例：基本Playwright脚本

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto('http://localhost:5173')
    page.wait_for_load_state('networkidle')  # 关键：等待JS执行
    # ... 你的自动化逻辑
    browser.close()

示例

查看examples/目录中的示例：

  • element_discovery.py - 在页面上发现按钮、链接和输入框
  • static_html_automation.py - 使用file:// URL处理本地HTML
  • console_logging.py - 在自动化过程中捕获控制台日志

参考文件

如需详细的测试模式和工作流，请根据需要加载参考文件：

  • references/framework_workflows.md - 针对Python（pytest）、JavaScript（Jest、Vitest）、Java（JUnit）、Go、Rust的框架特定TDD工作流和示例
  • references/test_patterns.md - 常见测试模式、测试组织、命名约定、测试替身（模拟、存根、间谍）、参数化和反模式
  • references/webapp_testing.md - Web应用程序测试模式、Playwright最佳实践和端到端测试策略
  • references/TESTING_REPORT.template.md - 测试质量报告模板，包含覆盖率指标、审计发现和建议

当处理特定框架或需要详细模式时，加载相应的参考文件。

最佳实践

测试质量

  1. 隔离性：测试应独立且可以按任何顺序运行
  2. 确定性：测试应产生一致的结果
  3. 快速性：单元测试应快速运行（每个< 100毫秒）
  4. 清晰性：测试名称应描述它们测试的内容
  5. 可维护性：当代码更改时，测试应易于更新

TDD最佳实践

  1. 每个测试一个行为：每个测试验证一个行为
  2. 描述性名称：测试名称描述被测试的行为
  3. 独立测试：测试不相互依赖
  4. 快速测试：模拟外部依赖以保持测试快速
  5. 清晰断言：断言清楚地显示正在验证的内容

应避免的常见错误

  • ❌ 一次编写多个测试（一次编写一个测试）
  • ❌ 跳过重构阶段（在绿阶段后始终重构）
  • ❌ 在测试之前编写实现（删除代码并从测试开始）
  • ❌ 在绿阶段过度设计（通过测试的最简单实现）
  • ❌ 编写立即通过的测试（必须先失败）

测试维护

  • 当需求变化时，审查和更新测试
  • 移除过时的测试
  • 重构测试以减少重复
  • 保持测试数据工厂更新
  • 监控测试执行时间

与其他技能的集成

  • debugging：当测试意外失败时使用
  • code-review：TDD产生的代码更易于审查
  • dead-code-removal：测试有助于识别未使用的代码
  • performance：用于性能测试策略

元原则

TDD是一种设计技术，而不是测试技术。

循环永不改变：红 → 绿 → 重构 → 重复

先写测试迫使你思考：
- 我需要什么行为？
- 我怎么知道它有效？
- 最简单的实现是什么？

这会产生设计更好、更易维护的代码。