软件质量测试

软件测试

第一章：软件测试核心概念

1.2：软件测试的概念

软件

定义

软件 = 程序 + 数据(库) + 文档 + 服务

特点

1. 必须依靠人类智力劳动才能创造出来
2. 软件必须依赖于硬件设备才能运行
3. 软件不会如硬件一般产生磨损

软件测试

定义

软件测试是使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验被测软件系统是否满足规定的需要，或是弄清被测系统的预期结果与实际结果之间的差别。

1. 软件错误是的根本目的是保证软件满足用户需求
2. 软件测试的目的是要衡量软件产品是否符合预期
3. 软件测试是一个持续的过程
   1. 计划测试
   2. 设计测试
   3. 实施测试
   4. 执行测试
   5. 评估测试
4. 测试既需要动态执行也需要静态检查
5. 测试不仅仅需要手动执行还需要自动执行

主要解决问题

1. 围绕用户需求测试
2. 围绕产品是否符合预期测试目的
3. 围绕测试过程的管理

认识误区

1. 良好的设计和高水平的运动员不需要测试 --测试是必要的-- ×
2. 软件测试并不创造任何代码产品，可不用测试 --测试会编写测试脚本，同时测试是必要的-- ×
3. 测试等与调试 --测试找错，调试改错-- ×
4. 软件需求规格说明应详细的包含所有的用户需求 --成本太大，同时也不需要-- ×
5. 软件测试可以提高产品质量 --测试只负责找错-- ×

软件缺陷

定义

• 软件测试员认为软件难以理解，不宜使用，运行速度缓慢，或者最终用户觉得不好
• 软件未达到需求规格说明书中指明的功能
• 软件出现了需求规格说明书中指明不会出现的错误
• 软件功能超出需求规格说明书中指明的范围
• 软件未达到需求规格说明书中虽未指明但应达到的目标

软件测试员的主要任务

• 根据用户的意见和反馈执行测试
• 根据SRS描述，针对系统的有效输入及有效操作下的正常功能进行测试
• 依据SRS的描述或者个人经验，针对系统在无效输入或者无效操作下的软件容错能力进行测试
• 开发人员应遵循良好的开发习惯，与用户和项目成员及时沟通，避免植入无依据的软件缺陷
• 需求分析阶段强调测试专家的介入，从测试的视角完善SRS，提高系统的外部环境容错能力

测试分析

• 测试为完整性和有效性

• 代码的测试

• 测试的管理

软件去缺陷的来源及代价

• 系统本身的复杂性不断增长，使得测试范围和难度也随之增大
• 与用户沟通不当导致无法获取最真实的用户需求
• 需求不断变化
• 开发人员的劳累，自大和追求个性化，导致不断植入各种缺陷
• 进度压力导致测试被压缩，无法进行充分的测试
• 对文档的轻视致使测试缺乏依，带来测试的漏洞

测试用例的概念

测试用例 = 输入 + 输出 + 测试环境

• 输入数据
  • 正常数据
  • 错误数据
  • 边界数据

自动化测试

手动测试

1. 代码走读
2. 查看程序结构
3. 使用多种测试方法，针对性设置测试用例
4. 一句测试用例执行结果发现缺陷

自动测试技术

1. 录制/回放技术
   • 优点：
2. 脚本技术

自动化测试实施要点

实质：为了追求快速，高效地发现和预防回归缺陷

自动化测试的局限性

测试人员需要编写，不断调试测试脚本。

第三章：黑盒测试技术

概述

黑盒测试仅需要知道被测对象的输入和预期输出，不需要了解其实现细节

对测试人员透明，且程序透明，不需要测试人员了解其内部实现

适用

测试为函数，对象功能时----测试不需要了解被测程序的内部实现逻辑时

评价

1. 测试用例对被测对象的覆盖率
2. 测试用例的冗余
3. 测试用例的数量
4. 测试用例对缺陷的定位能力
5. 测试用例设计的复杂度

边界值测试

测试核心和难点

1. 如何选择输入输出域
2. 如何确定输入输出域边界
3. 如何确定输入输出域边界的邻域范围
4. 如何根据被测对象的边界及其邻域设计测试用例

测试用例设计

• 测试数据选择
  1. 穷举法
  2. 典型值法
• 边界组合方式
  1. 强边界法 — 覆盖所有输入条件的所有边界组合 — 多个输入条件同时取边界值
  2. 弱边界法 — 单缺陷假设
  3. 全边界法 — 强边界 + 弱边界

等价类测试

软件测试目标

• 测试的完备性：在理论上完全覆盖被测对象的输入输出域
• 测试的无冗余性：每个测试用例都是为了揭示某一类型的软件缺陷而设计，射出任何用例都将影响对该类缺陷的挖掘能力

将输入域划分为若干子集

• 子集中所有数据等价—在系统中被处理的方式相同
• 子集之间互不相交
• 所有子集的并集为整个输入域

测试用例设计

相关概念

有效等价类：其对于SRS而言，合理，有意义的输入数据构成的集合，即被测对象可以接受的数据

无效等价类：其对于SRS而言，不合理，无意义的输入数据构成的集合，即被测对象不能接受的数据

等价类划分时，必须遵循 – 独立性假设，即输入条件之间相互独立，互不影响

用例设计

强组合方式：构成测试用例的每个输入条件对应某个有效等价类 — 全覆盖

弱组合方式：测试用例仅需完全覆盖所有输入条件的有效等价类

针对无效等价类的测试用例设计

单缺陷假设 — 每个用例仅覆盖一个输入条件的某一个无效等价类

基于决策表的测试

为了弥补等价类划分时强加的独立性假设，其设计在等价类划分的基础上

决策表划分

• 输入区，输出区，输入取值区，输出取值区

输入区	输入取值区
输出区	输出取值区

决策表的简化

两个前提

• 输出相同
• 输入相似

补充

• 当输入条件本身不存在相关性，则不需要使用决策表，因为等价类划分本身不存在冗余
• 其不处理无效等价类
• 仅针对输入域进行分析

基于正交表的测试

在数据毫无规律或测试人员不了解数据规律的情况下使用

特点

• 均匀分布：实验点均匀分布
• 整齐可比：实验结果便于分析

用例设计

• 等水平正交表 — Ln(q ^ s)
• 混合水平正交表 — Ln(q1 ^ s1 * q2 ^ s2)

n：实际测试用例的个数 — 正交表的列数

q：每个输入条件所取测试数据的个数

q ^ s：理论上的全组合方式个数

一般应采用边界值测试和等价类测试方法，通过结合边界值来建立正交表和设计测试用例，对边界进行补充测试，从而得到多个边界缺陷共存的情况

基于场景的测试

以事件流为核心，是高层测试设计的基础

用例设计

基本流：从初始状态到最终状态过程的最主要的一个业务流程

备选流：！！！

场景构建

场景可以仅包含一个基本流，可以包含一个基本流和若干的备选流

最少的场景数等于事件流总数 —基本流 + 备选流

补充

• 一个测试用例对应一个场景，但一个场景可对应多个测试用例
• 仅对输入域分析
• 部分场景逻辑上可行，但现实不可行

第五章：白盒测试技术

白盒测试基于软件的源代码，已知产品的内部工作过程

关注对象

• 源代码 — 查看源代码，检查代码规范等问题，并查找代码缺陷
• 程序结构 — 通过函数调用图，算法流程图等反应程序设计的相关图表，找到代码缺陷，或评价程序执行效率，数据定义和使用缺陷

优势

• 针对性强，测试效率高
• 在函数级别工作，缺陷修复成本低

局限性

• 对测试人员技术要求高

适用阶段

• 被测对象为函数或者功能

静态白盒测试

• 代码检查

  • 主要通过同行评审方法来发现缺陷，即基于缺陷预防的思想
  • 同行审批
    • 审查
    • 团队评审
    • 走查
    • 结对编程
    • 同行桌查
    • 轮查
    • 特别检查

• 静态结构分析

  • 通过引入多种形式的图表，帮助快速了解程序设计和结构，更好地理解源代码，并找到缺陷和代码优化方向
  • 函数调用函数图
  • 函数控制流图
    • [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lcgN8kow-1661077722011)(D:\Typora\picture\bffd7f6544da486b8508668970dea965.png)]
    • ：函数出入口
    • ：串行语句
    • ：逻辑判断(开始)
    • ：逻辑判断(结束)
    • ：break
    • ：包含函数调用
    • 设计特点
      • 多出口
      • 环复杂度高
      • 存在非结构化设计

• 代码质量度量

  • 软件质量模型
    • 外部质量模型
      • 高层：质量特性 — 软件质量需求评价标准
      • 中层：质量子特征 — 软件质量设计评价准则
      • 底层：质量度量 — 软件质量度量评价准则
    • 内部质量模型
      • 高层：质量特性 — 软件质量需求评价标准
      • 中层：质量子特征 — 软件质量设计评价准则
      • 底层：质量度量 — 软件质量度量评价准则
    • 使用中质量模型
  • 代码质量度量模型
    • 质量因素
    • 质量标准
    • 质量度量元：规范代码行为属性
  • 代码质量的自动度量
    • 代码之来给你可以通过测试工具来完成自动度量，以直观的图表形式呈现，即利于后续分析，又节省人力，加快工作进度

• 静态结构分析的局限

  • 函数调用图中无法看出接口的复杂度，流程控制如无法看出每个判定节点的复杂度和循环结构的复杂度

对判定的测试

对代码中所有的逻辑值均需要测试真值和假值的情况

1. 语句覆盖
   • 每条语句至少执行一次
   • 关注语句而非判定，即隐式的分支无效(分支上不存在可执行语句)
2. 判定覆盖
   • 保证程序中每个判定结点的真假路径各执行一次
   • 处理复合判定表达式时会存在遗漏
3. 条件覆盖
   • 保证每个符合表达式中每个表达式的真假情况个执行一次
   • 其并不能保证判定覆盖
4. 判定/条件覆盖
   • 判定覆盖 + 条件覆盖
   • 测试用例复杂，有时难以设计
5. 条件组合覆盖
   • 每个判定结点中的简单判定可能取值结果组合情况应该至少执行一次
   • 测试用例会存在冗余，规模巨大
6. 修正的判定/条件覆盖
   • 在满足判定/条件覆盖的基础上，每个简单判定都应该独立的影响到整个判定表达式取值
   • 无法处理耦合的表达式

对路径的测试

相关概念：

程序图：经过压缩后的控制流图，也是一种特殊形式的有向图。

• 压缩：
  • 剔除注释语句
  • 剔除数据变量的声明语句
  • 所有的串行结点压缩为一个节点
  • 所有循环压缩为一个循环

环复杂度：基于判定节点对程序图封闭环数据造成影响来衡量程序的复杂程度

• 环复杂度计算
  1. 直接观察法
     • 程序将二维平面分割为封闭区域和开放区域的个数
  2. 公式计算法
     • V(G) = e - n + 1
       • e：图中边的数量
       • n：图中节点的总数
     • 使用条件：无孤立节点，且为强连通图
  3. 判定节点法
     • V(G) = P + 1
       • P：图中独立判定结点的个数
  4. 多出口程序
     1. 将两个出口连接到要给虚拟结点(不存在)上，形成单出口程序
     2. 将两个出口连接到入口节点，形成强连通图

基本复杂度：通过结构化设计节点不断进行压缩，最终得到一个无法压缩的程序图

基本原理：将全路径集合看作一个向量空间，并从全路径集合中抽取一组线性无关的独立路径看作一组向量基。

目标

• 测试的完备性：对独立路径的测试达到对所有路径的测试覆盖
• 测试的无冗余性：每条路径都是独立的，针对每条路径设计的测试用例之间不存在冗余

独立路径的抽取

1. 两条线性无关的路径
2. 所选独立路径的并是整个向量空间

测试难点

1. 如何确定独立路径集合的规模
2. 如何保证路径的独立性以及抽取的独立路径集合的完备性
3. 如何保证每条独立路径的可行性
4. 如何从独立路径设计测试用例

对循环的测试

重点关注循环的过程正确性，即在循环的边界和运行界限内对循环体的执行过程进行测试

循环分类

单个循环

1. 循环初始化
2. 循环迭代
3. 循环终止

循环的串联

• 判定为每个循环独立，即可独立测试

循环的嵌套

• 先进性内循环测试，在进行外循环测试

非结构化的循环

• 若为编写人员，改写为结构化循环，若为测试人员，则按照相关逻辑设计并执行测试用例

对变量的测试

定义/引用异常缺陷

1. 变量在使用前从未定义
2. 变量被定义但从未使用
3. 变量在使用之前多次定义

用例设计

相关概念

• 定义节点 — 变量值发生改变
• 使用节点 — 使用
• 定义/使用节点对
• 定义/使用路径 — 从节点值被改变到该变量停止使用的一条路径
• 定义清除路径 — 从节点值被改变到该变量停止使用的一条路径(中间节点不修改变量值)

所有的定义/使用路径(不包括定义清除路径)为高风险路径

第七章：单元测试

单元测试是指对软件中的最小可测试单元或基本组成单元进行检查和验证

单元

• C(面向过程)：常指一个函数或者一个过程
• Java(面向对象)：一般指一个类
• 图形化软件：常指要给窗口或一个菜单

单元测试内容

• 静态检查
  • 适用于所有可能出现的运行情况
• 动态测试
  • 能够真实反映程序在特定运行期的运转情况

被测功能单元的测试为黑盒测试，对代码所作测试为白盒测试

静态检查

• 主要对模块局部数据结构的测试

动态测试

• 模块接口测试

• 模块边界条件测试

• 模块独立路径测试

• 错误处理路径测试

驱动和桩模块的设计

驱动模块：模拟被测单元的上级模块，用于接收测试数据，启动被测模块和输出结果

• 利用已有测试用例，接受测试的输入数据
• 将测试数据传递被测单元
• 打印和输出测试用例的相关结果，判断测试是通过还是失败
• 通过测试日志文件记录测试过程，便于后继数据保存和分析

桩模块：被被测模块所调用的模块

• 在特定情况下完成原单元的基本功能
• 能够正确被调用
• 有返回值
• 不包含有单元的所有细节

认识误区

测试需求针对实现的功能或性能，可测试需求是指需求分析是应该注意需求的可测试性要求

单元测试过程

1. 计划阶段
2. 设计阶段
3. 实施阶段
4. 执行阶段
5. 评估阶段

日构建

日构建是自动，完整地构建整个代码库的代码，在构建的同时完成单元测试执行的软件研发工作模式(一天可构建多次)

优势

• 进度可见，可控
• 适于多环境下的团队开发
• 便于尽早发现，修复和验证缺陷
• 增量测试

不足

• 给开发人员带来压力
• 加重开发经理的工作负担
• 开发小组需要投入精力保证每日构建的顺畅
• 需要额外忍受负责冒烟测试

回归测试

主要对修改后的软件重新进行测试，以保证其正确性

第八章：集成测试

单元测试无法取代集成测试

将经过单元测试的模块组成子系统或系统，并进行测试的过程，

内容

• 检查模块接口间的数据是否会丢失
• 检查模块功能是否对其他模块产生不利影响
• 检查全局数据结构是否正确
• 单元测试的误差会不会累加成无法接受的程度

评价

• 测试用例越小越好
• 驱动模块，桩模块数量越少越好
• 单个集成测试设计的接口越少越好

集成方式

成对集成

• 容易定位缺陷 — 每个集成测试只存在一对调用单元

邻居集成

• 邻居构成
  • 中间层模块 + 上层模块 + 下层模块
  • 根模块 + 叶子模块
• 测试用例减少，驱动模块和桩模块相对较少

基于独立路径的集成

• 从根节点到叶子节点形成的独立路径

集成测试遍历顺序的设计

大爆炸集成

一次性组装所有通过单元测试的模块

自顶而下的集成

自底而上的集成

三明治集成

上下结合，一同执行集成

第九章：系统测试

功能测试

性能测试

安全性测试

兼容性测试

用户界面测试

进行测试的过程，

内容

• 检查模块接口间的数据是否会丢失
• 检查模块功能是否对其他模块产生不利影响
• 检查全局数据结构是否正确
• 单元测试的误差会不会累加成无法接受的程度

评价

• 测试用例越小越好
• 驱动模块，桩模块数量越少越好
• 单个集成测试设计的接口越少越好

集成方式

成对集成

• 容易定位缺陷 — 每个集成测试只存在一对调用单元

邻居集成

• 邻居构成
  • 中间层模块 + 上层模块 + 下层模块
  • 根模块 + 叶子模块
• 测试用例减少，驱动模块和桩模块相对较少

基于独立路径的集成

• 从根节点到叶子节点形成的独立路径

集成测试遍历顺序的设计

大爆炸集成

一次性组装所有通过单元测试的模块

自顶而下的集成

自底而上的集成

三明治集成

上下结合，一同执行集成

第九章：系统测试

功能测试

性能测试

安全性测试

兼容性测试

用户界面测试

可安装性测试