【软件测试-4】&用例篇

【前言】上一节讲述的是一次基本的测试过程。在我们开始做了一段时间基础测试，熟悉了业务之后，往往会分配来写测试用例，并且在日常测试中，有时也需要补充测试用例到现有的案例库中。

1.测试用例的基本要素

回顾测试用例的概念：

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

好的测试用例是一个不熟悉业务的人也能依据用例来很快的进行测试

评价测试用例的标准：对比好坏代码的评价标准

• 用例表达清楚，无二义性。
  无二义性：即两个人看，不会看出不同的点或意思，看的点都是一样的

• 用例可操作性强。
  如现在要进行一个性能测试，并发的测试，该系统的支付功能1000个人同时并发（即同时点击支付按钮付款）使用的时候，它的系统的响应时间。按照实际情况的话，这个用例的操作很难实现，因为很难找1000个人支付，就算找到了1000个人，也很难做到同时并发。
  如何解决上面的这种有问题测试方案呢？可以使用性能测试工具模拟虚拟用户的操作，可以模拟1000个用户进行支付功能

• 用例的输入与输出明确。要保证一条用例只有一个预期结果。
  因为测试用例如果多种情况混合在一起，容易漏测。

• 用例的可维护性好。
  测试用例要存放成容易修改的格式（如Excel,不要存放成PDF(PDF无法修改)）

• 用例对需求的覆盖率高
  测试用例要对需求的每一个细节都能够覆盖到

• 暴露程序Bug的能力强。
  如:你写的测试用例发现了以前测试人员没有发现的BUG(发现了历史遗留BUG)

用例的基本要素可以参见如下例子：案例1

测试用例 ecsp-439: 单位用户注册成功
步骤动作:	期望的结果:
进入注册页面，选择注册	系统展现注册页面
输入符合要求的单位名称、单位邮箱、密码、确认密码、组织机构代码、验证码，并确认同意《用户注册协议》，	提交注册信息系统进行注册操作，发送激活邮件。注册成功后，跳转到注册成功页面，并提示用户进
进入注册用的邮箱，进行激活操作	激活成功
用注册的邮箱和密码，进行登录操作	登录成功，系统展示欢迎页面
测试方式	手工
重要性	重要
测试环境	CHROME,IE10+
测试前提	系统运行正常，邮件服务器已开启
功能模块	注册登录

案例2：手机拍照测试用例

用例元素：标题、测试思路、预设条件、步骤、预期输出

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

• 它是测试执行者的依据
• 使得工作可重复，是自动化测试的基础（依据）
• 评估需求覆盖率：测试人员进行测试的准则就是根据需求进行测试，写测试用例能够覆盖大多数的需求
• 积累测试的方法思路以供后续借鉴

使用中带来的困扰

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

解决如下问题：

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

3.测试用例的设计方法

测试用例的总体设计方法

3.1根据需求写测试用例（基于需求的设计）

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

基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。

（1）验证需求是否正确、完整、无二义性，并且逻辑一致。

（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。

（1）首先要保证需求的合理性和正确性，要先验证需求。测试人员在拿到一个需求的时候，要有基本的判断能力，如果这个需求有问题或不合理，测试人员可以提出这个需求没法实现，没法测；

（2）分析需求。在需求和合理和正确的前提下，我们要理解需求，然后把大需求细化成小需求（设计需求），根据每一个小需求提炼功能点，根据每一个功能点，发散地考虑它的测试用例，然后去写测试用例（用具体的设计测试用例的方法写）。

实例：

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

需求是否合理：合理

测试用例：根据用户需求写测试用例（把大需求细化成小需求，根据每一个小需求提炼出功能点）
1.价格：<=3000元
2.品牌：华为
3.类型：智能手机
4.手机功能验证：
4-1.打电话
4-2.接电话
4-3.发短信
4-4.收短信

…

软件需求：

事件流

1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
   对于未收到激活邮件：可从已收到激活邮件和没有收到激活邮件两个方面来写测试用例
   对于登录界面录入电子邮件及密码：可从输入正确的电子邮件和密码、输入错误的电子邮件和正确的密码、输入正确的电子邮件和错误的密码、输入错误的电子邮件和错误的密码四个方面来写测试用例
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。
   对于发送邮件后起24小时之内有效：可从三个方面来写测试用例

   24小时之内，打开邮件，进行点击激活；
   等于24小时，打开邮件，进行点击激活；
   超过24小时，打开邮件，进行点击激活

测试用例

1-1、用户未收到激活邮件，登录时输入电子邮件及密码后，再次发送激活邮件

1-2、用户已经收到激活邮件，登录时输入电子邮件及密码后，不发送激活邮件

1-3、用户已经收到激活邮件，登录界面录入正确的电子邮件和密码，不发送激活邮件

1-4、用户已经收到激活邮件，登录界面录入输入错误的电子邮件和正确的密码，再次发送激活邮件

1-5、用户已经收到激活邮件，登录界面录入输入正确的电子邮件和错误的密码，再次发送激活邮件

1-6、用户已经收到激活邮件，登录界面录入输入错误的电子邮件和错误的密码，再次发送激活邮件

2-1、收到邮件，24小时内进行激活

2-2、收到邮件，24小时后链接过期进行激活。

2-3、收到邮件，等于24小时进行激活

2-4、收到邮件，已激活（已在24小时内点击激活邮件成功进行激活操作），24小时后链接过期，又重新打开激活邮件，再次点击激活会怎样？会提示：您已激活，无需再次激活，或链接已过期。

页面检查：

1、收到激活邮件

2、邮件内容正确

3、激活URl正确，可激活

4、再次激活提示已激活

5、过期激活提示已过期

3.2具体的设计测试用例的方法（6个）

3.2.1等价类

等价类就是为了解决测试用例无法穷举的情况；

把输入分成若干个等价类，从每一个等价类当中选一个测试用例进行测试，如果这个测试用例测试通过，我们就说这个测试用例代表着等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

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

等价类只考虑输入域的分类，没有考虑输入域的组合，需要其他的设计方法和补充。

案例1

超市买水果

有效等价类：苹果、桃子、梨

无效等价类：青菜、米、饮料，…

案例2

针对字符类型设计测试用例

• 有效等价类：大写字符A-Z，小写字符a-z，大小写混合
• 无效等价类：非字符类型，如：汉字，特殊符号，数字，空格，字母和前面符号的混合，前面无效符号的混合
  针对6-15位长度设计测试用例
• 有效等价类：大于等于6位，小于等于15位的任何长度
• 无效等价类：小于6位, 大于15位

案例3

3.2.2边界值

边界值就是对输入输出的边界进行测试用例的设计

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

如：针对6-15位长度的边界进行测试用例的设计

边界值：5 6 7 14 15 16

备注：设计测试用例的时候，往往会把等价类和边界值结合在一起进行测试用例的设计，这样设计出来的测试用例会比较完整。

3.2.3因果图

输入有多个，不同的输入组合有不同的输出，这种情况可以使用因果图法来设计测试用例。

因果图是一种简化了的逻辑图，能直观地表明程序输入条件（原因）和输出动作（结果）之间的相互关系。因果图法是借助图形来设计测试用例的一种系统方法，特别适用于被测试程序具有多种输入条件、程序的输出又依赖于输入条件的各种情况。

因果图的需要掌握的基本知识：因果图就是一个逻辑图，恒等、与、或、非

• 恒等：如果原因为真，那么结果必定为真。 例如：动物园运来大熊猫，动物园一定有大熊猫

  

• 与：输入有多个条件，多个条件为真时，输出结果才为真。例如：北京姑娘要求男方，必须有车并且有房

  

• 或：输入有多个条件，其中有一个条件为真，输出结果就为真。 例如：长沙姑娘要求男方，你有车或者有房

• 非：输入为真，输出为假，输入为假，输出为真。例如：你不好好学习，找到好工作

  

如何用因果图法设计测试用例？

因果图法设计测试用例的步骤如下。

(1)分析所有可能的输入和可能的输出。

(2)确定不同的输入组合与输出之间的对应关系。

(3)画因果图，用因果图来表示输入和输出之间的关系。

(4)根据输入输出的关系用因果图画判定表。

(5)根据判定表写对应到的每一个测试用例。

案例：

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

输入:订单提交、金额大于300元、有红包

输出：有优惠、无优惠、

（2）确定不同的输入组合与输出之间的对应关系（红包和金额四种组合情况）

订单已提交，金额大于300元，没有红包，有优惠

订单已提交，金额小于300元，有红包，有优惠

订单已提交，金额大于300元、有红包，有优惠

订单已提交，金额小于300元，没有红包，没有优惠

订单没有提交，没有优惠

（3）画因果图，用因果图来表示输入和输出之间的关系。

(4)根据输入输出的关系用因果图画判定表。

(5)根据判定表写对应到的每一个测试用例。

订单已提交，金额大于300元，有红包，有优惠

订单已提交，金额大于300元，没有红包，有优惠

订单已提交，金额小于300元，有红包，有优惠

订单已提交，金额小于300元，没有红包，没有优惠

订单未提交，金额大于300元，有红包，没有优惠

订单未提交，金额大于300元，没有红包，没有优惠

订单未提交，金额小于300元，有红包，没有优惠

订单未提交，金额小于300元，没有红包，没有优惠

3.2.4 正交排列(正交设计法)

正交设计法是研究多因素多水平的一种测试用例的设计方法。

它是根据正交性，在所有的试验组合中找到最优的组合进行测试，通过这些最优组合的解来分析验证整个试验整体的结果。它非常的经济和高效。

多因素就是指输入项，多水平就是指每个输入的取值情况
因素：输入
水平：输入的取值
正交表的组成：
正交表的列：因素数（C）,输入的个数
水平数：每一个因素的取值的最大个数（T）
正交表的行：L=(水平数-1)*因素数+1

正交表的性质：
（1）每一列个数据出现的次数一样多
（2）不同两列不同的数据组合出现的次数一样多

根据正交表设计法设计测试用例的步骤：

（1）先确定因素（输入）
（2）确定每一个因素的水平
（3）找出因素数和水平数
（4）根据因素数和水平数确定正交表的行和列
（5）根据正交表的性质去填充正交表里的数据
（6）根据正交表的每一行设计测试用例
（7）补充正交表里面没有的，但是你认为可能比较关键的测试用例

案例：还是以邮箱注册为例：

（1）姓名、email 、 密码、确认密码、验证码

（2）填写、不填写

（3）因素数：5；水平数：2

（4）列=因素数=5；行=（水平数-1）*因素数+1=6；（即一个6行5列的一个表）

（5）填充数据

（6）根据正交表的每一行设计测试用例

①姓名填写，email不填写，密码填写，确认密码填写，验证码不填写，注册失败。

②姓名不填写，email填写，密码不填写，确认密码不填写，验证码不填写，注册失败。

③姓名填写，email不填写，密码填写，确认密码不填写，验证码填写，注册失败。

④姓名填写，email不填写，密码不填写，确认密码填写，验证码不填写，注册失败。

⑤姓名不填写，email填写，密码填写，确认密码不填写，验证码填写，注册失败。

⑥姓名不填写，email填写，密码不填写，确认密码填写，验证码填写，注册失败。

（7）补充正交表里面没有的，但是你认为可能比较关键的测试用例

全填写：姓名填写，email填写，密码填写，确认密码填写，验证码填写，注册成功。

全不填写：姓名不填写，email不填写，密码不填写，确认密码不填写，验证码不填写，注册失败。

3.2.5场景设计法

场景设计法就是，把各个孤立的功能点按照一定的策略组合起来，形成一个应用场景。

案例：ATM取款机的取款场景（流程）

流程：插卡——选择语言——输入密码——输入取款金额——取钱——退卡

每个功能点的正常情况：

卡正常并插卡成功，语言合适、密码正确、输入小于银行卡余额的钱数、成功取钱、成功退卡

每个功能点的异常情况：

插卡：卡插反了、卡芯片消磁或损坏了、卡注销了、卡无效（公交卡）、卡挂失后又找到了
ATM机：断网、断电、没钱了、损坏了、系统正在升级
密码：第一次输入密码错误，第二次或第三次输入正确，继续取款流程
三次都输入错误，吞卡/账户锁定
输入取款金额：输入金额大于银行卡余额、输入金额小于银行卡余额，但ATM机余额不足、输入小于100的金额、输入的钱数不是100的倍数
取钱：钱已经吐出来了，但是长时间不拿，会发生什么情况呢？
退卡：卡已经退出来但是长时间不去拿（具体有时间限制），会吞卡

取钱场景测试用例

正常的

1.成功插卡进ATM机，选择合适的语言，密码输入正确，输入小于银行卡余额的钱数，成功取钱，退卡（以上所有操作都在银行限定的长时间不操作吞卡时间范围之内）

异常的（这里先写一个插卡功能的测试用例）

2.卡插反了，ATM机给出“请重新插卡！”，提示，重新正确插卡，选择合适的语言，密码输入正确，金额输入正确，成功取钱，退卡；

3.插入无效卡，ATM机给出“请插入有效的银行卡！”，提示，重新正确插卡，选择合适的语言，密码输入正确，金额输入正确，成功取钱，退卡；

4.插入消磁的银行卡，ATM机给出“该银行卡无效！”，取款失败；

5.插入注销后的银行卡，ATM机给出“该银行卡无效！”，取款失败；

总结：找出场景当中的每一个功能点，根据每一个功能点的正常和异常情况去设计测试用例

3.2.6错误猜测法

错误猜测法就是根据测试人员的知识和经验去推断可能会出现问题的功能模块，有针对性的去设计测试用例。

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

错误猜测法并不是特别靠谱，他只是一种补充的设计测试用例的方法，测试人员可以使用其他设计测试用例的方法设计需求的测试用例，然后用错误猜测法作为一种补充的方式去不补充可能遗漏或没想到的测试用例。（根据丰富的经验和知识去加测试用例）。