东南大学《软件测试》课程复习笔记

2020-05-27
惊闻这两天就要安排线上考试，抓紧把之前剩了个尾巴的复习笔记完成了，希望可以取得还OK的成绩。

整理了一下2019-2020学年计算机学院大三下《软件测试》课程的内容，仅供参考。

by z0gSh1u

导论 / Chapter 1

大型软件开发中经常遇到巴别塔和焦油坑（极度混乱、复杂的情况）

什么是错误（error）：1+2=5；死机、崩溃…

为什么有错误：Everything & Everyone。软件测试就是为了发现错误以便解决错误。

软件测试过程图

正确的测试策略：尽可能经常测试，并且尽早测试。缺陷发现的越晚，消除的代价就越大。

经典测试理论 / Chapter 2

测试的V模型

提出的四大测试过程：单元测试、集成测试、系统测试、验收测试

扫描二维码关注公众号，回复： 11280699 查看本文章

问题：错误引入的越早，发现的却越晚。

单元测试

对最小可测试元素（函数、类）进行测试。

模块接口测试：检查进出模块的数据是否正确
模块局部数据结构测试：未使用的变量、数组越界…
模块边界条件测试：合法数据、非法数据…
模块独立执行通路测试：计算错误、判定错误、控制流错误
模块内部错误处理测试：错误处理设施是否有效

集成测试

对单元进行集成后测试。测试对象可以是一个包或一组包。

进行集成的方法

增式

A → AB → ABC

特点：工作量小；发现错误早；错误定位容易；测试彻底；需要机器多；并行性差
- 自顶向下
  
  高级模块作为驱动，每次替换掉一个低级的stub（桩，临时占位的模块），逐步求精。
  
  缺点：需要提供stub；stub模块可能难以模拟数据
- 自底向上
  
  要编制驱动程序，协调测试用例输入输出。生成测试数据没有困难，适合关键模块在底部的情况。
  
  缺点：不能尽快看到整个程序的框架；时序和资源竞争问题只能到后期发现
非增式

特点：工作量大；发现错误晚；错误定位难；测试不彻底；需要机器少；并行性好

A → B → C → ABC

系统测试

对系统“整体”进行测试，模拟真实运行环境。

验收测试

最后一道工序，用户在场测试，非开发人员和测试人员完成。

α测试（内测）

开发即将完成时进行，可以对程序作小的变动。测试环境受开发方控制，用户的数量少，时间集中。
β测试（公测）

开发基本完成时进行，正式发布前寻找错误。测试环境不受开发方控制，用户的数量多，时间不集中。

测试任务的过程

测试计划

测试目标

单元测试的目标是检查最小单元有无错误；集成测试的目标是检查模块有无错误…
测试范围（回答“哪些“的问题）

哪些接口需要测试？哪些要做性能测试？
测试项目

功能测试；数据库集成测试…
测试策略

基于代码覆盖；基于规格说明…
测试工具
测试资源
产出物件

测试设计

设计测试用例
设计测试脚本
评估测试覆盖

开发

搭建测试环境
编写测试脚本

执行

执行测试脚本
分析执行情况
Bug报告 / Bug跟踪

评估

分析覆盖率（测试用例覆盖、代码覆盖）
分析缺陷
是否达到退出标准
撰写报告

测试方法

静态方法和动态方法
- 静态分析：检查和阅读
- 动态方法：运行测试用例
黑盒测试与白盒测试
- 黑盒测试：不考虑程序内部
- 白盒测试：分析程序的内部结构
回归测试

检查修改或增加的部分是正确的，并且没有造成其他错误
模拟用户操作

测试类型

可靠性测试
功能测试
性能测试
……

测试工具

测试管理工具：Quality Center
性能测试工具：Load Runner
单元测试工具：JUnit

黑盒测试 / Chapter 3

将程序当作黑盒，进行总体功能验证。

特点：基于规格说明（需求），与代码实现无关，以用户视角进行，适用于测试的各个阶段。

实施工具：需求规格说明；需求跟踪矩阵RTM；测试执行数据

实施策略：正面（预期输入输出）和负面（非预期输入）测试用例

等价类划分

将程序的输入域划分为有效等价类（有效输入数据）和无效等价类（无效输入数据），来导出测试用例。

划分准则

下表描述了一些输入数据类型的等价类划分思想：

例子：

合法的用户名要求：
（1）由字母开头；（2）后跟字母或数字的任意组合构成；（3）有效字符数不超过6个

2个有效等价类：
（1）{0<全字母<=6}：John, Kenedy
（2）{0<字母开头+数字<=6}：u001, user01

4个无效等价类：
（1）字母串，且长度超过6：userabcd
（2）字母开头的字符、数字组合串，且长度超过6：user01587
（3）长度不超过6的数字开头串：010ah
（4）其他：数字开头的字符串集合、空字符串、非法字符串

因果图（判定表）

多个输入条件互相关联、存在逻辑关系时，组合测试可能生成大量无效的测试用例。

因果的四种关系

四种输入约束，一种输出约束

输入：

互斥：最多只有一个成立
包含：至少一个成立
唯一：有且只有一个成立
要求：有向，C1成立则C2成立

输出：

屏蔽：有向，E1成立则E2不成立

根据因果图，可以快速排除一些不可能的输入，和一些不可能的输入输出组合。

边界值分析

利用并扩展了缺陷更容易出现在边界处的概念。

等价类划分时，往往先要确定边界值。边界值分析是等价类划分方法的补充，测试中需要将两者结合起来使用。

Paul Jorgensen公式

n为存在边界值的参数个数。

4n+1：基本边界测试

每个参数取min、min+1、max、max-1各一次，其他参数取典型值；最后全部参数取典型值
6n+1：健壮性边界测试

每个参数取min、min±1、max、max±1各一次，其他参数取典型值；最后全部参数取典型值
3m：条件边界测试

每个条件取自身、±1各一次

白盒测试 / Chapter 4

白盒测试就是结构化测试。两个特点：

基于代码
尽可能覆盖实现的行为

概论

静态白盒测试

不执行软件，审查软件设计、体系结构和代码。

特点：

可发现某些机器发现不了的错误
利用不同人对代码的不同观点
节约计算机资源，但以增加人工成本为代价

动态白盒测试

提供源代码和可执行程序，测试过程需要在计算机上执行程序。

优点：

能检测代码中的判断和路径
对代码的测试比较彻底

缺点：

无法检测不可达路径
不能验证需求规格

覆盖准则

我们不可能进行穷举测试，覆盖准则回答了“测试执行到何时才是足够”的问题。

基于控制流的动态白盒测试方法

语句覆盖

测试用例能使得每个可执行语句都至少执行一次。

例子：

问题：

100%的语句覆盖很困难，可能存在不可达代码
可能无法发现一些严重问题

判定覆盖

测试用例使得被测程序的每个判定分支至少经过一次（即真假至少取一次）。

特点：

判定覆盖包含了语句覆盖，并避免了遗漏边的问题
不能发现条件表达式中的错误

条件覆盖

保证每个判断中的每个原子条件的可能取值（不是每种组合）至少满足一次。

例：if A and B then Action1

则（1）A=true，B=true（2）A=false，B=false 两个用例即满足要求

条件覆盖不能保证程序所有分支都被执行。

条件组合覆盖

保证每个条件的取值组合至少出现一次。问题是代价昂贵（2^n）。

某些条件组合是不可能的（如F OR F = F）。

判定条件覆盖

每个条件的所有可能取值至少一次（条件覆盖），每个判断本身所有可能结果也至少一次（判定覆盖）。

路径覆盖

保证每条可能执行到的路径都至少经过一次。

优点：相对彻底；缺点：路径数可能指数级增加（2^n，n是分支次数）；可能存在不可达路径

基本路径测试

寻找基本路径，保证每条路径至少执行一次。

从流程图到流图

流图：描述程序中的逻辑控制流（顺序结点可以合并）
寻找基本路径

基本路径：贯穿程序的、至少引入一组新的处理语句或一个新判断的程序通道

例：

圈复杂度：度量基本路径数，也是所有语句被执行一次所需测试用例数的下限。高圈复杂度的模块蕴含错误的可能性最大，是测试中关注的焦点。

基本路径集合可能有多种，但基本路径数是确定的，等于圈复杂度。

寻找基本路径：
- 找到从入口到出口的最短路径
- 递归地改变该最短路径上所有判定结点的真假情况，生成新的路径
- 直到找到所有基本路径
产生测试用例

根据基本路径设计测试用例进行测试。

基本路径的本质

每一条路径可以表示成边的向量，Px=(e1, ..., en)（n为边数，元素为该边在路径中的出现次数）。其他任何路径对应的向量，都可以用这些基本路径的向量线性组合得到。这说明只要基本路径测试正确，则其他逻辑也测试正确。

循环的处理

简单循环

跳过；执行一次；执行两次；执行m次；执行n-1、n、n+1次（n为循环次数，m<n）
嵌套循环
- 先测试最内层循环，此时外层的循环变量取最小值，内层按简单循环测试
- 从内往外测试上层循环，更外层的取最小值，更内层的取典型值，该层按简单循环测试
- 最后全体按同时取最小或最大循环次数测试
串接循环
- 串接互相独立：分别用简单循环方法测试
- 串接不独立（第一个循环变量与第二个循环控制相关）：把第一个看作外循环，第二个看作内循环，按嵌套循环测试
非结构循环

需要先进行结构化。可以使用重复编码法、状态变量法、判定转移法。

基于数据流的动态白盒测试方法

根据程序中变量定义和其后变量使用的位置来选择程序的测试路径。

一些定义：

P：程序
G(P)：程序流图
V：变量集合
PATH(P)：P的所有路径集合
DEF(v, n)：变量v的定义节点是n
USE(v, n)：变量v的使用节点是n
- P-USE：谓词使用，即在条件判断语句中使用
- C-USE：运算使用，即在计算表达式中使用
- O-USE：输出使用
- L-USE：数组定位使用
- I-USE：循环迭代次数控制使用
DU-PATH：定义-使用路径，是PATH中的某条路径，以DEF起始，中间可有其他DEF，到USE终止
DC-PATH：定义-清除路径，DEF起始，中间没有其他DEF

测试过程

分析出DEF和USE节点，记DEF节点数为NDEF，USE节点数为NUSE
列出可能的DU-PATH（NDEF*NUSE条）
约简DU-PATH，对于相同前缀的，只保留最长的
针对每个剩下的DU-PATH设计测试用例

Q问题

面向路径的测试数据生成问题——是否存在一组输入，使得P中任意一条语句可被执行，在理论上是不可判定的。

解决方法：

随机法
静态法
- 符号执行：用符号值表示程序变量，然后模拟程序执行
- 区间算术：数值和变量都用区间表示，然后进行区间消减
迭代松弛法
遗传算法
模拟退火

面向对象软件测试 / Chapter 5

面向对象核心概念

对象（实例）：可操作性的实体
消息：对象之间通过消息传递来协作
接口：对象行为声明的集合
类：具有共性的对象的集合
封装
继承：类的依赖关系
多态：重载，动态绑定

OO软件测试概论

与传统测试的异同

单元测试时基于两个基本元素：METHOD和CLASS
系统测试与传统测试类似，仍然基于需求规约
集成测试是OO测试最复杂的部分

面向对象技术对软件测试的影响

类的使用

使得基本可测单元是类或对象，而不是子程序。在对每个类进行单元测试后还要对类簇进行测试。
封装的使用

信息隐藏使得对象的一部分不可访问，减轻了波动影响。但测试时经常需要访问对象的内部状态，信息隐藏给这带来了难度。

修改时需要大量的回归测试。
继承的使用

要确定衍类中从基类继承的已测试的功能是否需要再测试。
多态和动态绑定的使用

引入了不可判定问题：难以确定该用例使得哪个多态方法被激活；多态组件的每个可能的绑定都需要独立测试，而实际上又难以找到所有的绑定。

状态的控制分布在整个系统中，使得难以对每个状态进行单一的测试。
抽象的使用

要执行内部的结构测试时，降低了软件的可测试性。

OO软件测试

OO软件的开发过程

采用迭代式增量开发过程模型，每次迭代包含OOA（分析）、OOD（设计）、OOP（编程）三个阶段。

面向对象测试模型（OOTM）

在整个软件开发生命周期全过程中不断测试。

OOA Test、OOD Test

测试分析和设计的结果，由建模专家、领域专家、软件专家参与
OOP Test

针对编程风格和程序代码进行测试，采取单元测试、集成测试等手段
OO Unit Test

对具体单一的功能模块的测试（类）
OO Integrate Test

对系统内部的相互服务进行测试（函数间、类间合作）
OO System Test

最后阶段的测试，主要以用户需求为测试标准

面向对象单元测试（OO Unit Test）

面向对象的单元测试，实际就是对类的测试。

基于服务的类测试策略

考察类中的方法对数据的操作。

为了避免软件测试的盲目性，Kung提出了块分支图法（BBD）

一个方法f的BBD是一个五元组(修改前的类Du, 修改后的类Dd, 参数表P, 调用的服务Fe, 控制结构图G)：

构造BBD图后可对程序的流程进行抽象进行测试：
- 绘制服务的控制流图
- 确定基本路径集（每个可执行语句至少一次）
- 生成测试用例
基于状态的类测试策略

从外界向对象发送特定消息序列，来测试对象的响应状态。利用对象状态图（OSD）模型来测试：

OSD描述了对象在其生命周期中的所有状态及其状态之间的相互转移。构造过程如下：
- 扫描源程序，得出执行分析表
- 确定对象状态
- 构造状态转移
- 构造测试消息序列
- 生成测试用例（根据每条测试消息序列，选择相应的数据进行测试）

面向对象的集成测试（OO Integrate Test）

由于程序的控制流无法确定，只能对编译完成的程序做基于黑盒的集成测试。要参考OOD的结果。

静态测试

得出源程序的类系统图和函数功能调用关系图，检测程序结构是否符合设计要求（OOP是否符合OOD要求）
动态测试

根据静态测试得出的图表，设计测试用例，达到一定的覆盖标准

设计测试用例的方法：
- 确定类的状态和行为
- 确定待测类的所有关联
- 根据类的对象构造测试用例，使用一定的输入激发某种状态，也要设计类禁止的负例

面向对象的系统测试（OO System Test）

测试软件与系统其他部分配套运行的表现。要参考的OOA的结果。

主要测试内容：

功能测试；强度测试；性能测试；安全测试；恢复测试；可用性测试；安装/卸载测试

性能测试 / Chapter 6

引言

性能需求是一种非功能性需求。

性能测试是模拟正常、峰值、异常负载条件下，测量系统的性能指标能否达到需求，以找出瓶颈，优化系统。

性能测试的步骤

熟悉应用：以知道需要模拟什么
测试需求：可能需要进行指标的转换（UV如何转换成吞吐量、响应时间指标）
测试准备
- 机器数量
- 网络环境：带宽应高于服务器吞吐量，避免出现瓶颈
- 测试数据准备：用户注册、数据量
- 测试用例设计
- 测试脚本准备
测试执行：监控客户端和服务器性能，后续归档处理
测试结果分析：内存问题、共享资源竞争问题

性能测试的指标

响应时间

网络传输时间+应用服务器处理时间+数据库处理时间
并发用户数
吞吐量
- 业务视角：请求数/秒、页面数/秒…
- 网络视角：字节/秒
资源利用率（内存、磁盘、处理器、网络）

实际使用/总量

性能测试的方法

基准测试

制定一个性能基准测试标准。系统变化之后，进行一次相同标准的测试，即可看出变化对性能的影响
负载测试

找出负载逐渐增加时系统性能指标的变化情况，找出系统的负载极限
压力测试

找出高负载系统下的问题，如资源竞争、同步问题、内存泄漏
容量测试

找出能正常运行的最大负载或工作量
失效恢复测试

局部发生故障，能多大程度上继续使用系统
并发测试
……

例子 - 压力测试

安全测试 / Chapter 7

引论

基本概念

safety安全可靠：软件在运行过程中不到达某个不安全的状态
security安全保密：软件不会被黑客攻击
vulnerability漏洞：系统设计、实现或操作和管理中存在的缺陷或弱点

为什么要关注软件安全

黑客攻击机会越来越多，越来越容易
漏洞利用速度越来越快
病毒的种类和感染的机会越来越多

软件安全问题

安全问题	例子
内存安全	缓冲区溢出问题可能导致攻击者控制内存空间，执行恶意代码
进程/线程安全	线程同步问题、线程协作问题、线程死锁问题、线程控制问题…
异常/错误处理	异常捕获安全、异常处理安全…
输入安全	不要信任用户的任何输入…
国际化安全	字符集转换安全
面向对象安全	对象的内存分配与释放、序列化安全…
Web安全	XSS攻击、SQL注入…
访问控制不当	特权提升问题…
远程调用安全	恶意调用RPC服务器中的过程…
拒绝服务攻击	DoS、DDoS…
数据加密保护	加密算法不良、密码保存不安全…
代码注入	DLL注入…

产生的原因：观念不足；软件设计不好；编码错误；测试不到位…

解决之道

先验方法

让每个人都参与进来

软件安全观念教育；同步行业安全问题
主动的安全开发过程
- 攻击面最小化：尽量减少暴露给用户的可受攻击的地方
- 威胁建模：对最可能影响系统的威胁进行系统的识别和评估

后验方法

软件安全测试

一般测试以发现BUG为目标，安全测试以发现安全隐患为目标。
渗透测试

通过模拟恶意黑客的攻击方法，来评估计算机网络系统安全。

回归测试 / Chapter 8

在软件日常维护、迭代更新中，需要对变化的部分加以测试。回归测试就是仅对修改的部分进行测试，并且保持原有测试覆盖的方法。

引言

过程步骤

提出修改需求
修改软件制品（artifact）
选择测试用例，执行测试
识别失败结果
确认错误，排除错误

策略

全部重测

优点：不用花精力选择测试用例；缺点：耗时较长，可能产生浪费
有选择的重测

优点：适合小部分的修改；缺点：需要选择测试用例

开销

两种测试用例
- T1：为了测试改变的代码的新测试用例
- T2：原有测试用例要进行有效性重确认
提高效率的实用性建议
- 使用工具
- 考虑依赖性（模块依赖、修改依赖）

波及效应分析（REA）

因为软件工件间的依赖性，所以需要REA来发现被影响到的部分。

波及效应分析的两种方法

字符串匹配或交叉应用
程序切片

波及效应的分类

直接波及
诱发波及

如果直接波及后不需要进一步的更改，那么诱发波及就不需要分析。