业务流程测试的方法和实践

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

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

一．          关注需求和用户

1．              站在用户的角度

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

2． 重视全局，而非细节

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

3．             现场客户

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

二．          精心设计流程用例

1．              流程用例编写要点

l     要有基本数据，以便系统测试多次使用，同时方便自动化工具介入。

l     其他流程要依赖这套数据，使之每个流程可以更有针对性的执行。

l     构建的数据要尽量有具体的意义，严禁用a、b、c；1、2、3等

l         流程要符合用户常用的业务操作习惯，尽量考虑用户的实际操作去编写。

l         流程可大可小，但每一个流程都要是一个典型的业务操作。

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

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

2． 流程用例编写实践

l         系统总流程表                                                

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

l         角色功能表                                      

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

l     测试数据列表                                                

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

l     流程测试用例表

这是最重要的一个部分，是我们测试流程的出发点和根据，和功能测试用例不同的是，

我们这里所关注的是业务操作的流程，编写时参照“流程用例编写要点”。

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

三．          测试执行

l     在系统测试每轮测试保持测试数据库都是完整的一套初始数据，通过exp/imp实现；

l     在数据稳定、界面稳定的前提下通过自动化工具录制流程测试脚本；现在部门推荐MI公司WinRunner和LoadRunner。

l      

WinRunner使用参照vss中测试组整理的WinRunner7.6使用指南

LoadRunner使用参照vss中测试组整理的LoadRunner 压力测试实例