什么是软件测试中的工作流测试？举例
编辑团队
什么是工作流测试？
工作流程测试 工作流测试是一种软件测试类型，它检查每个软件工作流是否准确反映了给定的业务流程。工作流是一系列产生预期结果的任务，通常包含多个阶段或步骤。对于任何业务流程，对这些顺序步骤的测试都称为工作流测试。
关键的区别在于范围。 测试用例 工作流测试询问单个函数是否返回正确答案。而工作流测试则询问按照真实用户操作顺序执行的十个函数，是否仍然能够产生业务预期的结果。因此，工作流测试属于流程导向型测试的范畴。 软件测试类型 而不是采用单元级技术进行目录编制。
工作流测试示例
例如，验证该系统是否可以安装在用户的平台上，以及它是否能够正确运行。
一个更丰富的例子是线上订单。顾客将商品添加到购物车，使用折扣码，选择配送方式，付款，并收到确认邮件，同时仓库收到拣货指令。这些步骤单独来看可能都成功，但串联起来却可能失败：折扣码可能在付款环节失效，或者仓库的拣货指令可能永远无法从队列中发出。
工作流程测试分阶段进行。以下是工作流程测试的执行步骤。
- 初始阶段该阶段包括初步测试计划和原型测试。
- 细化阶段此阶段包括建立测试架构基线。
- 施工阶段此阶段包括对每次构建进行大量测试。
- 过渡阶段此阶段包括 回归测试 并重新测试修复方案。
如何执行工作流测试
上述阶段模型描述了工作发生的先后顺序。下面的步骤序列描述了测试人员在任何一个阶段中实际执行的操作。
- 绘制业务流程图。 按照业务实际运作方式绘制工作流程图，包括每个决策点、审批流程以及部门间的交接环节。通常情况下，业务分析师是绘制准确流程图的最快途径。 业务分析师 文档是用来核对地图的参考依据。
- 设置准入和退出标准。 记录系统在工作流开始前必须达到的状态，以及工作流完成时的状态。如果缺少这两项，测试人员对测试是否通过的判断就会出现分歧。
- 设计测试用例。 工作流程的每个路径对应一个案例，而不是每个屏幕对应一个案例。给每个步骤编号，说明每个步骤的预期结果，并为每个案例分配一个唯一标识符，以便识别缺陷。 trac回到正轨。
- 准备真实的测试数据。 与其使用虚构的数值，不如重复使用匿名化的生产数据记录。折扣码、税收规则和地址格式通常是合成数据掩盖真实缺陷的地方。
- 首先运行主路径。 在故意破坏任何环节之前，务必确认工作流程能够完整无误地完成。如果此处出现故障，则后续所有负面结果都将无效。
- 故意打破链条。 中途取消、在决策点提交无效值、会话超时以及拒绝批准。真正棘手的缺陷存在于这些中断的路径中，而不是主要路径中。
- 报告问题，修复问题，然后重新测试。 将每个缺陷记录到产生该缺陷的步骤中，然后在修复后重新运行整个工作流程。修复后的步骤通常会将故障转移到流程链的下一个阶段。
每次发布都会重复的稳定工作流程最适合自动化，因为每次运行的步骤都相同，脚本只需几个周期就能收回成本。
谁将执行工作流测试？
工作流程测试是一项协作工作，因为没有哪个角色能够看到整个流程。这项工作由四个角色共同承担，每个角色都有各自的职责。
工作流程中需要测试的内容
软件工作流程记录在业务需求文档中，该文档是测试覆盖率的权威来源。工作流程测试也将包含系统测试和集成测试的部分内容。
对工作流程进行全面检查，不仅仅要关注用户看到的屏幕。
- 序列： 这些步骤必须按照文档规定的顺序执行，不能跳过任何步骤，也不能随意重复执行。
- 数据交接： 在流程早期输入的值会完整地保留到最后一步以及任何下游系统。
- 角色和权限： 每个步骤只有获得授权的角色才能执行。
- 中断的路径： 取消、超时、拒绝和重试都会使工作流程处于特定状态。
- 伪像： 工作流测试模型涵盖测试用例、测试程序、测试组件和测试子系统，因此需要依次验证其中的每一部分。
- 通知： 电子邮件、警报和队列消息会在正确的步骤中以正确的内容触发一次。
工作流程测试、端到端测试和系统测试
这三种技术之间存在诸多重叠之处，容易混淆，但它们回答的问题却各不相同。下表列出了它们的界限。
| 方面 | 工作流程测试 | 端到端测试 | 系统测试 |
| 问题已解答 | 该软件是否与业务流程相匹配？ | 整个流程是否在所有连接的系统中都能正常运行？ | 组装好的系统是否满足要求？ |
| 覆盖单位 | 一个业务流程，逐步进行 | 一个用户旅程，从前端到后端 | 完整的应用程序构建 |
| 主要参考文献 | 业务需求文档 | 用户旅程图 | 系统需求规范 |
| 典型业主 | 测试工程师（需业务分析师参与） | 自动化或质量保证工程师 | 系统测试员 |
在实践中，工作流程测试通常是规范和 端到端测试 由……构成，而 系统测试 提供工作流运行所依赖的稳定版本。
最佳实践和常见挑战
从工作流程测试中获得价值的团队往往会遵循相同的几个习惯。
- 优先处理那些会带来收入或监管风险的工作流程，而不是那些罕见的工作流程。
- 用简洁明了的语言描述每个步骤和预期结果。
- 保持可重复使用、真实的测试数据集，以便不同环境下的测试结果具有可比性。
- 在每个决策点，分别使用有效输入和无效输入测试每个工作流程。
- 一旦底层业务流程发生变化，立即更新测试用例。
这些反复出现的障碍同样是可以预见的。
- 未记录的流程： 工作流程存在于人们的脑海中，因此测试人员是在验证某个假设。
- 执行时间长： 涉及审批的工作流程可能需要数小时，这限制了手动运行的频率。
- 环境漂移： 产业链下游系统存在缺陷或老化，缺陷只会在生产过程中显现出来。
- 脆弱的自动化： 与屏幕布局相关的脚本会在界面发生变化时中断，即使进程没有发生变化。
- 数据冲突： 并行运行会消耗相同的记录，从而产生看起来像产品缺陷的故障。
