测试用例设计

本章重点

• 测试用例的基本要素
• 测试用例的设计方法

• 基于需求的设计方法
• 等价类
• 边界值
• 因果图
• 正交分析法
• 错误猜测法
• 场景法

• 测试用例的有效性
• 测试用例的粒度和评价

测试用例的基本要素

测试用例就是为了实施测试而先被测试系统提供的一组集合,这组集合包括,测试环境,测试步骤,测试数据,预期结果等

评价测试用例好的标准

• 用例表达清楚,无义性
• 用例可操作性强
• 用例的输入输出明确,一条用例只有一个预期结果
• 用例对需求的覆盖率高

测试用例给我们带来的好处

• 测试执行的依据
• 使得工作可重复,自动化测试的基础
• 评估需求覆盖率
• 用例的复用
• 积累测试方法思路以供后续鉴赏
• 解决了如下问题

不知道是否全面的测试了所有功能,测试的覆盖率无法衡量,重复测试无法进行,回归测试等,测试用例的大量冗余,影响测试效率

测试用例设计方法

• 基于需求的设计方法
• 等价类
• 边界值
• 因果图
• 正交分析法
• 错误猜测法
• 场景法

基于需求的设计方法

基于需求的设计方法是测试设计/开发测试用例的基础,我们通过需求分析,验证需求是否合理,正确,完整,无二义性,并且逻辑自洽.然后我们在需求分析的基础细化需求,上列出功能需求点或者需求项,并且根据需求点或者需求项进一步设计测试用例!

分析需求一般分为功能需求和非功能需求

• 功能性测试

• 界面的全面性测试(界面从左到右从上到下)
• 按照业务的场景把一个个独立的功能串起来测试
• 验证功能之间的交互性和一致性
• 同一个功能不同输入数据的测试
• 同一个功能异常数据,错误操作测试
• 功能相关的算法验证(白盒测试需要看代码,对代码进行测试)

• 非功能性测试

可靠性测试,安全性测试,易用性测试,兼容性测试,性能测试,可移植性测试,容错性测试

等价类

把输入或输出划分若干个等价类,从每一个等价类中选一个(或多个)测试用例进行测试,如果该测试用例通过,那么这个等价类测试就通过

• 有效等价类:符合数据规格说明书的数据
• 无效等价类:不符合数据规格说明书的数据

边界值

边界值是等价类的补充,输入输出的边界进行测试用例的设计,叫做边界值法
等价类和边界值往往结合起来进行测试用例的设计

因果图法

因果图是一种逻辑图,恒等,与,或,非,用因果图来设计测试用例,叫做因果图法
使用场景:当我们有很多的输入,不同的输入或者不同输入组合针对有不同的输出,这个时候我们就可以用因果图法进行设计用例

因果图发设计测试用例步骤

• 分析出所有的输入和输出
• 找出输入和输出之间的关系
• 根据关系画出因果图
• 根据因果图画出判定表
• 根据判定表写出测试用例

场景法

很多软件不同场景,是基于不同事件触发,导致场景走不同的事件流!
不同的功能点串起来形成一个场景.不同的功能点又有不同的输入,不同的输出导致不同的测试场景

例如ATM取款场景

插卡-> 输入密码->输入取款数->取款->退卡

每个步骤都可能导致不同的测试场景
这里就类似于一个事务,只有所有操作都通过了,这个事务才成功,如果其中一个操作失败了,事务也就执行失败

错误猜测

根据测试人员的测试经验,知识的积累,自觉,对自己认为有bug的模块进行专门的测试用例的设计,类似于探索性测试

正交分析法

根据正交分析来测试设计用例,从大量的实验数据中根据正交原则取出最优的数据组合,根据最优集合测试的结果,来分析整个测试结果

测试用例的有效性

• 测试用例对应的功能已经删除,不可操作了
• 执行一条测试用例未发现bug,但实际上此处有bug
• 执行一条测试用例发现了bug
• 执行一条测试用例未发现bug,此处bug已修改

测试用例的粒度和评价

测试用例的粒度

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试
粒度: 指测试用例编写的详细程度

• 测试用例写的过于复杂和详细带来的问题

1.效率问题2.维护成本问题.测试用例写的过于详细,留给测试人员思考的的空间比较少,容易限制测试人员的思维!

• 测试用例写的过于简单,则可能失去了测试用例的意义

它的作用仅仅是在测试过程中作为一个简单的测
试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

大多数编写测试用例的粒度介于这2者之间,主要通过下面方面考虑

• 产品的质量要求
• 项目对用例的要求
• 测试时间和资源是否充分

用例可以简化,但是不能省略

测试用例的评价

测试用例设计出来了,如何提高用例的质量呢?测试用例的质量保证需要综合各种手段和方法.评审分为正式和非正式评审.

• 同行评审
• 用户评审
• 项目组评审

(1)测试用例的检查可以有多种方式 但是最敏捷的应当属临时的同行评审。同行评审，尤其是临时的同行评审，应该演变成类似结对编程一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例。
（2）除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让用户参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于如何定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家)；如果测试是被定义为对开发提供帮助和支持，那么顾客显然就是程序员了。
(3) 由测试负责人组织协调开展会议，用例编写人对用例进行讲解，参会人员有异议的当场提出。