John Qiu
187f5621c9
在 /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>
218 lines
7.2 KiB
Markdown
218 lines
7.2 KiB
Markdown
---
|
||
name: dev-test
|
||
description: 软件测试技能。用于单元测试、集成测试、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 Playwright：API 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 浏览器。
|
||
|
||
```bash
|
||
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
|
||
```
|
||
|
||
### 测试用例模板
|
||
|
||
```markdown
|
||
## TC-001: 用户登录成功
|
||
|
||
**前置条件**: 用户已注册
|
||
**步骤**:
|
||
1. 输入有效用户名
|
||
2. 输入有效密码
|
||
3. 点击登录
|
||
|
||
**预期**: 跳转到首页
|
||
**优先级**: P0
|
||
```
|
||
|
||
---
|
||
|
||
## 覆盖率目标
|
||
|
||
| 类型 | 目标 |
|
||
|------|------|
|
||
| 行覆盖 | >80% |
|
||
| 分支覆盖 | >70% |
|
||
| 函数覆盖 | >90% |
|
||
|
||
---
|
||
|
||
## 与 ai-proj 集成
|
||
|
||
```bash
|
||
# 创建测试任务
|
||
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 + 真实 store，mock 等于没测
|
||
7. **Mock 仅限 Handler 层** - handler 层可以 mock biz 接口 + httptest
|
||
8. **E2E 冒烟测试必须用 API Mock** - E2E 门禁不能依赖后端，否则形同虚设。用 `page.route()` 拦截 API，见 `e2e-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 执行方式
|
||
|
||
```bash
|
||
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`），若在三个目录中均出现，则触发集成测试生成。
|