软件测试---用例篇

软件测试—用例篇

测试用例（Test Case）概念

是为了实施测试而向被测试系统提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果等要素。

好的测试用例是不熟悉业务的人也能根据用例很go准

• 用例表达清楚，无二义性，不能出项“是否”这样的词汇
• 用例可操作性强
• 用例的输入输出明确，一条用例只有一个预期结果
• 用例可维护性好，即可读性好
• 用例对需求的覆盖性高
• 暴露程序bug的能力强，才能发现更多更深的bug。

测试用例的好处

测试执行者的依据
使得工作可重复，自动化测试的基础
评估需求覆盖率
用例的复用
积累测试的方法思路以供后续借鉴

测试用例除了有很多好处外，也有它的缺点：测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行测试的时间要多。

设计测试用例要解决的问题：

• 不知道是否全面的测试了所有的功能
• 测试的覆盖率无法衡量
• 对新版本的重复测试很难实施
• 存在大量冗余测试影响测试效率

测试用例的设计方法（七种）

1.基于需求的设计

RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为 它使测试专注于质量问题产生的根源，即需求。

基于需求的测试是最根本的软件测试，它关注两个关键问题：

• 验证需求是否正确，完整，无二义性，逻辑一致
• 从黑盒角度，设计出充分并必要的测试集，使设计和代码能够完全满足需求

1.等价类划分
概念：根据需求将输入划分为若干个等价类，从等价类中选出一个测试用例，若这个测试用例通过，就认为所代表的等价类测试通过，这样就使用了较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合。
  

  eg:账号为9位数字字符
  有效等价类：9位数字字符
  无效等价类：（1）有非数字字符 （2）少于9位数字字符 （3）多于9位数字字符

等价类只考虑到了输入域的分类，未考虑输入域的组合，需要其他方法来补充 **2.边界值分析** 对输入输出边界值进行测试的一种黑盒测试方法，一般是等价类划分法的补充，边界值来自于等价类的边界。一般应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

常见的边界值：

• 对16-bit 的整数而言 32767 和 -32768 是边界
• 屏幕上光标在最左上、最右下位置
• 报表的第一行和最后一行
• 数组元素的第一个和最后一个
• 循环的第 0 次、第 1 次和倒数第2 次、最后一次

–

1. 输入框长度为1-11，取边界值为：1、11、12、0
2. 运动员的参赛项目为1-3项，取边界值为：0项、1项、3项、4项
3. 查询面页面有999行，每50行为一页，取边界值为：输出0行、1行、50行、51行、999行、1000行

注意：要搞清楚是闭区间还是开区间

如：
（1，10）取边界值为：1，2，9，10
[ 1,10 ] 取边界值为：0，1，10，11
（1,10 ]取边界值为：1，2，10，11

**3.因果图** 是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，适合检查输入条件的各种组合情况。特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。 等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了 **四种因果关系**

• 恒等

• 与

- 或

- 非

因果图法设计测试用例的步骤
1.分析所有可能的输入和输出
2.找出输入和输出之间的对应关系
3.画出因果图
4.将因果图转成判定表
5.判定表对应每个测试用例

一个案例：
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”
步骤一：

• 输入：订单已提交、金额大于300、有红包
• 输出：优惠、不优惠

步骤二：

• 订单未提交，不优惠
• 订单已提交，订单金额大于等于300，没有红包，优惠
• 订单已提交，订单金额大于等于300，有红包，优惠
• 订单已提交，订单金额小于300，有红包，优惠
• 订单已提交，订单金额小于300，没有红包，不优惠

步骤三：因果图

步骤四：判定表

步骤五：测试用例
1，2，3，4，5（包含6，7，8）

因果法设计测试用例可以帮助测试人员理清输入和输出的关系，但是对于比较复杂的输入和输出，会耗费大量时间

4.正交法
正交法的出现时为了减少测试用例的数目，用尽可能少的用例覆盖输入的两两组合
利用因果图来设计测试用例时, 作为输入条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系非常庞大,以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地,合理地减少测试的工时与费用,可利用正交实验设计方法进行测试用例的设计。

正交实验设计方法:从大量的（实验）数据（测试用例）中挑选适量的,有代表性的点（例）,从而合理地安排实验（测试）的一种科学实验设计方法.类似的方法有:聚类分析方法,因子方法方法等.

正交表的两条性质

• 每一列中各数字出现的次数一样多
• 任何两列构成的有序数对出现的次数一样多

因素（Factor）：在一项实验中，凡欲考察的变量称为因素（变量）
水平（Level）：实验范围内，因素被考察的值被称为水平（变量的取值）

正交表的构成：
1.行数（Runs）：正交表中行的个数，即实验的次数，用N表示
2.因素数（Factors）：正交表中列的个数，用C表示
3.水平数：任何单个因素所能取值的最大个数，从0~水平数-1或从1~水平数，用T表示

正交表的表示形式：
L=行数（水平数*因素数） L=N（TC）

正交法设计测试用例的步骤：
1.有哪些因素（变量）
2.每个因素有哪些水平（变量的取值）
3.选择合适的正交表
4.把变量的值映射到正交表中
5.把每行各因素水平的组合作为一条测试用例
6.再加上可疑但没在表中出现的测试用例

案例：继续以注册为例（类似工具可以使用微软的PICT工具）
步骤一：
因素：姓名、邮箱、密码、确认密码、验证码
步骤二：
水平：填写、不填写
步骤三：
表中的因素数>=5；
表中至每个因素数的水平数>=2
行数取最少的一个，即试验次数最少的一个
L=N（TC）
这里的N是实验次数，N（min）=因素数C*（水平数T-1）+1=5*（2-1）+1=6
选择正交表，这里选择了L6_2_5。
步骤四：

正交表的建立需满足正交表的两条性质，并且实验次数应大于等于最小试验次数6
步骤五：
根据正交表生成八条测试用例
步骤六：
增补可疑测试用例，这里我们没有可疑的

6.场景设计法
软件一般以事件触发来控制流程
事件流：点击之后完成的动作，同一事件不同的触发顺序和处理结果就形成事件流。
场景法特别适用于控制流清晰的系统。

设计步骤：
1.画出程序控制流图（可先画出程序流程图，再把流程图转化成控制流图）
2.根据控制流图设计出场景
3.根据场景设计测试用例

7.错误猜测法
经验丰富的测试人员经常用这种方式。
基于多年的经验和直觉，找出程序中可能出现的bug，有针对性地设计测试用例。
经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见，或者从故障管理库中整理bug。梳理出产品以往哪些地方容易出现问题，问题越多的地方，潜在的bug也就越多。

以注册为例：
1.校验中特殊字符空格的处理？
空格在前面或后面可直接截取，在中间就认为出现错误
2.密码校验的大小写？
3.姓名中的特殊字符？
4.密码发送是明文？

测试用例的有效性

测试用例对应的功能已删除，不能进行操作
执行一条测试用例，发现了bug
执行一条测试用例未发现bug，实际该处BUG已修改，该条测试用例是有效的，是为了测试无bug

测试用例的粒度和评价

粒度：是指测试用例编写的详细程度
最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。
而最复杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题
(2)测试用例写得过于简单，则可能失去了测试的意义。

因此，我们可以根据产品的质量需求、项目对用例的要求、测试的时间和资源是否充足这三点来把握测试用例的粒度