探索软件测试——用例篇

1.测试用例

[1.1 概念](#1.1 概念)

[2 设计测试用例的万能公式](#2 设计测试用例的万能公式)

[2.1 常规思考+逆向思维+发散性思维](#2.1 常规思考+逆向思维+发散性思维)

[2.2 万能公式](#2.2 万能公式)

1.测试用例

1.1 概念

什么是测试用例？

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

为什么需要测试用例？

在测试中我们会遇见很多的问题，例如：

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

为了解决上面这些问题，所有我们需要有一个很好的办法来设计我们的测试用例

2 设计测试用例的万能公式

2.1 常规思考+逆向思维+发散性思维

正确设计测试用例的思想：常规思维+逆向思维+发散性思维

设计测试用例的原则有三：

1.测试用力的编写不仅应当根据有效和预料到的输入情况，而且也应该根据无效和未预料到的输入情况。

2.检查程序是否"未做其应该做的"仅是成功的⼀半，测试的另⼀半是检查程序是否"做了其不应该

做的"。

3.计划测试工作时不应默许假定不会发现错误，利用发散性思维去思考

2.2 万能公式

设计测试用例的万能公式：功能测试 + 性能测试 + 兼容性测试 + 界面测试 + 安全测试 + 易用性测试

功能测试 ：功能测试是⼀个试图发现程序与其外部**规格说明（需求文档）**之间存在不⼀致的过程。外部规格说明是⼀份从最终用户的角度对程序行为的精确描述。功能测试通常是⼀项黑盒操作。在进行功能测试时，需要对规格说明进行分析以提炼测试用例

然而，不仅是⼯作中还是面试中，可能会存在需求不明确的功能？这种情况下该如何进行功能测试？

查找其他相关文档，来帮助理解所要测试的产品需要完成的目标;
尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解;
召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了;
如果是⼀款已经上线的产品，可以多使用产品，有不懂的问产品经理;
也可以去看历史bug，可以了解到⼀些需要关注的东西

**界面测试：**对软件界面山所有的内容都需要进行测试

**性能测试：**性能测试和功能测试的区别是：功能测试检查软件是否做了，而性能测试测试软件做的好不好，性能测试主要是在一些极端的情况下该软件的能力如何

**兼容性测试：**软件是部署在硬件系统之上，并依赖所需要的软件环境。如QQ可以在PC端打开，也可以在移动端打开；移动端又分为IOS系统和Android系统，且市面上收机又有不同的品牌、不同的机型、不同的版本。软件是否能够在不同的环境下正确运行需要测试人员进行验证。

**易用性测试：**易用性测试的标准是检查产品是否具备简单易上手的属性。假如测试人员从来没有安装或使用过该产品，作为⼀个新用户，对当前产品是否能够快速适用产品的使用流程。

**安全测试：**安全测试和性能测试⼀样都是比较大的领域。常见的安全问题如：

隐私数据明文显示。
参数未强校验导致SQL注⼊。
越权：普通用户也可以执行管理员权限的操作。

下面我们用杯子来给大家演示一下在极端时间内可以提出的测试用例

这就是我们的万能公式所包含的六大部分，从这六个部分出发，能基本完成所有的测试用例的设计

除了万能公式中的公式之外，我们一个比较常见的测试类型：弱网测试 和安装卸载测试。

弱网测试：

关键点包含如下：

页面响应时间是否可以接受，关注包括热启动、冷启动时间、页面切换、前后台切换、首字时间，首屏时间等。
页面呈现是否完成⼀致。
超时文案是否符合定义，异常信息是否显示正常。
是否有超时重连。
安全角度：是否会发生dns劫持、登陆ip更换频繁、单点登陆异常等。
大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作

弱⽹需要借助⼯具来构造弱⽹，这⾥推荐使⽤fiddler

安装卸载测试：

针对需要进行部署的软件，除了软件功能外，我们还需要关注软件的能够成功安装和卸载，对软件进行反复卸载安装来测试该功能

3、设计测试用例的方法

1、等价法

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

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

假设我们有一个注册功能的测试任务，规定账号只能是6~15位的数字，但是如果我们去详细设计测试用例的话似乎有无穷多个，所以这里我们就可以利用等价类来设计。

将该功能分为三个等价类，账号>= 6 && <= 15, 账号>15个数字的账号,<5的账号，这么一划分我们好像在正确的数据里面的就可以找到一个代表来作为等价类完成我们的对于这一类型数据的所以测试了，但是我们这里面又该如何找到合适的代表，这就需要用到边界法了。

2、边界法

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

边界值包含：边界值+次边界值

边界值即为给定数据的左数据和右数据

次边界值取法如下：

1）若边界值为有效等价类中的数据，则次边界值为无效等价类中的数据的边界

2）若边界值为无效等价类中的数据，则次边界值为有效等价类中的数据的边界

我们用 $6,15$ 和(6,15)来举例说明：

对于 $6,15$ 中的边界值位：6,15，次边界值为5，16.

对于(6,15)中的边界值为：6，16，次边界值为：7，14

3、正交法

对于正交法来说，我们的在填写实验数据的时候会发现有些时候我们的枚举数量太多了，正交法就是解决这个办法的方法之一

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

正交表：

如图最简单的正交表是L4(2^3)，含意如下："L"代表正交表；L 旁边的数字"4"表示有 4 横行，简称行，即要做四次试验；括号内的指数"3"有3 纵列，简称列，即最多允许安排的因素是3个；括号内的数"2"表示表的主要部分只有2 种数字，即因素有两种水平1与2。

正交表的构成：因素数、水平数、行数。

因素：对指标的影响条件，通常是正交表中的⼀列。

水平：因素对应的可选项。
正交表的性质：

每⼀列中，不同的数字出现的次数相等。

任意两列中数字的排列方式齐全而且均衡

正交法设计测试⽤例的步骤：

找到因素和水平
用allparis⼯具生成正交表
将因素和水平写⼊Excel表格中
allparis目录下创建新的文本文件new.txt，复制Excel中的因素和水平，直接粘贴到文本中保存并退出
使用allparis命令生成正交表：allparis.exe new.txt > zhengjiao.txt
根据正交表编写测试用例
补充遗漏的重要测试用例

以邮箱注册为例子来演示一下：

1.找到因素和⽔平

因素：姓名、电子邮箱、密码、确认密码、验证码

水平：填写、不填写

用allparis⼯具生成正交表

a. 将因素和水平写入Excel表格中

b. allparis目录下创建新的文本文件 new.txt，复制Excel中的因素和水平，直接粘贴到文本中保存并退出

c. 使用allparis命令生成正交表：allparis.exe new.txt > test.txt（将生成的正交表数据放入test.txt⽂件中）

这样我们就可以根据我们的正交表来设计测试用例了，注意正交表这是提供了一些，我们还需要自己主动的来完成测试案例设计

4、判定表法

通过具体的方法能够将测试用例设计的更加完整和规范。
根据判定表法设计测试用例的步骤：

确认需求中输入条件和输出条件
找出输入条件和输出条件之间的关系
画判定表
根据判定表编写测试用例

我们依旧举一例子来说明一下：我们利用管理员身份注册来说明

a、确认需求中输入条件和输出条件

输⼊条件：账号包含admin字符（a）、内部注册链接(b)、点击注册按钮(c)

输出条件：管理员（1）、无管理员（2）
b、找出输入条件和输出条件之间的关系

输⼊条件：ac ab bc abc a b c ⾮abc

对应结果：1 2 1 1 2 2 2 2
c、画判定表

d、根据判定表来编写测试用例

5、场景法

现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同⼀事件不同的触发顺序和处理结果就形成事件流。

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的⼀种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。

场景法⼀般包含基本流和备用流，从⼀个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。

场景法就是⼀个常规的流程中，某些阶段可能会出现⼀些意想不到的情况，常规流程是基本流，从阶段中分析出来的不同情况被称之为备选流，场景法比较考验发散思维

6、错误猜测法

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

这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，还有个人的经验和直觉。错误推测法和目前流行的"探索式测试方法"的基本思想⼀致，这类方法在敏捷开发模式下的投入产出比很⾼，被广泛应用于测试。