7.3多模块的软件测试

D2
s5
模块群1
模块群2
模块群3
自底向上集成的特点 优：
不用桩模块，测试用例的设计相对简单
缺点：
程序最后一个模块加入时才具有整体的形象
3)混合式集成策略（三明治法）
A B E F C D G
测E 测F 测B 测B/E/F 测ABCEDF
测D 测G
测A
Байду номын сангаас
测DG
两头向中间逼近 特点
并行度高/适于大型项目
华北电力大学计算机系软件教研室
7.3 多模块的软件测试
目录
7.3.0 软件测试策略及层次性 7.3.1单元测试 7.3.2集成测试 7.3.3 确认测试 7.3.4 系统测试
7.3.0软件测试策略及层次性
1）软件测试策略
如何把设计测试用例的技术组织成一个系统的有计划的测试步骤 从模块开始，一级级向外扩展，直至正个系统测试完毕
DB 客户端
驱动模块 客户端
数据传输模块
服务器端 桩模块
设计驱动程序和桩程序测试该单元
编写一个模块模拟DB提供数据，和接收需复制的数据(即是driver又是stub) 能随机产生可设置大小的数据包、按设置好的时间间隔发送数据包 同时也是接受端，能对接受到的数据包数量、大小进行统计
设计用例
(1) (2) (3)
M1 s3 s4 M2 S2 s5 s6 M5 M8
M1 s3 s4
(4)
M1 M2 S2 s5 M5 s3 s4 M2 S2 s5 M5
M1 M3 s4 M2 S2 s5 M5
M1 M3 M4 s7 M2 S2 s5 M5 M8
(8)
M1
M3 M4 M7
M6
M6
M6
M6
M8
(5)
2)测试的层次性——多模块步骤
软件需求
模块 单元测试 设计信息 已集成的 软件 集 成 测 试 确认 测试 已确认的 软件 a测试 β测试
系统其他元素
可运行的 系统 系 统 测 试
模块
单元测试 模块 单元测试
测试报告
测试报告
测试的步骤
1 单元测试(模块测试)
测试每个模块（模块内的算法、接口）,每个模块运行正确
驱动模块： 接收测试数据，并将其传到被测模块 并打印结果
例 单元测试之黑盒测试
测试一个大型网络服务系统(负责多个DB的数据复制)，
分为服务器端、客户端、数据传输部分 服务系统是实时的，开发人员完成数据传输模块(尚未编写数据库相关模块) 对数据传输模块的性能进行测试
DB 客户端
备份数据服务器
1.深度优先 M1-M2-M5-M8-M6-M3-M4-M7
M1 M2 M5 M6 M3 M4 M7
2.广度优先 M1-M3-M4-M5-M6-M7-M8 M1 M2 S2 M3 s3 M4 s4 M7 s7
M8
M5 s5 M6 s6
M8 s8
附：深度优先集成分解图
M1 S2 s3 s4 M2 s5 s6 M1 s3 s4 M2 S2 M5 s6 s8
原因：


误差累计
•单个模块内部可以允许的误差，组装后的累计误差可能无法容忍
解决——集成测试
1. 选择集成测试策略 2. 设计测试用例(黑盒)——接口关系、全局数据、模块调用序列 3. 进行测试和回归测试
2)集成测试策略
非渐增式集成测试 渐增式集成测试
1)非渐增式集成测试(大棒法)
(Non-Increment Integration)
Prurify 内存和资源检查 Quantify 性能瓶颈检查 PureCoverage 代码覆盖测试
7.3.2 集成测试
集成测试概述 集成测试的策略 回归测试
1）集成测试概述
问题：
每个模块都能单独工作，而这些模块集成到一起却不能单独 工作？
接口
1.数据经过接口的时候会丢失 2.一个模块可能会对另一个模块造成不应有的影响 3.几个子功能累计起来不等于主功能
测C
测AC
对上层模块——自顶向下 对关键模块或子系统——自底向上
3)回归测试(Regression Testing)
再来一次——把做过的测试再做一遍 背景：
发现软件有bug，修改后——打Patch
•bug被修改了么？ •原有的正常功能依旧正常么？
版本升级（新增功能）
•新的功能是否达到了要求呢
2 集成测试：
把通过单元测试的模块逐步组装起来，从一个单元开始，逐一增加新单 元，边加边纠错，直至最终将所有单元集成为一个系统 •测试软件的总体结构，主要是模块中的接口、 •参照概要设计
3 确认测试
组装后的软件是否满足用户的全部需求
4 系统测试
当被测软件安装到系统以后，与系统中的软、硬件系统、人员能否协调 工作
数据引用错误 使用未赋值变量，或变量从未使用
数据说明错误
数据计算错误 数据比较错误 控制流程错误 多余结构 I/O错误
未定义变量就用，或变量类型与初始值不符
除0 做比较的变量间类型不匹配 循环次数多/少一次，死循环等 不可达代码 忘记Open或Close文件，I/O错误等
D）单元测试所需编制的测试软件
背景：单元(模块)不是独立的程序，可能调用其他模块或被其他模块 调用
需为被测模块编制若干测试软件，为它的上、下级模块做替身
上级模块 驱动模块
界面 局部数据结构 边界条件 独立路径 错误处理路径
被测模块
下级模块 桩模块
下级模块 桩模块
测试用例
桩模块： 代替被测模块的下级模块 内部只做少量数据处理
回归测试：为了验证修改(修改bug、升级、新增)的正确性，及 其影响(对原有功能)而进行的测试
回归测试的选择方法
X
再测全部测试用例
太费时，没必要
基于风险选择测试 基于操作剖面选择测试
运行关键的、最可疑的测试 80/20原则，选最常用或最频繁使用 的功能测试 将回归测试局限在被修改的模块及接口
返回
1)模块接口测试
输入、输出参数
形、实参的个数、类型等是否一致
若模块内包括外部的输入、输出，还应考虑
文件的属性是否正确？ Open/close语句是否正确？ 文件使用前是否已经成功打开？ 缓冲区大小与记录长度是否匹配？ 是否处理了文件尾EOF？ 是否处理的输入/出错误？
2)检查局部数据结构
(increment integration) 逐一增加模块，每并入一个模块，进行一次测试， 程序范围不断扩大，同时增加回归测试 测试策略
自顶向下集成 自底向上集成 混合式集成
a)自顶向下集成
从主控模块开始，沿被测程序的结构图逐步向下测试， 要使用桩模块 每次只能替代一个桩模块 移动路线分为
局部数据结构——往往是错误的根源
不适合/不相容的数据类型说明 变量无初值、初始化或缺省值有错 变量名有错（大小写、错拼） 越界和地址异常
全局数据对模块的影响
3）模块中所有独立执行通路的测试
使用
基本路径测试 循环测试
重点检查
不同数据类型的对象间的比较 逻辑运算符或优先级使用错误 比较运算或变量出错 循环终止条件或不可能出现 迭代发散或不能退出 错误地修改了循环变量
M8
(6)
M8
(7)
自顶向下集成的特点：
优：
能尽早的对程序的主要控制&决策进行检验
缺：
需要大量的桩模块 测试较高层次时，底层的桩模块替身不能反应真实 的情况
2）自底向上集成测试
从底层的“原子模块”开始组装测试无需桩模块 步骤：
1. 把低层模块按功能组织成模块群 2. 为每个模块群开发一个测试驱动模块Di ，控制测试 数据的输入输出 3. 对每个模块群进行测试 4. 删除Di，用较高层模块组成更大功能的新模块群
回归测试——把以前做过的又重做了几次
•刀耕火种么？ •有现代化的装备？
测试自动化——让测试程序自动运行
自动配置、 测试用例的管理、自动输入 测试信息与结果的自动采集 测试结果的比较结论
1）简单的测试——捕获回放工具：
winRuner、QARun、VisualTest、Rational RFT
2）复杂测试——使用脚本语言编制测试脚本
如TCL、Pathon、Perl、GCC
7.3.3 确认测试
研发单位在开发组内实施的最后一项开发活动 1. 有效性测试(黑盒测试) 2. 配置复审
程序的文档是否配齐？ 文档的内容是否一致？ α测试：软件开发公司内部人员 模拟各类用户对 即将面世的软件产品进行测试——α版 β测试：小规模发行，典型的用户在日常生活中 实际使用β版
根据指标考虑数据包的大小、频率(大包低发、小包频发) 考虑两个驱动程序的数据对发 从两个driver多个driver对发 从一个网段多个网段，验证proxy或网关的影响
驱动模块 驱动模块 驱动模块 数据传输模块
桩模块 桩模块 桩模块
e)单元测试工具
Junit Visual Unit，简称VU Rational
A B E F C D G
一步到位 先分别测每个模块，然后 把所有的模块一次集成
测试过程如下：
A S1 S2 S3 S1 D1 B S2 D1 C D1 D S1 D1 E D1 F D1 G E B F
A
C D G
优：迅速完成集成测试、简单 缺：难以定位错误&纠正错误
2)渐增式集成测试
自底向上集成例：
从底层的“原子模块”开始组装测 试无需桩模块 步骤： 1. 把低层模块按功能组织成 模块群 2. 为每个模块群开发一个测 试驱动 模块Di ，控制测试 数据的输入输出 3. 对每个模块群进行测试 4. 删除Di，用较高层模块组 成更大功能的新模块群
Mc
Dc Ma
Db Mb Mb
D1 s5
αβ测试
7.3.4 系统测试
1)压力测试(Stress Testing) 2)性能测试(Performance testing) 3)容量测试(Volumn Testing) 4)安全测试(Security test) 5）web测试 6）基于数据库应用服务器的测试
1）压力测试(Stress Testing)
4）错误处理通路
目标：
一个好的设计应该能预见各种出错条件，并预设各种出错处 理通路
重点检查
输出的错误信息难以理解 记录的错误与实际遇到的错误不相符 在程序自定义的出错处理段运行之前，系统已介入 异常处理不当 错误提示中未能提供足够的定位出错信息
c)单元测试的步骤
编译 静态分析器检查 代码评审 动态测试 语法错误 人工 功能性错误 结构错误
7.3.1单元测试
单元测试发作的错误约占程序总错误的65%
对象： 模块 承担者： 代码员、测试人员 测试方法：白盒为主、黑盒为辅
A）目的：
对模块进行静态、动态测试，使之达到模块说明书的要求
B）单元测试任务：
模块接口 局部数据结构 模块中所有独立执行通路 错误处理通路 边界条件
C) 单元测试的步骤 D）单元测试所需编制的测试软件
2)性能测试(Performance testing)
目标：
什么压力下，系统达到最佳状况，什么压力是系统的 极限？
定义：通过测试确定系统运行时的性能表现(常同 压力测试一起进行)
运行速度 响应时间 资源占有(CPU、内存)
例：基于B/S的网络实时培训系统 (HTTP连接)
借用测试工具完成——最大的在线人数？你能忍 受的页面打开时间？ 测试要点：在各种情况下Server的
√ √
局限在修改范围内测试
在受影响的功能模块内回归
凭以往经验分析当前修改影响到哪些 功能 对修改范围内的——100%重测 其他范围内—— 60%重测
根据一定覆盖率指标选择（影响 范围难以界定的）
一句总结回归测试
没必要全部重测、改哪里测哪里、测重点、关键、常用 的地方
回归测试的自动化
背景：
也称为强度测试、负载测试
反思：铁道部12306购票网站的例子 从1月1日到1月9日，“12306”订票网站日均点击次数已经超过了10亿次， 网站瞬间访问量可能达到“世界第一”。
定义：测试在短时间峰值状态、超负荷情况下
被测系统的性能、可靠性以及稳定性等 ——我们能把系统折腾到什么程度而不会崩溃！ ——系统所能承受的最大限度 方法： 可重复的负荷实验(反常数量、频率或资源下执行) 例如： 成千上万的用户同一时间接入Intenet——网络带宽 正常时，单服务器有100个并发用户，峰值时达到500个并发，峰值的1.5~2 倍作为压力测试数据——找到最大在线用户数 正常每秒期望1~2个中断，压力测试：运行每秒10个中断 定量增长数据输入率，检查对数据处理的反应能力 键盘输入（120单词/秒、测500单词/秒）