最近做一个项目,项目中推行单元测试,单元测试实施起来还真是一个需要开发和测试一起协同的工作,我们已经初步设计了一套方案,具体的流程注意事项我后续单发一个帖子说明,这里分享一下我写给开发同学的用例设计说明文档,大家帮我纠纠错。
我在网上看了不少资料,怎么说的都有,而且测试方法五花八门,我整合归纳了几个我觉得挺核心的,通过理解,yy了几个用例辅助说明了一下 ,吼吼 :) 图直接看有点不清楚,点击可以看大图 :)
目录
一、概述...4
二、基本概念...4
2.1正面测试(Positive Testing)...4
2.2负面测试(Negative Testing)...4
2.3分支测试...4
2.4黑盒测试...5
2.5白盒测试...5
三、单元测试范围...5
四、常见测试用例设计方法及举例...5
4.1流程图法...5
4.2等价类划分法...6
4.3边界值分析法...6
4.4循环测试法...7
五、相关注意事项...8
5.1独立性...8
5.2尽量脱离被测代码的束缚...8
5.3面向对象的语言单元测试特点...8
六、参考文档...8
一、概述用于从测试角度出发,进行测试用例设计在单元测试用的使用。单元测试用例在设计过程中,用例的划分,用例分支的覆盖原则。
这里强调,单元测试用例的设计是进入实际编码之前的,测试用例设计在前,更能体现出灵活性,如果已经编码完成再进行测试用例的补充,这样很容易进入一个仅仅是测试了被测代码段功能的怪圈,所以希望所有的单元测试工作,可以放在前面完成。
同时单元测试用例是一个不断完善的过程,前期设计好的用例,在代码已经实现完成后,会发现覆盖的并不是很全面,有良好的习惯是需要将对应的测试用例进行补充,而在提交测试后发现的重要的bug,也需要进行单元测试用例的补充,使单元测试和各种测试方法相结合,实现测试质量的充分保证。
2.1正面测试(Positive Testing)
测试被测对象的正确功能实现无误,即正常流程功能。往往需要根据设计说明进行用例导出,严格按照设计说明编写即可,用例划分注意等价类区分等方法。
例如:接口返回小于等于24个中文字的offer标题(这里标题控制不会超过24个字)进行页面展示。
2.2负面测试(Negative Testing)
测试被测对象的异常功能实现无误,多在异常流程,异常数据中体现。该部分测试需要对被测对象进行错误发散,常依赖于边界值区分等方法。
例如:接口返回25个中文字的offer标题进行页面展示。
使用流程图,明确可能出现的每条分支,制造响应的数据进行覆盖,实现对被测对象的测试。这个过程对于分支可以进行响应的简化,可以穿插等价类等方法去除同类分支。
例如:实现offer发布的功能,分别会出现发布普通产品,代理加盟,求购,供应等分支,测试offer提交模块的时候,需要区分这么多重类型的数据,那么假设对于全部供应类型的offer,实现上都是一样的,就可以进行等价类划分,区分供应和求购即可。
不关心被测对象内部,将其当做一个黑盒,仅仅关注对该模块的输入区分和输出结果校验。
将被测对象的每个实现都充分了解,根据内部实现进行用例设计,需要保证每个独立路径都完成用例覆盖,而常规的对每个独立路径进行真假验证,
单元测试范围的定义有多方的来源,其中重点包括了几方面:测试代码实现的功能,这个可以通过需求文档进行featurelist的整理,然后调整每个功能点的颗粒度,尽量可以和开发实现的被测单元进行对应,这个的入口文档包括需求文档、设计文档;另外有很多外部接口和底层实现,这个需要在设计完成后补充道用例中,其实这里说白了,就是要编码人员自己去衡量,那些代码我需要自己测一下,这些一定是重点的,公用的模块。
画出被测对象的控制流程图,例如被测对象中出现的if判断,for循环等。根据图展现出来的分支进行区分。
例如:
图4-1
由图4-1,输出两个数中较大的数,有这样的A-B-C-D-F;A-B-C-E-F,需要测试判断是否生效,而对于上面的流程,还有会出现x=y的情况,是否按照第二个流程完成。
越复杂的控制单元,越需要使用这种方法进行分析完成用例设计。
被测对象将输入输出划分成了多个区域,对于每一个区域,它的处理方式是一样的,那么在这种情况下,用例仅需覆盖每个区域中一条用例即可。这里需要区分,分支是不可以进行省略的,仅仅是在这个分支中,对于产生的数据类型,进行等价类划分,这个等价类是严格根据设计实现来进行判定的,需要明确。
例如:
由下图4-2,从接口取回数据,根据返回数据的值进行状态判断,决定进入的分支流程,那么根据程序实现的设计,一共有4个区域,分别是return为1,2,3和other的时候,那么对于other的值,就不需要区分返回的结果是个5还是a,或者是xxx,但是对于分支E和F,他们在这个设计中不属于等价区域,他们是两条分支,这两条分支都是需要覆盖的,这里刨除这个例子的特殊性,不要说设计时不合理的,这里强调的是分支和等价类的概念。
图4-2
这种方法更偏向于黑盒测试用例设计中使用,对被测输入进行边界分析,从各个角度都会有边界值,例如程序内部依赖之间,已经有一些边界存在,在程序集成展示后,也会有新的边界出现,在设计的时候,需要注意这些细节。例如我们可输入范围是3-6,和输入类型为浮点数。那么如下图4-3:
图4-3
那么在3-6区间为合理区域,我们进行测试的时候,根据程序对区域内处理方法进行等价类和分支划分,在6以上为上边界区域,根据类型,我们重点关注6.1和7,3以下为下边界区域,我们重点关注2和2.9。
在程序中多循环判断是,我们一样需要重点关注,根据循环的重量级进行。
例如一个简单循环判断:
如下图4-4,有如下几个分支需要覆盖:
1、跳过整个循环:不进入循环流程
2、仅有一次进入循环:需要进行数据构造,能够让循环运行一次
3、n次进入循环(n为循环的最大次数)
不难看出,通过上述分支的覆盖,就可以验证循环的功能以及循环设置的边界是否生效,不会出现循环没有控制好,导致实际使用的时候会多进行一次或者少进行一次循环的情况。
图4-4
单元测试用例在设计和数据准备的过程中,需要保持良好的独立性,确保本测试的数据是不需要依赖其他输出的,这样减少相互影响。
5.2尽量脱离被测代码的束缚
在测试用例设计的过程中,尤其是测试用例编写在代码编写完成后进行的,一定小心被代码实现功能所影响,多考虑异常分支和异常数据。
5.3面向对象的语言单元测试特点
面向对象的语言进行单元测试还有一定的特点,对于每一个类,可能他出现在程序中的情况各不相同,在进行测试的时候,可以结合上面介绍的方法,根据内部方法相互调用逻辑,完成测试设计。
大体划分两个方向,一个是功能性的,就是类似黑盒的方法,仅仅关注实现的功能点是否正确;另一个就是结构性测试,需要分析类中的方法相互实现逻辑,进行类似白盒测试,确保每个分支覆盖。