流程测试——流程需求分析

软件在发展初期，大部分实现的都是单一功能，如计算器，用户期望计算器实现加、减、乘、除等运算功能，单一输入，单一输出，无论是软件开发还是测试，相对来说较为容易。

随着用户需求越来越复杂，对软件系统的价值要求越来越高，软件系统不再仅仅实现一些基础功能，如信息的增、删、改、查，而是在基础功能平台上，实现更多流程性、事务性的功能。

【案例1 信用卡申请功能流程】

银行提供用户在线申请信用卡功能，用户访问申请地址，输入身份证号码，输入个人信用证明，银行后台自动校验，如果符合，则根据规则发放信用卡，如不符合则拒绝，或发起人工审核。可能涉及的流程图如图1所示。

图1 信用卡在线申请业务处理流程

如今绝大多数的业务系统由用户管理、权限管理、工作流管理、基础数据维护四大核心组件构成，每个核心组件中涉及信息的增加、修改、删除、查询等相关操作。测试工程师测试任何软件，应当先理解被测的业务结构，从而根据用户需求优先级制定合理的测试计划与策略。

从用户角度考虑，用户期望软件完成其所需的业务流程，其他功能则是辅助流程的，因此流程测试是日常测试工作中非常重要的内容。

流程测试是测试工程师将被测对象的各个功能通过业务流程贯穿起来运行，模拟真实用户实际的工作流程，从而验证流程的正确性。

流程测试通常分为三个步骤：流程需求分析、流程测试设计、流程测试执行。

业务流程，一般可能由多个功能、多种角色、多种权限组合而成，过程中涉及较多的测试点，进行流程时，需分析业务流程涉及哪些具体的功能、角色及权限。

【案例2 ECShop用户购买商品流程】

ECShop系统的“注册用户购买商品”业务流程如图2所示。

图2 注册用户商品购买流程

上图是ECShop注册用户登陆平台后购买商品的基本流程，从登陆->查询->浏览商品到最终的收货节点，从用户应用角度分析，仅涉及一个角色、一种权限，虽然过程中包含多个功能点，但测试工程师针对这样的流程测试时，无须关注每个节点的功能性特性，仅需考虑软件系统是否正确实现了对应的业务流程，具体每个节点的验证性测试活动应该单独开展。

也有些流程较为复杂，以请假流程来说，过程中可能涉及多个角色、多种权限，如图3所示。

图3 员工请假流程

测试工程师测试图3所描述的请假流程时，需分析该流程中包含哪些角色、需要哪些权限，判定路径有几条。

需确定被测流程共涉及几种角色，因为每种角色对应的权限不同，测试工程师应当从用户角色考虑流程的合理性，而不仅仅关注系统实现。

上述流程图共涉及普通员工、部门领导、公司领导、人事四种角色，测试用例设计时至少需要创建这四种角色的用户，才能真实的模拟用户行为。

不同的角色对应不同的权限，通过流程测试，可发现权限设计方面的缺陷，以请假流程为例，部门领导应该具有审批普通员工的请假单权限，但不应当具有审批公司领导请假单的权限。测试流程前需确保权限功能的正确性。

路径，是流程包含的分支路径。分支路径说明了业务流程的复杂度，以员工请假流程为例，共有4条路径，分别是：

路径1：1、2、3

路径2：1、2、4

路径3：5、6、7

路径4：5、6、8

路径根据其处理业务流程的方式不同，划分为基本流、备选流及异常流等三种形式。

基本流从流程开始直至流程结束，中间无任何异常分支，往往表述一个正向的业务流程，也是优先级较高的流程，简单而言，即流程中所有功能都输入软件系统可接受的数据，从而完成整个业务流程。如图5- 37员工请假流程中“普通员工提交请假单->部门领导->同意->人事记录请假信息”是基本流。

尽管在流程流转过程中出现了异常，但仍能回到基本流主线，最终完成用户期望的业务行为，这样的流程称为备选流。以ECShop用户进行订单支付时，密码输入错误后重新输入，系统验证正确后完成支付，这样的业务过程即属于备选流。

针对业务流程，一般分解到基本流与备选流即可，但笔者认为在实际的测试过程中，应当根据实际业务情况增加异常流分支划分。异常流是在备选流的基础上，违反系统约束最终导致用户期望结果未能达成的路径。同样以订单支付为例，系统调用支付接口，用户密码输入错误超过3次，导致支付行为锁定，无法完成后续业务，这样的处理路径，理解为异常流。

简单的业务流程，通过文字描述即可，但很多时候流程相对较为复杂，此时测试工程师最好绘制流程图，这样更利于后续的测试用例设计。分析流程的时候，根据流程的重要程度及使用频率确定流程的优先级。