业务流程测试

业务流程测试规范和要点

流程测试是测试人员把系统各个模块连贯起来运行、 模拟真实用户实际的工作流程， 满 足用户需求定义的功能来进行测试的过程。

业务流程测试是系统测试最重要的内容， 而测试的依据就是用户定义的需求和测试人员的测 试设计， 因此下面就从需求、 测试设计、 测试执行等角度上重点来阐述如何做好业务流程测 试。

一．关注需求和用户

1.站在用户的角度

优秀的需求应该是站在用户的角度来思考问题， 是用户能够利用系统完成什么， 而不是 系统自己完成。 因此在需求理解时要多和软件的最终用户进行交流， 了解他们的诉求， 以便 有针对性的进行测试。

2.重视全局，而非细节

工作重点应该是放在尽可能全面的收集需求要点、 了解整体的业务流程、 分析主体业务 流程和重点业务流程等工作上。 在获得了系统的全貌之后， 我们会发现原先在编写功能测试 用例对系统的认识是不充分的，这时要编写的流程测试用例需要根据新的思路进行重新排 列。

3.现场客户

现场客户随时提供对需求细节的指导。 如果没有条件， 可以定期的邀请用户参加项目例 会或安排和用户交流等。另外在需求理解评审和测试设计评审会尽量邀请用户参与。

二．精心设计流程用例

1.流程用例编写要点

要有基本数据，以便系统测试多次使用，同时方便自动化工具介入。 其他流程要依赖这套数据，使之每个流程可以更有针对性的执行。 构建的数据要尽量有具体的意义，严禁用 a 、b 、c； 1 、2、3 等 流程要符合用户常用的业务操作习惯，尽量考虑用户的实际操作去编写。 流程可大可小，但每一个流程都要是一个典型的业务操作。

流程不必覆盖到所有功能点，因为流程用例是功能用例的一个补充。

流程不要被具体的模块所， 各个模块可以交叉。用户实际的业务操作是没有界限的。 2.流程用例编写实践

系统总流程表

该表制定的目的首先是理清系统脉络，和编写者的思路；其次是给后进入项目的 tester ，一个对系统大概的认识，对于系统的功能和各个模块之间的关系有个宏观的认识。 角色功能表

因为我们现在所做的系统大都是多用户多权限的， 对应不同角色有不同的权限。 包括菜 单级和操作级的。比如 E-Sales 系统中就有 8 种角色 50 多种权限，所以有一个清晰的列表 对于用户理解和测试系统是有很大帮助的， 在测试不同角色对应的不同功能页面或操作可以 通过该表进行二维的对应。

测试数据列表

流程测试要依赖一套可以重用的并且尽量符合用户实际操作的数据。 测试用例中包含精 心准备的数据，在执行时会有的放矢，更贴近用户的操作。

流程测试用例表

这是最重要的一个部分，是我们测试流程的出发点和根据，和功能测试用例不同的是， 我们这里所关注的是业务操作的流程，编写时参照《流程用例编写要点》 。

流程测试用例编写参照《流程测试模版及案例》 。

三．测试执行

在系统测试每轮测试保持测试数据库都是完整的一套初始数据，通过 exp/imp 实现； 在数据稳定、界面稳定的前提下通过自动化工具录制流程测试脚本；

业务流程测试主要是在功能点测试的基础上， 测试系统完成某项业务的能力。 业务流程 重点考查系统不同模块、 不同子系统之间的功能衔接、 数据流向以及完成业务功能的正确性 和便利性。按照以下原则进行流程测试：

1)先测功能后测流程： 业务流程测试是建立在功能点测试基础上的。 首先要保证流 程测试涉及到的功能点实现正确，所以，流程测试安排在功能测试的后面进行。

2)先测主流程后测分支流程： 主流程就是指按照正常情况实现的业务流程， 分支流 程指出现特殊情况后的业务流程。

3)先测子系统内的流程， 后测子系统间的流程： 子系统内的流程测试随子系统的功 能测试进行。