流程测试,相比单个功能点测试更消耗测试时间,尤其是金融、通信及运营类的系统平台,往往一条路径的测试就需要构造大量的测试数据才能完成,因此,在执行流程测试时,应该提前准备好相关的测试数据,如果涉及较大量的数量,可利用一些数据生成工具来制造测试数据。

 

敏捷测试中以一个Sprint为节点,通常Sprint中包括的用户故事具有较强的耦合度,测试工程师根据产品实现,确定业务流程从而开展测试活动。

 

流程测试执行的顺序可以先从单个功能测试开始,这点根据开发工程师提供的模块确定,开发工程师提供了哪些功能,测试工程师则先开始测试,当模块逐步集成时,再进行流程测试,因为流程测试的前提是单个功能点正确。

 

当产品功能逐步集成后,进行冒烟测试时,应当以将基本流作为冒烟测试用例执行,验证被测对象是否具备可测性。冒烟测试通过后再进行正式测试。

 

以上介绍的是从用户角度出发,完成某个具体业务需求的流程测试方法,在实际测试工作中,还有一种流程测试思路,笔者称为逻辑流程测试方法。

 

【案例1  ECShop商品管理功能测试】

ECShop商品管理功能的应用逻辑流程如图1所示。

 

流程测试执行

图1 ECShop商品管理流程

 

软件测试实施过程中,从用户角度出发,可能因每个角色的业务目标不同,而导致业务逻辑断裂,造成测试活动无逻辑,浪费测试时间,如果测试工程师不仅仅关注用户期望,还从数据完整性、可溯性角度考虑,将会降低这类风险。

 

以图1为例,测试工程师在实施测试过程中,可先进行后台商品类别管理的测试,然后再进行商品信息管理,最后再切换用户进行购买业务。如果测试任务分配时,将后台商品管理与前台购物分开,则有可能造成数据不一致的错误,同时也增加了测试工程师之间的沟通成本。以笔者的测试经验,通常进行如下的测试流程:

 

首先测试商品类别管理功能,只有存在商品类别,才能添加商品。商品类别管理中先执行增加商品类别测试用例,然后再执行修改商品类别用例,最后执行删除商品类别用例;

 

商品类别管理功能测试完成后,进行商品管理测试,同样的顺序,执行增加商品用例->修改商品用例->删除商品用例->查询商品用例,遵循用户基本的应用习惯。

 

最后切换身份,使用注册用户帐号登陆前台,执行查询商品、购买商品的用例,从而完成完整的商品管理功能(提供数据、应用数据)。

 

除了上述两种情况外,还有一种可能性,就是Web系统与App结合的结构,测试这种结构时同样需考虑业务逻辑的一致性,笔者曾经遇到一个缺陷,是某航空官网与其App注册与登陆功能要求不一致的问题。官网要求注册帐号密码不少于6位,但App登陆时,提示密码为6位,当用户在官网密码设置超过6位时,则无法在App登陆,必须修改为6位。这样的缺陷对用户而言是无法接受的,应用起来非常麻烦。

 

目前大部分的业务系统中,都涉及到大量的业务流程,因此测试工程师应当重视流程测试的方式方法。如果被测对象没有明确的需求或者需求中没有给出流程图,测试工程师可根据相关测试资源绘制流程图,流程图不一定画的很完美,只需要表述流程结构即可,这样便于对被测对象的理解、测试用例设计及后期的执行操作。如果测试设计时,能够接触到实际的用户更好,可请用户帮忙评审流程,从而保证测试设计的正确性。