文章目录
注:观《软件测试的艺术》记录
一、测试用例的设计
1.1 白盒测试用例设计
- 语句覆盖:将每条语句至少执行一次
- 判定覆盖:只关心判定表达式的值(即if能得出true/false)
- 条件覆盖:判定表达式中每个子条件的值(true/false)
- 判定/条件覆盖:将每个子条件的所有可能的结果至少执行一次
- 多重条件覆盖:每个判定表达式的所有可能的条件结果的组合,以及所有的入口点都至少执行一次
1.2 黑盒测试用例设计
1.2.1 划分等价类
主要存在两个步骤:1、确定等价类; 2、生成测试用例
确定等价类
一般根据输入条件将等价类分为两类:有效等价类,无效等价类
-
有效等价类:对程序的有效输入
-
无效等价类:其他任何可能的输入条件(不正确的输入值)
- 注:要注意无效等价类主要是不正确的输入值
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-33bWMg34-1616945173873)(en-resource://database/1278:1)]
生成测试用例
- 为每个等价类设置编号
- 编写新的测试用例,尽可能覆盖未使用的有效等价类
- 覆盖一个且仅一个尚未被涵盖的无效等价类
1.2.2 边界值分析
与划分等价类不同的是:
- 同时考虑了输入条件和输出条件
- 需选择一个或多个元素
通用指南:
- 输入条件:规定范围;针对:考虑越界
- 输入条件:规定数量;针对:最小,最大,更小,更大
1.2.3 因果图(TODO)
(TODO):观看对应视频,查找对应编写因果图的商业软件
因果图一般分为三列状态:输入(因,最前)、中间结果(可能多列)、输出(果,最后)
注1:三列均为数字符号,无实际含义
注2:每个符号都有一个布尔值,根据连接线的不同,来得出下一状态的值
注3:输出包含正确和错误的输出
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DmAbFJ3w-1616945173878)(en-resource://database/1282:1)]
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DqJjSGiu-1616945173881)(en-resource://database/1280:1)]
建立有限项的判定表
- 首先 假定果 -> 推出所有可能的因的组合
- 对于以上的所有组合,判断所有其他的果的状态
注1:遇到结果为1的OR,不可将输入同时设置为1
注2:结果为0的AND,列出 导致结果为0的 所有输入组合情况
注3:结果为0的AND,列出一种所有输入均为0的情况
1.2.4 测试策略
- 若规格说明中包含输入条件组合,应首先使用因果图分析法
- 任何情况都应使用边界值分析法
- 必要情况下,划分等价类对上述确认的测试用例进行补充
- 使用错误猜测技术增加更多的测试用例
- 针对上述测试用例检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖
1.3 测试用例编写模块
测试用例主要包括:
- 用例编号:英文 + 数字 表示唯一性
- 用例标题:验证某个功能的目的,和用例编号一一对应
- 测试项目:该测试用例所属的测试的范围
- 用例级别:当前测试的功能对系统的影响
- 预置条件:执行的前提条件
- 测试输入
- 测试步骤:验证操作步骤按序号编写
- 预期结果:希望得到的结果
二、模块(单元)测试
模块测试一般针对片段代码,软件较大时,不方便对整个程序进行测试。
目的:发现程序模块与其接口规格说明之间的不一致性。
优点:
- 可以多人并行测试
- 容易发现错误位置
针对:
- 带有 if 的代码,对其进行分析
- 每行 if 可导向两种不同的结果(true/false)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-si8i7uBA-1616945173885)(en-resource://database/1276:1)]
- 非增量测试:独立地测试每个模块,然后再将这些模块组装
- 增量测试:将下一步要测试的模块组装到测试完全的模块集合中
2.1 增量测试
注:增量测试一般使用自顶向下的方法测试
注2:主模块在顶层,即包含main的模块
2.1.1 非增量测试的特点
因为非增量测试中需要进行独立地测试,故需使用驱动模块和桩模块
注:
- 驱动模块:包含main函数,是主模块,通过驱动模块可以调动测试模块。
- 桩模块:模拟测试模块工作过程中所调用的模块
2.1.2 增量测试的特点
优点:
- 自顶向下的增量测试无需驱动模块,只需要桩模块
- 使用增量模块,可以较早发现模块中与不匹配接口、不正确假设相关的编程错误。
- 使用增量模块,调试会容易一些,并容易定位相关错误(不正确接口等错误)
- 增量测试会将测试进行的更彻底,实际测试的模块经受住了更多的检验
缺点:
- 非增量测试所占的机器时间少一些
- 非增量测试有更多机会进行并行操作
注:错误发现的越早,改正的成本越低,故增量测试的优点日益突出
2.1.3 自顶向下测试与自底向上测试
自顶向下的测试
- 自顶向下的测试:从程序的初试模块开始,测试开始后,挑选后续模块进行增量测试
由于模块A调用模块B,则需编写B的桩模块。
桩模块:桩模块不仅需要编写一条简单的显示信息,在必要的情况下,也需返回一个有意义的输出参数
自底向上的测试(TODO)
TODO:找寻生成驱动模块的应用
- 自底向上的测试:开始于程序的终端模块,每一个模块都需要一个特殊的驱动模块
两种测试方法的特点
自顶向下测试
优点:
- 如果主要缺陷发生在程序的顶层将非常有利
- 一旦引用I/O功能,提交测试用例会更容易
- 早期的程序可以进行演示,可激发积极性
缺点:
- 必须开发桩模块,并且桩模块的开发比较复杂
- 引用I/O功能之前,向桩模块中引用测试用例比较困难
- 创建测试环境可能很难,同时观察测试输出也会很困难
- 使人误解设计和测试可以交叠进行
- 会导致特定模块测试的完成延后
自底向上测试
优点:
- 如果主要缺陷发生在程序的底层将非常有利
- 测试环境比较容易建立
- 观察测试输出比较容易
缺点:
- 必须开发驱动模块(应有相关软件,减少驱动模块的需求)
- 直到最后一个模块添加进去,程序才形成一个整体
三、更高级别的测试
- 模块测试目的:发现程序模块与其接口规格说明之间的不一致性。
- 功能测试的目的:证明程序未能符合其外部规格说明。
- 系统测试的目的:证明软件产品与其初始目标不一致。
功能测试:通常是一项黑盒测试,主要针对规格说明进行分析,以获取测试用例集来进行测试。
注:第一章即为测试用例的编写
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tEnnpG5M-1616945173888)(en-resource://database/1286:1)]
3.1 系统测试
系统测试的目标:将系统与初始目标进行比较
- 系统测试是试图说明程序作为一个整体是如何不满足其目标的过程
- 如果产品没有一组书面的、可度量的目标,系统测试也就无法进行
过程:利用程序的用户文档或书面材料;通过分析目标文档来设计系统测试,分析用户文档来阐明测试用例。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xQ5XjYmp-1616945173890)(en-resource://database/1288:1)]
3.1.1 能力测试
判断目标文件提及的每一项能力是否都确定已经实现。
3.1.2 容量测试
使程序经受住大容量数据的检验,为了证明程序不能处理目标文档中规定的数据容量
注:是大容量数据,即**编译器(所作系统)**可能要编译规模非常庞大的源程序
3.1.3 强度测试
使系统承受高负载或强度的检验;所谓高强度:在很短时间间隔内达到的数据或操作的数量峰值。
例:
- 容量测试:判断打字员能否处理大篇幅的稿子
- **强度测试:判断打字员是否能达到每分钟50个单词的速度;**操作系统支持最多15道作业,可尝试同时运行15个作业对其进行强度测试。
3.1.4 易用性测试
视图发现人为因素或易用性的问题
需要测试以下问题:
- 每个用户界面是否都根据最终用户的智力、教育背景和环境要求而进行了调整。
- 程序的输出是否是有意义、不模糊的信息
- 错误诊断是否直接
- **整体的用户界面是否在语法、惯例、语义、格式、风格和缩写方面展现出了相当程度的概念完整性、基本的一致性和统一性。
- 在准确性极为重要的环境里(如网上银行系统),输入中是否有足够的冗余信息
- 系统是否包含过多或不太可能用到的选项,菜单系统应合乎逻辑、符合直觉
- 对于所有的输入,系统是否返回了某些类型的即时确认信息?
- 程序是否易于使用;例:如果输入是区分大小写字符的,这一点用户是否清楚?
3.1.5 安全性测试
设计测试用例来突破程序安全检查的过程
过程:研究类似系统中已知的安全问题,然后生成测试用例,尽量暴露被测系统存在相似问题。
3.1.6 性能测试
在特定负载和配置环境下程序的响应时间和吞吐率,应设计测试用例来说明程序不能满足其性能目标。
3.1.7 存储测试
软件文档描述了程序使用的内存和辅存的容量,以及临时文件和溢出文件的大小,应设计测试用例来证明这些存储目标没有得到满足。
3.1.8 配置测试
系统支持多种硬件配置,包括不同类型和数量的I/O设备和通信线路,或不同的存储容量。至少应该使用每一种类型的设备,以最大和最小的配置来测试程序。
3.1.9 兼容性测试
证明兼容性目标未被没满足,在将数据从一个系统转移到另一个系统时,应尽力发现错误
3.1.10 安装测试
测试安装过程是系统测试中的一个重要部分。
3.1.11 可靠性测试(TODO)
3.1.12 可恢复性测试
诸如操作系统等软件通常都有可恢复性目标,证明这些恢复机制不能正确发挥作用
3.1.13 实用性测试
系统提供的服务辅助功能,包括存储转存程序或诊断程序、调试明显问题的平均时间
3.1.14 文档测试
检查用户文档的正确性,根据文档来确定系统测试用例的形式,即通过文档来作为编写实际测试用例的指南。
3.1.15 过程测试
必须对所有已规定的人工过程的操作过程进行测试
四、调试
4.1 归纳法调试
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O6oEPFsC-1616945173891)(en-resource://database/1290:1)]
- 确定相关数据。将所有可用的数据都考虑进去
- 组织数据:一般通过分析以下四行来分析组织数据,是什么->在何处->何时->多大程度(如图)
- 作出假设:研究线索之间的联系
- 证明假设:应将假设与其最初的线索或数据相比较,以此来证明假设的合理性,确定这些假设可以完全解释这些线索的存在。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bcfwUPrx-1616945173892)(en-resource://database/1292:1)]
4.2 演绎法调试
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w6mKREmq-1616945173893)(en-resource://database/1294:1)]
- 列举出所有可能的原因或假设
- 利用数据排除可能的原因,详细检查所有数据,尤其寻找存在矛盾的地方,尽量排除所有可能的原因
- 提炼剩下的假设
- 证明剩下的假设
4.3 回溯法调试、测试法调试
- 回溯法调试:沿着程序的逻辑结构回溯不正确的结果,直到找出程序逻辑出错的位置
- 测试法调试:当发现了某个被怀疑的错误后,需要编写不同的测试用例,尽量确定错误的位置
4.4 调试的原则
调试的过程由两部分组成:定位错误、修改错误。
4.4.1 定位错误的原则
按以下顺序进行:
- 动脑筋:一个高效的程序调试人员应该不使用计算机就能定位大多数的错误
- 如果遇到僵局,就留到稍后解决
- 如果遇到了困境,就把问题描述给其他人听
- 仅将测试工具作为第二种手段
- 避免使用实验法-仅作为最后的手段
4.4.2 修改错误的技术
- 存在一个缺陷地方,很可能还存在其他缺陷
- 应纠正错误本身,而不仅是修改某个特例
- 正确纠正错误的可能性并非100%
- 正确修改错误的可能性随着程序规模的增加而降低
- 应意识改正错误会引入新错误的可能性
- 修改错误的过程也是临时回到设计阶段的过程
4.5 错误分析
详细的错误分析会包括如下内容:
-
错误出现在什么地方?
- 通过对程序文档和项目历史进行回溯研究,指出该错误的源头和发生时间 ;举例:错误的源头可能是规格说明的一个模棱两可的语句,对先前错误的一次修改等
-
谁制作了这个错误?
-
哪些做得不正确:准确判断出错误发生的原因
-
如何避免该错误的发生:在下次项目中可以进行哪些调整以避免该问题的出现
-
该如何更早地发现错误:如何改进评审和测试过程,以便在将来的项目中更早地发现同类型地错误
- 若是由测试用例发现的,那么我们编写了一个成功的测试用例,这个测试用例为什么会成功?能从中学习到了什么?