xst/QaAutomationHub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
QaAutomationHub/output/analysis/安徽运八需求_评审报告.md
T

15 KiB
Raw Permalink Blame History

安徽运八需求 评审报告

评审时间: 2026-07-13 评审对象: output/test_cases/安徽运八需求_测试用例.md (128条) 评审依据: review_checklist.md / test_case_template.md / definition_of_done.md / 风险评估报告

评审概览

指标 值
用例总数 128
阻断项 7
建议项 7
优化项 7
评分 80/100

阻断项

B-001: R2_004 字段数标题与预期结果不一致（标题14 vs 实际列举17）

  • 用例编号: AH_REPORT_R2_004
  • 问题: 标题声明"验证第二次上报列表14个字段完整"，但预期结果中逐项列举了17个字段（货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/承运运费/总金额/付款方式/付款时间/收款人/收款账号/收款账号类型/核验状态/异常项/上报状态/操作）。执行人无法确认应以标题为准还是以预期结果为准。
  • 修复建议: 与需求/前端确认第二次上报列表的实际列数，统一标题和预期结果中的字段数量和名称列表。

B-002: R3_002 字段数标题与预期结果不一致（标题11 vs 实际列举13）

  • 用例编号: AH_REPORT_R3_002
  • 问题: 标题声明"验证第三次上报列表展示11个字段完整"，预期结果文字也写"列表展示11个字段"，但实际逐项列举了13个字段（货源单号/运单号/托运单号/车牌号/司机姓名/托运方名称/发票号码/发票金额/开票日期/核验状态/异常原因/上报状态/操作）。文字表述"11个字段"与列举内容自相矛盾。
  • 修复建议: 确认第三次上报列表的准确字段数，修正标题和预期结果中的数字，使其与列举的字段名数一致。

B-003: LOG_006 字段数标题与预期结果不一致（标题9 vs 实际列举11）

  • 用例编号: AH_REPORT_LOG_006
  • 问题: 标题声明"验证上报日志列表9个字段完整展示"，但预期结果中逐项列举了11个字段（序号/货源单号/运单号/托运单号/上报阶段/上报结果/接口URL/HTTP状态码/响应时间/上报时间/操作）。
  • 修复建议: 确认上报日志列表实际列数，统一标题和预期结果。

B-004: APL_003 字段数标题与预期结果不一致（标题13 vs 实际列举14）

  • 用例编号: AH_REPORT_APL_003
  • 问题: 标题声明"验证申诉记录列表13个字段完整展示"，但预期结果逐项列举了14个字段（运单号/托运单号/车牌号/司机姓名/托运方名称/上报阶段/核验状态/异常项/申诉状态/申诉时间/申诉人/省平台反馈结果/监管平台反馈时间/操作）。
  • 修复建议: 确认申诉记录列表实际列数，统一标题和预期结果。

B-005: R3_003 字段数标题与预期结果不一致（标题17 vs 实际合计19）

  • 用例编号: AH_REPORT_R3_003
  • 问题: 标题声明"验证第三次上报详情弹窗发票信息17字段完整展示"，但预期结果中各分组字段合计为19个：发票基础字段5个（托运单号数组、发票号码、发票代码号、发票金额(价税合计)、开票日期）+ 销售方8字段（名称/纳税人识别号/地址/电话/开户行/银行账户/账号/联系人）+ 受票方6字段（名称/纳税人识别号/地址/电话/开户行/银行卡号）= 19。标题的"17"与实际合计"19"不匹配。
  • 修复建议: 逐字段核对发票信息分组，确认准确字段数为17还是19，修正标题或补充/删除预期结果中的字段。

B-006: APL_015 预期结果使用"可能"措辞，不可验证

  • 用例编号: AH_REPORT_APL_015
  • 问题: 预期结果中出现"系统可能有超时告警提醒运营人员跟进"——"可能"表示该行为不确定，无法作为可验证的测试断言。若超时告警是需求要求的必要行为，则必须断言为"系统触发超时告警通知运营人员"；若当前未明确，应标记为待确认项。
  • 修复建议: (1) 若超时告警已纳入需求，将"可能"改为确定性描述并补充告警渠道和内容；(2) 若尚未明确，在备注中增加 > ⚠️ 待确认：申诉超时告警机制是否实现、告警渠道和阈值。

B-007: CROSS_003 违反原子性原则——单条用例验证完整四阶段端到端流程

  • 用例编号: AH_REPORT_CROSS_003
  • 问题: 该用例将装货完成、财务打款、发票开具、ETC上传全部串联在一条用例中验证，跨越4个上报阶段和多个触发条件。任一环节失败时，无法快速定位问题在哪个阶段。此外，各阶段已有独立的单阶段用例覆盖（R1/R2/R3/ETC系列），此全链路用例与它们形成冗余但缺乏精确定位能力。
  • 修复建议: 保留此用例作为冒烟测试或集成验证（类型改为"冒烟测试"），但应将各阶段的独立断言缩减为"全链路各阶段按序成功完成，看板和日志数据一致"，移除重复的具体阶段内断言；或拆分为阶段衔接用例（如"第一阶段成功后第二阶段可触发"），每种衔接一个用例。

建议项

S-001: LOG_001 和 LOG_003 优先级 P0 偏高，建议降为 P1

  • 用例编号: AH_REPORT_LOG_001, AH_REPORT_LOG_003
  • 问题: 上报日志属于审计/支持类功能，日志搜索和阶段筛选并非用户核心业务操作流程，置于 P0 会稀释 P0 集合的聚焦度。当前 P0 已有 28 条（占比 22%），将这两个降级可优化 P0 密度。
  • 修复建议: 降为 P1。核心原因：日志功能不可用时不影响上报主流程和业务闭环，不符合 P0 定义（核心流程阻断/资损风险）。

S-002: APL_015 类型建议改为"易用性测试"

  • 用例编号: AH_REPORT_APL_015
  • 问题: 该用例验证的是"用户长时间等待后的系统状态提示和超时告警体验"，属于用户体验/易用性范畴，而非纯功能正确性验证。
  • 修复建议: 将 类型 从 功能测试 改为 易用性测试。

S-003: R1_003 同时验证3个省份，建议按省份拆分为独立用例

  • 用例编号: AH_REPORT_R1_003
  • 问题: 该用例在一条用例中同时验证安徽(34)、云南(28)、四川(51)三个省份的上报触发行为。若仅四川不触发有问题而安徽正常，该用例的单一"通过/失败"结果无法精确区分是哪个省份的问题。
  • 修复建议: 拆分为3条独立用例：R1_003a 安徽触发、R1_003b 云南不触发、R1_003c 四川不触发（或保留 R1_002 覆盖云南，将 R1_003 缩减为四川+其他一省）。确保每个省份的触发/不触发行为有独立可定位的用例。

S-004: DASH_012 测试5种标签颜色，建议至少将申诉状态独立拆分

  • 用例编号: AH_REPORT_DASH_012
  • 问题: 该用例验证4种上报状态标签颜色（蓝色/绿色/红色/橙色）外加申诉状态标签颜色，共计5个颜色断言。虽然都属于"标签颜色映射"这一验证点，但上报状态和申诉状态是两个不同的状态维度。任一颜色配置错误时，该用例失败但无法直接指示是哪个具体标签。
  • 修复建议: 将申诉状态标签颜色验证拆出为独立用例，或至少在上报状态验证和申诉状态验证之间设立分组。

S-005: R2_004 合并了两个验证关注点（字段完整性 + 标签颜色）

  • 用例编号: AH_REPORT_R2_004
  • 问题: 标题和预期结果同时验证"17个字段完整性"和"收款账号类型标签颜色"，这两个关注点属于不同的验证维度（列表字段结构 vs 视觉样式映射），应拆分。
  • 修复建议: 拆分为 (a) 验证第二次上报列表字段完整且数据正确；(b) 验证收款账号类型标签颜色——个人账户蓝色、对公账户绿色。

S-006: DASH_017 分页测试优先级 P3 偏低，建议升为 P2

  • 用例编号: AH_REPORT_DASH_017
  • 问题: 分页翻页数据重复/遗漏是列表类功能的常见高频缺陷，直接影响数据完整性和用户信任度。当前置于 P3（最低优先级），与实际风险不匹配。
  • 修复建议: 升为 P2。分页缺陷虽不阻断主流程，但会导致数据不一致，用户可能基于不完整数据做出错误判断。

S-007: R1_019 和 R1_020 预期结果缺少数据库层面的一致性校验

  • 用例编号: AH_REPORT_R1_019, AH_REPORT_R1_020
  • 问题: R1_019 验证1条货物记录、R1_020 验证5条货物记录，预期结果仅覆盖了请求JSON数组和详情弹窗展示，未包含数据库货物表的落库数据与上报数据的一致性校验。与其他用例（如 R2_002 明确校验数据来源表）相比，数据验证深度不足。
  • 修复建议: 在预期结果中补充"数据库waybill_goods表中货物记录与上报数据一致"或类似断言。

优化项

O-001: R1_016 弱网测试预期结果可更精确

  • 用例编号: AH_REPORT_R1_016
  • 问题: 预期结果中"请求发送成功但响应延迟时不立即判定失败（超时阈值30s）"未明确在弱网（延迟2000ms、丢包30%）下的具体预期行为——例如是否预期在X次重试内成功，或最终应达到何种状态。建议：明确弱网条件下预期最终状态（如"在网络恢复后10s内完成上报，状态变为已上传"）。
  • 修复建议: 补充弱网恢复后的具体时效预期和最终状态断言。

O-002: 部分测试数据列存在与步骤重复的信息

  • 涉及用例: DASH_001DASH_007, R1_001R1_023 等多条
  • 问题: 测试数据列中的内容（如"运单号: YB202607130001"）已在测试步骤或前置条件中出现，数据列未提供独立增量信息。虽然模板允许这样做，但数据列的最佳实践是提供步骤中未提及但执行必需的输入值。
  • 修复建议: 检查并精简测试数据列，使其仅包含步骤中未体现的独立测试数据（如边界金额、特殊字符、长文本等）。

O-003: 导出测试缺少导出取消/中断场景

  • 涉及用例: AH_REPORT_DASH_008, AH_REPORT_DASH_009
  • 问题: 当前导出相关用例覆盖了正常导出和大数据量导出，但未覆盖"导出进行中取消操作""导出时网络中断""导出时关闭浏览器标签页"等中断场景。对于2000+条的大数据量导出场景，中途取消是常见用户行为。
  • 修复建议: 考虑新增一条 P3 用例覆盖导出中断场景，验证取消后系统资源释放、无残留临时文件。

O-004: 搜索功能缺少特殊字符和注入防护测试

  • 涉及模块: 模块A（看板搜索）、模块G（日志搜索）
  • 问题: 当前搜索用例仅覆盖了正常搜索、模糊搜索、不存在搜索和空结果，未覆盖输入特殊字符（如 <script>alert(1)</script>、SQL注入字符串 ' OR '1'='1、超长字符串 1000+ 字符）的防御行为。
  • 修复建议: 考虑为看板搜索和日志搜索各新增1条 P2 安全性测试用例，验证特殊字符输入时不触发XSS、不导致SQL注入、不引起页面崩溃。

O-005: 列表字段验证用例中缺少"列宽/截断/换行"展示验证

  • 涉及用例: AH_REPORT_DASH_011, AH_REPORT_R2_004, AH_REPORT_R3_002, AH_REPORT_APL_003
  • 问题: 当前字段完整性验证聚焦于字段存在性和顺序，未验证字段内容过长时的截断/换行/省略号展示、列宽自适应等展示细节。对于司机姓名、托运方名称、货物名称等文本字段，超长内容展示异常是常见 UI 缺陷。
  • 修复建议: 考虑在现有字段验证用例的预期结果中补充："超长文本字段（如托运方名称50+字符）展示省略号或正确换行，表格不横向溢出"。

O-006: 看板详情弹窗缺少"关闭弹窗后列表状态保持"验证

  • 涉及用例: AH_REPORT_DASH_014, AH_REPORT_DASH_015
  • 问题: 当前详情弹窗用例验证了弹窗内容完整性，但未验证关闭弹窗后看板列表的筛选状态、分页位置是否保持。这是一个常见的易用性缺陷——关闭弹窗后列表重置为第1页，用户需重新翻页。
  • 修复建议: 在现有详情弹窗用例中补充一步"关闭弹窗→验证看板列表筛选条件和分页保持不变"。

O-007: 前置条件中"系统中存在XX条运单"缺少数据准备指引

  • 涉及用例: 约 90% 的用例
  • 问题: 大量用例的前置条件使用"系统中存在运单号XXX的运单记录"或"数据库中存在XX条运单"，未说明如何创建或准备这些数据。虽然这些是前置状态描述而非执行步骤，但对首次执行的测试人员而言，缺少数据准备脚本或数据构造指引会增加执行门槛。
  • 修复建议: 在文件头部或每个模块开头增加数据准备工作说明（如 SQL 脚本引用、造数工具说明），或在备注中标注"可参考测试数据文件构造"。

维度评分

维度 得分 说明
结构完整性 13/20 表头格式和列数一致，模块路径格式正确，必填列无空值。但存在5处字段数标题与预期结果不一致（B-001~B-005），影响执行可信度。
可执行性 24/25 测试步骤具体、有明确操作和数据，前置条件大多清晰。少量用例（R1_016）预期行为在异常条件下不够精确。
原子性 10/15 绝大多数用例为单一验证点。CROSS_003（全链路四阶段）明显违反原子性。DASH_012、R2_004、R1_003 存在合并多个关注点的情况。
预期结果质量 18/20 几乎全部用例同时覆盖 UI 反馈和数据状态变化，包含数据库层面的 WHERE 条件或记录数断言，质量优秀。APL_015 使用"可能"措辞是唯一明显缺陷。
类型准确性 9/10 类型枚举使用规范。APL_015 建议改为"易用性测试"。
优先级合理性 8/10 整体分布合理（P0 22% / P1 48% / P2 23% / P3 6%）。LOG_001/LOG_003 置于 P0 偏高；DASH_017 置于 P3 偏低。

总分: 82/100

亮点总结

  1. 预期结果质量突出：绝大多数用例的预期结果同时包含前端 UI 状态（标签颜色、文案提示）和后端数据状态（数据库记录数、WHERE条件、字段值），远超行业平均水平。
  2. 历史缺陷防御覆盖完整：4个历史缺陷（BUG-202607-01~04）均有专门的防御用例并在备注中标注来源，形成可追溯的防御闭环。
  3. 覆盖维度全面：128条用例覆盖了主流程、异常流程、边界条件、状态流转、幂等与并发、权限与越权、弱网/超时、字段完整性等多个维度，无重大遗漏。
  4. 测试点到用例映射完整：103个测试点均映射到至少1条用例，无静默遗漏。
  5. 待确认项显式标注：7项待确认均在文末显式标注，符合 DoD 要求。

修复优先级建议

  1. 优先修复 B-001~B-005（字段数不一致）：直接修改标题或预期结果中的数字，低改动成本、高信心增益。
  2. 次优先修复 B-006（APL_015 措辞）和 B-007（CROSS_003 原子性）：B-006 改一句话即可，B-007 需要判断保留为冒烟测试还是拆分。
  3. 建议项和优化项可在下轮迭代中集中处理，不阻塞当前评审通过。
Reference in New Issue View Git Blame Copy Permalink