业务流程测试总结

近期公司比较强调业务流程的测试，本人就总结一下业务流程的测试经验与大家分享，欢迎大家多提意见。

一、业务流程整理

1、充分掌握业务知识，业务流程以及业务的数据流向。

站在用户的角度思考，而不仅仅考虑在系统中如何操作业务流程；搞清楚每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试。

2、从需求人员或者客户那里了解到各业务流程的重要程度和使用频率。（这点对把握测试重点很重要）

3、了解业务流程在系统中对应的功能。（建立业务与系统的映射，为编写测试用例做好准备）

二、编写测试用例（在需求文档以及UI原型评审之后）

1、绘制业务流程图（对于较简单的流程，也可以用文字描述的形式，但流程图比较直观，也便于进行路径的分析）。

2、根据业务流程的重要程度、使用频率为各流程设置好优先级。

3、采用场景法、路径法或其他方法（方法其实是不固定的，有时候可以综合使用多种方法）梳理出每个业务流程在系统中对应的操作步骤，形成业务流程的测试用例。

注意：

* 这里的操作步骤没有必要像功能点测试用例的步骤那么详细，这个操作步骤可能是一个业务操作集，可以分解成多个步骤，这些业务操作集合，也可以对应具体的功能点测试用例，从而做到测试用例的复用。所以可以说这里的业务流程测试用例就像是将多个功能点的测试用例组合成一个集合，形成一个业务流。 * 在每个步骤中需要标识出执行该操作的用户角色，因为在一个业务流程中，很可能涉及到不同的角色。

* 需要平衡项目的进度、成本，不一定需要覆盖所有的路径。

三、测试数据设计

1、输入数据：

测试业务流程与功能点测试的重点不一样，因此设计测试数据的时候更多需要考虑下面的因素（按重要到次要排列）：

1）关键的判断条件

2）符合业务意义的数据

3）边界数据

4）异常数据

另外，对流程无任何影响的数据，我认为可以在此不考虑，放到功能点测试中更加合适，这样可以减

少不必要的干扰。不过，有些功能点对流程的依赖很强，或者业务流程非常简单，也可以将业务流程测试

与功能点测试结合。（实际我觉得功能点测试与业务流程测试的数据分开会好一点，因为毕竟重点不一样；

但有时迫于进度的压力，也会将这些数据结合在一起）

2、输出数据：

系统中得到的结果数据以及报表中的数据，都需要体现出来，必要的时候还需要根据报表的格式提供

输出数据，以便在测试时进行核对。

注意：需要平衡项目的进度、成本，尽可能用少的测试数据发现多的问题。

四、测试执行

主要在下面几个阶段执行业务流程测试：

1、最主要是在系统测试阶段进行（将优先级高的主要业务流程测试用例作为冒烟测试用例）。

2、在集成测试的后期，已经对部分业务测试流程进行了测试，可以根据系统集成的顺序，在集成测试

阶段对部分业务流程进行测试。集成测试阶段重点是测试功能点，功能点测试存在严重问题，是无法进行

业务流程测试的，所以一般是等功能比较稳定的时间才会进行业务流程测试。

3、验收测试。

4、个人观点：保证质量最有力的手段还是预防，如果能够将业务流程测试用于测试的前期，比如：用

于开发人员进行联调、或者送测前的测试，这样可能会提高送测质量，减少测试轮次，提高编码质量。

另外，有了具体的步骤，以及测试数据，可以结合自动化测试工具进行业务流程测试。（以上言论仅代

表作者的个人观点，不代表51Testing观点）

用路径分析法来编写测试用例

来源：网络 作者：不详

熟悉测试理论的人都知道，路径覆盖是白盒测试中一种很重要的方法，广泛应用于单元测试。那么基于路径覆盖的分析方法是不是只能应用于单元测试呢，能不能将其推而广之呢。一般而言，在单元测试中，路径就是指函数代码的某个分支，而实际上如果我们将软件系统的某个流程也看成路径的话，我们将可以尝试着用路径分析的方法来设计测试用例。采用路径分析的方法设计测试用例有两点好处：一是降低了测试用例设计的难度，只要搞清了各种流程，就可以设计出高质量的测试用例来，而不用太多测试方面的经验；二是在测试时间较紧的情况下，可以有的放矢的选择测试用例，而不用完全根据经验来取舍。下面就具体的介绍一下如何用路径分析的方法编写测试用例。

首先是将系统运行过程中所涉及到的各种流程图表化，可以先从最基本的流程入手，将流程抽象成为不同功能的顺序执

行。在最基本流程的基础上再去考虑次要或者异常的流程，这样将各种流程逐渐细化，这样既可以逐渐加深对流程的理解，还可以将各个看似孤立的流程关联起来。完成所有流程的图表化后就完成了所有路径的设定。

找出了所有的路径，下面的工作就是给每条路径设定优先级，这样在测试时就可以先测优先级高的，再测优先级低的，在时间紧迫的情况下甚至可以考虑忽略一些低优先级的路径。优先级根据两个原则来选取：一是路径使用的频率，使用越频繁的优先级越高；二是路径的重要程度，如果失败对系统影响越大的优先级越高。将根据两个原则所分别得到的优先级相加就得到了整个路径的优先级。根据优先级的排序就可以更有针对性的进行测试。

为每条路径设定好优先级后，接下来的工作就是为每条路径选取测试数据，构造测试用例。一条路径可以对应多个测试用例，在选取测试数据时，可以充分利用边界值选取等方法，通过表格将各种测试数据的输入输出对应起来，这样就完成了测试用例的设计。

对于测试人员而言，测试用例的设计是一件非常困难的工作，而同时测试用例的设计好坏又直接关系到整个系统的设计质量。本文介绍了一种更理论化的设计方法来尽量简化这种工作，将一般应用于单元测试的路径分析方法推广到集成测试、系统测试等后续测试过程中，希望能给大家一点启示。我会将自己尝试过的一些感受以及具体例子跟在本贴之后.<BR>如果想让本方法很好的用在实际的工作中,那么流程就必须明确的规范的（就是有画出相应业务或者功能走向图）,这样就可以极大的加快了用例编写的速度和质量，但是如果碰到没有明确流程图的时候，可能会花不少的时间去捉摸功能点的流程走向问题，这又让工作进度慢了下来（流程不明确是因为需求没有明确表述和设计没有相应流程描述）,所以在实际工作中想使用这种方法来加快和改进测试用例的进度和质量，还要说服项目组尽可能的规范需求和设计的文档规范性，毕竟软件质量的控制不是我们一组人就能做到的。

拿到这个流程时，第一眼看上去，是不是有点晕晕的呢，确实如此，因为这不能称为标准的流程图，我们需要做一些改进，不妨事先约定，画流程图时，在有判定条件处，就往下走，而就往左走，以下是简化后的流程：

上面这个流程图看上去是不是清晰很多,确实如此,从心理学的角度来讲,正常人的思维是很难接受一个横向很复杂的事物.而且上面的流程图也更规范一点,所以建议大家以后这样画流程图.下图是作进一步的改进:这个流程图是不是更方便你设计用例呢,尤其是用路径分析法,是不是很方便就能找出其中的路径.

这个流程图是不是更方便你设计用例呢,尤其是用路径分析法,是不是很方便就能找出其中的路径

第二篇：测试流程

疑问：测试大纲与测试方案只需要一个