软件测试课件第2章测试的流程

观察和解释测试输出往往也是困 难的
由于驱动模块模拟了所有 调用参数，即使数据流并 未构成有向的非环状图， 生成测试数据也没有困难
特别适合于关键模块在结 构图底部的情况
直到最后一个模块被加进去之后 才能看到整个程序（系统）的框 架
只有到测试过程的后期才能发现 时序问题和资源竞争问题
系统测试 ---确认测试
安全性测试
检验在系统中已经存在的系统安 全性、保密性措施是否发挥作用， 有无漏洞。
可使用性测试
主要从使用的合理性和方便性等角 度对软件系统进行检查，发现人为因素或使 用上的问题。 用户界面便于使用，对输入量可容错、响应 时间和响应方式合理可行、输出信息有意义、 正确并前后一致；出错信息能够引导用户去 解决问题；软件文档全面、正规、确切。
判定／条件覆盖：同时考虑条件的组合值及判定结果的检验； 路径覆盖：只考虑对程序路径的全面检验。
黑盒测试与白盒测试的比较
测试规划
特
优点
点
缺点
方法举例
黑盒测试 根据用户的规格说明，即针对命 令、信息、报表等用户界面及体 现它们的输入数据与输出数据之 间的对应关系，特别是针对功能 进行测试。 能站在用户立场上进行测试。
改错性回归测试 增量性回归测试
回归测试方法
Retest ALL Selected Retest Stratery
模拟用户操作测试方法
基于对用户如何使用被测试软件的了解来 开发测试的方法。
经验表明，复杂的软件产品可能有许多错 误，但用户一般只能找出这些错误中很少 的一部分。
为给用户带来最大利益，要着重对那些用 户可能发现的错误进行测试和修改工作。
语句覆盖 判定覆盖 条件覆盖 判定/条件覆盖 基本路径覆盖 循环覆盖 模块接口测试
黑盒测试与白盒测试发现的错误
回归测试
Myers：修改一个现有程序比编写一个新程序更 容易出错。
目标：① 修改的或增加的部分是正确的 ② 没有引起其他部分产生错误
应用：①增量开发 ②版本控制 ③软件维护
回归测试类型
▪ β测试是由软件的多个用户在实际使用 环境下进行的测试。这些用户返回有关 错误信息给开发者。
强度测试
检查在系统运行环境不正常乃至发生 故障的情况下，系统可以运行到何种程 度的测试。例如：
把输入数据速率提高一个数量级，确定输 入功能将如何响应。
设计需要占用最大存储量或其它资源的测 试用例进行测试。
2.2 测试步骤
单元测试 集成测试 系统测试
单元测试
目的：分别完成每个单元的测试任务，以确保每个模块 能正常工作。
单元测试
单元测试在迭代的早期实施，侧重于核实软件的最小 可测试元素。单元测试通常应用于实施模型中的构件， 核实是否已覆盖控制流和数据流，以及构件是否可以按 照预期工作。
单元测试的考虑
第二章 软件测试的策略
测试的设计
测试过程设计 测试类型设计 测试数据设计
测试的管理
流程管理 数据管理
软件测试与软件工程模型
V模型介绍
需求
测试
验收测试
功能
测试
系统测试
设计
测试
集成测试
编码
测试 单元测试
2.1 测试方法 2.2 测试的步骤
2.1 测试方法
静态方法和动态方法 黑盒测试和白盒测试 回归测试方法 模拟用户操作测试方法 自动方法和手工方法
未使用过的变量； 不会执行到的代码； 未引用过的标号； 可疑的计算； 潜在的死循环。
静态分析的工作（3）
提供间接涉及程序缺陷的信息
每一类型语句出现的次数； 所用变量和常量的交叉引用表； 标识符的使用方式； 过程的调用层次； 违背编码规则。
黑盒测试
黑盒测试（Black—box Testing）又称功能测试、 数据驱动测试或基于规格说明的测试，是一种从用户 观点出发的测试。
静态分析的工作（1）
可能发现的程序缺陷
用错的局部变量和全程变量； 不匹配的参数； 不适当的循环嵌套和分支嵌套； 不适当的处理顺序； 无终止的死循环； 未定义的变量； 不允许的递归； 调用并不存在的子程序； 遗漏了标号或代码； 不适当的连接。
静态分析的工作（2）
找到潜伏着的问题根源
上述过程从第2步重复进行，直到整个系统结 构被集成完成。
自顶向下增式测试
自底向上增式测试
工作程序：
组装从最底层的模块开始，组合成一个 构件，用以完成指定的软件子功能
编制驱动程序，协调测试用例的输入与 输出
测试集成后的构件 按程序结构向上组装测试后的构件，同
时除掉驱动程序
自底向上增式测试
容； 硬件的配置是否合理。
兼容性测试
主要验证软件产品在不同版本之间的兼容性。
配置测试
检查计算机系统内各个设备或各种资源之间 的相互联结和功能分配中的错误。
容量测试
容量测试是要检验系统的能力最高能达到什么程 度。例如， 对于编译程序，让它处理特别长的源程序； 对于操作系统，让它的作业队列“满员”； 对于信息检索系统，让它使用频率达到最大。 在使系统的全部资源达到“满负荷”的情形下，测 试系统的承受能力。
算法和逻辑 模块接口 数据结构（全局和局部） 边界条件 独立的路径 错误处理
单元测试的辅助模块
驱动程序：用于模拟主程序的运行 桩模块：用于模拟子程序的运行
单元测试的过程
集成测试
为什么进行集成测试？
一个模块可能对另一个模块产生不利的影响 将子功能合成时不一定产生所期望的主功能 独立可接受的误差，在组装后可能会超过可接受的
printf ("A is %d\n",a); }
1）变量X的异常是由于在“if“的条件之 前未给x 赋初值引起的。 修正： 在原码中给x 赋初值。
2）变量Y的异常是在Y被赋初始值 0 后如 果是走 if 的真分支那么 Y 在没有被引用 的情况下就再次被赋了初值。这是由于使 用了不完整的 if 语句造成的。 修正： 用 if-then-else结构重写if语句。
两种集成测试方法的比较
优点
缺点
自顶 向下 测试
自底 向上 测试
可以自然地做到逐步求精， 需要提供桩模块
一开始便能让测试者看到 系统的框架
在输入/输出模块接入系统以前， 在桩模块中表示测试数据有一定
困难
由于桩模块不能模拟数据，如果 模块间的数据流不能构成有向的 非环状图，一些模块的测试数据 难于生成；
增式测试 ：把下一个要测试的模块同已经 测试好的模块结合起来进行测试，一次增加 一个测试的模块。
非增式测试
增式测试
增式测试把单元测试与集成测试结合起 来进行，将模块逐步集成起来，逐步完 成集成测试。 实施方法：
自顶向下结合 自底向上结合
两种集成方法的比较
非增式测试 增式测试
工作量
工作量大
安装测试
安装测试的目的不是找软件错误，而是找安 装错误。 安装软件系统时，会有多种选择。 要分配和装入文件与程序库 布置适用的硬件配置 进行程序的联结。
安装测试是在系统安装之后进行测试。 它要检验：
用户选择的一套任选方案是否相容； 系统的每一部分是否都齐全； 所有文件是否都已产生并确有所需要的内
工作量小
接口错误
发现错误较晚 发现错误早
错误定位
错误定位难 错误定位易
测试程度
测试不彻底 测试彻底
需要的机器量 需要机器量少 需要机器量多
测试的并行性 并行性好
并行性差
自顶向下增式测试
集成步骤： 主控模块作为测试驱动，所有与主控模块直 接相连的模块作为桩模块； 根据集成的方式（深度或广度），每次用一 个替换从属的桩模块； 在每个模块被集成时，都必须已经进行了单 元测试； 进行回归测试以确定集成新模块后没有引入 错误
数据
结果
白盒测试要求对某些程序的结构特性做到一定程 度的覆盖，或者说是“基于覆盖的测试” 。
最为常见的程序结构覆盖有：
语句覆盖：它要求被测程序的每一可执行语句在测试中尽可 能都检验过，这是最弱的逻辑覆盖准则；
分支覆盖或判定覆盖：要求程序中所有判定的分支尽可能得 到检验；
条件覆盖：当判定式中含有多个条件时，要求每个条件的取 值均得到检验；
误差限度 可能会发现单元测试中未发现的接口方面的错误 在单元测试中无法发现时序问题（实时系统） 在单元测试中无法发现资源竞争问题
集成测试的目的：在模块组装后查找模块间接口的错误
Байду номын сангаас成测试的方法
非增式测试：采用一步到位的方法来构造测 试：对所有模块进行个别的单元测试后，按 程序结构图将各模块联接起来，把联接后的 程序当作一个整体进行测试。
静态分析
void f1(int *p1, int p2, int p3) {
*p1 = p3 - p2; } main()
{ int a,x,y; printf ("Type in a value for a"); scanf ("%d",&a); printf ("\n"); y = 0; if (x != 0) { f1 (&y,a,x); }
＊功能测试 ＊强度测试 ＊可使用性测试 ＊资源使用测试 ＊兼容性测试 ＊可靠性测试
＊ α测试
＊ 容量测试 ＊ 安全测试 ＊ 性能测试 ＊ 配置测试 ＊ 安装测试 ＊ 回归测试
＊ β测试
α测试和β测试
▪ α测试是由一个用户在开发环境下进行 的测试，也可以是公司内部的用户在模 拟实际操作环境下进行的测试。
• 不能测试程序内部特定部位。 • 如果规格说明有误，则无法发 现。
基于图的测试 等价类划分 边值分析 比较测试
白盒测试 根据程序的内部结构，比如语句的 控制结构，模块间的控制结构以及 内部数据结构等进行测试。
能够对程序内部的特定部位进行覆 盖测试。 • 无法检验程序的外部特性。 • 无法对未实现规格说明的程序内 部欠缺部分进行测试。
静态方法和动态方法
静态方法的主要特征是在用计算机测试源程 序时，计算机并不真正运行被测试的程序， 只对被测程序进行特性分析。因此，静态方 法常称为“分析”，静态分析是对被测程序 进行特性分析的一些方法的总称。
动态方法的主要特征是计算机必须真正运行 被测试的程序，通过输入测试用例，对其运 行情况(输入/输出的对应关系)进行分析。
结果
白盒测试
白盒测试（White—box Testing）又称结构测试、逻辑 驱动测试或基于程序的测试。 它依赖于对程序细节的严密检验，针对特定条件设计测 试用例，对软件的逻辑路经进行测试。 在程序的不同点检验“程序的状态”以判定其实际情况 是否和预期的状态相一致。 软件的白盒测试用来分析程序的内部结构
被测程序被当作一个黑盒，不考虑程序内部结构和内 部特性，测试者只知道该程序输入和输出之间的关系 或程序的功能，依靠能够反映这一关系和程序功能的 需求规格说明书考虑确定测试用例和推断测试结果的 正确性。
软件的黑盒测试被用来证实软件功能的正确性和可操 作性。
数据
abcdef ghijklm nopqrs tuvw
设计出会对磁盘常驻内存的数据过度访问 的测试用例进行测试。
性能测试
检查系统是否满足在需求说明书中规定的 性能。特别是对于实时系统或嵌入式系统。 性能测试常常需要与强度测试结合起来进行， 并常常要求同时进行硬件和软件检测。 软件性能的检测：响应时间、吞吐量、辅助存储 区，例如缓冲区，工作区的大小等、处理精度， 等等。