改造功能测试用例的一点思考(2)
作者:海37度思念 发布时间:[ 2017/5/5 14:57:29 ] 推荐标签:功能测试 测试用例
现在,在我的问题清单上,有了四个问题,分别是:
1、怎么确定功能与流程之间的关系,才能确保页面功能与流程都有比较充分的测试?
2、怎么安排和分配页面功能与流程测试,才能做到不重复不遗漏,不多不少?
3、怎么确定流程测试是充分的、少遗漏的?
4、从用例数量的角度,怎么平衡页面功能与流程的测试?分解开来,是怎么确定各需要多少用例,才是相对比较合适的?
一个一个来解决吧。
首先,流程为纲,页面为内容,纲举目张。页面和功能是所有流程的基础,必须保证这一部分是相对比较充分的测试。这是一个一个零散的珍珠,一个一个捡,需要花费不少功夫,需要找根线,将它们串起来。而想来想去,只有流程是合适的。总体来说:可以按照流程为主,在流程中穿插页面和功能测试,通过流程的主动流转,对页面和功能进行测试;而对于独立的页面和功能,则单独拧出来测试;在所有可能的页面功能都测试结束后,则对剩下的流程执行业务流程测试。当然,这里会产生一个问题,在这种设计思路中,怎么遵循用例设计中的独立性原则?留待后面解决。
其次,以流程为主,穿插页面功能测试,模块化设计。流程穿插页面,这个其实在前面基本上确定了,所以这里主要解决遗漏和重复的问题。从需求设计的角度来说,页面和功能是流程的基础,而同时也是依附于流程的,在流程中的独立页面(注意与独立的功能页面的区别),是没有意义的,也是说,只要流程的测试足够充分了,那么页面和功能的测试也充分了,不会遗漏了。这里的重复存在的可能性是很大的,无论流程怎么变,总体来说,页面数量大体是固定的,只是处理逻辑会略有不同,则肯定会在大量的流程用例中出现相同的功能和页面。对于随着流程不同,而略有变化的页面和功能,需要在后面的用例中将之前存在过的页面和功能用例省略并且过滤,比如房间数量随人数不同而变化的功能,在多次执行流程时,可以在后面省略该流程;对于固定的功能,比如担保功能这样的功能,不随审批与否而变化,可以作为独立功能,单独拧出来,作为功能测试用例中的担保模块存在,关于这样的功能,需要一个列表单独列出,并且根据流程中出现的情况,可以增减。
第三,采用科学的设计方法,来确保流程用例的充分完整。既然确定了流程为主线的用例设计思路,那么要确保流程的用例是充分完整的,好的办法,是使用科学的测试用例设计方法。这个时候回过头来看学过的和常用的用例设计方法,等价类、边界值、判定表等这些方法,在针对某一个功能或某一个不大的模块的时候,是够用而且很适合的(当然,这个在后面的具体页面功能的用例设计中,依然是必须要用的),不过,在针对某一个业务线或产品的时候,却很明显不够用了,需要更加宏观更加有效的设计方法。在仔细分析过整体业务流程的规律、大量的比对后,结合我目前所掌握的知识和方法,后,决定使用正交实验分析法为主要思路来规划整体流程用例,结合分层的测试设计思想,以等价类等方法来设计具体测试用例。
第四,关于具体的测试用例数量,目前还没法估计,等后面分析完再说吧。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11