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

1. 测试用例的概念

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

测试环境
操作步骤
测试数据
预取结果

测试用例的评价标准：

用例表达清楚，无二义性。。
用例可操作性强。
用例的输入与输出明确。一条用例只有一个预期结果。
用例的可维护性好。
用例对需求的覆盖率高。

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

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

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

方法:

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

系统各个功能界面的验证(借助UI设计稿)
业务流程相关(借助需求规格说明书)
用户操作的易用性，用户体验(往往结合功能测试同时验证 )
功能的一致性，交互性（多功能互操作）的测试
系统的不同输入，结果输出的业务数据测试。
功能的错误操作，异常操作的测试（属于负面测试）
功能实现用到的算法验证，有时需要用运代码评审

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

性能
安全性
可靠性
兼容性
易维护性
可移植性

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

等价类法

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

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

步骤：

充分理解需求
划分有效等价类，划分无效等价类
从有效等价类中抽取其中一个数据进行设计测试用例；从无效等价类中抽取其中一个进行测试用例设计。

案例：

边界值法

userName(string user_name) {user_name_length = user_name.lengthif(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目录下

输入命令，点击回车
allpairs.exe [源文件名] > [目标文件名]
6. 进入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

按照是否查看代码划分

黑盒测试
完全不考虑程序和内部结构, 检查系统功能是否按照需求规格说明书的规定正常使用, 是否能适当的接收输入数据而输出正确的结果,满足规范的需求.
测试方法: 等价类, 边界值, 因果图, 场景法, 错误猜测法.

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

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