流程测试是测试人员把系统各个模块连贯起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。
业务流程测试是系统测试最重要的内容，而测试的依据就是用户定义的需求和测试人员的测试设计，因此下面就从需求、测试设计、测试执行等角度上重点来阐述如何做好业务流程测试。
一． 关注需求和用户
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 压力测试实例
一、业务流程整理
1、充分掌握业务知识，业务流程以及业务的数据流向。
站在用户的角度思考，而不仅仅考虑在系统中如何操作业务流程；搞清楚每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试。
2、从需求人员或者客户那里了解到各业务流程的重要程度和使用频率。（这点对把握测试重点很重要）
3、了解业务流程在系统中对应的功能。（建立业务与系统的映射，为编写测试用例做好准备）
二、编写测试用例（在需求文档以及UI原型评审之后）
1、绘制业务流程图（对于较简单的流程，也可以用文字描述的形式，但流程图比较直观，也便于进行路径的分析）。
2、根据业务流程的重要程度、使用频率为各流程设置好优先级。
3、采用场景法、路径法或其他方法（方法其实是不固定的，有时候可以综合使用多种方法）梳理出每个业务流程在系统中对应的操作步骤，形成业务流程的测试用例。
注意：
* 这里的操作步骤没有必要像功能点测试用例的步骤那么详细，这个操作步骤可能是一个业务操作集，可以分解成多个步骤，这些业务操作集合，也可以对应具体的功能点测试用例，从而做到测试用例的复用。所以可以说这里的业务流程测试用例就像是将多个功能点的测试用例组合成一个集合，形成一个业务流。
* 在每个步骤中需要标识出执行该操作的用户角色，因为在一个业务流程中，很可能涉及到不同的角色。
* 需要平衡项目的进度、成本，不一定需要覆盖所有的路径。
三、测试数据设计
1、输入数据：
测试业务流程与功能点测试的重点不一样，因此设计测试数据的时候更多需要考虑下面的因素（按重要到次要排列）：
1）关键的判断条件
2）符合业务意义的数据
3）边界数据
4）异常数据
另外，对流程无任何影响的数据，我认为可以在此不考虑，放到功能点测试中更加合适，这样可以减少不必要的干扰。不过，有些功能点对流程的依赖很强，或者业务流程非常简单，也可以将业务流程测试与功能点测试结合。（实际我觉得功能点测试与业务流程测试的数据分开会好一点，因为毕竟重点不一样；但有时迫于进度的压力，也会将这些数据结合在一起）
2、输出数据：
系统中得到的结果数据以及报表中的数据，都需要体现出来，必要的时候还需要根据报表的格式提供输出数据，以便在测试时进行核对。
注意：需要平衡项目的进度、成本，尽可能用少的测试数据发现多的问题。
四、测试执行
主要在下面几个阶段执行业务流程测试：
1、最主要是在系统测试阶段进行（将优先级高的主要业务流程测试用例作为冒烟测试用例）。
2、在集成测试的后期，已经对部分业务测试流程进行了测试，可以根据系统集成的顺序，在集成测试阶段对部分业务流程进行测试。集成测试阶段重点是测试功能点，功能点测试存在严重问题，是无法进行业务流程测试的，所以一般是等功能比较稳定的时间才会进行业务流程测试。
3、验收测试。
4、个人观点：保证质量最有力的手段还是预防，如果能够将业务流程测试用于测试的前期，比如：用于开发人员进行联调、或者送测前的测试，这样可能会提高送测质量，减少测试轮次，提高编码质量
