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