《软件测试与质量》B站笔记【华中科技大学】——黑盒测试技术

第一部分 绪论

1.1 软件测试是软件质量保证的一部分，早期引入软件测试有利于尽早发现缺陷和预防缺陷植入，并可以协助建立质量的文化。

1.2 哪些人需要了解软件测试？

用户：参与需求验证和验收测试

项目经理：参与测试计划指定

程序员：完成单元测试

测试员：设计和执行测试

1.3 软件测试以需求为中心，观察测试系统实际输出与预期输出是否一致

1.4 软件开发的过程：定义需求、分析需求、实现需求、校验需求

1.5 什么是软件测试？

软件测试是 以人工方式或通过使用工具以自动化方式运行被测软件系统，或静态检查被测系统的过程。

包括：动态测试和静态检查

测试的执行：人工、自动化

1.6 什么是软件缺陷？

软件缺陷：软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

（1）被测系统与需求说明不一致，意味着缺陷

（2）软件未达到需求规格说明书中指明的功能，则是缺陷。

（3）软件出现了需求规格说明书中指明不会出现的错误，则是缺陷。

（4）软件功能超出需求规格说明书中指明的范围，则是缺陷。

（5）软件未达到需求规格说明书中虽未指出但应达到的目标，则是缺陷。

1.7 测试目标：在最短时间内、找到最严重、最多的缺陷，最大程度地保证产品符合已知用户需求。

1.8 基于风险最低、效率最高、分而治之的测试设计原则，测试用例就是

• 能代表需求的小的测试单元
• 描述用户预期输出
• 反映系统实际执行结果

1.9 测试用例的组成：

• 输入：测试数据和操作步骤
• 输出：系统预期执行结果
• 测试环境：是系统环境设置，即进行软件测试所必需的工作平台和前提条件。（模拟实际的生产环境）

1.10 测试用例的基本属性：

• 典型性：能揭示最有可能存在缺陷的地方，能代表和覆盖合理与不合理、合法或不合法的情况。
• 可测试性：一个测试用例的预期输出必须是可以检验的，可以根据相关开发文档得到明确的、可判定的结论。
• 可重现性：对于相同的测试用例，系统的预期执行结果应该完全相同，否则，如果系统预期输出存在不确定性，一旦实际运行该测试用例，也无法进行校验。
• 独立性：测试用例应尽量独立（不是必须具备的）

1.11 测试用例的设计：

• 输入数据

  正常数据：软件可以接受的数据

  错误数据：

  • 满足数据类型，不在有效取值范围内。
  • 不完全满座数据类型
  • 输入条件缺失

  边界数据：介于正常数据与错误数据之间的临界数据。

• 操作步骤

1.12 软件测试的分类

（1）从测试阶段或对象角度分类

• 单元测试：对应编码阶段，其测试对象是单个模块或组件。
• 集成测试：对应详细设计，其测试对象是一组模块或组件。
• 系统测试：对应概要设计，其测试对象是整个软件系统。
• 验收测试：对应需求阶段，其测试对象是整个软件系统。

（2）从测试技术的角度来分类

• 白盒测试：关注与产品的外部行为相关的缺陷，并不考虑产品的内部结构或运行逻辑。
• 黑盒测试：关注与代码内部结构型相关的缺陷，需掌握一定的编程技术。
• 灰盒测试：综合运用黑盒测试和白盒测试技术的一种混合测试方法。

（3）从测试目标的角度分类

• 回归测试、功能测试、性能测试、Alpha测试（α测试）、Beta测试（β测试）
• 压力测试、负载测试、安全性测试
• 配置测试、安装测试、可用性测、可恢复性测试等。

其中，

功能测试：针对软件功能需求进行测试，目的是检查应用程序的行为是否符合预期。

性能测试：用于验证系统是否满足规格说明的性能需求，例如容量和响应时间等。

Alpha测试（α测试）：在软件发布前，有时会让小规模、有代表性的潜在用户试用软件，如果由开发机构人员来模拟潜在用户开展测试，则称为α测试。

Beta测试（β测试）：软件的早期版本被发布给具有代表性用户群来测试，称为β测试。常被用于面向大众市场的系统、计算机游戏和类似的应用程序。

回归测试：在软件版本修改后的重新测试，可应用于所有测试级别，目的是为了确保被修改组件的行为没有改变，不会造成意外结果。（可应用于不同的测试级别，例如：单元测试、集成测试等。）

（4）从测试执行方式的角度分类

• 手动测试
• 自动化测试

1.13 什么是软件质量

反映软件满足明确或隐含需要能力的特性总和。

• 客观而言，软件质量是软件具有某种能力的属性，这是前提条件
• 主观而言，软件具有的能力对应不同层次的用户需求。

1.14 不同层次的用户需求

（1）显示需求：

• 需求规格说明书描述的内容
• 是软件内部质量

（2）隐式需求：

• 未在需求规格说明书中明确描述
• 用户明确说明的目标
• 反映验收质量

（3）实际需求：

• 软件的使用质量
• 用户在实际使用过程中对产品的质量评价

以上需求的难度（重要度）：依次增加

1.15 预防产生质量，检验不能提高质量，提高软件质量依赖于改进软件开发过程质量

1.16 软件测试是软件质量保证的关键步骤，但提高软件质量的途径是改进软件开发过程的质量，而不是提高软件测试。

第二部分 黑盒测试技术

2.1 黑盒测试的定义

只知道系统输入和预期输出，不需要了解程序内部结构和内部特性的测试方法就称为黑盒测试。

2.2 黑盒测试的优势

• 方法简单有效
• 可以整体测试系统的行为
• 开发与测试可以并行
• 对测试人员技术要求相对较低

2.3 黑盒测试的不足和弊端

• 入门门槛低

2.4 黑盒测试的经济学问题

• 通过测试无法证明，被测软件系统是没有缺陷的。（古训：不要试图找到程序中所有的缺陷）
• 软件测试的经济学问题
• 应对策略一：黑盒测试
• 软件测试是不完备的
• 软件测试是有风险的
• 测试设计应达到的目标 ——》 提高效率，降低风险

2.5 测试方法的评价标准

在最短时间内，以最少的人力，有利于发现最多的，以及最严重的缺陷。

• 精确的：测试针对性强
• 完备的：测试覆盖全面，无漏洞
• 无冗余
• 简单的：测试方法简单易行
• 易于调试：缺陷定位难度小

2.6 测试方法的评价

• 测试用例的覆盖度：高
• 测试用例的数量：少
• 测试用例的冗余度：低
• 测试用例的缺陷定位能力：高
• 测试用例的复杂度：低

2.7 黑盒测试方法

2.7.1 边界值测试

2.7.1.1 产生的原因

• 长期的工作经验表明，在输入域的边界或边界附近，常常会发现大量缺陷

• 边界值测试倾向于选择系统边界或边界附近的数据来设计测试用例

2.7.1.2 边界在哪里

2.7.1.3 如何选择测试数据

x1的一组边界测试用例有1518个，6*（301-49+1）= 1518，

x2的一组边界测试用例有1212个，6*（201-0+1）= 1212；

边界测试用例总数：2730个

2.7.1.4 单边界测试

2.7.1.5 边界值测试流程

2.7.1.6 输出域的测试用例设计流程

单输入设计测试用例，虽然可以覆盖100%测试数据，但只能对应输出用例的 “（1800，+∞）—> 0.20” 这个区间，另外两个不能对应

2.7.2 等价类测试

2.7.2.1 产生原因

将无穷多数据缩减到有限个等价区域中，通过测试等价区域完成穷尽测试。

2.7.2.2 基本原理

2.7.2.3 从数学角度解释等价类测试的原理

2.7.2.4 等价类的划分（有效等价类和无效等价类）

2.7.2.5 举例：后一日问题

2.7.2.6 如何设计测试用例（强覆盖和弱覆盖）

一共有6种组合，但以上方案，都只覆盖了3种组合（弱覆盖）

改进* 强覆盖如下

2.7.2.7 等价类测试流程

2.7.2.8 等价类测试的陷阱

2.7.2.9 输出域的等价类测试流程

2.7.3 场景法测试

2.7.3.1 产生原因

2.7.3.2 基本原理（基本流和备选流）

基本流：

• 测试中，至少需要确保系统基本流的执行是完全正确的，基本流只有1个。

• 应选择容易出错的，或者出错后导致损失严重的高风险事件流作为基本流。

备选流：

• 起始节点从基本流的某个判定节点开始，如备选流1,3；
• 起始节点从其他备选流的某个判定节点开始，如备选流2；
• 终止节点是基本流上的某个状态，如备选流1；
• 终止节点是其他的系统终止状态，如备选流2，4；
• 备选流上的每个节点执行后可以继续往下执行，也可以返回基本流上的某个节点继续执行。如基本流和备选流1，构成判定结构；基本流和备选流3，构成循环结构；

2.7.3.3 基本流和备选流的区别

2.7.3.4 定义场景

2.7.3.5 从场景设计测试用例