Story 13.4: 人员状态更新跨端同步

Status: in-progress

Story

作为测试开发者，我想要验证后台更新人员状态后双小程序的数据同步，以便确保跨端数据同步的正确性和时效性。

Acceptance Criteria

AC1: 后台更新人员工作状态 → 企业小程序验证

Given 后台订单管理功能已完成（Epic 10） When 测试者在管理后台更新人员的工作状态 Then 测试应验证以下功能：

使用 OrderManagementPage 打开订单人员管理对话框
修改人员工作状态（如：未就业 → 待就业 → 已就业）
验证后台列表中状态更新正确
在企业小程序订单详情中验证人员状态同步正确
验证数据同步在合理时间内完成（≤ 10 秒）

AC2: 后台更新人员工作状态 → 人才小程序验证

Given 后台订单管理功能已完成（Epic 10） When 测试者在管理后台更新人员的工作状态 Then 测试应验证以下功能：

使用 OrderManagementPage 修改人员工作状态
在人才小程序订单列表中验证人员状态同步正确
在人才小程序订单详情中验证人员状态同步正确
验证数据同步在合理时间内完成（≤ 10 秒）

AC3: 多种工作状态流转测试

Given 人员工作状态有多种可能值 When 测试者在后台更新不同状态 Then 测试应验证以下状态流转：

未就业 → 待就业
待就业 → 已就业
已就业 → 已离职
已离职 → 未就业（重新入职）
验证所有状态流转在双小程序中正确同步

AC4: 状态字段完整性验证

Given 人员状态包含多个字段 When 测试者在后台更新状态 Then 测试应验证以下字段：

工作状态（workStatus）正确同步
入职日期（hireDate）正确同步
离职日期（resignDate）正确同步
验证所有字段在双小程序中正确显示

AC5: 测试数据隔离和清理

Given 跨端测试涉及多个系统 When 执行测试 Then 测试应遵循以下策略：

使用唯一标识符创建测试人员（避免冲突）
测试后恢复人员到原始状态
验证恢复后双小程序显示原始状态

AC6: 代码质量标准

Given 遵循项目测试规范 When 编写测试代码 Then 代码应符合以下标准：

使用 TIMEOUTS 常量定义超时
使用 data-testid 选择器（优先级高于文本选择器）
测试文件命名：status-update-sync.spec.ts
完整的测试描述和注释
TypeScript 类型安全
通过 pnpm typecheck 类型检查

Tasks / Subtasks

阶段 1: EXPLORE - Playwright MCP 探索（RED 之前）

任务 0: Playwright MCP 探索验证
- 0.1 启动子代理使用 Playwright MCP 手动验证完整测试流程
- 0.2 记录验证的选择器（优先 data-testid，避免文本选择器）
- 0.3 记录交互模式（打开对话框、选择状态、保存）
- 0.4 记录数据流（API 调用、请求/响应格式、同步时间）
- 0.5 立即修复发现的应用层 bug（如果有）
- 0.6 生成测试代码骨架（基于验证的流程）
- 0.7 将探索结果更新到本文档 Dev Notes 的"Playwright MCP 探索结果"部分

阶段 2: RED - 编写测试（基于任务 0 的探索结果）

[ ] 任务 1: 创建跨端测试文件和基础设施 (AC: #6)
- 1.1 基于任务 0 的探索结果创建 web/tests/e2e/specs/cross-platform/status-update-sync.spec.ts
- 1.2 配置测试 fixtures（使用任务 0 验证过的选择器）
- 1.3 添加测试前置条件（需要测试订单和人员数据）
[ ] 任务 2: 实现后台更新状态测试 (AC: #1, #3, #4)
- 2.1 使用任务 0 验证的选择器编写"后台更新人员工作状态"测试
- 2.2 验证后台列表中状态更新正确
- 2.3 获取并存储人员和订单关键信息
[ ] 任务 3: 实现企业小程序验证测试 (AC: #1, #2, #4)
- 3.1 使用任务 0 验证的选择器编写"企业小程序显示更新后状态"测试
- 3.2 验证工作状态字段同步正确
- 3.3 验证入职日期和离职日期字段同步正确
- 3.4 实现数据同步等待机制（基于任务 0 实测的同步时间）
[ ] 任务 4: 实现人才小程序验证测试 (AC: #2, #4)
- 4.1 使用任务 0 验证的选择器编写"人才小程序显示更新后状态"测试
- 4.2 验证工作状态字段同步正确
- 4.3 验证入职日期和离职日期字段同步正确

阶段 3: GREEN - 实现代码（让测试通过）

[ ] 任务 5: 实现测试数据清理策略 (AC: #5)
- 5.1 添加 afterEach 钩子恢复人员状态
- 5.2 验证恢复后双小程序显示原始状态
[ ] 任务 6: 实现数据同步时效性验证 (AC: #1, #2)
- 6.1 实现轮询等待机制
- 6.2 验证正常同步时间（基于任务 0 的实测数据，应 ≤ 5 秒）
- 6.3 验证超时处理（最长 10 秒）

阶段 4: REFACTOR - 优化代码质量

任务 7: 验证代码质量 (AC: #6)
- 7.1 运行 pnpm typecheck 验证类型检查
- 7.2 运行测试确保所有测试通过
- 7.3 验证使用 data-testid 选择器（任务 0 已确认）

Dev Notes

Playwright MCP 探索结果（Task 0）

探索日期: 2026-01-14

探索方法: 使用 Playwright MCP 工具进行后台页面探索

探索发现:

浏览器环境问题: Playwright MCP 在当前开发环境中遇到页面崩溃和超时问题，无法完成完整的手动探索流程
替代方案: 基于现有 Page Object (OrderManagementPage) 和已完成测试（order-create-sync.spec.ts）的模式创建测试

选择器验证结果（基于现有 Page Object）: | 功能 | 选择器 | 来源 | |------|--------|------| | 订单列表 | table tbody tr | OrderManagementPage | | 订单详情对话框 | [role="dialog"] | OrderManagementPage.openDetailDialog | | 人员列表 | table tbody tr (在对话框中) | OrderManagementPage.getPersonListFromDetail | | 工作状态选择器 | getByRole('combobox') | OrderManagementPage.updatePersonWorkStatus | | 状态选项 | getByRole('option') | OrderManagementPage.updatePersonWorkStatus |

数据流记录:

API 端点: 后台通过 updatePersonWorkStatus 方法调用相关 API
状态映射: WORK_STATUS 枚举 → 中文标签（not_working: "未入职", pre_working: "已入职", working: "工作中", resigned: "已离职"）
同步时间: 预计 3-5 秒（基于类似测试的经验）

测试文件创建: web/tests/e2e/specs/cross-platform/status-update-sync.spec.ts

Epic 13 背景和依赖

Epic 13: 跨端数据同步测试 (Epic E)

目标: 验证后台操作后小程序端的数据同步，覆盖完整的业务流程
业务分组: Epic E（跨端数据同步测试）
背景: 真实用户旅程跨越管理后台和小程序，需要验证数据同步的正确性和时效性
依赖:
- Epic 10: ✅ 已完成（订单管理 E2E 测试）
- Epic 12: ✅ 已完成（小程序登录测试）
- Story 13.1: ✅ 已完成（后台创建订单 → 企业小程序验证）

Epic 13 Story 依赖关系：

Story 13.1: 后台创建订单 → 企业小程序验证 ✅
Story 13.2: 后台编辑订单 → 企业小程序验证
Story 13.3: 后台添加人员 → 人才小程序验证
Story 13.4: 后台更新状态 → 双小程序验证 ← 当前 Story
Story 13.5: 跨端测试稳定性验证
Story 13.6: 首页看板数据联动专项测试 ✅
Story 13.7: 首页导航和交互测试

Epic 10 关键经验（订单管理）

从已完成的 Epic 10 中学习到的订单管理模式：

OrderManagementPage 可用方法：

// 订单人员管理
async openPersonManagementDialog(orderName: string): Promise<void>
async updatePersonWorkStatus(personId: string, workStatus: string): Promise<FormSubmitResult>
async setPersonHireDate(personId: string, hireDate: string): Promise<FormSubmitResult>
async setPersonResignDate(personId: string, resignDate: string): Promise<FormSubmitResult>

// 获取人员状态
async getPersonStatus(personId: string): Promise<PersonStatus>

工作状态枚举：

enum WorkStatus {
  UNEMPLOYED = '未就业',    // 未就业
  PENDING = '待就业',       // 待就业
  EMPLOYED = '已就业',      // 已就业
  RESIGNED = '已离职',      // 已离职
}

人员状态数据结构：

interface PersonStatus {
  personId: string;
  personName: string;
  workStatus: WorkStatus;
  hireDate?: string;
  resignDate?: string;
  orderId: string;
  orderName: string;
}

Epic 12 关键经验（小程序登录）

从已完成的 Epic 12 中学习到的小程序模式：

EnterpriseMiniPage 可用方法：

// 订单详情
async openOrderDetail(orderName: string): Promise<void>
async getOrderPersonList(): Promise<PersonStatus[]>
async getPersonStatus(personId: string): Promise<PersonStatus>

TalentMiniPage 可用方法：

// 订单详情
async openOrderDetail(orderName: string): Promise<void>
async getOrderPersonList(): Promise<PersonStatus[]>
async getPersonStatus(personId: string): Promise<PersonStatus>

状态更新选择器策略

后台人员管理对话框选择器（待验证）： | 功能 | data-testid | |------|-------------| | 人员管理按钮 | person-management-button | | 工作状态下拉框 | work-status-selector | | 入职日期输入框 | hire-date-input | | 离职日期输入框 | resign-date-input | | 保存按钮 | save-person-button |

小程序订单详情选择器（待验证）： | 功能 | data-testid | |------|-------------| | 订单详情容器 | mini-order-detail | | 人员列表容器 | mini-person-list | | 人员状态标签 | mini-person-status-{personId} | | 入职日期标签 | mini-hire-date-{personId} | | 离职日期标签 | mini-resign-date-{personId} |

数据同步等待策略

轮询等待模式：

async waitForStatusUpdate(
  personId: string,
  expectedStatus: string,
  timeout: number = 10000
): Promise<boolean> {
  const startTime = Date.now();
  while (Date.now() - startTime < timeout) {
    const status = await this.getPersonStatus(personId);
    if (status.workStatus === expectedStatus) {
      return true;
    }
    await this.page.waitForTimeout(500); // 每 500ms 检查一次
  }
  return false;
}

测试数据准备策略

前置条件：

需要测试订单数据（使用 Story 11.2 创建的平台、Story 11.5 创建的公司）
需要测试人员数据（使用 Story 12.3 创建的人才用户）
需要订单关联人员（使用 Story 13.3 的方法）

测试数据唯一性：

const timestamp = Date.now();
const personData = {
  name: `状态同步测试人员_${timestamp}`,
  idCard: generateUniqueIdCard(timestamp),
};

测试数据清理策略

清理方法：

test.afterEach(async ({ orderManagementPage, originalStatus }) => {
  // 在后台恢复人员到原始状态
  await orderManagementPage.updatePersonWorkStatus(
    personId,
    originalStatus.workStatus
  );
});

参考文档

架构文档：

_bmad-output/planning-artifacts/epics.md#Epic 13
_bmad-output/project-context.md
docs/standards/e2e-radix-testing.md

相关 Story 文档：

10-9-order-person-tests.md (人员关联功能测试)
12-4-enterprise-mini-page-object.md (企业小程序 Page Object)
12-6-talent-mini-page-object.md (人才小程序 Page Object)
13-1-order-create-sync.md (订单列表同步测试)
13-3-person-add-sync.md (后台添加人员测试)

Dev Agent Record

Agent Model Used

Created by create-story workflow

Debug Log References

Story 13.4 开发记录 (2026-01-14):

Task 0: Playwright MCP 探索验证: 部分完成
- Playwright MCP 遇到浏览器环境问题（页面崩溃、超时）
- 使用现有 Page Object 和已完成测试作为参考创建测试
Task 1: 创建跨端测试文件: 已完成
- 创建了 web/tests/e2e/specs/cross-platform/status-update-sync.spec.ts
- 基于现有 OrderManagementPage.updatePersonWorkStatus 方法
- 包含后台更新、企业小程序验证、人才小程序验证三个主要测试
Task 7: 测试运行时调试: 进行中
- 测试遇到超时问题，需要进一步调试
- 可能原因：开发服务器响应慢、网络延迟、测试等待时间设置

Completion Notes List

2026-01-14 开发进度:

✅ 测试文件创建完成
✅ 测试基础设施就绪（fixtures, helpers）
⏳ 测试运行时调试（超时问题需要环境调试）
❌ 测试验证（需要解决超时问题）

File List

Created files:

/mnt/code/188-179-template-6/web/tests/e2e/specs/cross-platform/status-update-sync.spec.ts

Modified files:

/mnt/code/188-179-template-6/_bmad-output/implementation-artifacts/13-4-status-update-sync.md

Change Log

2026-01-14: Story 13.4 开发进度更新
- 创建测试文件 status-update-sync.spec.ts
- 完成测试基础设施编写
- 遇到测试运行时超时问题，需要进一步调试
- 状态：in-progress
2026-01-14: Story 13.4 创建完成
- 人员状态更新跨端同步需求
- 工作状态流转测试
- 状态字段完整性验证
- 状态：backlog

13-4-status-update-sync.md 13 KB Түүх Анхны өгөгдөл