软件测试-期末复习
Published:
东南大学-软件测试-期末复习笔记
软件测试概述
软件测试的产生背景
软件危机
危机原因：缺乏规范化工程约束->缺陷的不断积累与放大效应
缺陷累积放大⭐
缺陷出现的原因⭐
产品说明书（主要原因）
随意、易变、沟通不足
设计（次要原因）
随意、易变、沟通不足
编码
软件复杂度，进度压力，低级错误
其它
理解错误，测试错误
有关测试观点的正确理解⭐
Glenford J. Myers 定义
测试是为发现错误而执行一个程序或系统的过程
核心思想：测试是尽可能多地发现软件错误
- 测试是为了证明程序有错，而不是证明程序无错误
- 一个好的测试用例是在于它能发现至今未发现的错误
- 一个成功的测试是发现了至今未发现的错误的测试
软件测试基本概念
测试定义⭐
使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别
- 在特定的条件下运行系统或构件，观察或记录结果，对系统的某方面作出评价。
- 分析某个软件项以发现现存和要求的条件之差别并评价此软件项的特性。
测试与调试⭐
测试目的⭐
确保软件质量
找出软件错误和缺陷，降低软件发布后潜在错误和缺陷造成的损失；验证软件是否能满足用户需求，树立对软件的信心
确保软件开发过程方向的正确性
通过分析错误产生的原因帮助发现当前开发工作所采用的软件过程的缺陷，促进软件过程改进；为风险评估提供信息。
测试原理/原则⭐
用户需求至上
所有测试都应追溯到用户需求。最严重的错误是导致软件无法满足需求的错误。测试的目标是在用户发现缺陷前找到它们。
测试是有计划的活动
测试计划制定先于测试的执行；测试贯穿于全部软件生存周期。
缺陷出现的集群性
软件缺陷会集中出现；80%的错误可能起源于20%的模块。
测试应从“小规模”走向“大规模”
最初测试单个程序模块，然后在集成的模块簇中找缺陷，最后在整个系统中找缺陷。
穷尽测试（完全测试）不可能
有效的测试应由第三方独立进行
有些测试应避免由开发人员进行
测试无法揭示所有缺陷
测试可以报告说缺陷存在，但没有找到缺陷的话却不能说明软件没有缺陷
测试的杀虫剂悖论
潜在缺陷对已进行的测试具有免疫力
测试是有风险的行为
并非所有的软件缺陷都需要修复
不值得修复的原因：
- 没有足够时间
- 不算真正的代码缺陷
- 修复风险太大
- 不值得修复
测试过程
- 拟定软件测试计划
- 编制软件测试大纲
- 设计和生成测试用例
- 实施测试
- 分析测试结果
测试用例（三要素）⭐
输入、执行条件、期望输出
设计准则：代表性、可判定性、可再现性
软件测试类型⭐
- 测试技术
- 白盒测试
- 黑盒测试
- 灰盒测试
- 开发阶段
- 单元测试
- 集成测试
- 确认测试
- 系统测试
- 性能测试
- 回归测试
- 验收测试
- 执行状态
- 静态测试
- 动态测试
- 执行主体
- 开发方测试
- 用户测试
- 第三方测试
- 特殊测试
- 国际化测试
- 即兴测试
- 兼容性测试
- 安全性测试
- 可用性与易获得性测试
- 面向对象系统测试
- Web测试
软件测试过程W模型⭐
软件测试现状和趋势
软件测试的地位（工作量百分比）
国际知名IT企业开发：测试1：1，微软1：2
国内逐渐受到重视
白盒测试
白盒测试基本概念
定义
白盒测试：一种基于源程序或代码的测试方法。依据源代码或代码结构与逻辑，生成测试用例以尽可能多的发现并修改源程序错误。
白盒测试分为静态和动态两种类型。
其他称谓：结构测试、逻辑驱动测试、基于程序的测试
意义
主要的单元测试方法
保证软件质量的基础
实施者⭐
单元测试阶段：一般由开发人员进行。
集成测试阶段：一般由测试人员和开发人员共同完成。
进入退出条件
进入：编码开始阶段
退出
- 完成测试计划(满足一定覆盖率)
- 发现并修正了错误
- 预算和开发时间
步骤
动态：
- 程序图
- 生成测试用例
- 执行测试
- 分析覆盖标准
- 判定测试结果
静态：
桌面检查、代码走查、代码审查
静态白盒测试
特点和优/缺点
在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构化分析。
测试条件：
只要求提供软件源代码，不要求提供可执行程序，即不用在计算机上执行程序，而是由人阅读代码
测试目标：
- 代码是否满足功能需求
- 代码是否与设计一致
- 代码是否遗漏某些功能
- 代码是否恰当地处理错误
优点：
- 可发现某些机器发现不了的错误
- 利用不同人对代码的不同观点
- 对照设计，确保程序能完成预期功能
- 不但能检测出错误，还可以尝试确定错误根源
- 节约计算机资源，但以增加人工成本为代价
- 尽早发现缺陷，避免后期缺陷修复造成的巨大压力
静态白盒测试方法
桌面检查⭐
实施者：通常是代码编写者，多数程序员在编译执行前都会做桌面检查
特点：
- 无结构化或形式化方法保证
- 不维护记录或检查单
桌面检查记录格式
行号
变量
条件
输入输出
输入：变量名+？+变量值
输出：变量名+=+变量值
优点：
编码者容易理解和阅读自己代码
- 开销小，没有指定进度
- 尽早发现缺陷
缺点：
- 开发人员不是实施测试的最佳人选
- 依靠个人勤奋和技能，有效性难以保证
代码走查⭐
特点：
- 由特定人员组成的团队通过会议完成
- 与会者充当计算机执行测试用例
- 开发人员及时回答与会者提出的问题
成员构成：主持人、记录员、编码者、测试人员、其他项目成员。审查人员中至少有一位资深程序员
走查规程：
- 审查员在审查前接到软件拷贝，事先准备
- 作者逐行或者逐个功能通读代码，解释代码
- 审查人员聆听，充当“计算机”模拟运行，提出有疑义的问题
- 审查后，作者编写报告，说明发现了什么问题，计划如何解决
代码评审⭐
是最正式的审查类型，具有高度组织化，要求每个参与者都接受训练。
代码审查小组：
- 主持人：多面手
- 表述者：会上通读程序，但不是作者
- 作者：解释
- 评论员：找出缺陷
- 记录员
代码审查步骤：
计划Plan
主持人做计划
概述Overview Meeting
描述技术背景
准备Preparation
评论员审查代码
核对表例1
数据引用错误
数据声明错误
计算错误
比较错误
控制流错误
5.1 循环是否能中止
5.2 程序、模块和子程序是否会中止
5.3 某些取值是否会导致循环从不被执行
接口错误
输入/输出错误
审查会议Inspection Meeting
阅读代码、讨论、提问
记录错误：类型、严重级别
不讨论解决方案
审查报告Report
缺陷列表：类型、严重级别
核对表的基础
返工Rework
分配缺陷并修复
跟进Follow up
监督、审查修复部分
代码审查作用
- 发现代码缺陷
- 提高代码质量
- 及早定位缺陷群集位置
代码审查挑战
- 费时间
- 涉及多人参加
- 不能保证参与者全部理解程序
动态白盒测试概念⭐
特点和优/缺点
特点：
不但要提供软件源代码，还要提供可执行程序，测试过程需要在计算机上执行程序。
不可达路径
测试流程
设计测试用例
执行测试
收集测试结果
测试覆盖分析
测试是否足够 N回第一步 Y👇
测试结果文档
流图（流图的画法）⭐
覆盖标准（控制流、数据流）⭐
控制流
语句覆盖：保证程序中的每条语句都执行一遍
100%的语句覆盖可能很困难
- 处理错误的代码片段
- 小概率事件
- 不可达代码
判定覆盖：保证每个判断取True和False至少一次
优点：简单，包含语句覆盖并避免了语句覆盖的问题
缺点：忽略了表达式内的条件，不能发现每个条件的错误
条件覆盖：保证每个判断中的每个条件的取值至少满足一次
不能保证程序所有分支都被执行
条件覆盖不要求覆盖判定结果的不同逻辑值，因此可能比语句覆盖或判定覆盖要弱
判定条件覆盖：保证每个条件和由条件组成的判断的取值至少出现一次
条件组合覆盖：保证每个条件的取值组合至少出现一次
代价昂贵，$2^n$组合数目，n为原子条件数
某些条件组合是不可能的
路径覆盖：覆盖程序中所有可能路径
优点：相对彻底的测试
缺点：
- 路径分支可能以指数级增加
- 不可达路径存在
- 并未测试各分支中的条件
动态白盒测试方法⭐
基于控制流覆盖的测试（语句、判定、条件、判定条件、条件组合、路径）⭐
- 根据题目分析是否需要考虑短路
- 使用尽量少的测试用例实现相关测试
- 测试用例要充分体现相应控制流覆盖的特点
- 对各个控制流覆盖标准（语句、判定、条件、判定条件、条件组合、路径）有明确认识
- 注意：控制流覆盖并不使用程序流图
基本路径测试⭐
- 能够正确画出程序流图，弄清对于组合条件的判定如何处理
- 能够使用多种方法计算圈复杂度（环复杂度）
- 能够正确得出基本路径（注意得出的顺序）
- 不是所有的基本路径都能写出测试用例
基本路径：任何贯穿程序的、至少引入一组新的处理语句或一个新判断的程序通道
环复杂度：环复杂度度量基本路径数，是所有语句被执行一次所需测试用例数的上限
- 域的数量
- 边数 - 结点数 + 2
- 判定结点数 + 1
- 图矩阵法
基本路径集寻找算法
- 确认从入口到出口的最短基本路径
- 从入口到第一个未被先后评估为真和假两种结果的条件语句
- 改变该条件语句的判断值
- 按最短路径从这个条件语句到出口
- 重复2-4，直到所有基本路径都被找到
循环测试⭐
简单循环
测试用例构造
- 跳过整个循环
- 只执行一次循环
- 执行两次循环
- 执行m(m<n)次循环
- 执行n-1,n,n+1次循环
嵌套循环
测试用例构造
- 先测试最内层循环
- 所有外层的循环变量置为最小值
- 最内层按简单循环测试
- 由里向外，测试上层循环
- 此层以外的所有外层循环的循环变量取最小值
- 此层以内的所有嵌套内层循环的循环变量取“典型值”
- 该层按简单循环测试
- 重复上一条规则，直到所有各层循环测试完毕
- 对全部各层循环同时取最小循环次数，或者同时取最大循环次数
串接循环
测试用例构造
- 若串接的各个循环相互独立
- 分别用简单循环的方法进行测试
- 若两个循环不独立(第一个循环的循环变量与第二个循环控制相关)
- 把第一个循环看作外循环，第二个循环看作内循环，然后用测试嵌套循环的办法来处理
非结构循环
先将其结构化，然后再测试
数据流测试⭐
- 不考虑数据流覆盖的各种标准
- 能够找出定义节点和使用节点
- 列举出所有可能的DU路径
- 进行DU路径约简
数据流覆盖思想
- 程序是对数据的加工处理过程，对程序的测试可从数据处理流程的角度进行考虑
- debugging的启发：寻找关于某变量的定义和使用位置，思考程序在运行时该变量的值会如何变化，从而分析bug产生的原因
数据的处理过程对应一定的控制流路径
P——程序
G(P)——程序图(流图)
V——变量集合
PATH(P)——P的所有路径集合(此路径为数据流测试路径，不同于前面的路径覆盖的路径)
定义节点DEF(v,n)——在节点n定义了变量v
使用节点USE(v,n)——在节点n使用了变量v
谓词使用P-use——位于一个谓词中，即条件判断语句中
运算使用C-use——位于一个运算中，即计算表达式中
输出使用O-use——变量值被输出到屏幕/打印机
定位使用L-use——变量值用于定位数组位置
迭代使用I-use——变量值用于控制循环次数
变量v的定义-使用路径(du-path)
给定PATH(P)中的某条路径，如果定义节点DEF(v,m)为该路径的起始节点，使用节点USE(v,n)为该路径的终止节点，则该路径是v的一条du-path
变量v的定义-清除路径(dc-path)
某条du-path除了起始节点没有其他定义节点
动态白盒测试优点
- 检测代码中的判断和路径
- 揭示隐藏在代码中的错误
- 对代码的测试比较彻底
缺点：
- 无法检测代码中不可达路径
- 不验证需求规格
白盒测试工具
测试工具分类
静态分析工具
动态分析工具
各种测试工具的作用
静态分析工具
- 在生命周期早期检测软件编码缺陷，帮助缩短开发时间
- 通过指出未测试的软件代码，改进代码可靠性，定位易出错的模块，这些模块通常导致了大部分软件错误
- 通过提供基于软件度量和图形的信息，预测和诊断问题
- 通过适当的代码优化重组，识别源码树结构中重复的代码，帮助降低维护成本
动态错误检测工具
检查代码中类似内存泄漏、数组越界等错误
时间性能测试工具
记录程序执行时间的细节，包括语句或函数，定位代码中的性能瓶颈
覆盖率统计工具
统计当前测试用例对代码的覆盖率，保证单元测试的全面性
黑盒测试
黑盒测试基本概念
定义
一种基于规格说明，不要求考察代码，以用户视角进行的测试。
（功能测试、基于规格说明的测试）
意义
黑盒测试有助于软件产品的总体功能验证：
- 检查明确需求和隐含需求
- 采用有效输入和无效输入
- 包含用户视角
目的⭐
实施者⭐
专门的软件测试部门；有经验的测试人员
步骤
- 规格说明书
- 生成测试用例
- 执行测试
- 判定测试结果
进入退出条件⭐
黑盒测试方法基础
基于需求的测试（RTM）
确认软件需求规格说明书列出的需求
前提：需求规格已经过仔细评审，隐含需求明确化
需求跟踪矩阵(RTM)
正面测试和负面测试
正面测试
正面测试用例：测试用例通过一组预期输出验证产品需求
目的：证明软件对于每条规格说明和期望都能通过
注意：预期产品给出一个错误时，它确实给出该错误，这也是正面测试的一部分
正面测试用于验证已知测试条件，证明软件可以完成所期望的工作
负面测试
展示当输入非预期输入时产品没有失败
目的：使用产品没有设计和预想到的场景，尝试使系统垮掉
负面测试用于通过未知条件把产品搞垮
黑盒测试方法
等价类划分⭐
原理：
- 将程序的输入域划分为数据类，以便导出测试用例
- 他试图定义一个测试用例以发现各类错误，从而减少测试用例数目，降低测试工作量
等价类（划分）：
- 如果软件行为对一组值来说是相同的，则称这组值为等价类
- 产生同一种预期输出的一组输入值叫一个划分
有效等价类：完全满足产品规格说明的输入数据，即有效的、有意义的输入数据构成的集合
无效等价类：不满足程序输入要求或者无效的输入数据构成的集合
等价划分准则
- 输入条件是布尔表达式，则可以定义一个有效等价类和一个无效等价类
- 输入条件代表一个范围，则可以定义一个有效等价类和两个无效等价类
- 输入数据个数有规定，则可以定义一个有效等价类和两个无效等价类
- 输入条件代表集合的某个子集，则可以定义一个有效等价类和一个或多个无效等价类
- 输入条件代表一组列表形式的数据，则可以定义N个有效等价类和一个无效等价类
- 输入条件代表要求符合某几个规则，则可以定义多个有效等价类和若干个无效等价类
等价划分方法步骤
- 选择划分准则
- 根据准则确定有效等价类和无效等价类
- 从等价类中选取样本数据
- 根据需求写预期结果
- 加入特殊值
- 执行测试
边界值分析⭐
- 等价类划分一定要考虑全面，分为有效等价类和无效等价类，并统一编号
- 写测试用例时，每个等价类至少有一个测试用例
- 边界值分析可考虑边界值和条件值
- 边界值要考虑需求的限制、数据类型的限制、系统的限制等多种限制条件
边界值分析原理
软件的两个主要缺陷源：
1.条件 2. 边界
条件：变量取值需要采取的特定行动
边界：各种变量值的“极限”
边界值分析：能有效捕获出现在边界处的缺陷的一种测试方法；利用并扩展了缺陷更容易出现在边界处的概念
缺陷出现在边界处的原因：
使用比较操作符时未仔细分析
多种循环和条件检查方法引起的困惑
对边界附近需求的理解不够
测试边界：
测试临近边界的有效数据，测试最后一个可能有效的数据，同时测试刚超过边界的无效数据
如何界定边界值
n：存在边界值的参数个数
m：边界值条件个数
4n+1：基本边界测试
每个参数取min，min+1，max-1，max各一次，同时其他参数取典型值。最后全部参数取典型值一次。
6n+1：健壮性边界测试
每个参数取min-1，min，min+1，max-1，max，max+1各一次，同时其他参数取典型值。最后全部参数取典型值一次。
3m：边界条件测试
每个条件取-1，自身，+1各一次
因果分析法⭐
因果图：将导致问题的原因划分为多种因素，并描述这些因素间的关系，从而找出问题根源的复杂问题分析工具。
原理：
- 软件的输入和输出之间存在逻辑关系，即因果图
- 因果图可从规格说明书中获得
输入约束
E 互斥
I 包含
O 唯一
R 要求
M 屏蔽(输出约束)
步骤
- 分析规格说明书，识别原因和结果
- 在因果图连接原因和结果
- 标明原因之间以及结果之间的约束条件
- 因果图转换为因果图列表进而生成决策表
- 决策表的规则转换为测试用例
决策表⭐
- 能够列出原因和结果列表
- 因果图的画法（会读图）
- 根据因果图得出因果列表，进一步得出决策表
- 决策表约简
决策表组成
- 条件桩：列出所有可能问题(条件)
- 条件项：列出条件所有可能取值
- 动作桩：列出可能采取的操作
- 动作项：指出在条件项的各种取值情况下应采取的动作
决策规则：贯穿条件项和动作项的一列
决策表构造
- 列出所有的条件桩和动作桩
- 填入条件项
- 填入动作项，得到初始决策表
- 简化决策表，合并相似规则
规则可能总数：$2^n$
基于模型的测试
正交数组⭐
正交表
构成
- 因子Factor：欲考察的变量因素(输入参数)
- 水平Level：单个因子的取值(输入取值)
- 因子数Factors：正交表中列的个数
- 水平数Levels：单个因子的取值个数
- 行数Runs：正交表行数，即测试用例个数
形式
$L_{行数}(水平数^{因子数})$
正交表的正交性
整齐可比性
在同一张正交表中，每个因子的每个水平出现的次数是完全相同的
均衡分散性
在同一张正交表中，任意两列(两个因子)的水平搭配(横向形成的数字对)是完全相同的
测试步骤
- 确定因子和水平
- 判断是否能使用正交数组
- 选择合适的正交表
- 把变量值映射到表中
- 正交测试用例制作
- 补充测试用例
选择原则
考虑因子的个数
正交表因子数≥实际因子数
考虑因子的水平个数
正交表每个因子数≥实际每个因子数
考虑正交表的行数
如果出现2个或2个以上正交表符合以上条件，则选择行数最少的正交表
蜕变测试⭐
随机测试⭐
黑盒测试工具
测试工具原理、作用
功能测试工具
- 录制和回放
- 检验
- 可编程
自动化测试工具原理
运行被测软件的同时，捕获过程中的键盘、鼠标操作，生成脚本文件，这个脚本文件可以进行修改和回放
单元测试与集成测试
单元测试
基本概念
（软件单元、定义、意义、目标、实施者、关注点）
软件单元
一个应用程序中的最小可测部分
- 面向过程中的单元：单独的程序、函数、过程、网页、菜单
- 面向对象中的单元：类(基类、抽象类、子类)
定义
对最小的软件设计单元(模块/源程序单元)的验证工作
意义
- 消除软件单元本身的不确定性
- 其他测试阶段的必要的基础环节
实施者
软件开发人员
关注点
- 模块功能
- 内部逻辑处理
- 数据结构
- 性能
- 安全
单元测试规程（驱动器和程序桩）⭐
绝大多数情况下，单个单元是不能正常工作的，而是要和其他单元一起才能正常工作
单元测试通常与编码工作结合起来进行
模块本身不是一个独立的程序，在测试模块时，必须为每个被测模块开发一个驱动器和若干个桩程序
驱动器(Driver)
对底层或子层模块进行测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块。
接受测试数据，并把数据传送给被测模块，最后输出相关结果
桩程序(Stub)
对上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。
模拟未被测试模块/隶属模块的功能
插桩：或为获取特定的测试信息而添加进程序的测试操作
高内聚性程序：驱动器和程序桩简单，错误容易被发现
低内聚性程序：驱动器和程序桩工作量大，某些白盒测试需要推迟到集成测试阶段
手工和自动化测试
手工测试
按照需求规格设计测试用例完成测试
静态测试
自动测试
自动化方法的效果：有效验证较为独立单元的正确性
单元测试驱使程序员创建松耦合、高内聚的代码体，有助于开发健壮的软件
单元测试的局限性：
- 只验证单元自身的功能，不能捕获系统范围的错误
- 被测模块现实中可能接受的所有输入情况难以预料
集成测试
概念
定义
把单独的软件模块结合在一起作为整体接受测试
意义
- 验证软件单元间能否协调工作
- 验证单元集合的功能、性能和可靠性需求
实施者
软件测试人员+软件开发人员
技术
黑盒为主，白盒为辅
接口
内部接口
产品内部两模块之间通信的接口
外部接口
产品之外第三方可以看到的接口
接口提供方法
API、SDK
桩程序
以合适的格式提供合适的值，模拟实际组件
显式接口
写入文档的明确化的接口
隐含接口
未写入文档，只有开发人员知道
瞬时集成测试⭐
又称大爆炸测试策略
特点：当所有构件都通过单元测试，就把他们组合成一个最终系统，并观察它是否正常运转
缺陷
- 无休止的错误：错误很多；错误修复很困难；修正错误后，新的错误马上出现
- 模块一次性结合，难以找出错误原因
- 接口错误和其他错误容易混淆
适用领域：小型软件开发
增量集成测试（自顶向下，自底向上）⭐
特点：将程序分成小的部分进行构造和测试
优点：
- 错误容易分离和修正
- 接口容易进行彻底测试
缺点：会有额外开销，但能大大减少发现和修正错误的时间
自顶向下
集成顺序
首先集成主模块(主程序)，然后按照控制层次向下进行集成
集成方式
- 深度优先
- 广度优先
集成步骤
- 主程序作为测试驱动器
- 根据集成顺序，程序桩逐渐被各模块替换
- 每个模块集成时都需要进行测试
- 每完成一次测试后，将新模块替换程序桩
- 利用回归测试来保证没有引进新的错误
优点
- 尽早发现高层控制和决策错误
- 最多只需要一个驱动器
- 每步只增加一个模块
- 支持深度优先和广度优先
缺点
- 对底层模块行为的验证比较晚
- 需要编写额外程序(stub)模拟未测试的模块
- 部分测试用例由于依赖于其他层次的模块，在该模块未测试之前，这些测试用例的输入和输出很难确定
实施的主要难点
对于高层测试需要在低层测试完成后才可进行的情形难于编写桩模块
解决方法
推迟测试，直到低层模块完成测试；
设计程序桩，模拟低层模块
自底向上测试
自底向上
集成顺序
从原子模块，即程序最底层模块开始就构造并进行集成测试 原子模块->造价(Build)->应用软件系统
集成步骤
- 低层模块组成实现特定子功能的造件
- 编写测试控制程序协调输入输出
- 测试特定子功能的造件
- 沿层次向上对造件进行组合
优点：
- 尽早确认低层行为
- 无需编写程序桩
- 对实现特定功能的树容易表示输入输出
缺点：
- 推迟确认高层行为
- 需编写驱动器
- 组合子树时，有许多元素要进行集成
混合式
集成顺序
综合自顶向下和自底向上，是实际测试中的实用集成测试策略
特点
开发小组对各自的低层模块向上集成；
专门的集成小组进行自顶向下集成；
步骤
- 用程序桩独立测试上层模块；
- 用驱动器独立测试低层模块；
- 集成时对中间层进行测试；
测试插桩
黑盒插桩
白盒插桩
插桩作用⭐
白盒插桩作用
- 生成特定状态，检验状态的可达性
- 显示或读取内部数据或私有数据
- 监测不变数据
- 监测前提条件
- 人为触发事件时间
- 监测事件时间
黑盒插桩作用
测试预言
检查函数正确性、系统安全性
随机数据生成器(随机测试技术)
避免只测试所知道的将奏效的场景
系统测试、确认测试和回归测试
系统测试
概念（定义、意义、目的、实施者等）⭐
定义
对完整集成后的产品和解决方案进行测试，用来评价系统对具体需求规格说明的功能和非功能的符合性的测试
目的/作用
- 发现可能难以直接与模块或接口关联的缺陷
- 发现产品设计、体系和代码的基础问题(产品级缺陷)
引入时机
集成测试之后(基础的程序逻辑错误和缺陷已更正后)
实施人员
独立测试团队(引入独立视角，有助于发现遗漏缺陷)
特点
是既测试产品功能也测试产品非功能的唯一测试阶段
实施原因
在测试中引入独立视角
独立测试团队；直接向高层报告
在测试中引入客户视角
消除对产品的偏见；验证完整产品
在测试中模拟客户使用环境
正式、完备和现实的测试环境
测试产品功能和非功能的问题
产品交付给客户之前发现各种残余产品缺陷的最后机会
建立对产品的信心
把握系统测试发现缺陷的度
分析和降低产品发布的风险
对发现的缺陷进行分析和分类，修复高影响风险的缺陷
保证满足所有需求，产品具备交付确认测试条件
功能测试和非功能测试⭐
功能测试（设计/体系结构测试、业务垂直测试、部署测试、Alpha/Beta测试、符合性）和非功能测试（可伸缩性测试/容量测试、可靠性测试、压力测试、互操作性测试/兼容性测试、可使用性与易获得性测试、国际化测试、性能测试、安全性测试）
功能测试
设计/体系结构测试
原理：对照设计和体系结构开发和检查测试用例，从而整理出产品级测试用例。集成测试用例关注模块或组件间交互，而功能系统测试用例关注整个产品的行为。从产品角度出发，检查软件体系结构的总体拓扑结构、构件模型的结构是否合理？构件的接口和连接件的角色之间是否匹配？是否满足相应的约束？等
方法
- 体系结构的静态测试
- 即体系结构分析
- 对体系结构的特征进行建模、分析，如：对类定义的一致性分析
- 体系结构的动态测试
业务垂直测试
原理：针对不同业务纵深的产品，根据业务定制测试用例，验证业务运作和使用
应用范围：通用的工作流自动化系统在不同商业领域的应用
方法：
- 模拟：测试需求和业务流
- 复制：获取客户数据和过程，针对特殊业务进行定制
定制：改变系统的一般工作流，以适用于不同业务纵深
术语：尽量使用各业务领域的专属名词
部署测试
验证系统是否能满足客户的部署需求
目的：特定产品版本短期内是否能成功使用
离场部署
在产品开发组织内进行，以确保客户部署需求的(模拟)部署测试
现场部署(离场部署的扩展)
- 现场部署是指在客户场地中的资源和环境都发布后，实施的一种部署方案。
- 第1阶段：采集实际系统真实数据，建立镜像测试环境，重新执行用户操作。
- 可以在不影响用户的情况下了解产品功效，并可以用智能记录器来记录并比对事务处理
- 第2阶段：引入新产品，进行新业务操作，同时比对事务处理情况，以确定新系统是否能够替代老系统
Alpha测试和Beta测试
Alpha测试
- 定义：用户在开发环境下进行的受控测试
- 特点：不由程序员或测试员完成，但开发者会在现场
在Alpha测试达到一定程度后进行Beta测试
Beta测试
- 定义：用户在实际使用环境下进行测试。一种可以把待测产品交给客户收集反馈意见的机制
- 特点：开发者通常不在现场
- 挑战：客户数量；客户充分了解产品
符合性的认证、标准和测试
产品需要通过主流硬件、操作系统、数据库和其他基础设施构件上进行的验证，并符合相关法规和行规
主流基础设施：操作系统、硬件、数据库…
约定和法律要求：质量行业标准、法规、技术领域标准
非功能测试
非功能测试用于验证系统的质量因素。非功能测试要求理解产品行为、设计和体系结构；针对不同配置和资源对产品进行测试，并收集和分析相应数据。评判产品的质量。
最大挑战：设置配置
原因：
- 难以预测客户使用的环境
- 对配置进行组合测试的代价太高
- 建立测试环境成本高
- 很难准确预测客户使用的数据
设置配置的两种方法
模拟环境和真实客户环境
可伸缩性测试/容量测试
系统的接受或容纳能力，也可以指某项功能的最大承受能力
目标：确认产品参数的最大值，确定产品的主要瓶颈
测试方法：
- 设计和体系结构会提出理论值，客户会提出期望的最大能力值
- 首先验证二者较低的参数；若设计不满足合理的客户期望值，直接返工；否则逐步更改参数直到最大能力
测试失效：系统不能响应或者系统崩溃
失效改正：
- 对容量缺陷的改正可能会对产品的其他非功能特性产生影响
- 不能在牺牲其他质量因素的前提下获得容量的改进
- 测试失效可能意味着产品策划不够，对产品行为也不够了解，需要寻求其他技术方案以提高系统容量
测试注意点：此类测试需要大量资源并且开销大
可靠性测试
在一定时间段内持续不断地测试软件产品，评价该产品在规定时间和条件下，维持其正常的功能操作、性能水平的程度
应用领域：银行交易系统、铁路交通管制系统、导弹防御系统
测试目标：评价产品在给定条件下在给定时间段内或很多轮迭代内，执行所要求功能的能力
测试失效：由于重复执行某些操作而引起错误，如：内存泄漏(典型)、系统无响应
可恢复性：系统快速从错误状态中恢复到正常状态的能力或时间
容错性：对外界错误(如误操作)隔离的能力
可靠性指标：
- 平均失效等待时间：连续失效之间的平均间隔时间
- 失效率(风险参数)：单位时间内发生的失效次数
- 平均发现下k个缺陷的时间：预测下k个缺陷的平均时间
经可靠性测试产品特征：
- 重复执行事务操作没有或极少有错误
- 零宕机
- 资源的优化使用
- 具有一致的性能和时间响应
- 重复执行事务操作没有副作用
负载测试
负载：并发用户数、上载文件大小、数据库的记录数
负载测试：通过模拟实际软件系统所承受的负载条件、改变系统负载大小和负载方式来发现系统中所存在的问题。
负载测试 vs. 容量测试
- 负载测试通过改变系统负载方式、增加负载等来发现系统的性能问题
- 容量测试是在预先定义(或分析)的极限值下，看系统是否能正常工作。考虑到预期业务处理量的增加，容量测试还将确定测试对象在给定时间内能够持续处理的最大负载
压力测试
压力来自于系统的极端情况
不足的内存、有限的网络带宽、磁盘读写被占用
目的：
- 评价系统超过所描述的需求或资源限制时的情况，保证系统不崩溃
- 有助于了解系统在极端和现实环境中的行为，期望随着负载增加产品性能平稳下降，但任何时刻都不应该崩溃
压力测试方法
- 负载通过各种方式逐步增加，产品会达到一个压力点，此时有些事务会因为资源不可用而失效，超过这个压力点失效率会增加
- 略微降低负载至压力点以下，观察产品是否能恢复到正常状态，失效率是否降低
- 升降负载2-3次，观察产品行为是否与预期一致
- MTTR(平均恢复时间)：由失效恢复的平均时间
用例选择
- 重复性测试用例：如反复执行的操作
- 并发性测试用例：如多用户并发操作
- 负载量级要对系统形成压力
- 随机变化的输入和量级以对系统产生压力
可发现的典型缺陷：内存泄漏、死锁等并发和同步问题
压力测试可以看作负载测试的一种，压力测试更强调持续加压，测试系统极限值
性能测试
为了获取或验证系统性能指标而进行的测试
性能测试评价响应时间、吞吐率和系统的使用情况，执行所要求的功能以对同一产品的不同版本或不同的竞争产品进行比较
实现有明确的性能指标，在严格的测试环境和所定义的负载下进行，获得不同负载情况下的性能指标数据
性能测试可使用负载测试的技术和工具
确认测试
概念理解
定义：检查产品是否满足在项目的需求阶段定义的确认准则，或者说是否具备在真实环境中使用的条件
引入时机：系统测试之后
测试用例：数量较少，目的也不是为了发现缺陷
测试环境：近似实际场景下执行
实施者⭐
客户或客户代表
目的
验证和接受产品
回归测试基础
概念
回归测试是对之前已测试过、经过修改的程序进行的重新测试，以保证该修改没有引入新的错误或者由于更改而发现之前未发现的错误
回归测试要保证增强型或改正型修改使软件正常进行并且不影响已有的功能
组测试
波及效应⭐
波及效应是为了发现所有受影响部分和发现潜在的受影响部分，以保证软件发生改变后仍然保持一致性与完整性
四种波及效应
- 需求的波及效应
- 设计的波及效应
- 代码的波及效应
- 测试用例的波及效应
分析步骤
两种识别技术
- 字符串匹配或交叉引用
- 程序切片