测试用例?(TestCase)是为特定的测试目的而设计的一组测试输入、执行条件和预期结果的文档。它的作用是为了测试系统功能是否满足用户某个特定需求。测试用例是指导测试人员工作的依据。
1.测试用例的组成
白哦准的测试用例通常由以下几个模块组成。
测试用例编号:测试用例的唯一标识。
模块:标明被测需求具体属于系统中哪个模块,这是为了更好地识别及维护测试用例。
测试用例标题:有称为测试点,就是用一句话描述测试用例的关注点,每一条测试用例对应一个测试目的。
优先级:根据需求的优先级别来定义,高优先级的测试用例要覆盖核心业务、重要特性,以及使用频率比较高的系统功能部分。
前提条件:测试用例在执行之前需要满足的一些条件,否则测试用例无法执行,例如,一些测试环境或者需要提前执行的操作。
测试数据:在执行测试用例时,需要输入一些外部数据来完成测试,这些数据根据测试用例的统计情况来确定,有参数、文件或者数据库记录等数据。
测试步骤:测试用例执行的步骤描述,测试用例的使用人员可以根据测试步骤完成测试的执行。
期望结果:是测试用例中最重要的部分,主要用来判断被测试对象是否运行正常。
实际结果:结果一般有通过、失败和未执行。
2.测试用例优先级
在实际工作中,测试人员根据系统需求会吧测试用例划分成不同的等级。
P0:核心功能是测试用例(冒烟测试),确定此系统版本是否可测的测试用例,此部分测试用例的结果如果是FALL(失败),其他测试用例就可以不用执行了,需要把程序退还回去给开发人员修改,然后再重新提测。
P1:高优先级测试用例,最常执行的测试用例,测试系统功能是否稳定,它包含基本功能测试和重要的错误、边界测试。
P2:中优先级测试用例,用以更全面地验证系统功能的各个方面,包含异常、边界、中断、网络、容错、UI等的测试用例。
P3:低优先级测试用例,不常被执行,一般包含性能、压力、兼容性、安全、可用性等的测试用例。不同的公司可能对测试用例的等级划分有所差异,但基本上大同小异。
3.测试用例的作用
写测试用例带来哪些好处呢?
首先,测试用例可以帮助人员做到心中有数,在测试用例的指导下,测试人员不会在一个测试点上重复测试好多次,同时也会避免漏掉测试点。而且测试人员在测试用例中可以将测试数据提前准备好,这样就不会漏掉一些重要的数据了。
其次,测试用例的执行结果也是评估测试结果的度量基准。如果设计全面覆盖需求的测试用例都执行过了,发现的系统问题全部修改了,程序员即可放心地把应用程序交付给客户使用。
再次,测试用例也是分析缺陷的标准。因为测试用例中会详细描述期望结果,这个期望结果其实就是分析系统中是不是有缺陷的标准。因为测试用例中会详细描述期望结果,这个期望结果其实就是分析系统中是不是有Bug的一个标准。测试用例执行后反向的结果和预期结果一致的,就说明系统没有Bug;反之,和预期结果不一致,就是系统存在Bug,需要开发人员对Bug进行修复。
4.测试用例设计工具
在写测试用例的时候,测试人员可以使用思维导图把待测的系统模块和测试用例的设计思路理清楚。思维导图完成之后就可以对测试用例进行评审,评审完毕后,测试用例有需要修改的地方可以在思维导图上直接修改。
如果团队要求测试人员用表格的方式去写测试用例,可以再把思维导图中的测试思路转化成为表格形式。
5.测试用例常见的编写方法
边界值分析法是一种很实在的黑盒测试用例方法,它具有很强的“发现”系统故障(Bug)的能力。边界值分析法也是对等价类划分法的补充,测试用例中的边界值是通过等价类划分出来的。
等价类是输入的集合,在每个等价类中选取一定数目的值,选择适当的数据子集来代表整个数据集。等价类分为有效等价类和无效等价类,输入符合条件的值对功能进行检验,输入无效等价类中的值可以找出程序错误的地方。通过降低测试的数目来实现合理的覆盖,覆盖更多的可能数据,以发现更多的软件缺陷。
因果图一般指鱼骨图
鱼骨图(又名因果图、石川图),指的是一种发现问题“根本原因”的分析方法,现代工商管理教育将其划分为问题型、原因型及对策型鱼骨图等几类。
鱼骨图由日本管理大师石川馨先生所发明,故又名石川图。鱼骨图是一种发现问题“根本原因”的方法,它也可以称之为“Ishikawa”或者“因果图”。其特点是简捷实用,深入直观。它看上去有些像鱼骨,问题或缺陷(即后果)标在“鱼头”处。在鱼骨上长出鱼刺,上面按出现机会多寡列出产生问题的可能原因,有助于说明各个原因之间是如何相互影响的。
问题的特性总是受到一些因素的影响,我们通过头脑风暴法找出这些因素,并将它们与特性值一起,按相互关联性整理而成的层次分明、条理清楚,并标出重要因素的图形就叫特性要因图、特性原因图。因其形状如鱼骨,所以又叫鱼骨图(以下称鱼骨图),它是一种透过现象看本质的分析方法。鱼骨图也用在生产中,用来形象地表示生产车间的流程。
场景法:软件的运行几乎都是用时间触发来控制流程的,事件触发时的情景便是形成了场景,而同一事件不同的触发顺序和处理程序就形成事件流。场景法就是通过场景对系统的功能或业务流程进行测试。
判定表是由条件桩、动作桩、条件和动作项组成的。条件桩表示可能出现这个问题(Bug)的所有条件,动作桩表示这个问题(Bug)的所有输出结果,条件项为条件桩的取值,动作项为条件项的各个取值情况下的输出结果。