本帖最后由 manbuyunduanlg 于 2012-3-7 11:41 编辑
这是我对测试用例编写的总结初稿,供大家参考,有什么写的不对的地方,欢迎批评指正。
如何以最少的人力、资源投入,在最短的时间内完成测试,发现系统的缺陷,保证系统的优良品质,是我们搜索和追求的目标。影响系统测试的因素很多,例如系统本身的复杂程度、开发人员(包括分析、设计、编程和测试的人员)的素质、测试方法和技术的运用等等。因为有些因素是客观存在的,无法避免。有些因素则是波动的、不稳定的,例如测试队伍是流动的,有经验的走了,新人不断补充进来;一个具体的人工作也受情绪等影响等等。 如何保障系统测试质量的稳定?有了测试用例,无论是谁来测试,参照测试用例实施,都能保障测试的质量。可以把人为因素的影响减小到最小。即便最初的测试用例考虑不周全,随着测试的进行和系统版本的更新,也将日趋完善。
因此测试用例的设计和编制是系统测试活动中最重要的。测试用例是测试工作的指导,是系统测试的必须遵守的准则,更是系统测试质量稳定的根本保障。
测试需求收集完毕后,就要开始设计测试用例了。测试用例是什么?测试用例就是一个文档,是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序或核实是否满足某个特定需求,以及该程序的某个特性是否正常工作。
要是最终用户对系统感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而,核实这些需求可能通过不通的方式并由不同的测试人员来实施。
使用测试用例的重要性主要原因有以下几个方面:
(1)在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率;
(2)测试用例的使用令测试的实施重点突出、目的明确;
(3)测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件,因此,随着测试用例数量的增加,您对产品质量和测试流程也就越有信心;
(4)测试工作量与测试用例的数量成比例。根据全面且细化的测试用例,可以更准确地估计测试周期各连续阶段的时间安排;
(5)在系统版本更新后只需修正少部分的测试用例便可开展测试工作,降低工作强度、缩短项目周期。
以下章节对如何编制测试用例,直至用例发布做详细说明。
1.
测试用例在testlink上创建格式规则(1)
首先由testlink管理员创建“测试产品”标识,一般按照产品名称来创建等; (2)
第二,在“测试用例”标签页,创建根目录,点击新建测试套件,测试套件名称创建原则也是一般按照产品名称来创建; (3)
创建根目录下一级测试子集:在根目录下创建一级测试子集,创建编号规则:Chapter1-*****、Chapter2-*****,具体子集创建规则参照本文档第二章测试用例架构规则; (4)
创建二级测试子集:在一级测试子集目录下创建二级测试子集,创建编号规则:Chapter1-*****下二级测试子集创建编号规则[1-1]******,[1-2]******。。。, Chapter2-*****下二级测试子集创建编号规则[2-1]******,[2-2]******。。。, 。。。。。。 (5)
第三级为单条测试用例,创建编号规则:统一文件夹下采用同一号段 [1-1]******下测试用例编号规则[1-1-1]******,[1-1-2]******。。。, [1-2]******下测试用例编号规则[1-2-1]******,[1-2-2]******。。。, 。。。 [2-1]******下测试用例编号规则[2-1-1]******,[2-1-2]******。。。, [2-2]******下测试用例编号规则[2-2-1]******,[2-2-2]******。。。, 。。。 测试用例的编号一个最基本的原则是应该具有唯一性,便于查找测试用例,也便于测试用例的跟踪,以及便于填写需求跟踪矩阵。另一个基本原则是更改、添加,以及后期补充测试用例时不能造成用例编号的紊乱。 如果因为项目实际需要创建三级测试子集的,那么第四级为单条测试用例,最好将测试用例控制在第三级。 2.
测试用例架构规则 测试用例的整体架构指的是一个项目确立后,从哪方面来设计整个系统的测试用例结构,测试用例架构设计对测试子集的划分很重要,划分的好,则可以提高测试执行效率,又可以使测试步骤清晰化,使测试人员准确快速的完成测试执行操作。 一般可以按照系统需求规格书的顺序、系统的各子系统来划分,如果系统需求规格书写的规范,有条理,采用这个顺序写就可以做需求矩阵时省时省力。另一个方法是按照系统的子系统来划分结构,一个系统不论大小都是由各个子系统集成而成,通过各个子系统为架构来设计测试用例,就可以使测试目标非常明确,测试效率大大提高,并且测试很有针对性,可以根据项目的具体需求来确定测试用例的整体架构,除此之外,对测试用例子集的划分还需要从发现测试用例中以下几个方面的共性来考虑: (1)
测试前提条件有共性的测试用例; (2)
采用的测试工具有共性的测试用例; (3)
测试环境,组网限制方面有共性的测试用例;如测试DICOM Send,DICOM Print,MPPS等功能; (4)
测试执行策略的原因有共性的测试用例;如有些测试用例需要修改某些参数,并需要再次加载的,或需要系统重启的,因为重新加载或系统重启花费时间比较长,为了提高效率,可以将其放在一起成为一个测试用例子集。 3.
测试用例设计规则 (1)
测试用例的全面性: 测试用例应尽可能代表并覆盖各种合理的和不合理的,合法的和非法的,边界的和越界的,以及极限的输入数据,操作和环境设置等;还应该考虑是否存在跨年、跨月的数据,以及大量数据并发测试; (2)
测试用例的适用性 测试用例对于当前的测试环境和测试人员而言是可以执行的。如果测试用例是理论上可行的或者超过了测试人员的技能范围,该测试用例就是不适用的,即使有个别测试人员能够执行该测试用例,该测试用例也是不适合维护的; (3)
测试用例的可重用性 测试用例的设计要求是可控的,它能够使任何人在任何时间进行测试都能获得同样的结果,也即对同样的测试用例,系统的执行结果应当是相同的,如果出现仅测试用例编写者能够进行测试并获得结果,或者不同的测试人员获得不同的结果的情况,该测试用例就应该被重新设计了。此种除了一种特殊情况:该缺陷的出现频率不是“总是”。 (4)
测试用例的可跟踪性 测试用例是针对特定的测试需求来设计的, 每条测试用例都应该有与之对应的系统需求,同样,系统需求规格书中的每条需求都要有用例与之对应。 目前采用系统需求跟踪矩阵来实现系统需求规格书中各需求的跟踪。在testlink中可以将系统需求规格书与相应的测试用例链接。
|