使用用例场景,设计测试用例
作者:周毅
概念和定义
不完全、不彻底是软件测试的致命缺陷,任何程序只能进行少量而有限的测试。测试用例在此情况下产生,同时它也是软件测试系统化、工程化的产物。而测试用例的设计一直是软件测试工作的重点和难点.
什么是测试用例?
为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据,称之为测试用例。我们不可能进行穷举测试,为了节省时间和资源、提高测试效率,必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。
怎样的用例算是好用例?
一个好的测试用例是在于它能发现至今未发现的错误。
使用测试用例的好处
在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。
功能模块的通用化和复用化使软件易于开发,而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升。
设计测试用例的方法
u 黑盒测试:
等价类划分法
边界值分析法
错误推测法
因果图法
u 白盒测试:
逻辑覆盖法
基本路径测试法
测试用例的设计过程
测试设计员(分析设计员)依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。
测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员,则可用分析设计员代替。
针对白盒,还应有驱动程序和桩模块。
测试点的确定
u ISO 质量体系:
在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。
u CMM 质量体系:
在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程,每一个用例模型为一个测试点,用例模型中每一个测试需求至少应有两个测试用例。
理解上的误区
测试用例应由测试设计员或分析设计员来制定,而不是普通的测试员。
测试点应由分析设计员确立,与测试人员无关。
测试工作展开于项目立项后,而不是代码开发完成之后。
测试对象不仅仅是源代码,还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。
用例场景的定义
用例场景是通过描述流经用例的路径来确定的过程,这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
为什么引入用例场景
现在的软件几乎都是由事件触发来控制流程的,事件触发时的情景便形成了场景,而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中,生动的描绘出事件触发时的情景,有利于测试设计者设计测试用例,同时测试用例也更容易的得到理解和执行。
提出这种测试思想的是Rational 公司,在RUP2000 中文版当中有其详尽的解释和应用,用例场景贯穿其中。
用例场景例子
下图中经过用例的每条不同路径都反映了基本流和备选流,都用箭头来表示。基本流用直黑线来表示,是经过用例的最简单的路径。每个备选流自基本流开始,之后,备选流会在某个特定条件下执行。备选流可能会重新加入基本流中(备选流 1 和 3),还可能起源于另一个备选流(备选流 2),或者终止用例而不再重新加入某个流(备选流 2 和 4)
图1-1 测试用例流
遵循上图中每个经过用例的可能路径,可以确定不同的用例场景。从基本流开始,再将基本流和备选流结合起来,可以确定以下用例场景:
场景 1 基本流
场景 2 基本流 备选流 1
场景 3 基本流 备选流 1 备选流 2
场景 4 基本流 备选流 3
场景 5 基本流 备选流 3 备选流 1
场景 6 基本流 备选流 3 备选流 1 备选流 2
场景 7 基本流 备选流 4
场景 8 基本流 备选流 3 备选流 4
注:为方便起见,场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。
生成每个场景的测试用例是通过确定某个特定条件来完成的,这个特定条件将导致特定用例场景的执行。
测试用例例子
假定上图描述的用例对备选流 3 规定如下:
“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额,则出现此事件流。系统将显示一则警告消息,之后重新加入基本流,再次执行上述步骤 2‘输入提款金额’,此时银行客户可以输入新的提款金额。”
据此,可以开始确定需要用来执行备选流 3 的测试用例:
表1-1 备选流 3 的测试用例
|