Files
John Qiu 187f5621c9 feat(req): 部署门禁制度 — PDV 验收任务 + Deploy Gate 1-3
在 /req deploy 流程中增加部署后 E2E 验收(Post-Deploy Verification)门禁:
- 新增 verification linkRole 和【验收】任务命名规范
- Deploy Gate 1 健康检查 / Gate 2 PDV 任务完成 / Gate 3 证据完整
- PDV Playwright spec 模板(页面可达、菜单可见、API 连通)
- 同步更新 req-workflow、dev-test、e2e-testing 相关文档

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-31 09:34:08 +10:30

7.2 KiB
Raw Permalink Blame History

name, description
name description
dev-test 软件测试技能。用于单元测试、集成测试、E2E测试、测试用例设计。支持 Go、Vue、React、iOS、Android 等多平台测试。

软件测试 Skill (dev-test)

子文件索引

文件 内容
go-testing.md Go 后端测试 (testify + test DB + httptest)。biz 层禁止 mock必须用真实 PostgreSQL test DB
frontend-testing.md Vue (Vitest) + React (Jest) 前端测试
ios-testing.md iOS 测试 (XCTest + Swift Concurrency)
android-testing.md Android 测试 (JUnit + Espresso + Compose)
e2e-testing.md E2E PlaywrightAPI Mock 冒烟测试(无后端)+ 全链路集成测试
templates/go-integration-test.md Go 集成测试模板(多步骤 API 流程、中间件验证、租户隔离)
templates/pdv-smoke-spec.md PDV 部署后验收 Playwright 模板页面可达、菜单可见、API 连通)

测试金字塔

        /\
       /  \       E2E (少量)
      /----\
     /      \     集成测试 (适量)
    /--------\
   /          \   单元测试 (大量)
  /------------\
类型 范围 速度 数量
单元测试 函数/方法
集成测试 模块交互 适量
E2E 测试 完整流程

测试命令速查

平台 命令 详见
Go make test / go test ./... go-testing.md
Vue npm run test frontend-testing.md
React npm test frontend-testing.md
iOS xcodebuild test ios-testing.md
Android ./gradlew test android-testing.md
E2E (Mock 冒烟) npm run test:e2e:smoke-mock e2e-testing.md §API Mock
E2E (全链路) npm run test:e2e e2e-testing.md §全链路
E2E (Coolbuy PaaS) make e2e e2e-testing.md §Coolbuy
E2E (部署后验收 PDV) E2E_BASE_URL=<url> npx playwright test e2e/pdv/ §PDV

Chrome DevTools MCP (AI 浏览器调试)

Google 官方 MCP 服务器,让 AI 助手直接控制和检查 Chrome 浏览器。

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest
分类 工具 说明
输入 click / fill / fill_form / hover / upload_file 页面交互
导航 navigate_page / new_page / list_pages / wait_for 页面导航
调试 evaluate_script / list_console_messages / take_screenshot 调试工具
网络 list_network_requests / get_network_request 网络分析
性能 performance_start_trace / performance_stop_trace 性能追踪
模拟 emulate_device / throttle_network / throttle_cpu 环境模拟

测试用例设计

等价类划分

输入 有效类 无效类
用户名 3-64字符 <3, >64
年龄 0-150 <0, >150
邮箱 有效格式 无效格式

边界值

范围 [1, 100]:
测试点: 0, 1, 2, 99, 100, 101

测试用例模板

## TC-001: 用户登录成功

**前置条件**: 用户已注册
**步骤**:
1. 输入有效用户名
2. 输入有效密码
3. 点击登录

**预期**: 跳转到首页
**优先级**: P0

覆盖率目标

类型 目标
行覆盖 >80%
分支覆盖 >70%
函数覆盖 >90%

与 ai-proj 集成

# 创建测试任务
ai-proj task create --title "[模块] 单元测试"

# 记录测试结果
ai-proj task append-doc --id <taskId> --content "# 测试报告
- 覆盖率: 85%
- 通过: 42
- 失败: 0"

最佳实践

  1. 测试金字塔 - 多单元测试,少 E2E
  2. 测试隔离 - 每个测试独立
  3. 命名清晰 - 描述预期行为
  4. 快速反馈 - 测试要快
  5. 持续集成 - 每次提交运行
  6. Biz 层禁止 Mock - biz/service 层必须使用真实 PostgreSQL test DB + 真实 storemock 等于没测
  7. Mock 仅限 Handler 层 - handler 层可以 mock biz 接口 + httptest
  8. E2E 冒烟测试必须用 API Mock - E2E 门禁不能依赖后端,否则形同虚设。用 page.route() 拦截 APIe2e-testing.md。质量门禁流程Gates 1-5定义在 req-test-gate 技能中
  9. 李宁测试用例 - Excel 导出见 coolbuy-legacy 技能的 test-cases-excel.md

部署后 E2E 验收 (PDV — Post-Deploy Verification)

部署后验收是独立于 TG4 的 E2E 冒烟模式,在 /req deploy 健康检查通过后执行。

PDV vs TG4 区别

维度 TG4 (开发阶段 E2E 冒烟) PDV (部署后验收)
触发时机 /req test Gate 4 /req deploy 步骤 6
环境 本地开发环境API Mock 真实部署环境 (staging/prod)
目的 验证前端逻辑、UI 渲染 验证功能入口可达、基本可用
API page.route() 拦截 真实后端 API
范围 回归冒烟 仅新功能可达性

PDV 检查项

检查项 说明 示例
页面可达 需求涉及的前端页面返回 200 /okr/my, /okr/team
菜单可见 新增菜单项在侧栏中出现 OKR 菜单对目标用户角色可见
基础渲染 页面无白屏/JS 报错 页面有预期的标题/组件
API 连通 关键 API 带 token 调用返回正常 GET /api/v1/okr/objectives 返回 200

PDV 不做什么

  • 不做完整回归测试(那是 TG4 的事)
  • 不测试复杂业务流程(如多步骤表单提交)
  • 不替代手动验收
  • 只做「功能入口可达 + 基本可用」的冒烟验证

PDV 执行方式

E2E_BASE_URL=<部署环境URL> npx playwright test e2e/pdv/ --project=chromium

PDV Spec 生成规则

AI 根据需求变更范围动态生成 Playwright spec模板见 templates/pdv-smoke-spec.md。生成流程:

  1. 从需求关联任务提取前端变更范围页面路由、菜单项、API 端点)
  2. 登录测试账号(使用 storageState 或手动登录)
  3. 验证新增菜单项可见(检查 .ant-menu 包含目标文本)
  4. 导航到新页面验证非白屏title 不含 error/500/404
  5. 调用关键 API验证返回状态码 < 500
  6. 每步截图保存为证据

PDV 结果判定

  • 全部 PASS → 继续推进到 released
  • 任一 FAIL → 阻断推进,在部署文档记录失败项,通知修复

TG2 集成测试检测

模板映射

变更范围 测试输出位置 模板
单个 handler 或 service *_test.go (同目录) go-testing.md
handlers/ + middleware/ + routes/ (同一功能) tests/{feature}_integration_test.go templates/go-integration-test.md

检测规则

若 git diff 显示同一功能的 handlers/middleware/routes/ 文件均有变更(通过命名模式识别,如 impersonation_handler.go + impersonation_middleware.go + impersonation_routes.go),则除单元测试外额外生成 backend/tests/ 下的集成测试。

识别方式:提取文件名中的功能前缀(如 impersonation),若在三个目录中均出现,则触发集成测试生成。