用真实业务场景测试应用

本章目标：建立以业务结果为中心的测试方式，覆盖正常、边界、异常和权限情况，而不是只检查页面能否打开、按钮能否点击。

1. 测试要证明什么

一个业务场景通过，需要同时证明：

• 正确的人能完成正确操作；
• 输入和计算符合业务规则；
• 状态和责任按预期变化；
• 下一角色收到正确待办或入口；
• 保存后重新打开仍然正确；
• 视图、统计和输出得到正确结果；
• 不应允许的人和操作被拒绝；
• 异常发生时有清楚、可恢复的结果。

“没有报错”不等于业务正确。

2. 从需求场景生成测试

需求：

总金额大于 5000 元时增加行政负责人审批。

测试不应只有一条 6000 元申请，还应包含：

• 4999.99；
• 5000.00；
• 5000.01；
• 金额为空；
• 退回后从 6000 改成 4000；
• 明细变化但总额未更新时禁止使用旧结果；
• 连续点击提交；
• 无行政负责人。

测试直接来自规则、边界和异常分析。

3. 一条测试剧本的结构

项目	示例
编号	T-WF-03
目的	验证高金额增加审批
角色	申请人、直属主管、行政负责人
前提	三个账号和组织关系已准备
数据	总金额 5000.01
步骤	新建→提交→主管同意→负责人同意
预期结果	主管同意后仍为审批中；负责人同意后进入待采购
反例	5000.00 不应进入负责人审批
证据	状态、任务、视图、重新打开后的记录
实际结果	测试时填写

预期结果必须在执行前写好，不能看到实际结果后再解释为“也合理”。

4. 六类必测场景

4.1 正常场景

典型用户按正常步骤完成业务。

4.2 边界场景

金额、数量、日期、行数和时间恰好位于规则边界。

4.3 异常场景

输入错误、人员缺失、退回、撤回、缺货、作废和超时。

4.4 权限场景

不同角色允许和拒绝的操作。

4.5 重复与并发场景

连续点击、重复提交、两人同时处理同一任务、两人修改同一记录。

4.6 变更回归场景

应用修改后，过去已经正确的核心业务仍然正确。

5. 验证数据和计算

采购金额测试：

明细	数量	单价	期望行金额
纸张	10	35.00	350.00
键盘	2	180.00	360.00

期望总额：710.00。

继续测试：

• 修改数量；
• 修改单价；
• 删除一行；
• 新增空白行；
• 数量为 0；
• 数量为负；
• 多位小数；
• 保存后重新打开；
• 退回修改后重新计算。

同时检查显示值、流程使用值和统计结果是否保持同一业务含义。

6. 验证保存和重新打开

任何重要数据操作都执行：

1. 填写或修改；
2. 保存；
3. 离开当前页面；
4. 从列表重新找到；
5. 再次打开；
6. 核对字段、明细、金额、状态和可操作按钮。

只看保存前页面上的临时变化，不能证明业务记录已经正确保留。

7. 验证权限

采用角色账号矩阵，而不是在管理员账号中切换想象。

申请人 A

• 能创建和查看自己的；
• 看不到申请人 B 的；
• 审批中不能修改；
• 不能登记采购结果。

主管

• 能处理属于自己的任务；
• 能查看职责范围内申请；
• 不能处理其他主管的任务；
• 不能修改申请内容。

行政采购员

• 能查看待采购；
• 能登记采购结果；
• 看不到不在授权范围内的敏感内容；
• 是否能导出符合权限矩阵。

未授权用户

• 看不到应用入口；
• 即使获得旧链接也不能打开业务记录。

8. 验证流程

检查的不只是最终“通过”：

• 提交后状态；
• 正确处理人；
• 任务是否只产生一次；
• 同意后下一节点；
• 退回意见和修改入口；
• 拒绝后的终止；
• 撤回后的状态；
• 高金额分支；
• 无处理人；
• 超时和代理；
• 流程结束后待采购视图。

9. 验证视图、统计和输出

准备一组可人工算清的样例数据：

• 不同状态；
• 不同部门；
• 不同月份；
• 正常、拒绝和作废；
• 不同金额。

逐项核对：

• 默认筛选；
• 数据范围；
• 排序；
• 汇总数量；
• 金额口径；
• 导出记录数和字段；
• 打印内容和分页；
• 敏感字段是否被排除。

10. 用接近真实的数量验证

三条记录正常，不代表日常使用正常。

至少模拟：

• 一张包含典型明细行数的申请；
• 一个角色拥有日常可能看到的记录量；
• 常用视图在真实筛选下是否易用；
• 导出和打印是否仍符合业务期望；
• 多人连续操作时责任和状态是否清楚。

业务开发者不需要分析技术指标，但要用真实规模检查用户能否正常完成工作。

11. 记录缺陷

缺陷记录包括：

• 编号和标题；
• 测试角色；
• 业务前提；
• 使用数据；
• 明确步骤；
• 预期结果；
• 实际结果；
• 影响范围；
• 是否阻塞上线；
• 修复后需要回归哪些场景。

好的标题：

“总金额等于 5000 元时错误进入高级审批”

差的标题：

“流程有问题”

12. 区分缺陷、遗漏和新需求

类型	判断	处理
缺陷	已确认设计没有正确实现	修复并回归
设计遗漏	原需求存在，但蓝图没有覆盖	回到设计重新确认影响
新需求	之前没有确认的新期望	进入变更清单评估
使用问题	功能正确，但用户不知道怎么操作	改体验、提示或培训
能力差距	当前无法完整实现	明确替代、延后或补齐

不要把所有反馈都立即当成缺陷修改。

13. 建立核心回归集

每次发布都必须重测的最小集合：

• 创建并保存申请；
• 多行金额计算；
• 普通金额审批；
• 高金额审批；
• 退回修改重提；
• 权限允许和拒绝；
• 待采购处理；
• 完成后的查询和统计；
• 导出或打印关键输出；
• 重复提交保护。

核心回归集应随着新业务不变量和严重缺陷持续补充。

14. 测试结束条件

不是“测试了两天”，而是：

• 所有必须需求有测试；
• 核心正常场景通过；
• 关键边界和异常通过；
• 权限正反例通过；
• 严重缺陷已关闭；
• 修复后完成相关回归；
• 已知限制记录并被业务负责人接受；
• 证据足以让另一人复现结果。

15. 常见错误

• 只测按钮能点；
• 预期结果在执行后才补写；
• 全部使用管理员账号；
• 不重新打开已保存记录；
• 只测一条正常审批；
• 统计只看数字“差不多”；
• 修复一个问题后不回归相关场景；
• 把所有用户建议直接改进当前版本。

16. 本章完成标准

• [ ] 测试由需求、规则、边界和异常生成；
• [ ] 每条测试有角色、前提、数据和明确预期；
• [ ] 保存后重新打开是标准步骤；
• [ ] 每个主要角色都有权限正反例；
• [ ] 流程覆盖普通、高金额、退回、撤回和人员缺失；
• [ ] 视图和指标使用可人工核算的数据；
• [ ] 缺陷、遗漏、新需求和使用问题已分类；
• [ ] 核心回归集已经建立。

下一步

内部测试通过后，需要让真实业务代表确认应用是否适合工作，并准备正式启用。下一章学习组织用户验收并准备上线。