【软件测试】测试用例

目录

1. 测试用例的基本要素

2. 测试用例的设计方法

2.1 基于需求进行测试用例的设计

⭐️（1）功能需求测试分析

⭐️（2）非功能需求测试分析

2.2 具体的设计方法 （黑盒测试）

⭐️（1）等价类

⭐️（2）边界值

⭐️（3）错误猜测法

⭐️（4）场景设计法

⭐️（5）因果图

⭐️（6）判定表 

---

1. 测试用例的基本要素

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

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

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

用例表达清楚，无二义性

用例可操作性强

用例的输入与输出明确。一条用例只有一个预期结果

用例的可维护性好

用例对需求的覆盖率高

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

测试执行者的依据

使得工作可重复，自动化测试的基础

评估需求覆盖率

用例的复用

积累测试的方法思路以供后续借鉴

• 使用中带来困扰：

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

• 解决如下问题：

不知道是否较全面的测试了所有功能

测试的覆盖率无法衡量

对新版本的重复测试很难实施

存在大量冗余测试影响测试效率

2. 测试用例的设计方法

2.1 基于需求进行测试用例的设计

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正 确、完整、无二义性，并且符合逻辑。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测 试点或者测试项，然后根据每一个测试点进行测试用例的设计；

在分析测试需求时，一般分为功能测试需求和非功能测试需求

⭐️（1）功能需求测试分析

对于功能测试中，可以借助功能框图来帮助我们进行测试的需求分析。概括起来， 功能测试需求通常包括以下几个方面。

（1）业务流程（软件规格说明书）

（2）界面相关（UI设计稿）

（3）易用性（测试人员经验）

下面以我们常用的百度云盘手机端为例进行分析功能：

 

在进行需求分析的时候，我们还要考虑业务规则如，上传文件的大小有没有限制；一次性上传多少数量的文件，比如小于100个；文件夹最多有多少层等等；

⭐️（2）非功能需求测试分析

非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。从测试需求分析来看，每一类非功能特性测试都需要根据需求单独分析。他们之间可能会存在相互影响，如安全性越高，就越有可能给易用性，性能带来更大的挑战。

例如：163.com登录模块测试用例设计

 

2.2 具体的设计方法 （黑盒测试）

⭐️（1）等价类

因材施教的例子:

原则上讲, 老师应该依据每个学生自身的情况, 指定符合的学习方案. 但是实际上学生太多老湿管不过来, 只能分成几类: 优等生强调知识面的扩展和综合能力的提升; 中等生强调夯实基础, 查缺补漏; 差等生强调 优先掌握重点, 暂时跳过难点...

思路：输入的集合是无穷的, 不能全都覆盖到

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

• 有效等价类: 满足用户需求对应的输入集合就是有效的等价类
• 无效等价类:不满足用户需求对应的输入集合就是无效等价类

举个简单的例子：

超市买水果

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

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

思考一下：如何针对 6-15 位长度设计测试用例？

需求: 需求有输入，输入是无穷的

⭐️（2）边界值

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

边界点：

• 上点: 边界上的点
• 内点: 边界内的点
• 离点:上点附近的一个点 (如果是闭区间，边界外的点，如果是开区间，边界内的点)

 如何通过这个方法设计测试用例

• （1）充分理解需求
• （2）找边界点
• （3）针对边界点设计测试用例

需求: 用户名长度6~15

上点: 6，15
内点: 10
离点：5，16

 

⭐️（3）错误猜测法

错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性地设计测试用例的方法。

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。

错误推测法和目前流行的“探索式测试方法”的基本思想一致，这类方法在敏捷开发模式下的投入产出比很高，被广泛应运于测试。

这个方法的缺点是难以系统化，并且过度依赖个人能力。

以注册为例

1 、校验中特殊字符空格的处理 ?

2 、密码校验中的大小写？

3 、姓名中的特殊字符？

4 、密码发送是否明文

⭐️（4）场景设计法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触 发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向

以注册为例：

想象注册的场景来设计用例，这与根据需求的业务流来设计差不多。主要是想象各种业务流来设计用例。例如我们可以再想象以下场景：

1 、用户激活后再次点击邮件激活链接？

2 、已注册用户再次注册？

 

⭐️（5）因果图

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

因果图最后还得用到判定表，因此不讲 因果图。

⭐️（6）判定表 

• ①什么是判定表

判定表(Decision table)是另一种表达逻辑判断的工具。一个表格，表格里面有条件，有结果。

• ②关系

恒等、非、与、或
恒等: 条件为真，结果一定为真
非: 条件为假，结果为真
与: 两个条件必须为真 -> 结果才为真，如果一个条件为假 -> 结果就为假
或: 两个条件全为假 -> 结果才为假，如果条件一个为真 -> 结果为真

• ③如何设计测试用例

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

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

根据输入和输出确定判定表。

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

案例一：

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

1. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：

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

2. 然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。

(1) 订单已提交，订单金额大于 300 元，则优惠。

(2) 订单已提交，订单金额小于等于 300 元，无红包，不优惠

(3) 订单已提交，有红包，则优惠。

(4) 订单已提交，订单金额大于 300 元，有红包，则优惠。

(5) 订单未提交，不优惠。

3. 画出判定表

4. 最终的测试用例