|
@@ -1,5 +1,5 @@
|
|
|
---
|
|
---
|
|
|
-stepsCompleted: ['step-01-init', 'step-02-discovery', 'step-03-success', 'step-04-journeys', 'step-07-project-type', 'step-08-scoping', 'step-09-functional', 'step-10-nonfunctional', 'step-11-complete']
|
|
|
|
|
|
|
+stepsCompleted: ['step-01-init', 'step-02-discovery', 'step-03-success', 'step-04-journeys', 'step-07-project-type', 'step-08-scoping', 'step-09-functional', 'step-10-nonfunctional', 'step-11-complete', 'revision-2025-01-10']
|
|
|
inputDocuments:
|
|
inputDocuments:
|
|
|
- name: 项目文档索引
|
|
- name: 项目文档索引
|
|
|
path: docs/index.md
|
|
path: docs/index.md
|
|
@@ -32,18 +32,21 @@ documentCounts:
|
|
|
testReferences: 1
|
|
testReferences: 1
|
|
|
workflowType: 'prd'
|
|
workflowType: 'prd'
|
|
|
lastStep: 6
|
|
lastStep: 6
|
|
|
|
|
+revisedAt: '2026-01-10'
|
|
|
|
|
+revisionNotes: '修订范围:从"测试工具包开发"扩展为"Web E2E 测试覆盖",业务测试为主,工具包为支持手段'
|
|
|
---
|
|
---
|
|
|
|
|
|
|
|
-# Product Requirements Document - 188-179 招聘系统
|
|
|
|
|
|
|
+# Product Requirements Document - Web 应用 E2E 测试覆盖
|
|
|
|
|
|
|
|
**作者:** Root
|
|
**作者:** Root
|
|
|
-**日期:** 2026-01-07
|
|
|
|
|
|
|
+**创建日期:** 2026-01-07
|
|
|
|
|
+**修订日期:** 2026-01-10
|
|
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
|
## 执行摘要
|
|
## 执行摘要
|
|
|
|
|
|
|
|
-本项目旨在建立一套可复用的 E2E 测试模式和规范,从残疾人管理功能的测试实践中提取通用测试工具,特别是针对 Radix UI 组件的测试方法。
|
|
|
|
|
|
|
+本项目旨在为 Web 管理后台的关键业务功能建立完整的 E2E 测试覆盖。在编写业务测试的过程中,将通用测试模式抽象到 `@d8d/e2e-test-utils` 包中,以加速后续功能的测试开发。
|
|
|
|
|
|
|
|
### 项目背景
|
|
### 项目背景
|
|
|
|
|
|
|
@@ -59,56 +62,75 @@ lastStep: 6
|
|
|
|
|
|
|
|
### 核心目标
|
|
### 核心目标
|
|
|
|
|
|
|
|
-**不仅为残疾人管理补充测试,更重要的是建立可复用的测试模式:**
|
|
|
|
|
|
|
+**主目标:为 Web 管理后台的业务功能建立完整的 E2E 测试覆盖**
|
|
|
|
|
|
|
|
-1. **提取 Radix UI Select 测试规范**(最关键)
|
|
|
|
|
- - 静态枚举型 Select(如残疾类型、等级)
|
|
|
|
|
- - 异步加载型 Select(如省份、城市)
|
|
|
|
|
- - 统一的 API 接口和错误处理
|
|
|
|
|
|
|
+**副目标:在测试过程中抽象可复用工具**
|
|
|
|
|
|
|
|
-2. **提取其他常用表单组件测试模式**
|
|
|
|
|
- - 文件上传(照片、银行卡)
|
|
|
|
|
- - 多步骤表单(填写 → 滚动 → 提交)
|
|
|
|
|
- - 动态列表管理(添加/删除银行卡、备注)
|
|
|
|
|
- - 对话框操作模式
|
|
|
|
|
|
|
+**工作方式:测试驱动 + 工具演进**
|
|
|
|
|
+
|
|
|
|
|
+1. **编写业务 E2E 测试**(主任务)
|
|
|
|
|
+ - 优先完成业务功能的测试覆盖
|
|
|
|
|
+ - 验证业务逻辑的正确性
|
|
|
|
|
+ - 确保测试稳定性
|
|
|
|
|
+
|
|
|
|
|
+2. **抽象通用测试工具**(自然演进)
|
|
|
|
|
+ - 从业务测试中发现重复模式
|
|
|
|
|
+ - 将通用模式抽象到 `@d8d/e2e-test-utils` 包
|
|
|
|
|
+ - 持续完善工具函数
|
|
|
|
|
|
|
|
3. **输出两种形式**
|
|
3. **输出两种形式**
|
|
|
- - **共享测试工具包**:创建 `packages/e2e-test-utils` 新包
|
|
|
|
|
- - **测试文档指南**:更新到 `docs/standards/` 下
|
|
|
|
|
|
|
+ - **业务测试覆盖**:完整的 E2E 测试用例
|
|
|
|
|
+ - **共享测试工具包**:`packages/e2e-test-utils`
|
|
|
|
|
+
|
|
|
|
|
+### Epic 组织
|
|
|
|
|
+
|
|
|
|
|
+本项目按业务功能组织为多个 Epic:
|
|
|
|
|
+
|
|
|
|
|
+| Epic | 内容 | 状态 |
|
|
|
|
|
+|------|------|------|
|
|
|
|
|
+| **Epic A: 残疾人管理 E2E 测试** | 完整的残疾人管理功能测试覆盖 | ✅ 已完成 |
|
|
|
|
|
+| **Epic B: 区域管理 E2E 测试** | 区域管理(省市区街道)测试覆盖 | 🔄 待开发 |
|
|
|
|
|
+| **Epic C: e2e-test-utils 包维护** | 支持性任务:维护测试工具包 | 🌟 持续演进 |
|
|
|
|
|
+
|
|
|
|
|
+**说明**:
|
|
|
|
|
+- Epic A 和 Epic B 是**业务测试 Epic**,直接交付业务价值
|
|
|
|
|
+- Epic C 是**支持性 Epic**,为业务测试提供工具支持
|
|
|
|
|
+- 工具包的开发是**自然演进**的结果,不是预先规划的目标
|
|
|
|
|
|
|
|
### 特殊价值
|
|
### 特殊价值
|
|
|
|
|
|
|
|
**这个项目的特殊之处在于:**
|
|
**这个项目的特殊之处在于:**
|
|
|
|
|
|
|
|
-1. **从实践中提取模式**:不是从零开始,而是从已有的残疾人管理测试实践中提炼通用方法
|
|
|
|
|
|
|
+1. **业务价值优先**:直接交付业务测试覆盖,确保产品质量
|
|
|
|
|
|
|
|
-2. **双重收益**:
|
|
|
|
|
- - 直接收益:完成残疾人管理的完整 E2E 测试覆盖
|
|
|
|
|
- - 长期收益:建立测试规范,加速后续功能的测试开发
|
|
|
|
|
|
|
+2. **工具自然演进**:不是"为了做工具而做工具",而是从实践中抽象
|
|
|
|
|
|
|
|
-3. **降低认知负担**:新测试开发者不需要深入理解 Radix UI 内部机制,只需调用统一 API
|
|
|
|
|
|
|
+3. **双重收益**:
|
|
|
|
|
+ - 直接收益:完成业务功能的 E2E 测试覆盖
|
|
|
|
|
+ - 长期收益:可复用的测试工具,加速后续开发
|
|
|
|
|
|
|
|
-4. **提高测试稳定性**:统一的等待策略、错误处理和重试逻辑
|
|
|
|
|
|
|
+4. **降低认知负担**:新测试开发者不需要深入理解 Radix UI 内部机制,只需调用统一 API
|
|
|
|
|
|
|
|
-5. **高度复用性**:新增/编辑残疾人都会用到,未来其他管理功能也可复用
|
|
|
|
|
|
|
+5. **提高测试稳定性**:统一的等待策略、错误处理和重试逻辑
|
|
|
|
|
|
|
|
### 为什么现在做
|
|
### 为什么现在做
|
|
|
|
|
|
|
|
-- 残疾人管理功能已实现,是提取模式的最佳时机
|
|
|
|
|
-- 现有调试测试已验证了基本流程,可以在此基础上完善
|
|
|
|
|
-- 未来还有更多管理功能需要类似测试,提前建立规范能避免重复工作
|
|
|
|
|
|
|
+- 残疾人管理功能已实现,E2E 测试覆盖是质量保障的需要
|
|
|
|
|
+- 在编写残疾人管理测试时,发现可以抽象通用工具
|
|
|
|
|
+- 未来还有更多管理功能需要测试,提前建立工具能避免重复工作
|
|
|
|
|
+- 区域管理功能需要测试,是继续实践的好机会
|
|
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
|
## 项目分类
|
|
## 项目分类
|
|
|
|
|
|
|
|
-**技术类型:** `developer_tool`(测试工具/基础设施)
|
|
|
|
|
|
|
+**技术类型:** `testing`(E2E 测试覆盖)
|
|
|
|
|
|
|
|
-**领域:** `general`(通用测试模式,不限于特定业务领域)
|
|
|
|
|
|
|
+**领域:** `web_admin`(Web 管理后台业务功能测试)
|
|
|
|
|
|
|
|
-**复杂度:** `low`(相对独立的工具函数 + 文档,不影响核心业务逻辑)
|
|
|
|
|
|
|
+**复杂度:** `medium`(业务测试 + 工具抽象)
|
|
|
|
|
|
|
|
-**项目上下文:** 棕地项目 - 扩展现有测试基础设施,遵循现有 Page Object 模式
|
|
|
|
|
|
|
+**项目上下文:** 棕地项目 - 为现有 Web 管理后台补充 E2E 测试覆盖,遵循现有 Page Object 模式
|
|
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
@@ -136,15 +158,24 @@ lastStep: 6
|
|
|
|
|
|
|
|
### 业务成功
|
|
### 业务成功
|
|
|
|
|
|
|
|
|
|
+**业务测试覆盖率(主指标):**
|
|
|
|
|
+
|
|
|
|
|
+| 业务功能 | 目标覆盖率 | 当前状态 | 测量方式 |
|
|
|
|
|
+|---------|-----------|---------|---------|
|
|
|
|
|
+| 残疾人管理 | 关键流程 100% | ✅ 已完成 | 代码覆盖率报告 |
|
|
|
|
|
+| 区域管理 | 关键流程 100% | 🔄 待开发 | 代码覆盖率报告 |
|
|
|
|
|
+| 其他管理功能 | 按需补充 | ⏳ 规划中 | 业务优先级 |
|
|
|
|
|
+
|
|
|
**短期(1-3个月)**
|
|
**短期(1-3个月)**
|
|
|
- E2E 测试编写时间减少 50%(相比之前每次重新摸索)
|
|
- E2E 测试编写时间减少 50%(相比之前每次重新摸索)
|
|
|
-- 残疾人管理功能的测试覆盖率达到关键用户流程 100%
|
|
|
|
|
-- 工具函数被至少 1 个其他管理功能复用
|
|
|
|
|
|
|
+- 残疾人管理功能的测试覆盖率达到关键用户流程 100% ✅
|
|
|
|
|
+- 区域管理功能的测试覆盖率达到关键用户流程 100%
|
|
|
|
|
+- 工具函数被业务测试自然复用
|
|
|
|
|
|
|
|
**中期(3-6个月)**
|
|
**中期(3-6个月)**
|
|
|
- 新功能的 E2E 测试开发周期显著缩短
|
|
- 新功能的 E2E 测试开发周期显著缩短
|
|
|
- E2E 测试的 flaky 率降低到 5% 以下
|
|
- E2E 测试的 flaky 率降低到 5% 以下
|
|
|
-- 至少 3 个其他管理功能复用这套测试模式
|
|
|
|
|
|
|
+- 至少 3 个管理功能完成 E2E 测试覆盖
|
|
|
|
|
|
|
|
**长期(6-12个月)**
|
|
**长期(6-12个月)**
|
|
|
- 建立 E2E 测试规范成为团队标准
|
|
- 建立 E2E 测试规范成为团队标准
|
|
@@ -172,12 +203,12 @@ lastStep: 6
|
|
|
|
|
|
|
|
| 指标 | 当前状态 | 目标状态 | 测量方式 |
|
|
| 指标 | 当前状态 | 目标状态 | 测量方式 |
|
|
|
|------|---------|---------|---------|
|
|
|------|---------|---------|---------|
|
|
|
|
|
+| 残疾人管理测试覆盖率 | ✅ 关键流程 100% | ✅ 已达成 | 代码覆盖率报告 |
|
|
|
|
|
+| 区域管理测试覆盖率 | 0% | 关键流程 100% | 代码覆盖率报告 |
|
|
|
| Radix Select 测试编写时间 | 需要研究/摸索 | 5 分钟内完成 | 计时实验 |
|
|
| Radix Select 测试编写时间 | 需要研究/摸索 | 5 分钟内完成 | 计时实验 |
|
|
|
-| 测试稳定性(通过率) | 未知 | 20 次连续运行 100% 通过 | 自动化运行 |
|
|
|
|
|
-| 工具函数测试覆盖率 | 0% | ≥ 80% | 代码覆盖率报告 |
|
|
|
|
|
-| 文档完整性 | 无 | 覆盖 6 种模式 + 示例 | 文档检查清单 |
|
|
|
|
|
-| 残疾人管理测试覆盖率 | 基础表单 | 完整 CRUD + 子功能 | 代码覆盖率报告 |
|
|
|
|
|
-| 模式复用次数 | 0 | 至少 3 个功能复用 | 使用统计 |
|
|
|
|
|
|
|
+| 测试稳定性(通过率) | 良好 | 20 次连续运行 100% 通过 | 自动化运行 |
|
|
|
|
|
+| 工具函数测试覆盖率 | 进行中 | ≥ 80% | 代码覆盖率报告 |
|
|
|
|
|
+| 文档完整性 | 基础 | 覆盖所有工具 + 示例 | 文档检查清单 |
|
|
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
@@ -185,86 +216,89 @@ lastStep: 6
|
|
|
|
|
|
|
|
### MVP - Minimum Viable Product
|
|
### MVP - Minimum Viable Product
|
|
|
|
|
|
|
|
-**核心:从残疾人 E2E 测试中抽取可复用工具函数**
|
|
|
|
|
|
|
+**核心:为 Web 管理后台的业务功能建立完整的 E2E 测试覆盖**
|
|
|
|
|
|
|
|
-**1. 创建新包 `packages/e2e-test-utils`** ⭐(最重要)
|
|
|
|
|
|
|
+**1. Epic A: 残疾人管理 E2E 测试** ✅ 已完成
|
|
|
|
|
|
|
|
-独立于 `@d8d/shared-test-util`(后端集成测试),专门用于 Playwright E2E 测试:
|
|
|
|
|
|
|
+完整的残疾人管理功能测试覆盖:
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
-packages/e2e-test-utils/
|
|
|
|
|
-├── package.json
|
|
|
|
|
-├── src/
|
|
|
|
|
-│ ├── index.ts
|
|
|
|
|
-│ ├── radix-select.ts # Radix UI Select 工具
|
|
|
|
|
-│ ├── file-upload.ts # 文件上传工具
|
|
|
|
|
-│ ├── form-helper.ts # 表单辅助函数
|
|
|
|
|
-│ ├── dialog.ts # 对话框操作
|
|
|
|
|
-│ └── dynamic-list.ts # 动态列表管理
|
|
|
|
|
-├── tests/ # 工具函数的单元测试
|
|
|
|
|
-└── README.md
|
|
|
|
|
-```
|
|
|
|
|
|
|
+- 照片上传功能测试(身份证、残疾证、个人照片)
|
|
|
|
|
+- 银行卡管理功能测试(添加、编辑、删除)
|
|
|
|
|
+- 备注功能测试(添加、修改、删除)
|
|
|
|
|
+- 回访功能测试(记录创建、查看)
|
|
|
|
|
+- 完整流程测试(所有功能组合)
|
|
|
|
|
|
|
|
-**核心工具函数:**
|
|
|
|
|
|
|
+**测试过程中抽象的工具:**
|
|
|
|
|
+- Radix UI Select 测试工具(静态/异步)
|
|
|
|
|
+- 文件上传测试工具
|
|
|
|
|
+- 其他表单交互工具
|
|
|
|
|
|
|
|
-- **`selectRadixOption(page, label, value)`** - 静态枚举型 Radix UI Select
|
|
|
|
|
-- **`selectRadixOptionAsync(page, label, value, options)`** - 异步加载型 Select(省份、城市)
|
|
|
|
|
-- **`uploadFileToField(page, selector, fileName)`** - 文件上传(照片、银行卡)
|
|
|
|
|
-- **`fillMultiStepForm(page, steps)`** - 多步骤表单流程
|
|
|
|
|
-- **`addDynamicListItem(page, itemType, data)`** - 动态列表添加
|
|
|
|
|
-- **`handleDialog(page, action)`** - 对话框操作模式
|
|
|
|
|
|
|
+**2. Epic B: 区域管理 E2E 测试** 🔄 当前目标
|
|
|
|
|
|
|
|
-**2. 残疾人管理 E2E 测试**(验证工具函数)
|
|
|
|
|
|
|
+区域管理功能的完整测试覆盖:
|
|
|
|
|
|
|
|
-使用提取的工具函数编写的完整测试:
|
|
|
|
|
|
|
+- 区域列表查看测试
|
|
|
|
|
+- 添加区域测试(省/市/区/街道)
|
|
|
|
|
+- 编辑区域测试
|
|
|
|
|
+- 删除区域测试
|
|
|
|
|
+- 级联选择测试(省市区街道四级联动)
|
|
|
|
|
+- 完整流程测试
|
|
|
|
|
|
|
|
-- 照片上传功能测试
|
|
|
|
|
-- 银行卡管理功能测试
|
|
|
|
|
-- 备注功能测试
|
|
|
|
|
-- 回访功能测试
|
|
|
|
|
-- 完整流程测试(所有功能组合)
|
|
|
|
|
|
|
+**可能需要抽象的工具:**
|
|
|
|
|
+- 级联选择测试工具(如现有工具不满足需求)
|
|
|
|
|
+- 树形结构操作工具(如需要)
|
|
|
|
|
+
|
|
|
|
|
+**3. e2e-test-utils 包** 🌟 支持性任务
|
|
|
|
|
|
|
|
-**3. 基础测试文档**
|
|
|
|
|
|
|
+作为业务测试的支持工具,自然演进:
|
|
|
|
|
|
|
|
-- 快速入门指南
|
|
|
|
|
-- 2-3 个实际使用示例
|
|
|
|
|
-- 常见问题和解决方案
|
|
|
|
|
|
|
+```
|
|
|
|
|
+packages/e2e-test-utils/
|
|
|
|
|
+├── src/
|
|
|
|
|
+│ ├── index.ts
|
|
|
|
|
+│ ├── select.ts # Radix UI Select 工具 ✅
|
|
|
|
|
+│ ├── file-upload.ts # 文件上传工具 🔄
|
|
|
|
|
+│ └── ... # 其他工具(按需添加)
|
|
|
|
|
+├── tests/
|
|
|
|
|
+└── README.md
|
|
|
|
|
+```
|
|
|
|
|
|
|
|
-**价值主张:** 工具函数是核心资产,测试用例证明它们可用。
|
|
|
|
|
|
|
+**价值主张:** 业务测试覆盖直接交付价值,工具包是自然演进的支持产物。
|
|
|
|
|
|
|
|
### Growth Features (Post-MVP)
|
|
### Growth Features (Post-MVP)
|
|
|
|
|
|
|
|
-**扩展工具函数库:**
|
|
|
|
|
-- Date Picker、Slider、Tabs 等 Radix 组件测试模式
|
|
|
|
|
-- 表单验证错误处理测试模式
|
|
|
|
|
-- 网络请求 Mock 和断言辅助函数
|
|
|
|
|
|
|
+**更多业务功能的 E2E 测试覆盖:**
|
|
|
|
|
+- 其他管理功能的测试(按业务优先级)
|
|
|
|
|
+- 用户权限管理测试
|
|
|
|
|
+- 系统配置管理测试
|
|
|
|
|
+- 报表功能测试
|
|
|
|
|
+
|
|
|
|
|
+**工具包持续演进(按需):**
|
|
|
|
|
+- 在编写新业务测试时,如发现重复模式则抽象新工具
|
|
|
|
|
+- Date Picker、Slider、Tabs 等 Radix 组件测试模式(如业务需要)
|
|
|
|
|
+- 表单验证错误处理测试模式(如业务需要)
|
|
|
|
|
|
|
|
**开发体验增强:**
|
|
**开发体验增强:**
|
|
|
- VS Code snippets 快速插入测试代码
|
|
- VS Code snippets 快速插入测试代码
|
|
|
-- CLI 命令生成测试模板
|
|
|
|
|
-- 交互式调试模式(慢动作、可视化等待)
|
|
|
|
|
-
|
|
|
|
|
-**质量保障集成:**
|
|
|
|
|
-- 集成到 CI/CD 的自动化测试报告
|
|
|
|
|
-- 测试覆盖率趋势追踪
|
|
|
|
|
-- Flaky 测试自动检测和报告
|
|
|
|
|
|
|
+- 测试模板和最佳实践文档
|
|
|
|
|
+- 更完善的错误提示和调试信息
|
|
|
|
|
|
|
|
### Vision (Future)
|
|
### Vision (Future)
|
|
|
|
|
|
|
|
|
|
+**完整的 E2E 测试覆盖:**
|
|
|
|
|
+- Web 管理后台所有关键功能的测试覆盖
|
|
|
|
|
+- 自动化测试作为 CI/CD 的标准环节
|
|
|
|
|
+- 测试覆盖率可视化仪表盘
|
|
|
|
|
+
|
|
|
**智能化测试开发:**
|
|
**智能化测试开发:**
|
|
|
-- 自动发现页面中的 Radix 组件并生成测试骨架
|
|
|
|
|
- AI 辅助测试编写(描述行为自动生成测试)
|
|
- AI 辅助测试编写(描述行为自动生成测试)
|
|
|
|
|
+- 自动发现页面组件并生成测试骨架
|
|
|
- 智能等待策略(根据组件特性自动调整)
|
|
- 智能等待策略(根据组件特性自动调整)
|
|
|
|
|
|
|
|
-**可视化与监控:**
|
|
|
|
|
-- 测试覆盖率可视化仪表盘
|
|
|
|
|
-- 测试执行时间热力图
|
|
|
|
|
-- 跨项目的测试模式库和最佳实践分享
|
|
|
|
|
-
|
|
|
|
|
-**生态系统:**
|
|
|
|
|
-- 支持更多 UI 库(Ant Design、Material-UI)
|
|
|
|
|
-- 开源为独立的 Playwright 插件
|
|
|
|
|
-- 社区贡献的测试模式扩展包
|
|
|
|
|
|
|
+**团队测试文化:**
|
|
|
|
|
+- 测试驱动开发成为团队标准实践
|
|
|
|
|
+- 新人培训包含 E2E 测试开发
|
|
|
|
|
+- 测试模式库和最佳实践分享
|
|
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|
|
@@ -518,109 +552,86 @@ await selectRadixOption(page, '残疾类型', '视力残疾');
|
|
|
|
|
|
|
|
### MVP Strategy & Philosophy
|
|
### MVP Strategy & Philosophy
|
|
|
|
|
|
|
|
-**MVP 方法:** Platform MVP - 构建可扩展的测试工具基础设施
|
|
|
|
|
|
|
+**MVP 方法:** 测试驱动 + 工具演进
|
|
|
|
|
|
|
|
-核心理念:不仅是解决当前残疾人管理测试的需求,更要建立一个可持续扩展的平台,让未来所有功能的 E2E 测试都能受益。
|
|
|
|
|
|
|
+核心理念:优先完成业务功能的 E2E 测试覆盖,在测试过程中自然抽象可复用工具。工具包是支持手段,不是目标本身。
|
|
|
|
|
|
|
|
**资源需求:**
|
|
**资源需求:**
|
|
|
- 团队规模:1-2 名开发者
|
|
- 团队规模:1-2 名开发者
|
|
|
-- 技能要求:TypeScript、Playwright、Radix UI 理解
|
|
|
|
|
-- 时间估算:MVP 1-2 周完成
|
|
|
|
|
|
|
+- 技能要求:TypeScript、Playwright、业务理解
|
|
|
|
|
+- 时间估算:每个业务功能 1-2 周
|
|
|
|
|
|
|
|
### MVP Feature Set (Phase 1)
|
|
### MVP Feature Set (Phase 1)
|
|
|
|
|
|
|
|
**核心用户旅程支持:**
|
|
**核心用户旅程支持:**
|
|
|
-- ✅ 张伟的快速测试开发旅程(完整的残疾人管理测试)
|
|
|
|
|
-
|
|
|
|
|
-**必须具备的能力(MVP):**
|
|
|
|
|
-
|
|
|
|
|
-**1. Radix UI Select 测试工具(最关键)**
|
|
|
|
|
- - `selectRadixOption()` - 静态枚举型下拉框
|
|
|
|
|
- - `selectRadixOptionAsync()` - 异步加载型下拉框
|
|
|
|
|
- - 完整的错误处理和等待策略
|
|
|
|
|
- - 清晰的错误提示信息
|
|
|
|
|
-
|
|
|
|
|
-**2. 文件上传测试工具**
|
|
|
|
|
- - `uploadFileToField()` - 通用文件上传函数
|
|
|
|
|
- - 支持 fixtures 目录管理
|
|
|
|
|
- - 支持多文件上传场景
|
|
|
|
|
-
|
|
|
|
|
-**3. 表单辅助函数**
|
|
|
|
|
- - `fillMultiStepForm()` - 多步骤表单流程
|
|
|
|
|
- - `scrollToSection()` - 滚动到特定区域
|
|
|
|
|
- - 表单验证错误处理
|
|
|
|
|
-
|
|
|
|
|
-**4. 动态列表管理**
|
|
|
|
|
- - `addDynamicListItem()` - 添加动态列表项
|
|
|
|
|
- - `deleteDynamicListItem()` - 删除动态列表项
|
|
|
|
|
- - 支持银行卡、备注等多类型列表
|
|
|
|
|
-
|
|
|
|
|
-**5. 对话框操作模式**
|
|
|
|
|
- - `handleDialog()` - 统一的对话框操作
|
|
|
|
|
- - `waitForDialogClosed()` - 等待对话框关闭
|
|
|
|
|
- - `cancelDialog()` - 取消对话框操作
|
|
|
|
|
-
|
|
|
|
|
-**6. 残疾人管理 E2E 测试(验证工具函数可用)**
|
|
|
|
|
- - 照片上传功能测试
|
|
|
|
|
- - 银行卡管理功能测试
|
|
|
|
|
- - 备注功能测试
|
|
|
|
|
- - 回访功能测试
|
|
|
|
|
- - 完整流程测试
|
|
|
|
|
-
|
|
|
|
|
-**7. 基础文档**
|
|
|
|
|
- - README 快速入门
|
|
|
|
|
- - 每个工具函数的使用示例
|
|
|
|
|
- - 常见问题解答
|
|
|
|
|
|
|
+- ✅ 张伟的快速测试开发旅程(残疾人管理测试)
|
|
|
|
|
+- 🔄 张伟继续旅程(区域管理测试)
|
|
|
|
|
+
|
|
|
|
|
+**Epic A: 残疾人管理 E2E 测试** ✅ 已完成
|
|
|
|
|
+
|
|
|
|
|
+**业务测试覆盖:**
|
|
|
|
|
+- 照片上传功能测试
|
|
|
|
|
+- 银行卡管理功能测试
|
|
|
|
|
+- 备注功能测试
|
|
|
|
|
+- 回访功能测试
|
|
|
|
|
+- 完整流程测试
|
|
|
|
|
+
|
|
|
|
|
+**测试过程中抽象的工具:**
|
|
|
|
|
+- `selectRadixOption()` - 静态枚举型下拉框
|
|
|
|
|
+- `selectRadixOptionAsync()` - 异步加载型下拉框
|
|
|
|
|
+- `uploadFileToField()` - 文件上传
|
|
|
|
|
+- 其他表单辅助函数
|
|
|
|
|
+
|
|
|
|
|
+**Epic B: 区域管理 E2E 测试** 🔄 当前目标
|
|
|
|
|
+
|
|
|
|
|
+**业务测试覆盖:**
|
|
|
|
|
+- 区域列表查看
|
|
|
|
|
+- 添加区域(省/市/区/街道)
|
|
|
|
|
+- 编辑区域
|
|
|
|
|
+- 删除区域
|
|
|
|
|
+- 级联选择测试
|
|
|
|
|
+- 完整流程测试
|
|
|
|
|
+
|
|
|
|
|
+**可能需要抽象的工具(按需):**
|
|
|
|
|
+- 级联选择工具(如现有 `selectCascade` 不满足需求)
|
|
|
|
|
+- 树形结构操作工具(如需要)
|
|
|
|
|
+
|
|
|
|
|
+**e2e-test-utils 包维护** 🌟 持续演进
|
|
|
|
|
+
|
|
|
|
|
+- 工具函数测试覆盖率 ≥ 80%
|
|
|
|
|
+- 完善文档和使用示例
|
|
|
|
|
+- 按业务需求添加新工具
|
|
|
|
|
|
|
|
**MVP 排除的功能(留给后续版本):**
|
|
**MVP 排除的功能(留给后续版本):**
|
|
|
- VS Code snippets
|
|
- VS Code snippets
|
|
|
- CLI 测试生成器
|
|
- CLI 测试生成器
|
|
|
-- 交互式调试模式
|
|
|
|
|
-- 其他 Radix 组件(Date Picker、Slider 等)
|
|
|
|
|
- AI 辅助测试生成
|
|
- AI 辅助测试生成
|
|
|
|
|
+- 跨项目的工具包开源
|
|
|
|
|
|
|
|
### Post-MVP Features
|
|
### Post-MVP Features
|
|
|
|
|
|
|
|
-**Phase 2 (Post-MVP) - 增长阶段:**
|
|
|
|
|
|
|
+**Phase 2 (Post-MVP) - 业务测试扩展:**
|
|
|
|
|
|
|
|
-**扩展组件支持:**
|
|
|
|
|
-- Date Picker 测试工具
|
|
|
|
|
-- Slider 测试工具
|
|
|
|
|
-- Tabs 测试工具
|
|
|
|
|
-- 表单验证错误处理模式
|
|
|
|
|
|
|
+**更多业务功能测试:**
|
|
|
|
|
+- 其他管理功能的 E2E 测试覆盖
|
|
|
|
|
+- 按业务优先级和风险评估确定测试顺序
|
|
|
|
|
+- 每个功能的完整测试用例
|
|
|
|
|
+
|
|
|
|
|
+**工具包按需演进:**
|
|
|
|
|
+- 在编写新业务测试时,如发现重复模式则抽象新工具
|
|
|
|
|
+- Date Picker、Slider、Tabs 等(如业务需要)
|
|
|
|
|
+- 表单验证错误处理模式(如业务需要)
|
|
|
|
|
|
|
|
**开发体验增强:**
|
|
**开发体验增强:**
|
|
|
- VS Code snippets 快速插入
|
|
- VS Code snippets 快速插入
|
|
|
-- Playwright trace 集成
|
|
|
|
|
-- 更详细的错误上下文信息
|
|
|
|
|
|
|
+- 测试模板和最佳实践文档
|
|
|
|
|
+- 更完善的错误提示和调试信息
|
|
|
|
|
|
|
|
**质量保障:**
|
|
**质量保障:**
|
|
|
- CI/CD 集成测试报告
|
|
- CI/CD 集成测试报告
|
|
|
- 测试覆盖率趋势追踪
|
|
- 测试覆盖率趋势追踪
|
|
|
- Flaky 测试检测和报告
|
|
- Flaky 测试检测和报告
|
|
|
|
|
|
|
|
-**复用验证:**
|
|
|
|
|
-- 至少 3 个其他管理功能复用工具函数
|
|
|
|
|
-- 收集用户反馈并迭代优化
|
|
|
|
|
-
|
|
|
|
|
-**Phase 3 (Expansion) - 扩展阶段:**
|
|
|
|
|
-
|
|
|
|
|
-**高级功能:**
|
|
|
|
|
-- CLI 命令生成测试模板
|
|
|
|
|
-- 交互式调试模式(慢动作、可视化等待)
|
|
|
|
|
-- 网络请求 Mock 和断言辅助函数
|
|
|
|
|
-- 多窗口/多标签页测试工具
|
|
|
|
|
-
|
|
|
|
|
-**智能化:**
|
|
|
|
|
-- 自动发现页面中的 Radix 组件并生成测试骨架
|
|
|
|
|
-- AI 辅助测试编写(描述行为自动生成测试)
|
|
|
|
|
-- 智能等待策略(根据组件特性自动调整)
|
|
|
|
|
-
|
|
|
|
|
-**生态系统:**
|
|
|
|
|
-- 支持更多 UI 库(Ant Design、Material-UI)
|
|
|
|
|
-- 开源为独立的 Playwright 插件
|
|
|
|
|
-- 社区贡献的测试模式扩展包
|
|
|
|
|
-
|
|
|
|
|
### Risk Mitigation Strategy
|
|
### Risk Mitigation Strategy
|
|
|
|
|
|
|
|
**技术风险:**
|
|
**技术风险:**
|
|
@@ -630,47 +641,53 @@ await selectRadixOption(page, '残疾类型', '视力残疾');
|
|
|
- 设计可扩展的函数签名,支持自定义选择器
|
|
- 设计可扩展的函数签名,支持自定义选择器
|
|
|
- 工具函数自测,快速发现问题
|
|
- 工具函数自测,快速发现问题
|
|
|
|
|
|
|
|
|
|
+**业务测试风险:**
|
|
|
|
|
+- **风险:** 业务功能变更导致测试用例失效
|
|
|
|
|
+- **缓解:**
|
|
|
|
|
+ - 测试用例与业务实现解耦
|
|
|
|
|
+ - 使用 Page Object 模式提高可维护性
|
|
|
|
|
+ - 定期审查和更新测试用例
|
|
|
|
|
+
|
|
|
**市场/采用风险:**
|
|
**市场/采用风险:**
|
|
|
- **风险:** 团队成员不愿意使用新工具,继续用老方法
|
|
- **风险:** 团队成员不愿意使用新工具,继续用老方法
|
|
|
- **缓解:**
|
|
- **缓解:**
|
|
|
- - MVP 验证:先在残疾人管理测试中证明价值
|
|
|
|
|
- - 渐进式推广:让早期使用者(张伟)推荐给团队
|
|
|
|
|
- - 完善文档:降低学习成本,提供即时价值
|
|
|
|
|
|
|
+ - 通过实际业务测试证明价值
|
|
|
|
|
+ - 渐进式推广:让早期使用者推荐给团队
|
|
|
|
|
+ - 完善文档:降低学习成本
|
|
|
|
|
|
|
|
**资源风险:**
|
|
**资源风险:**
|
|
|
-- **风险:** 开发时间超出预期
|
|
|
|
|
|
|
+- **风险:** 测试开发时间超出预期
|
|
|
- **缓解:**
|
|
- **缓解:**
|
|
|
- - 明确 MVP 边界:只实现 6 个核心函数
|
|
|
|
|
- - 时间盒:MVP 限制在 1-2 周
|
|
|
|
|
- - 降级方案:如果时间紧张,优先完成 Select 工具函数(最核心)
|
|
|
|
|
|
|
+ - 按业务优先级排序,先做高价值功能
|
|
|
|
|
+ - 每个业务功能独立时间盒(1-2 周)
|
|
|
|
|
+ - 降级方案:优先保证关键路径的测试覆盖
|
|
|
|
|
|
|
|
**质量风险:**
|
|
**质量风险:**
|
|
|
-- **风险:** 工具函数本身有 bug,导致测试不稳定
|
|
|
|
|
|
|
+- **风险:** 测试不稳定,经常 flaky 失败
|
|
|
- **缓解:**
|
|
- **缓解:**
|
|
|
- 工具函数编写单元测试
|
|
- 工具函数编写单元测试
|
|
|
- - 在残疾人管理测试中验证
|
|
|
|
|
|
|
+ - 20 次连续运行稳定性验证
|
|
|
- 代码审查确保质量
|
|
- 代码审查确保质量
|
|
|
- - 20 次连续运行稳定性测试
|
|
|
|
|
|
|
|
|
|
### Scope Decision Rationale
|
|
### Scope Decision Rationale
|
|
|
|
|
|
|
|
**为什么 MVP 范围这样设计:**
|
|
**为什么 MVP 范围这样设计:**
|
|
|
|
|
|
|
|
-1. **聚焦核心价值**:Select 组件是最难测试的,也是最常用的,优先解决它
|
|
|
|
|
|
|
+1. **业务价值优先**:直接交付业务测试覆盖,确保产品质量
|
|
|
|
|
|
|
|
-2. **验证驱动**:通过残疾人管理测试验证工具函数的可用性,确保不是纸上谈兵
|
|
|
|
|
|
|
+2. **工具自然演进**:不预设工具需求,从实践中抽象
|
|
|
|
|
|
|
|
-3. **渐进式扩展**:MVP 验证成功后再扩展到其他组件和功能
|
|
|
|
|
|
|
+3. **渐进式扩展**:每个业务功能独立 Epic,可并行或串行
|
|
|
|
|
|
|
|
-4. **可测量成果**:每个功能都有明确的成功标准(时间、覆盖率、复用次数)
|
|
|
|
|
|
|
+4. **可测量成果**:每个 Epic 都有明确的成功标准(覆盖率、稳定性)
|
|
|
|
|
|
|
|
5. **风险可控**:范围明确,时间盒限制,有降级方案
|
|
5. **风险可控**:范围明确,时间盒限制,有降级方案
|
|
|
|
|
|
|
|
**MVP 成功标志:**
|
|
**MVP 成功标志:**
|
|
|
-- ✅ 6 个核心工具函数实现并测试通过
|
|
|
|
|
-- ✅ 残疾人管理 E2E 测试覆盖所有子功能
|
|
|
|
|
|
|
+- ✅ 残疾人管理 E2E 测试覆盖关键流程 100%
|
|
|
- ✅ 测试连续运行 20 次,100% 通过
|
|
- ✅ 测试连续运行 20 次,100% 通过
|
|
|
-- ✅ 至少 1 个团队成员(非开发者)成功使用工具函数编写测试
|
|
|
|
|
|
|
+- ✅ 从测试中抽象可复用工具
|
|
|
|
|
+- 🔄 区域管理 E2E 测试覆盖关键流程 100%
|
|
|
|
|
|
|
|
---
|
|
---
|
|
|
|
|
|