qihuaiflow/tests/improvement-plan.md

测试工作改进计划

文档信息

项目	内容
文档名称	AIFlow PaaS平台 - 测试工作改进计划
创建日期	2026-05-27
创建人	测试工程师（QA）
改进原因	用户反馈系统功能操作后无响应（知识图谱构建点击无响应、Token驾驶舱空白页、资产页面空白页等），测试未覆盖

---

1. 问题根因分析

1.1 已暴露的缺陷及测试遗漏原因

序号	用户反馈问题	代码层面根因	测试遗漏原因
1	Token驾驶舱空白页	TokenDashboardPage.tsx 第341行：log.cost.toFixed(2) — 当后端返回的日志数据中 cost 字段为 undefined 或 null 时，JS运行时报错导致React组件崩溃，页面白屏	API测试仅验证了接口返回的HTTP状态码(200)，未检查数据结构完整性；UI测试仅验证了页面"加载成功"时的快照，未测试异常数据场景
2	知识库构建知识图谱点击无响应	KnowledgePage.tsx 第892-902行：构建知识图谱按钮仅在知识库卡片展开状态(isExpanded)下渲染。用户必须先点击卡片展开，再点击构建按钮。若卡片处于折叠状态，用户点击的只是卡片头区域(触发toggleExpand)，看不到按钮	UI测试时仅验证了页面元素的存在性，未模拟"用户不展开卡片直接看到按钮"的真实交互路径
3	资产页面空白页	CSS布局缺陷：.assets-page 设置 height:100%，但若父容器 .front-main 未正确计算高度，页面将塌缩为高度0，视觉上呈现"空白"；同时 assetsAPI.getCategories() 返回404时可能导致后续渲染异常	API测试验证getCategories时发现404但被记录为可通过；UI测试可能因管理员账号数据导致页面正常渲染，未覆盖数据为空/异常的边界场景
4	退出登录按钮缺失	FrontLayout.tsx 第102-115行：退出按钮在侧边栏存在，但侧边栏折叠后文本标签隐藏，仅剩图标难以辨认	UI测试仅验证了页面整体布局的快照，未逐项检查每个功能按钮的可见性

1.2 根本原因总结

经过对三份测试报告和前后端代码的深入分析，总结出以下三个根本原因：

原因一：API测试只验证HTTP状态码，不验证数据完整性

接口自动化测试的判定标准为"HTTP 200 = PASS"，但未检查返回数据的结构、必要字段是否存在、字段类型是否正确。例如，Token驾驶舱的API返回了200，但返回的日志数据中 cost 字段缺失（或为null），前端组件崩溃。API测试脚本应该对每条返回数据的关键字段进行类型和值的断言。

原因二：UI测试仅做"快照验证"，未模拟真实用户操作流程

UI自动化测试中，对每个页面的测试方式是：导航到页面 → 截取快照 → 查看是否存在预期文本。这种方式只能验证页面初始渲染状态，无法覆盖以下场景：

• 用户点击按钮后是否有响应（如知识图谱构建按钮）
• 页面在异常数据下是否仍然渲染正常（如cost为null时）
• 需要前置操作的交互流程（如先展开卡片再点击内部按钮）
• 浏览器控制台是否有JS报错

原因三：测试用例缺少"交互响应验证"和"渲染健壮性"维度

207个测试用例中，大部分用例的预期结果是"功能正常/X显示正确/操作成功"，缺少以下类型的验证：

• 异常数据输入时的页面稳定性（空白页检测）
• 按钮点击后是否有UI反馈（loading状态、错误提示、成功提示）
• 浏览器控制台JavaScript报错检测
• 数据边界（空数组、null值、undefined字段）安全验证

---

2. 改进措施

2.1 UI自动化测试改进

2.1.1 从"快照验证"升级为"交互流程验证"

改进前（旧模式）：

1. 导航到页面
2. 截取快照
3. 查看是否存在预期文本/元素
4. 标记为 PASS

改进后（新模式）：

1. 导航到页面
2. 检查浏览器控制台是否有JS错误（console.error/warning）
3. 验证页面核心区域是否渲染（非空白页检测）
4. 验证所有关键按钮存在且可交互（非disabled状态）
5. 对每个可点击按钮，执行点击操作
6. 验证点击后的响应：
   - 是否有UI状态变化（loading动画、弹窗、切换）
   - 是否有成功/失败提示（toast、alert、模态框）
   - 数据展示是否更新（列表刷新、图表变化）
   - 控制台是否有新的JS错误
7. 对每个输入框，执行输入操作
8. 验证输入后的响应
9. 完成所有交互后标记为 PASS/FAIL

2.1.2 建立"空白页检测"标准验证项

每个页面测试必须包含以下基础断言：

验证项	检测方式	判定标准
页面是否白屏	检查根DOM元素的 innerText 长度 > 0	若为空字符串或无文本内容 → FAIL
页面内容是否可见	检查主内容区的 offsetHeight > 0	若为0 → FAIL（CSS布局塌缩）
控制台是否有报错	监听 console.error 输出	若有任何error → FAIL
数据为空时的兜底展示	清空后端数据后刷新页面	应显示"暂无数据"等空状态提示，而非空白或崩溃
Loading状态展示	在数据加载中检查页面状态	应显示loading动画或骨架屏，不应该是空白

2.1.3 采用Playwright真正模拟用户操作

UI自动化测试中使用Playwright进行完整的用户操作流程模拟：

• 使用 page.click() 真实点击按钮
• 使用 page.fill() 真实输入文本
• 使用 page.selectOption() 真实选择下拉框
• 等待每次交互后的页面响应（waitForSelector、waitForResponse）
• 监听网络请求，确认API调用正确发送
• 禁止仅依赖静态页面快照做判断

2.2 接口自动化测试改进

2.2.1 从"状态码验证"升级为"结构和数据验证"

改进前（旧模式）：

# 仅验证 HTTP 状态码
assert res.status_code == 200

改进后（新模式）：

# 1. 验证 HTTP 状态码
assert res.status_code == 200

# 2. 验证响应结构
data = res.json()
assert "data" in data

# 3. 验证必要字段存在且类型正确
for item in data["data"]["items"]:
    assert isinstance(item.get("id"), str), f"id字段缺失或类型错误: {item}"
    assert "total_tokens" in item or "totalTokens" in item
    # 对数值字段验证是否为数字类型
    assert isinstance(item.get("cost", 0), (int, float)), f"cost字段类型错误: {item.get('cost')}"

# 4. 验证空列表场景
empty_result = requests.get(api + "?search=nonexistent_keyword_xyz")
assert empty_result.status_code == 200
assert len(empty_result.json()["data"]["items"]) == 0

2.2.2 增加"前端兼容性"验证维度

API测试需要验证返回数据是否与前端代码的数据提取逻辑兼容：

• 检查前端期望的字段是否都存在于API返回中
• 检查后端返回的字段类型是否与前端TypeScript类型定义一致
• 检查前端代码中使用的 ?. 可选链访问的深层字段是否存在

2.3 测试用例设计改进

2.3.1 增加"渲染健壮性"测试维度

每个模块的测试用例必须包含：

用例编号模板	用例名称	测试内容
TC-{MOD}-ROBUST-001	空白页检测	页面首次加载时不出现完全空白（无任何DOM内容）的情况
TC-{MOD}-ROBUST-002	空数据状态	当后端返回空数据时，页面显示"暂无数据"兜底而非崩溃
TC-{MOD}-ROBUST-003	异常数据兼容	当后端返回缺失必要字段的数据时，页面不崩溃
TC-{MOD}-ROBUST-004	按钮响应验证	所有可见按钮点击后均有一致性反馈（loading/提示/跳转）
TC-{MOD}-ROBUST-005	控制台无报错	页面加载和交互过程中浏览器控制台无JS异常

2.3.2 增加"用户路径"测试维度

模拟用户从登录到完成业务目标的完整操作路径：

• 注册 → 登录 → 浏览首页 → 使用各模块功能
• 每个路径中的每一步操作都需要明确的验证断言

---

3. 新的测试流程规范

3.1 三阶段测试的改进要求

阶段一：测试用例生成

• 【新增】每个模块增加"渲染健壮性"测试用例（至少5条）
• 【新增】每个模块增加"用户操作路径"端到端测试用例
• 【保留】PRD功能点覆盖比对

阶段二：接口自动化测试

• 【新增】每项API测试必须包含：状态码验证 + 响应结构验证 + 关键字段类型验证
• 【新增】必须包含空数据/异常参数场景测试
• 【新增】必须检查返回数据与前端TypeScript类型定义的一致性
• 【保留】权限隔离、日志不可删除等核心检查

阶段三：UI自动化测试

• 【新增】每个页面必须执行控制台错误监听
• 【新增】每个页面必须执行空白页检测（DOM文本内容检查）
• 【新增】每个页面的所有按钮必须执行点击响应验证
• 【新增】每个页面的所有表单必须执行输入操作验证
• 【新增】必须覆盖数据为空/异常时的页面状态

3.2 测试报告的改进要求

测试报告中必须包含以下新增章节：

3.2.1 控制台错误报告

| 页面 | 错误类型 | 错误信息 | 严重程度 |
|------|---------|---------|----------|

3.2.2 交互响应报告

| 页面 | 操作按钮 | 预期响应 | 实际响应 | 状态 |
|------|---------|---------|---------|------|

3.2.3 空白页检测报告

| 页面 | 空白页检测 | 空数据检测 | 异常数据检测 | 状态 |
|------|----------|----------|------------|------|

---

4. 具体执行方案

4.1 立即执行：针对已发现问题的补测

需要在当前测试周期内补充以下测试：

优先级	测试项	测试内容
P0	Token驾驶舱页面 - 异常数据渲染	模拟后端返回cost=null的日志数据，验证页面不崩溃
P0	Token驾驶舱页面 - 空白页检测	验证页面首次加载有内容渲染（非完全空白）
P0	知识库页面 - 知识图谱按钮交互	模拟完整操作：展开知识库卡片 → 点击"构建知识图谱" → 验证有响应反馈
P0	资产页面 - 空白页检测	验证页面首次加载有内容渲染，检查categories API异常时的表现
P1	退出登录按钮 - 可见性	验证侧边栏展开和折叠两种状态下退出登录按钮的可发现性
P1	全站所有页面 - 控制台错误扫描	在每个页面导航和交互中监听控制台错误

4.2 后续测试遵循新规范

从下一轮测试开始，严格按照本改进计划中的第3节"新的测试流程规范"执行三阶段测试，确保不再出现"用户反馈有Bug但测试报告全通过"的情况。

---

5. 总结

本次测试工作的核心问题是测试深度不足：API测试停留在HTTP状态码层面，UI测试停留在页面快照层面，缺少对前端渲染健壮性、用户交互响应和异常数据兼容性的验证。

改进的核心思路是：

1. API测试：从"状态码验证"升级为"数据结构+类型+字段完整性验证"
2. UI测试：从"快照验证"升级为"真实用户交互流程验证 + 控制台错误监控 + 空白页检测"
3. 测试用例：从"功能点覆盖"扩展为"功能点覆盖 + 渲染健壮性 + 用户操作路径"

---

文档创建时间: 2026-05-27 创建人: 测试工程师（QA） 版本: v1.0