软件测试用例篇

测试用例的基本要素

测试用例:

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

基本要素:

1. 用例编号: 命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。编号是为了查找测试用例，便于测试用例的跟踪。

2. 测试项目： 要测试项目的名称，可以是测试用例所属的大类，被测需求，被测模块或者是被测的单元。

3. 测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。

4. 重要级别： 定义测试用例的优先级别，可以分为”高“、”中“、”低“三个级别。

高：保证系统基本功能、重要特性、实际使用频率比较高的用例；

中：重要程度介于高和低之间的测试用例；

低：实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。

5. 预置条件： 就是执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试。

6. 测试输入： 测试用例执行时，需要输入的外部信息。

7. 操作步骤： 执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行。

8. 预期结果： 当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。

9. 作者：谁写的

10. 创建时间：写用例的日期

11. 修改日期：最后一个修改用例的日期

12. 测试结果：执行用例后的结果：pass通过、fail失败、block 阻塞

评价测试用例的标准:

1. 用例表达清楚，无二义性
2. 用例可操作性强
3. 用例的输入与输出明确，一条测试用例只能有一个预期结果
4. 用例的可维护性好
5. 用例对需求的覆盖率高
6. 暴露程序BUG的能力强

测试用例的好处/优点和缺点

优点：

1. 产品需求转换为一种可操作的步骤，方便以后有步骤有计划的进行测试

2. 验证产品的需求是否合理

3. 监督产品对需求做出更加具体的设计

4. 记录产品的设计细节，保障以后的查阅

5. 反应测试进度

6. 方便回归测试复查BUG是否还会出现

在測试的过程中，我们会发现bug，而这个bug或许没有在測试用例里面有步骤描写叙述。但考虑到他或许会在以后的版本号中复现。于是我们把它的步骤整理出来。形成一个新的用例。以放便測试他是否会在以后的版本号中出现，

缺点:

1. 添加了测试的维护成本

需求的变动导致測试用例部分失效，于是測试须要更新測试用例。删除无效用例。

2. 消耗了时间成本

测试用例的设计是费时费力的工作，往往设计测试用例所花费的时间比执行所花费的时间还多

测试用例的设计方法

基于需求的设计

1. 验证需求的正确性和合理性
2. 细分需求，多细致的需求就设计多细致的测试用例，从细分的需求里面根据每一个功能点设计完整的测试用例

举例：

**用户需求:**购买3000 元以内的华为智能手机

测试用例:

1. 价格：<=3000元
2. 品牌：华为
3. 类型：智能手机
4. 功能：打电话，接电话，发短信，收短信等

软件需求:(邮箱登录的软件需求)

一个功能点事件流举例：

1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后,再次发送激活邮件
2. 每次发送激活邮件后，仅在发送邮件后24小时之内有效，超过24小时之后需要重新发送激活邮件

测试用例：

• 是否收到邮件角度，是否发送激活邮件

1. 用户未收到邮件，登录时输入电子邮件及密码后，再次发送激活邮件
2. 用户已收到邮件，登录时输入电子邮件和密码后，不发送激活邮件

• 是否超时角度

1. 收到邮件，24小时内，点击激活邮件，激活系统
2. 收到邮件，24小时之后，点击激活邮件，提示链接失效需要重新发送激活邮件
3. 收到邮件，24小时之内，点击激活系统，超过24小时之后，再次点击激活邮件提示链接失效系统已经激活

• 页面检查

1. 收到激活邮件
2. 邮件内容正确
3. 激活URL正确，可激活
4. 再次激活提示已激活
5. 过期激活提示已过期

具体的测试方法

• 等价类

定义：

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。 方法是一种重要的、常用的黑盒测试用例设计方法。

划分： 有效等价类和无效等价类

**有效等价类：**是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明所规定的功能和性能。

无效等价类： 指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能多个。

举例：

//伪代码
if(x>2){
return true;
}else if(-5<x<=2){
return false;
}else{
return false;
}

等价类划分:

1. 大于2的
2. -5到2之间的
3. 小于-5的

• 边界值

定义：

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界值和等价类区别：

1. 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2. 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

分析方法:

选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

举例：(沿用上述等价类的例子)

• 因果图

定义:

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

对比等价类和边界值

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

因果图表示

1. 恒等

2. 与

3. 或

4. 非

​

因果图设计测试用例的步骤：

1. 分析所有可能的输入和可能的输出
2. 找出输入与输出之间的对应关系
3. 画出因果图
4. 把因果图转换成判定表
5. 把判定表对应到每一个测试用例

举例:

需求

“淘宝618活动，定单已提交，订单合计金额大于300元或有红包，则进优惠”。

1. 分析所有可能的输入和可能的输出

**输入:**订单 已提交/订单不提交；金额大于300/金额小于300；有红包/没有红包

**输出:**有优惠/没有优惠

2. 找出输入与输出之间的对应关系

• 订单已提交，金额大于300，有红包，则进优惠
• 订单已提交，金额大于300，无红包，进优惠
• 订单已提交，金额小于300，有红包，进优惠
• 订单已提交，金额小于300，无红包，进优惠
• 订单未提交，无优惠

3. 画出因果图

4. 把因果图转换成判定表

5. 把判定表对应到每一个测试用例

优缺点:

优点

1. 充分考虑了条件之间的组合，对组合情况覆盖充分
2. 每个测试用例覆盖多种输入情况，有利于提高侧测试效率

缺点：

1. 测试输入较多时，判定表的规模就会非常大
2. 输入之间的约束条件不能有效区分输入是否确实需要进行组合测试，会造成不需要组合的测试输入做了组合从而产生用例冗余
3. 输入条件与输出结果的因果关系，有时难以从软件需求规格说明书得到。

• 正交排列

正交排列通俗易懂文章

定义：

正交试验设计(Orthogonal experimentaldesign)是研究多因素多水平的一种设计方法，它是根据正交性，由试验因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验。

因素:(待考察的变量)

一项实验中，欲考察的变量称为因素

水平:(每个待考察变量的值)

在实验范围中因素被考察的值

正交表构成：

行数:

正交表行的个数即实验的次数用N代表

因素数:(待考察变量的个数)

正交表的列的个数，用C表示

水平数：

任何单个因素能够取得的值的最大个数。正交表中的包含的值为从0到数“水平数-1”或从1到“水平

数”，用T代表

正交表的行数:

N=(水平数-1)*因素数+1

正交表的性质:

1. 每列中不同数字出现的次数相等

例如，在两水平正交表中，任何一列都有数码“1”与“2”，且任何一列中它们出现的次数是相等的；在三水平正交表中，任何一列都有“1”、“2”、“3”，且在任一列的出现数均相等。这一特点表明每个因素的每个水平与其它因素的每个水平参与试验的几率是完全相同的，从而保证了在各个水平中最大限度地排除了其它因素水平的干扰，能有效地比较试验结果并找出最优的试验条件。

2. 在任意两列其横向组成的数字对中，每种数字对出现的次数相等

例如，在两水平正交表中，任何两列（同一横行内）有序对子共有4种：（1，1）、（1，2）、（2，1）、（2，2）。每种对数出现次数相等。在三水平情况下，任何两列（同一横行内）有序对共有9种，1.1、1.2、1.3、2.1、2.2、2.3、3.1、3.2、3.3，且每对出现数也均相等。这个特点保证了试验点均匀地分散在因素与水平的完全组合之中，因此具有很强的代表性。

正交法设计测试用例的步骤

1. 找出因素和水平
2. 确认因素数和水平数
3. 确认正交表的行和列
4. 根据正交表的性质填充正交表的数据
5. 正交表的每一行就是一个测试用例
6. 补充认为可能但是正交表上没有的测试用例

举例

需求

以邮箱注册为例

1. 找出因素和水平

**因素：**姓名，邮箱，密码，确认密码，验证码

**水平:**t填写，不填写

2. 确认因素数和水平数

**因素数:**5

**每个因素的水平数:**2

3. 确认正交表的行和列

行数： （2-1）*5+1=6

**列数:**5

4. 根据正交表的性质填充正交表的数据

5. 正交表的每一行就是一个测试用例

• 输入账户，不输入邮箱，不输入密码，不输入确认密码，输入验证码
• 。。。
• 。。。

6. 补充认为可能但是正交表上没有的测试用例

全输入

全不输入

• 场景设计法

定义:

场景法主要用于测试软件的业务过程或业务逻辑，是一种基于软件业务和用户行为的测试方法。

把一个一个的功能点组合(可能是一个逻辑)起来，形成一个一个的场景

举例:

ATM取款

基本流程:插卡->输入密码->输入取款金额->取钱->退卡

分析:

正常业务流程:插卡正确，输入密码正确，输入取款金额小于等于银行卡余额，正常取钱，正常退卡

异常业务流程:

考虑异常事件:

操作超时，忘记退卡，三次密码错误账户锁定，卡插反，插错卡，卡消磁，ATM机金额不足，ATM机吐出的钱数和取的钱数不一致，取费100的面额，插入的卡和ATM机上显示的信息不符

异常流程:

1. 取钱完成后，忘记退卡，卡被吞
2. 取款中的操作超时卡被吞
3. 三次密码错误，账户被锁定
4. 插错卡没法取款
5. 卡消磁无法使用

• 错误猜测法

定义:

根据测试人员的知识和经验，猜测软件的哪一个模块或者哪一个功能点出现问题，专门对这个功能点进行测试用例的设计，适用于补充的设计测试用例的方法

举例:

根据关键字查询页面

比如只要存在关键字就可以查询到，但是我在关键字前后加了空格就差不到

因为是将输入的整个字符串都当做查询条件

select * from xx where name="  zpf  "//带空格查不到，解决方案就是自妇产trim去掉首尾空格

测试用例的有效性

Good article

有效性讲解

什么是测试用例的有效性**

1. 当业务代码出现问题的时候，测试用例可以发现这个问题，那么我们救人味儿这一组测试泳衣是有效的
2. 当业务代码出现问题的时候，测试用例没能发现这个问题，我们就认为这一组测试用例是无效的

为什么要评估测试用例的有效性

1. 大量的测试用例，花费大量的时间和资源，不一定就能找出所有BUG，因为包含无效的测试用例，那评估是否有效，过滤掉无效测试用例，节省时间和资源，提高效率，不是更好
2. 测试用例太多了，想要删除一些，但是又怕删除之后会不会就发现不了存在的BUG，那这个时候评估下测试用例是否有效，删除掉无效测试用例

测试用例的有效性度量/如何衡量测试用例的有效性/如何评价测试用例的有效性

代码注入逻辑：(变异机器人自动化测试)

1. 往被测试代码中写入一个BUG
2. 执行测试
3. 把测试结果和无变异时的测试结果对比，判断是否有新的测试用例失败
4. 重复1-3若干次每次注入一个不同的BUG
5. 统计该系统的测试有效性

测试有效性度量三板斧

测试用例的粒度

粒度详解

粒度：

指测试用例编写的详细程度。

测试用例可以写得很简单，也可以写得很复杂。

最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。

而最复 杂的测试用例就像飞机维修人员使用的工作指令卡一样，会指定输入的每项数据，期待的结果及检验的方法， 具体到界面元素的操作步骤，指定测试的方法和工具等。

(1)测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

(2)测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试 的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

**测试资源情况来决定设计出怎样粒度的测试用例。 **

主要考虑可以参考如下内容：

产品的质量要求

项目对用例的要求

测试时间和资源是否充分

测试用例的评价

1. 同行评审：测人人员之间通过讨论协作来完成测试用例的设计，理由：测试用例的目的就是尽可能全面的覆盖需求，测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性，因此需要一起设计测试用例
2. 用户检查：用户参与到测试用例的设计中，让用户参与评审，从而体现敏捷的顾客的写作比合同谈判更有价值
3. 项目组评审：测试负责人组织协调展会议用例编写人对用例进行讲解，参会人员有异议的当场提出