软件测试(测试用例详解)(三)

1. 测试用例的概念

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合。

测试环境

操作步骤

测试数据

预取结果
测试用例的评价标准：

用例表达清楚，无二义性。。

用例可操作性强。

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

用例的可维护性好。

用例对需求的覆盖率高。

2. 测试用例的设计方法(黑盒测试用例)

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

流程:

需求文档 ---> 梳理需求（掌握需求）---> 针对文档设计测试用例,只是针对需求进行了大概的测试。
方法:

功能相关：

针对具体的需求，可以根据业务分类，用户角色（餐厅的会员系统）或者用户操作区域等将系统的功能分解成若干个功能模块，然后按照功能模块分别进行测试需求分析。

系统各个功能界面的验证(借助UI设计稿)

业务流程相关(借助需求规格说明书)

用户操作的易用性，用户体验(往往结合功能测试同时验证 )

功能的一致性，交互性（多功能互操作）的测试

系统的不同输入，结果输出的业务数据测试。

功能的错误操作，异常操作的测试（属于负面测试）

功能实现用到的算法验证，有时需要用运代码评审

非功能相关：

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

性能

安全性

可靠性

兼容性

易维护性

可移植性
案例：

163邮箱注册(基于需求设计测试用例)

等价类法

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

有效等价类: 满足用户需求输入集合。

无效等价类: 不满足用户需求的输入集合。

步骤：

充分理解需求

划分有效等价类，划分无效等价类

从有效等价类中抽取其中一个数据进行设计测试用例；从无效等价类中抽取其中一个进行测试用例设计。

案例：

边界值法

java 复制代码
userName(string user_name) {
	user_name_length = user_name.length
   if(user_name_length >= 7 && user_name_length < 15) {
   	if(user_name_length > 6 && user_name_length <15) {
   		// 注册成功
   	}else {
   		// 注册失败
   	}
   }
}
步骤：

充分理解需求

找边界点

针对边界点设计测试用例

边界点 :

上点：边界上的点

内点：边界内的点

离点：边界值附近的一个点(闭区间外离上点最近的点，开区间区间内距离上点最近的点)。

因果图法

判定表

判定表是一种表达逻辑关系的工具。

判定关系：

与：所有的条件必须满足，如果一个条件不满足，此时结果为假。

或：满足其中一个条件结果为真，如果条件全部为假，结果就为假。

恒等：条件为真，结果一定为真

非：条件为假结果才为真。

如何使用因果图设计测试用例?

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

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

画出因果图

把因果图转换成判定表

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

案例：

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

输入：订单已提交，订单金额大于300，有红包

输出：优惠、不优惠

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

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

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

. . . . . .

正交表法

什么是正交表?

名词:
因素：变量
水平：变量取值

如何通过正交表设计测试用例?

充分理解需求

确定因素水平

画正交表

补充正交表

将正交表转换成测试用例

案例：

注册邮箱: 姓名、邮箱、密码、确认密码、验证码必须全部输入才能进行注册。

使用 allpirs 画正交表：

将因素和水平填到excel中

将excel复制并保存到一个文本文件，这里命名为：正交表test.txt 。

将文本文件移动到allpairs目录下。

打开命令行窗口，进入到allpairs目录下

输入命令，点击回车
java 复制代码
allpairs.exe [源文件名] > [目标文件名]
进入allpairs目录即可看到生成的文件

用记事本打开即可看到生成的测试用例（格式可能会乱，需要调整一下）

测试用例：

场景设计法

主事件流，次事件流。

案例：

ATM机取款

插卡 ---> 选择语言 ---> 输入密码 ---> 选择业务 ---> 输入取款金额 ---> 等待吐钱

错误猜测法

依赖测试人员的经验。

3. 如何模拟弱网？

使用fiddler模拟弱网

打开弱网

参数调整：

第一步：

第二步：

第三步：修改参数即可

charles

4. 如何测试接口？

工具：Postman

方法（GET/POST）

参数（传参数/不传参数/传入非法参数）

参数格式（parameter/json）

5. 练习

有一个冒泡排序，针对这个代码如何测试？

方法参数（参数类型，不给参数，参数传递为空）

异常处理

代码规范

语句覆盖

条件覆盖

语句条件覆盖

判定覆盖
...

Linux zip命令测试

功能：

打包的文件是一个不存在的文件；

命令使用正确，文件存在，文件是否被压缩；

能否一次性打包多个文件；

打包后的内容是否有缺失；
...

界面：打包后的zip高亮；打包后的文件后缀名.zip;

...

易用：

输入错误，此时有没有提示

...

性能：

打包一个1KB文件时间是多少？

打包一个20G的文件；

一次打包多个文件；
...

水杯测试用例

6. 测试用例设计万能公式

功能，界面，性能，易用，兼容，安全，网络，中断...

功能：

物体: 最基本的功能

软件：软件的实现功能

界面：

物体：外表，材质，大小，容量...

软件：界面，字体大小，字体颜色，页面布局...

易用：（主要依赖测试人员经验）操作简单，使用流畅，人性化...

兼容：

物体：除了本职功能还有没有其他功能

软件：操作系统，设备，浏览器版本...

性能：

物体：使用寿命...

软件：响应时间,CPU占用率 ,吞吐量，并发数...

安全：

物体：材质是否有毒，物体会不会对人体健康产生危害...

软件：SQL注入，xss漏洞，输入有毒脚本...

网络:

2G~5G

弱网

WiFi

...

7. 测试的分类

按照测试对象划分

界面测试:

用户直观看到的都是界面：web站，app，小程序，公众号，测试界面的时候，参考软规格说明书，UI设计稿

可靠性测试

可靠性= 正常运行时间/(正常运行时间+非正常运行时间)*100%

容错性测试:

输入异常容错, 异常操作如: 数据级测试, 校验测试, 界面容错测试

灾难恢复性测试: 强制让软件发生故障, 然后验证系统已保存的用户数据是否丢失,系统和数据是否能尽快恢复.

文档测试

包括: 测试文件, 开发文件, 产品文件

关注文档的术语,正确性,完整性,一致性,易用性.

兼容性测试

系统版本兼容

用户已有数据兼容

操作系统的兼容

应用平台兼容

浏览器的兼容

与第三方系统及第三方数据的兼容性

易用性测试

符合标准和规范

直观性

一致性

灵活性

舒适性

正确性

实用性

安装卸载测试

软件不同的安装卸载方式: 应用市场, 浏览器, 下载apk包, 技术脚本或命令等

安装兼容性: 应用是否可以在不同的环境系统及版本下安装

安装或卸载过程中是否可以手动暂停或取消

安装空间不足是系统是否有提示

是否可以正常卸载,及各种卸载方式

卸载和安装过程中出现环境问题软件是否可以正常并且合理的应对,如: 死机, 断电, 断网等.

安全性测试

输入域, 输入恶性或带有病毒的脚本或长字符串.

代码中的安全问题,如SQL/XML脚本注入

不安全的数据存储或传递

数据文件,邮件文件,系统配置文件等里面有危害系统的信息或数据.

有问题的访问控制及权限分配等.

假冒ID: 身份欺骗

篡改, 对数据的恶意修改,破坏数据的完整性

性能测试

资源泄露

资源瓶颈

线程死锁,线程阻塞

查询速度慢或效率低

受外部系统影响越来越大

衡量指标: 用户响应时间, 事务平均响应时间(TPS), 吞吐率, 每秒点击次数, 内存和CPU使用率等.

内存泄漏测试

人工静态法: 代码走读,人工查找未被回收的内存

自动工具法: 借助相应测试内存泄漏测试工具如:Visual Leak Detector

按照是否查看代码划分

黑盒测试

完全不考虑程序和内部结构, 检查系统功能是否按照需求规格说明书的规定正常使用, 是否能适当的接收输入数据而输出正确的结果,满足规范的需求.

测试方法: 等价类, 边界值, 因果图, 场景法, 错误猜测法.

白盒测试

检查软件内部的逻辑结构, 对软件中的逻辑路径进行覆盖测试, 在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致.

测试方法: 语句覆盖, 判定覆盖, 条件覆盖, 判定条件覆盖, 条件组合覆盖, 路径覆盖.

灰盒测试

介于白盒测试和黑盒测试之间,多用于集成测试阶段, 不仅关注输入输出的正确性也关注程序内部的情况.