测试初学概念

注：观《软件测试的艺术》记录

一、测试用例的设计

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. 若规格说明中包含输入条件组合，应首先使用因果图分析法
2. 任何情况都应使用边界值分析法
3. 必要情况下，划分等价类对上述确认的测试用例进行补充
4. 使用错误猜测技术增加更多的测试用例
5. 针对上述测试用例检查程序的逻辑结构。应使用判定覆盖、条件覆盖、判定/条件覆盖或多重条件覆盖

1.3 测试用例编写模块

测试用例主要包括：

• 用例编号：英文 + 数字 表示唯一性
• 用例标题：验证某个功能的目的，和用例编号一一对应
• 测试项目：该测试用例所属的测试的范围
• 用例级别：当前测试的功能对系统的影响
• 预置条件：执行的前提条件
• 测试输入
• 测试步骤：验证操作步骤按序号编写
• 预期结果：希望得到的结果

二、模块（单元）测试

模块测试一般针对片段代码，软件较大时，不方便对整个程序进行测试。

目的：发现程序模块与其接口规格说明之间的不一致性。

优点：

• 可以多人并行测试
• 容易发现错误位置

针对：

1. 带有 if 的代码，对其进行分析
2. 每行 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)]

1. 确定相关数据。将所有可用的数据都考虑进去
2. 组织数据：一般通过分析以下四行来分析组织数据，是什么->在何处->何时->多大程度（如图）
3. 作出假设：研究线索之间的联系
4. 证明假设：应将假设与其最初的线索或数据相比较，以此来证明假设的合理性，确定这些假设可以完全解释这些线索的存在。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bcfwUPrx-1616945173892)(en-resource://database/1292:1)]

4.2 演绎法调试

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w6mKREmq-1616945173893)(en-resource://database/1294:1)]

1. 列举出所有可能的原因或假设
2. 利用数据排除可能的原因，详细检查所有数据，尤其寻找存在矛盾的地方，尽量排除所有可能的原因
3. 提炼剩下的假设
4. 证明剩下的假设

4.3 回溯法调试、测试法调试

• 回溯法调试：沿着程序的逻辑结构回溯不正确的结果，直到找出程序逻辑出错的位置
• 测试法调试：当发现了某个被怀疑的错误后，需要编写不同的测试用例，尽量确定错误的位置

4.4 调试的原则

调试的过程由两部分组成：定位错误、修改错误。

4.4.1 定位错误的原则

按以下顺序进行：

1. 动脑筋：一个高效的程序调试人员应该不使用计算机就能定位大多数的错误
2. 如果遇到僵局，就留到稍后解决
3. 如果遇到了困境，就把问题描述给其他人听
4. 仅将测试工具作为第二种手段
5. 避免使用实验法-仅作为最后的手段

4.4.2 修改错误的技术

1. 存在一个缺陷地方，很可能还存在其他缺陷
2. 应纠正错误本身，而不仅是修改某个特例
3. 正确纠正错误的可能性并非100%
4. 正确修改错误的可能性随着程序规模的增加而降低
5. 应意识改正错误会引入新错误的可能性
6. 修改错误的过程也是临时回到设计阶段的过程

4.5 错误分析

详细的错误分析会包括如下内容：

• 错误出现在什么地方？

  • 通过对程序文档和项目历史进行回溯研究，指出该错误的源头和发生时间 ；举例：错误的源头可能是规格说明的一个模棱两可的语句，对先前错误的一次修改等

• 谁制作了这个错误？

• 哪些做得不正确：准确判断出错误发生的原因

• 如何避免该错误的发生：在下次项目中可以进行哪些调整以避免该问题的出现

• 该如何更早地发现错误：如何改进评审和测试过程，以便在将来的项目中更早地发现同类型地错误

  • 若是由测试用例发现的，那么我们编写了一个成功的测试用例，这个测试用例为什么会成功？能从中学习到了什么？