测试——用例篇

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

2.2.2 设计测试用例

充分理解需求
划分有效等价类和无效等价类
细分有效等价类和无效等价类
组合有效等价类和无效等价类

例子①:

用户名长度为6-15

例子②:

用户名长度为6-15的字符串组成

问:无效等价类的测试点可以为:长度小于6,非字母吗?

不可以,在测试点为:长度小于6,字母时,就已经确定了问题在"长度小于6",字母这块满足需求,此时再增加非字母,使得定位问题时间变长,无意义.

组合原则:

有效等价类在组合时,一个测试点,尽可能多的去覆盖有效等价类

无效等价类在组合时,一个测试点,只能组合一个无效等价类,其余的需要和有效等价类组合

适用于:

输入数据是无穷的,但是输入数据有特点

2.3 边界值

2.3.1 概念补充

上点:无论是开区间还是闭区间,或者是半开半闭区间,上点就是边界上的点

内点:无论是开区间还是闭区间,或者是半开半闭区间,内点就是边界内的点

离点:边界左右的一个点,如果是闭区间——范围外的点,开区间——范围内的点

2.3.2 设计测试用例

充分理解需求
找离点,内点,上点
针对离店,内点,上点设计测试用例

例如:输入用户名为6-15长度,字母与数字的组合

2.4 判定表法

2.4.1 逻辑关系概念

恒等:如果原因为真，那么结果必定为真。
与:只有2个原因都为真，那么结果为真;一个为假即为假
或:2个原因中有一个为真时，结果就为真;全为假才假
非: 只有原因为假，结果才为真。

2.4.2 设计测试用例

充分理解需求
分析所有可能的输入和可能的输出
找出输入与输出之间的对应关系
判定表
把判定表对应到每一个测试用例

例子:订单已提交,总计金额大于300或者有红包,则有优惠

输入:订单提交,订单未提交,金额大于300,金额小于300,有红包,无红包

输出:有优惠,无优惠

找关系:

判定表:

下面再分析一个例子:

注册用户,输入姓名,邮箱,密码,确认密码,验证码

需要设计多少用例呢？

2x2x2x2x2

对于比较复杂的输入和输出，会耗费大量时间

2.5 正交表法

2.5.1 几个名词概念

看百度的解释:

因素:变量

水平:变量的取值

2.5.2 正交表的性质

①每一列中各数字出现的次数都一样多

②任何两列中的各有序数对出现的次数都一样多

例如:

2.5.3 设计测试用例

确定因素
确定因素取值(水平)
通过工具画正交表
将正交表转换成测试用例
补充正交表

例子:注册用户,输入姓名,邮箱,密码,确认密码,验证码

因素:姓名,邮箱,密码,确认密码,验证码

水平:填/不填

生成正交表:(7为补充)

测试点①:姓名填,邮箱填,密码填,确认密码填,验证码填

......

2.6 场景设计法

2.6.1 什么是场景

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

2.6.2 设计测试用例

主事件流
次事件流
将主事件流次事件流串起来形成场景,一个场景就是一个测试用例

以淘宝购物为例:

测试点①:打开APP,搜索商品,选中商品,加入购物车,选择支付方式,支付,生成订单

测试点②:打开APP,APP闪退,没有订单

......

2.7 错误猜测法

这里不详细解释,主要依据个人经验而定

以注册为例:

校验中特殊字符空格的处理?
密码校验中的大小写？
姓名中的特殊字符？
密码发送是否明文

2.8 测试用例设计思路

测试用例万能公式:

功能,界面,易用性,兼容性,安全性,性能,网络

以物体为例:

3. 案例分析(详见飞书)

3.1 水杯测试用例

3.2 微信发朋友圈测试用例

基于软件设计测试用例:

功能:软件本职能够干什么
兼容:软件在各个平台上能够运行,通常考虑到的设备有IOS,Android,PC(电脑,Windows,Mac),如果是浏览器,就要考虑版本,操作系统也要考虑版本
易用性:软件设计符合大众操作习惯
安全:软件防止黑客攻击,XSS漏洞,SQL注入
性能:软件页面渲染的时长,软件能够同时承载大量的用户访问
界面:图片布局,图片大小,按钮颜色,文字字体