全网最全 | 软件测试基础

Posted 2022-05-06 有理想、有本领、有担当的有志青年

文章目录

• 什么是软件
• 软件测试定义
• 软件测试原则
• 软件测试发展历程
• 软件缺陷
• 测试用例的定义，设计
• 软件开发及测试模型
• • 瀑布模型（会画）
  • V模型特点（会画）
  • W模型（会画）
  • X模型
• 测试方法
• • 等价类划分法
  • 边界值测试
  • 决策表
  • 正交表
  • 因果图法
  • 场景法
  • 状态转换法
• 白盒测试
• • 动态白盒测试
  • 对判定的测试
  • 单元测试
  • 集成测试
  • 系统测试
• 软件测试流程
• 测试用例的属性
• 用例的组织和跟踪
• 缺陷产生的原因
• 测试团队的职责：
• 冒烟测试
• 回归测试
• 持续性集成
• CMM模型

什么是软件

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

软件测试定义

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

软件测试原则

1. 尽早地和及时地进行测试，从需求阶段开始介入
2. 测试前应当准备好测试数据和与之对应的预期结果这两部分
3. 测试输入数据应包括合理的输入条件和不合理输入条件
4. 程序提交测试后，应当由专门的测试人员进行测试
5. 严格执行测试计划，排除测试的随意性
6. 测试用例的预期结果应做全面地检查
7. 充分注意测试当中的群集现象
8. 保存测试计划、测试用例、出错统计和最终分析报告，为维护工作提供充分的资料
9. 做到0 bug，足够好
10. 缺陷具有免疫性（每修复3-4个缺陷，一般就会产生一个新的缺陷）

软件测试发展历程

• 初始阶段
• 定义阶段
• 集成阶段
• 管理、测试和最佳化阶段

软件缺陷

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

测试用例的定义，设计

定义：一组 测试输入、执行条件和预期结果，目的是要满足一个特定的目标，比如执行一条特定的程序路径或检验是否符合一个特定的需求
设计：分为正常数据，错误数据，边界数据
# 软件测试的分类
从是否关心内部结构角度：黑盒测试，白盒测试
从是否运行被测程序角度：静态测试，动态测试
从执行时是否需要人工干预角度：人工测试，自动化测试
从软件开发的过程的角度：单元测试，集成测试，系统测试，验收测试
从测试实施组织的角度划分：开发方测试，用户测试，第三方测试

软件开发及测试模型

瀑布模型（会画）

特点：

1. 逐级下落式
2. 将软件生存周期各活动规定为依线性顺序并联接的若干阶段的模型

优点
1． 易理解，阶段明显，强调需求分析，明确测试阶段，提供了一套模板
2． 文档驱动
缺点

1. 成果晚出，风险大
2. 反复和迭代不适合，灵活性差
3. 单次需求，适应性差
4. 缺陷晚查，代价多

工作场景
 功能、性能明确完善
 需求固定，无重大变动
 如操作系统，数据库管理系统

V模型特点（会画）

 动态测试与开发行为相对应
 测试滞后，缺少静态测试

W模型（会画）

** 静态测试和动态测试行为伴随整个开发阶段，并与开发行为对应
 有助于早发现缺陷，了解项目难度、评估测试风险，加快进度，降低成本
 不支持迭代的开发模型，不支持变更调整，不能体现测试流程的完整性
H模型

 测试是独立的流程，保持自身完整性
 测试准备和执行活动是分离的**

X模型

 更加清晰地体现了单元测试集成测试系统测试的过程
 能处理包括交接、频繁重复的集成等工作，更加贴合实际
综合策略
 宏观上衣W模型为基本框架
 微观上对每个测试阶段以H模型为指导，进行独立测试
 有诸多不确定因素时可利用X模型
 软件企业应以TMM为指导

测试方法

黑盒测试/功能测试/数据驱动测试（方法、步骤、适合场景）
概念：不考虑程序执行过程，测试者仅根据程序功能的需求规范考虑确定测试用例和推断测试结果的正确性
优势：方法简单有效，整体测试系统的行为，开发与测试并行，对测试人员要求相对低

等价类划分法

有效等价类：被测对象能接受的数据，用于考察软件的正常工作能力
无效等价类：被测对象不能接受的数据，用于考察软件的容错能力
适合场景：单个界面单个输入

1. 根据输入条件划分等价类

2. 设计有效等价类测试用例（尽可能覆盖多个有效等价类）
   编号＋覆盖等价类＋预期结果

3. 设计无效等价类测试用例（每个测试用例只包含一个无效等价类，其余为有效等价类）

边界值测试

定义：在被测对象的边界及边界值附近设置测试用例
边界的确定：
若输入条件规定了取值范围，则以该范围作为边界
若输入条件规定了值的个数，则以值的个数作为边界
若输入域是有序集合，则选取集合中特定次序的数据作为边界（如第一个或最后一个）
测试用例设计
典型值法：在边界点a处选择a-1，a，a+1这三个值作为测试数据
边界组合方式
等价类划分法＋边界值

决策表

也称判定表法，是分析和表达多种逻辑条件下执行不同操作情况的工具
适用情况：若输入输出较多，且互相制约的条件较多
条件桩：列出问题的所有条件
动作桩：列出问题规定可能才去的操作
条件项：列出条件的真假取值
动作项：列出在条件项各种取值条件下的动作

正交表

作用：缩减测试用例
使用场景：输入条件多并且条件中参数值多
步骤：根据几种条件对应几种因子，根据几种结果对应几种状态

因果图法

四种基本关系
恒等：原因与结果之间一对一关系
非：原因与结果之间否定关系
或：表示几个原因若有一个出现，则结果出现
与：表示几个原因都出现，结果才会出现
应用场合：软件输入条件过多
步骤：
 分析原因和结果
 画出因果图
 在因果图上表明约束或限制条件
 转换为决策表
 将决策表转换成测试用例

场景法

应用场合：业务流程类软件

状态转换法

适用场合：多状态变化的情况，订单类

黑盒测试方法总结
 首先进行等价类
 任何情况下都必须使用边界值
 多个输入条件：决策表/因果图
 业务流程清晰：场景法
 订单、播放器：状态转移法：
 参数配置：正交实验法
 补充：错误推测法

白盒测试

优势：
针对性强，缺陷修复成本低，利于了解测试覆盖程度，利于优化代码预防缺陷
函数级别
静态白盒测试
特点：不运行被测软件，不设计用例和结果分析
三种方法：代码检查，静态结构分析，代码质量度量
代码检查：通过同行评审，以评审会议的形式发现缺陷
静态结构分析：
函数调用关系图
 调用关系是否符合要求
 是否存在递归调用
 调用层次是否太深
 是否存在孤立函数
 根节点，叶子结点，接口数量多的节点优先测试
程序图
原则：
 剔除注释语句
 剔除所有数据变量声明语句
 所有连续的串行语句压缩为一个节点
 所有循环次数压缩为一次循环（仅考虑执行循环体和不执行循环体）
 单入口，单出口，若有多出口虚拟化一个end节点
分析：
 是否存在多出口
 是否存在孤立语句
 环复杂度是否太大（<=10）
 是否存在非结构化设计
计算环复杂度
（1） 直接观察法：封闭的区域＋1
（2） 公式法：（单入口单出口）e-v+2
（3） 判定节点法：有两条出弧的节点数+1
代码质量度量：ISO9126软件质量模型

动态白盒测试

主要是按一定的步骤和方法生成测试用例，并驱动相关模块去执行程序并发现软件中的错误和缺陷
包括对判定对路径对循环对变量的测试

对判定的测试

语句覆盖：保证程序的每一条可执行语句至少执行一次
判定覆盖：每个判定节点至少获得一次真值和假值
条件覆盖：每个判定中每个条件的可能取值至少满足一次
条件判定覆盖：所有条件可能取值，所有判定的可能至少执行一次
条件组合覆盖（最全）：判定中条件的各种组合至少执行一次
独立路径测试

1. 画程序图
2. 计算环复杂度以确定独立路径集合的大小
3. 确定主路径要求尽可能多的执行语句
4. 依据主路径补充其他路径
5. 写出测试用例

循环测试（边界思路）
单个循环，串联，嵌套
变量测试（数据流测试）
作用：作为独立路径的补充
定义节点：该变量的值在此处改变
使用节点：该变量的值在此处使用
定义/使用节点对：一对定义节点和使用节点
高风险路径：不是定义清除路径的路径
定义/清除路径：一条定义/使用路径中不包含该变量的其他定义节点
（变量的值在这条路径中不发生改变）

步骤

1. 确定需要重点测试的变量V
2. 确定变量V的所有定义节点和使用节点
3. 确定变量V的所有定义/使用节点数
4. 对V的重要定义/使用路径
5. 判断每条定义/使用路径是否为高风险路径（路径不是定义清除路径则为高风险路径）（定义清楚路径：在路径中变量的值没有发生改变）
   测试开发过程：单元测试，集成，系统，验收
   单元测试根据方法的输入和输出
   集成测试根据接口的输入和输出
   UI测试根据界面的输入和输出
   软件测试流程的各个阶段

单元测试

内容：
 模块接口测试：考虑数据能否正确地输入和输出（输入和输出）
 模块局部数据结构测试：考虑代码执行过程是完整正确的
 模块独立路径测试：考虑每条独立执行路径（逻辑分支）
 错误处理路径测试：考虑所有错误的处理（逻辑分支）
 边界条件测试：在被测模块的输入/输出域边界设计测试用例（边界）
原则：自动化，独立性，可重复
驱动模块：模拟被测单元的上级模块。
能利用测试用例，接收测试的输入数据，能将数据传递给被测单元
能判断测试失败还是通过，能通过日志文件记录测试过程
桩模块：模拟被测单元所调用的模块。
能完成原单元的基本功能，能被正确调用，
有返回值，不包含所有细节

集成测试

在单元测试的基础上，将模块组装成系统进行测试，目的是确保模块组合在一起后能够按预期要求正常运行，并确保增量的行为正确。
测试内容：
 检查穿越模块接口的数据是否丢失
 判断各子功能组合起来能否达到预期要求的父功能
 检查一个模块的功能是否会对其他模块的功能产生不利影响
 检查全局数据结构是否正确，以及在完成模块功能的过程中是否会被异常修改
 单个模块的误差累计起来，是否会放大到不可接受的程度
策略
 大爆炸集成：一次性组装，违反了范围从小到大的原则，难以定位
 自顶向下集成：沿控制层次从上而下组装，工作量大，不充分，效率低
 自顶向上集成：从下而上组装，工作量大，难发现时序问题，资源竞争问题，难以早期发现上层模块的缺陷
 混合集成：分别自定向下和自底向上集成，并在子树进行大爆炸集成

系统测试

功能测试：针对系统的功能需求展开测试，最基本的测试
性能测试：对软件的运行性能指标进行测试，主要考虑时间和空间性能
安全性测试：用于检测系统对非法侵入的防范能力。资源，风险，安全性控制
兼容性测试：检验被测软件与其他软硬件能否正确交互和实现信息共享
用户界面测试：测试用户输入和系统输出
可安装性测试：测试安装和卸载
易用性测试：从使用合理性和方便性等进行检查

## 验收测试
按照项目任务书或和合同、工序双方约定的验收依据文档进行的对整个系统的测试和评审，决定是否接受或拒收
α测试：在开发者受控的环境下，用户在开发环境下进行的测试
β测试：开发者无法控制的环境下，用户在实际使用环境下进行的测试

软件测试流程

1. 熟悉需求
2. 制定测试计划
3. 设计测试用例
4. 搭建测试环境
5. 实施测试
6. 测试评估
7. 测试总结
8. 测试管理

测试用例的属性

 用例序号
 输入条件
 操作步骤
 预期输出
 测试结果

用例的组织和跟踪

 整理模块需求
 设计测试思路
 编写测试用例
 评审测试用例
 修改更新测试用例
 执行测试用例
 分析评估测试用例质量

缺陷产生的原因

 技术问题
 团队沟通不充分
 软件本身
缺陷的生命周期：从需求到交付用户后使用的过程
严重程度：严重的（直接毙了），一般的（有点影响），次要的（几乎没影响）
优先级（紧急程度）：高（急需）中（排队）低（影响不大）

测试团队的职责：

 早发现多发现严重缺陷
 督促开发人员修复，督促开发人员养成良好习惯
 帮助项目管理人员制定开发计划
 分析总结和跟踪缺陷
 帮助改善开发流程

冒烟测试

 选取系统中重要功能，重要使用流程等进行测试
 发布上线后，提交给用户前

回归测试

软件有新版本后，对新版本重新进行测试
测试是否缺陷被修复，测试原先功能是否正常
过程

1. 识别出软件中被修改的部分
2. 识别由于次修改对软件产生哪些影响
3. 从原先的测试用例中，找到能验证此次修改的测试用例
4. 有问题修改后继续回归测试
5. 修改的多时，执行全部用例

持续性集成

团队开发成员经常集成工作，每次集成都通过自动化的构建来验证，从而尽快地发现集成错误

CMM模型

 能力成熟度模型
 把开发视为一个过程，进行过程监控和研究
 更科学化标准化更好实现商业目标
 初始级，可重复级，定义级，管理级，优化级