软件测试课程总结

课程学习总结

第一部分：软件测试概述

1. 软件测试的背景：

随着高科技发展软件规模日益庞大，支撑各行业的核心业务，在运行各大软件的时候要保持程序运行的准确性，正确性，以免出差错导致不必要的损失。软件测试ST（Software
Testing）是软件质量管理中最直接和最实际的手段

2. 软件缺陷：

缺陷（Fault / Defect） ：是差错在程序中的表现（静态的）。

• 过错缺陷 （Wrong） ：未将规格说明书正确实现

• 遗漏缺陷 （Missing） ：规定的或者预期的需求没有体现在产品中

• 多余缺陷 （Extra ） ：规格说明书中未规定的需求被实现

错误（Error）
：当程序缺陷被执行时，所导致的非预期的程序内部状态（动态的）

失效（Failure） ：当错误传播到外部时，所导致的结果

满足一下规则可称为软件缺陷：

• 软件未实现产品说明书要求的功能；

• 软件出现了产品说明书指明不会出现的错误；

• 软件实现了产品说明书未提到的功能；

• 软件未实现产品说明书虽未明确提出但应该实现的目标；

• 软件难以理解，不易使用，运行缓慢或者–从测试员的角度看–最终用户会认为不好

缺陷产生原因：

• 软件的需求规格说明书（RS-Requirement Specification）

（1）没有写

（2）不够全面，准确，细致

（3）经常变更

• 软件的设计（Architecture）

（1）描述不够清楚

（2）框架的结合不够紧密和连贯

（3）软件框架经常变动，不稳定

• 代码错误

（1）编码人员的素质、技术水平

（2）上层的分析和设计造成的问题

软件的错误和缺陷越到最后会导致的问题就会越大，产生的损失同样的可能也会越来越多，如图1所示：

图1

软件测试员目标：尽可能早地找出软件缺陷、并确保其得以修复。（注意：修复缺陷并非一定要改正软件。可以是指在用户手册中增加一段注释或为用户提供特殊的p）

3. 软件错误：在软件开发的一系列阶段和步骤中,出现错误的时机很多:

• 软件需求的描述可能有错和不完善；

• 软件的设计可能有错；

• 软件的编码可能有错；

4. 软件测试的意义：

• 是保障软件质量和可靠性的重要手段。

• 是软件质量度量的重要依据。

其开销在软件开发过程总成本中占很大比例。

5. 软件测试的含义：是为了发现错误而执行程序的过程，广义上讲，在软件开发过程中的所有评审、确认、检验等活动都是软件测试。

6. 软件测试的目的：发现问题，对质量或可接受性做出判断；

7. 软件测试的对象：软件测试是不等同于程序测试，软件测试贯穿于软件定义和开发的整个期间。需求分析，概要设计，详细设计以及程序编码等各个阶段所得到的文档，包括需求规格说明书、概要设计规格说明，详细设计规格说明以及源程序，都是软件测试的对象。

8. 调试：

含义：测试是一种检验；调试是推理过程。

调试与测试对比：

• 测试是一种检验；调试是推理过程。

• 测试的结果常常表明一个程序员的失败；调试则是程序员证明其正确。

• 测试经常由非程序设计者完成；调试必须有程序员完成。

• 大多数测试在不了解设计细节的条件下完成；而调试必须了解程序的细节。

• 测试可以并应该计划、设计和制定工作日程表；调试的规程和持续的时间不受约束。

• 在能做什么和不能做什么方面，测试有一套完整的理论；而调试没有。

• 很多测试的设计和执行能够自动化；而调试则不行。

9. 软件测试的特征：

• 软件测试的风险性：彻底测试程序是不可能的

原因

– 输入量太大

– 输出结果太多

– 软件运行的路径太多

– 软件说明书没有客观标准

• 软件测试的不修复原则：并非所有软件缺陷都需要修复

原因：

• 没有足够的时间

• 不算真正的软件缺陷

• 修复的风险太大

• 不值得修复

• 软件测试的群集现象 –
  (Pareto原则)：测试发现的错误中的80%很可能起源于程序模块中的20%。

• 软件缺陷的寄生虫性：

10. 软件测试过程：

分四步：制定测试计划，设计测试用例和测试脚本，运行测试用例，评估测试结果；如图2：

图2

软件测试的核心在于测试用例：软件测试最重要的工作:
针对要测试的内容设计一组测试用例

测试用例 = 输入 + 预期输出

输入：输入和前提 (前置条件,在测试用例执行之前已经存在的环境)

预期输出：输出和后果 (前置条件,在测试用例执行之后将产生的环境)

测试的最后要检查实际执行结果是否与预期结果是否一致，一致便是没有错误，测试成功。

11. 测试用例的两种基本的测试技术：

黑盒测试：功能性测试, 基于规格说明的测试

白盒测试：结构性测试，透明盒测试, 玻璃盒测试,基于程序的测试

下面第二第三部分将讲解黑盒白盒测试的细节

还有一种灰盒测试的技术：

通常指在无法直接获得源代码的情况下，通过一些软件制品、或者通过反编译反汇编等手段，

获得代码的部分结构信息，从而进行测试。

例如：对java、android等写的程序进行反编译，对嵌入式程序进行反汇编等。

12. 缺陷分类的办法：

• 以出现相应错误的开发阶段来划分；

• 以相应失效产生的后果来划分；

• 以解决难度来划分；

• 以不解决会产生的风险来划分；

13. 测试分类：

• 单元测试（Unit test）：

正确，规范；白盒测试为主

模块测试 （模块的粒度）：

• 集成测试（Integration test）

将通过单元测试的多个模块组合,形成更大的模块或子系统或产品，然后进行测试，如:模块接口、代码和界面的规范等。

• 系统测试(System test):

测试软件系统和其它系统元素（硬件、数据库和人机交互信息）的配合,
以及整个系统的测试规范，如：安装测试，配置测试，界面测试，可用性测试，安全性测试等。

• 确认测试: (Validation test)

根据需求规格说明书，测试系统对用户需求的满足程度。

• 验收测试（Acceptance test）

主要由用户执行,检查是否符合验收标准。黑盒测试为主

14. 软件测试的级别：

软件测试的级别是层层递进的，由单元测试到集成测试到系统测试再到验收测试，是一个由小到大，由部分到整体，由程序员到客户的过程，如图3：

图3

15. 软件测试的分类：

• 静态测试与动态测试

动态测试 (Dynamic testing)：通过运行被测试程序来达到测试的目的。

– 动态黑盒 ; 动态白盒

静态测试 (Static
testing)：不运行被测试程序，通过其它手段达到测试的目的，如：检查和审阅。

–
静态审查"需求规格说明书"：从用户角度出发，依据行业、国家、公司的标准与规范，检查描述的属性和用语，填写"检查表"。

– 静态扫描与分析

• 人工测试与自动测试

自动测试：利用自动化测试工具将大量的重复性工作交给计算机去完成。

– 节约资源，提高效率，可重用

节约人力、物力、资金、时间等资源，且测试脚本可重复利用（可以是不同项目）。

人工测试：

– 走查（Walk-through）

– 互评（Peer Review）

– 会审（Inspection）

• 主动测试与被动测试

主动测试：

测试人员设计和运行
测试用例。主动向被测试对象发送请求、用数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果

被动测试：

测试人员不设计测试用例。软件在线运行在实际环境中，测试者不干预其运行，而是被动地监控其运行，通过一定的被动机制来获得运行的数据，包括输入、输出数据.

– 关键：建立监控程序、分析所得的数据

– 用于：性能测试、在线测试

16. 部分总结：

软件测试可以从三个角度来理解，测试阶段和层次；方法；目标和特性：如图4：

图4

软件测试的流程可以简化为像图5的流程图：

图5

第二部分：黑盒测试

1. 抽象概念：

任何程序都可以看作是将输入定义域取值映射到输出值域的函数。将系统看成"黑盒子"。如图6：

图6

黑盒测试也称为功能测试和数据驱动测试。它将被测软件视为一个无法打开的黑盒，主要根据功能需求设计测试用例和测试。把产品软件想象成一个只有出口和入口的黑盒。在测试过程中，你只需要知道向黑盒输入什么，知道黑盒会产生什么结果。

2. 优缺点

设计测试用例的唯一依据是软件的规格说明。与软件的具体实现无关

优点:

• 如果实现发生变化，测试用例仍然有用

• 测试用例的开发可以与实现并行进行

缺点:

• 测试用例之间可能冗余度大；

• 测试有漏洞: 程序实现的某部分未被测试到

• 能发现: 多余缺陷(即:程序实现了未描述的行为)

3. 黑盒测试分类：

• 边界值测试法：

• 等价类测试法：

• 基于决策表测试法：（判定表法）

• 因果图测试法：

• 基于正交表的测试：

4. 边界值测试法：

（1）目标：针对各种边界情况设计测试用例，可以查出更多的错误。

–
在程序的设计和编码中，常常对规格说明中的输入域边界或输出域边界不够注意

– 例：应为x10，而实现为x10，计数器少计了一次

（2）依据：（测试经验）大量的错误是发生在输入或输出范围的边界上，而不是在范围的内部。

–输入的边界值附近

（3）定义：边界值测试，是最基本的测试方法。可将程序可看作是函数，将输入看作函数的定义域：a
≤x1≤ b；将输出看作函数的值域: ≤x2≤ d。如图7

图7

（4）分类：

• 健壮性测试：超过极值时的系统表现，即"例外情况处理"。
  是边界值分析的扩展，增加两个极值：略超过最大值的取值 (max+)
  ，略小于最小值的取值(min-) 。

• 最坏情况测试；对每个变量进行边界值分析，生成一个五元素的边界值集合；对所有变量的边界值集合进行笛卡儿积计算，如图8

图8

• 健壮最坏情况测试；对每个变量进行健壮性测试，生成一个七元素集；对所有变量的七元素集进行笛卡儿积计算；如图9

图9

• 特殊值测试；抽取特殊值

• 随机测试：使用随机数生成器选出测试用例。

（5）边界值分类：最小值、略高于最小值、正常值、略低于最大值、最大值（即：min,
min+, nor, max- ,max）

（6）生成方法：以基于输入空间的边界值分析为例，假设有n个输入变量，每次只对一个变量取极值（即：min,
min+, nor, max- ,max，而对其它所有变量取正常值。对每个变量都重复进行。

（7）特点：

局限性：

较适用于变量之间没有依赖的情况。

–例：年月日的关系则不容易用边界值分析，因为年月日相关联（大小月的天数，闰年的二月天数）。

–如果被测程序是多个独立变量的函数，则很适合边界值分析。

不适用于布尔变量

–每个变量只有两个边界值：T，F。（无其它三个边界值）

5. 等价类测试法：

（1）目标：测试用例集；避免冗余；减少遗漏 完备性

（2）依据：“集合的划分”：将一个集合分成互不相交的若干子集，这些子集的并是该集合的全集。

• 子集互不相交：无冗余

• 子集的并为全集：提供了一种形式的完备性

（3）定义：等价类是指某个输入域的子集合中各个数据对于揭露程序的错误都是等效的，或者进行相同的处理。测试某等价类的一组数据就等价于对这一类其他值得测试，因此在等价类中只需要取一组测试用例即可。等价类集合的划分，提供完备性、保证无冗余性。

（4）分类：弱一般等价类测试；强一般等价类测试；弱健壮等价类测试；强健壮等价类测试

弱一般等价类测试：基于单缺陷，不考虑无效值，对每个输入变量来说：自身的各个有效区间都被覆盖即可。如图10

图10

强一般等价类测试：基于多缺陷，不考虑无效值，所有输入变量的有效组合区间都被覆盖；所有的有效等价类都被覆盖。如图11

图11

弱健壮等价类测试：基于单缺陷，考虑无效值，保证每个输入变量各自
的有效区间被覆盖即可。如图12

图12

强健壮等价类测试：基于多缺陷，考虑无效值，所有的输入组合都被覆盖；所有的等价类都被覆盖。如图13

图13

说等价类弱是因为是单缺陷 （弱单缺陷，强多缺陷）

说等价类健壮是因为考虑无效值（一般不考虑无效值，健壮考虑无效值）

（5）等价类:

有效等价类：

• 是指对于程序的规格说明来说，是合理的，有意义的输入数据所构成的集合；

• 检验程序是否实现了预期的功能。

无效等价类：

• 是指对于程序的规格说明来说，是不合理的，无意义的输入数据所构成的集合；

• 检验程序对于无效数据的处理－意外处理能力，可靠性.

（6）特点：

• 等价类测试的弱形式不如对应的强形式全面。

• 健壮性测试适用于 "错误处理非常重要"的软件。

• 通过结合边界值测试，等价类测试可得到加强。

• 在发现"合适"的等价关系之前，可能需要进行多次尝试。

（7）划分等价类的原则

• 如果输入条件规定了取值范围，或者值的个数，则可以确
  定一个有效等价类和两个无效等价类；

• 如果输入条件规定了取值的集合，或者是规定了"必须…"
  的条件，这时可以确立一个有效等价类和一个无效等价类；

• 如果输入是一个布尔量，则可以确立两个有效等价类和一 个无效等价类

• 如果输入数据规定了一组值，而且程序要对每一个输入值
  分别进行处理，这时要对每一个规定的输入值确立一个等价类，
  而对于这组值之外的所有值确立一个等价类；

• 如果规定了输入数据必须遵守的规则，则可以确立一个有
  效等价类（符合规则）和若干个无效等价类（从不同角度违反规 则）。

• 如果确知以划分的等价类中的各元素在程序中的处理方式
  不同，则应进一步划分成更小的等价类

（8）等价类测试的步骤：

• 划分等价类，

• 生成测试用例：

6. 基于决策表测试法：（判定表法）

（1）相较于等价类：

• 很适合分析和表示上述的复杂逻辑关系。

• 在详细设计和测试阶段均可使用。

（2）定义：

是最严格的功能性测试，具有逻辑性，用于表示和分析复杂的逻辑关系。适合描述不同条件集合下采取行动的若干组合的情况。决策表被设计成说明性的（与命令相反），给出的条件没有特别的顺序，而且所选择的行动发生时也没有任何的特定顺序。

（3）组成：

由条件桩、条件条目、行动桩，行动条目4部分组成

（4）分类：

• 有限条目决策表：

– 每个条件都是二叉条件（逻辑条件，取值为真或假 T/F、Y/N）

– 条件部分是真值表

– 保证所有可能的条件组合（完备性）完备的测试

– n个条件  ？条规则

• 扩展条目决策表：

– 一个条件可以有多个取值

（5）特点：

• 决策表测试适用于：

–if-then-else逻辑很突出。

–输入变量之间存在依赖关系。

–输入与输出之间存在因果关系。

• 当条件较多时，决策表的规模的很大。

–有n个条件的有限条目决策表有2 n个规则。

– "收缩"决策表的方法： 合并相似规则；使用扩展条目决策表。

• 可能需要多次尝试和迭代。

–第一次尝试的条件和操作可能不令人满意。把第一次得到的结果作
为铺路石，逐渐迭代改进，直到得到满意的决策表。

7. 因果图测试法：

（1）优点：

• 考虑到输入情况的各种组合，和输入情况之 间的相互制约关系。

• 能够高效地选择测试用例，同时还能指出程 序规格说明中存在着什么问题。

• 等价类划分和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试测试到了，但多个输入条件组合起来可能出错的情况却被疏忽了。

（2）缺点：

当条件之间关系复杂时，因果图太庞大。

（3）定义：

因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，他适合与检查程序输入条件的各种组合情况

（4）步骤:

• 考虑到输入情况的各种组合，和输入情况之间的
  相互制约关系，建立因果图。

• 将因果图转成决策表。

（5）符号：

• 恒等：表示原因与结果之间一对一的对应关系。
  若原因出现则结果出现；若原因不出现，则结 果不出现。

• 非：表示原因与结果之间的一种否定关系。若
  原因出现，则结果不出现；若原因不出现，则 结果反而出现。

• 与：表示若几个原因都出现，结果才出现；若
  几个原因中有一个原因不出现，结果就不出现。

• 或：表示若几个原因中有一个出现，则结果出
  现；只有当几个原因都不出现时，结果才不出现。

（6）约束条件：

E（互斥）表示a、b两个原因不会同时出现（最多只能有一个出现）。

I（包含）表示a、b、c三个原因中至少有一个必须成立。

O（唯一）表示a、b中必须有一个，且只有一个成立。

R（要求）表示当原因a出现时原因b也必须出现，不可能a出现b不出现。

图14

（7）步骤：

• 挑选因子（因素，变量 ）和状态（水平，变量值 ）， 构造正交表

• 利用正交表进行因子和状态的各种组合

8. 基于正交表的测试：

（1）定义：

正交测试源于正交试验设计方法，是从大量的数据中挑选适量的、有代表性的点，从而合理地安排测试的一种科学的试
验设计方法。正交测试法就是使用已经造好了的正交表格来安排试验并进
行数据分析的一种方法。它简单易行并且计算表格化，应用性较好。

（2）基础知识：

因素/因子：在一项试验中，凡欲考察的变量称为因素（变量）。

水平/状态
（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）。

正交试验设计：是研究多因素多水平的一种设计方法，它是根据正交性
从全面试验中挑选出部分有代表性的点进行试验，这些有代
表性的点具备了"均匀分散，齐整可比"的特点，正交试验
设计是一种高效率、快速、经济的试验设计方法。

（3）构成：

行数(Runs)：正交表的行数，即试验的次数，即测试用 例的个数。

因素数(Factors)：正交表的列数，即待测试的功能点。

水平数(Levels)：单个因素所能取的值的个数。

（4）表示形式：如图15

图15

（5）正交性：

整齐可比性：

• 在同一张正交表中，每个因素的每个水平出现的次数是完 全相同的。

• 在试验中每个因素的每个水平参与试验的机率是完全相同
  的，从而较高程度地排除了水平之间的干扰。

• 均衡分散性：在同一张正交表中，任意两列（两个因素）的水平搭配
  （横向形成的数字对）是完全相同的。

• 试验条件均衡地分散在水平的组合之中，因而具有很强的 代表性。

（6）设计步骤：

• 确定测试中有多少个相互独立的变量，这映射到表中的因素数 （Factors）

• 确定每个变量可取的值的个数，这映射到表中的水平数（Levels）。

• 选择一个行数最少的、适合的正交表。
  适合是指：至少大于或等于上面所说明的因素数和水平数。

• 把因素和值映射到表中。

• 为剩下的水平数选取值。

• 把次数中所描述的组合转化成测试用例，再增加一些没有生成的但可
  疑的测试用例。

（7）优点：

• 节约测试工作工时；

• 可控制生成的测试用例的数量；

• 测试用例具有一定的覆盖率。

第三部分：白盒测试

1. 抽象概念：

程序实现是已知的:
把系统看做一个透明的盒子，利用程序内部的逻辑结构及有关信息，设计或选择测试用例。设计测试用例的唯一依据是程序实现。如图16：
图16

白盒测试又称为结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。盒子指的是被测试的软件，白盒指的是盒子是可视的，测试人员清楚盒子内部的东西以及里面是如何运作的。

2. 优缺点：

优点:

• 具有覆盖率指标

缺点:

• 不能发现: 遗漏缺陷(即:程序未能实现已描述的行为)

3. 白盒测试分类：

• 逻辑覆盖与路径测试

• 基本路径测试

• 主路径测试

• 数据流测试

• 变异测试

4. 思想：

• 利用程序内部的逻辑结构及有关信息，设计或选 择测试用例。

• 对程序所有逻辑路径进行测试

• 对程序所有逻辑路径进行测试

5. 一般原则：

保证模块中所有的，独立路径至少被执行一次;条件语句的每一个分支至少被执行一次；循环语句都在边界条件和一般条件下至少被执行一次;验证所有内部数据结构的有效性。

6. 逻辑覆盖

（1）定义：

逻辑覆盖是一种基于程序内部逻辑结构的动态白盒测试方法；

（2）分类：

• 语句覆盖SC ：是指在测试的过程中，软件测试人员应
  选择足够多的测试用例，保证被测试程序中的每
  一个语句至少执行一次。对于判断语句：只能覆盖其中的一个分支，不
  能发现另一个分支中的错误。

• 判定覆盖DC
  ：又称分支覆盖，保证程序中每一个判断的取真分支至少经历一次；取假分支
  至少经历一次。仍然不能确保一定查出在判定条 件中存在的错误。

• 条件覆盖CC ：保证程序中每个判断的每一个子条件的可能取
  值至少执行一次。要求程序中每个判定表达式里的每个判定条件的Y和N都要至少被执行一次

• 条件/判定覆盖 C/DC ：保证每个判断的所有分支至少执行一次，
  判断中每一个子条件的所有可能取值至少
  执行一次。不一定能查出在判定条件中存在的错误。

• 修订的条件/判定覆盖 MC/DC：首先要满足C/DC
  （条件/判定覆盖），在此基础上，对于每一个条件C，要求存在两次计算以满足如下条件：
  当"条件C取值相反，其余条件取值不变"时，判定的结果值也相反。

• 条件组合（多条件）覆盖 MCC ：使得每一个判断
  的所有可能的子条件取值组合 至少执行一次。

• 路径覆盖：覆盖程序中所有可能的路径

（3）强度的梯度

根据逻辑覆盖的强度由低到高为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。

7. 基本路径测试

（1）定义：基本路径测试是将程序流程图转化为控制流图，通过分析控制结构的环路复杂性，进而找出路径的基本独立集，最终导出测试用例。将测试路径压缩在一定的限度内（基本路径），
以保证每一条基本路径最少被执行一次。在流图（Flowgraph
）的基础上，分析环路复杂性，导出基本可执行路径，进而设计测试 用例。

（2）控制流图符号：如图17：

图17

在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。

（3）取得方法：

得从程序中取得流程图，再将其转化成为控制流图，在取得的同时不可能穷尽路径测试，只选择基本路径（独立路径）集合。

（4）独立路径：

是指从被测程序的入口到出口的最
短路径开始，包括一组以前没有处理过的语句或条件的一条 路径。

（5）步骤：

• 画出控制流图；

• 确定程序基本集的独立路径数量，再确保所有语句至少执行一次的测试数量的上界；

• 再根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径，于是形成路程测试用例

8. 数据流测试

（1）定义：

数据流测试方法是按照程序中变量定义和使用位置来选择程序的测试路径。数据流测试主要用于优化代码，早期的数据流分析常常集中于定义/引用异常的缺陷。

• 变量被定义，但从来没有使用（未使用）

• 所使用的变量没有被定义（未定义）

• 变量在使用之前被定义了两次（重复定义）

与"数据流图"无关 ν 关注 变量的"定义－使用"路径 ν
设计测试用例，覆盖这些相关路径或相关语句 ν 定义－使用(Define-Use) 测试 ν
基于程序片(Slice) 的测试

（2）定义-使用

变量 v ∈ V 的定义结点 n ∈G§ ，记做DEF(v,n),当且 仅当变量
v的值在对应结点 n的语句片段处定义。

变量 v ∈ V 的使用结点 n ∈G§，记做USE(v,n), 当且 仅当变量
v的值在对应结点 n的语句片段处使用。

使用结点 USE(v,n) 是一个谓词使用（记做P-use），当且 仅当语句
n是判定语句； • 否则， USE(v,n) 是计算使用（记做C-use）。

（3）优点：

• 适合测试计算密集型的程序和控制密集型的程序（全谓词使用/部分计算使用覆盖准则）

• 比基本路径测试更精细中

（4）覆盖准则：如图18：

图18

9. 变异测试

（1）定义：

变异测试是一种对测试集的充分性进行评估的技术，以 创建更有效的的测试集。
变异测试与路径或数据流测试不同，没有测试数据的选 择规则。
变异测试应该与传统的测试技术结合，而不是取代它们。

（2）变异测试的作用：

发现程序一些细微的错误 或者：表明替代的方法是不正确的。

（3）基本概念：

• P’称为P的变异体。

• 如果对于T中的测试t，有P(t)≠P’(t)，称作P’与P有 区别（
  distinguishes），或者t杀死（killed）P’.

• 如果T中所有的测试 t使得P(t)=P’(t)，称T不能区别P
  和P’。那么称在测试过程中P’是活的（live）.

• 如果在程序P的输入域中不存在任何测试用例t使得P与 P’
  区别，则称P’等价于P。

• 如果P’不等价于P，而且T中没有测试能够将P’与P区
  别，则认为T是不充分的。

• 不等价而且是活的变异体为测试人员提供了一个生成
  新测试用例的机会，进而增强测试T。

（4）强变异和弱变异：

强变异：关心程序的外部行为：如全局变量值的改变，数据文件等
；P和M2在强变异下是等价的，

弱变异：关心程序的内部行为：如状态。在给定的测试t，P和M2是有区别的，在弱变异下是不等价的。

第四部分：软件测试的级别

1. 分类：

分为三大级别：

• 单元测试

• 集成测试

• 系统测试

2. 单元测试：

（1）定义：

又称模块测试：依据详细设计说明书和源程序清单，检验 程序最小单位有无错误

（2）方法：

• 静态测试：代码审查和走查

• 动态测试：编写驱动和桩模块，运行被测模块

模块并不是一个独立的程序，在测试模块时，需要用一些辅助模块去
模拟与被测模块相联系的其它模块。驱动模块 (Driver) ： 模拟调用模块 ν
桩模块 (Stub)存根模块：模拟被调模块

3. 集层测试：

（1）定义：

也称 集成测试、联合测试。 ν
将通过单元测试的模块，按照设计的要求集成成子系统或系统，找出模块间
的接口和交互错误。

（2）方法：

• 基于功能分解树的集成（关注接口）

• 一次性集成：首先对各个模块分别进行单元测试，然后再把所有模块一次性集成在一
  起进行测试

• 渐增式集成：首先对各个模块进行单元测试，然后将这些模块逐步
  集成成子系统。边集成边测试，以发现集成过程中产生的问
  题。通过渐增，逐步集成为最终要求的系统

• 自顶向下集成：按系统程序结构，沿控制层次自顶向下进行集成

• 自底向上集成：从最底层的模块开始集成和测试。
  对于一个给定层次的模块，它的子模块（包括子模块的
  所有下属模块）已经集成并测试完成，因此不再需要桩 模块。

• 混合渐增式集成：1)
  衍变的自顶向下的渐增式测试，它的基本思想是强化对输入/输出模块和引入新算法模块进行测试，再自底向上组装成为功能相当完整且相对独立的子系统，然后由主模块开始自顶向下进行渐增式测试。2)
  自底向上------
  自顶向下的渐增式测试，首先对含读操作的子系统自底向上直至根结点模块进行组装和测试，然后对含写操作的子系统进行自顶向下的组装与测试。3)
  回归测试，这种方式采取自顶向下的方式测试被修改的模块及其子模块，然后将这一部分视为子系统，再自底向上测试，以检查该子系统与其上级模块的接口是否匹配。

• 基于调用图的集成（考虑接口和交互）

• 考虑模块间的动态交互；减少桩/驱动模块的开发

• 调用图：描述模块之间的调用关系

• 成对集成

• 邻居集成

• 基于路径的集成（关注交互）

• 关注模块之间的交互；接口是静态结构性的；而交互是动态行为性的。

• 模块的源节点：模块开始执行或重新执行处的语句或语句块。

• 模块的汇节点：模块执行结束处的语句或语句块

• 模块可执行路径（MEP）：是始于一个源节点、终于一个汇节
  点的一条路径，而且在此路径上没有其它的源节点、汇节点

• MM-路径：是由消息连接起来的MEP序列；优点：它依据系统的实际行为进行集成，而基于分解和调用图集
  成是依据系统的结构进行集成。
  及适用于结构化软件，也适用于面向对象软件，可以与系统测试无缝连接。缺点：需要更多的工作量标识MM-路径。

（3）步骤：

• 集成测试需要与单元测试完成的时间协调，并制 定测试计划

• 集成测试完成

• 完成预定的集成测试之后，测试小组对测试结果进
  行整理、分析，形成测试分析报告

• 提交文档

4. 系统测试

（1）定义：

是将通过确认测试的软件和系统的其它成分
结合在一起，在实际运行环境下，对计算机系统进行一系列的集成测试和确认测试，发现软件不符合系统需求定义的地方

（2）方法：

• 功能测试：对产品的功能进行测试，检验是否实现、实现是 否正确

• 性能测试：对产品的性能进行测试，检验是否达标

• 负载测试：在资源达到"满负载"（边界情况）的情形下，检查
  系统是否发生功能或者性能上的问题

• 压力测试：在人为设置的系统"资源紧缺"情况下，检查系统是否
  发生功能或者性能上的问题

• 配置测试：保证被测软件使用尽可能多样化的硬件组合。

• 兼容性测试：测试两个软件之间 能否正确地交换信息

• 安全性测试：检验在系统中的安全性、保密性措施是否发挥作用，有无漏洞。

• 可靠性测试：检查系统的平均失效间隔时间

• 恢复测试：检查系统在克服硬件故障

• 安装测试：在系统安装之后进行测试，找出在安装过程中出现的错误

• 易用性测试：从使用的合理性和方便性等角度对软件进行检查

• 文档测试：检查文档

第五部分：软件测试的过程和工具

1. 要求功能：

测试计划和管理；源代码控制；自动测试用例生成；标准测试用例包；内存泄漏测试；测试框架；捕获、回放与比较；模拟负载测试等

2. 优缺点：

优点：测试流程和数据的标准化、规范化；与项目计划、开发计划集成；测试用例、缺陷报告、缺陷分析与测试计划集成；测试文档管理；缺陷跟踪和管理、测试评估；测试脚本和测试用例可以重复使用、重新编辑；测试数据与测试过程/脚本分离；适合回归测试与压力测试、负载测试、疲劳测试；观察程序内部信息

缺点：费用风险；集成问题；银弹风险；测试套件；本地化问题；本地化问题

3. 工具：

例如：IBM Rational RequisitePro；Telelogic DOORSreg; Enterprise
Requirements Suite (DOORS/ERS)等；

第六部分：软件质量保证

1. 软件质量：

软件质量是指软件符合的程度

• 明确定义的功能和性能需求

• 明确规定的开发标准和准则

• 隐含要求的其他特性

重要性：软件质量不高是导致软件危机的根本原因；软件质量高可以降低总成本

2. 软件质量保证：

（1）SQA（Software Quality Assurance）

目标：

• 规避风险；减少并纠正软件的开发过程和开发结果与预期的不符合情况。

• 在软件开发的各个阶段进行过程控制

• 关注缺陷

（2）SQA模型：

• CMM(软件过程成熟度模型 Capability of Maturity Model）：

• 描述了软件管理和流程改进的公认模型是一种准则、指南，不是具体的实现方法，现在是CMMI

• 级别：如图19：

图19

软件缺陷事件案例

1. 背景：

事件：Equifax数据泄露

时间：2017年9月

地点：美国

经过：违规行为的后果包括公司遭受重大财务损失、声誉受损以及受影响的客户和监管机构采取法律行动。此外，数百万个人的个人信息遭到泄露，导致潜在的身份盗用和其他形式的网络犯罪。该事件还强调了定期安全更新和彻底测试软件以防止类似事件发生的重要性。

2. 经过：

Equifax在数据泄露事件前就收到很多关于系统的潜在风险和脆弱性的警告。Equifax收到了国家安全部发来的关于黑客用来入侵该公司系统的漏洞的告警消息。在这次大规模数据泄露前，Equifax还遭遇过多次小型的数据泄露，许多外部的专家发现并报告给Equifax的安全部门。但是该公司并没有有效处理这些警告信息。

数据泄露事件发送在2017年5月13日，Equifax在7月29日就发现了一些线索。但是直到公司确认数据泄露后40天才向客户、投资者和管理者通告数据泄露事件。因为Equifax没有及时采取合适的措施通知客户，这就剥夺了消费者采取合适措施保护自己的能力，也伤害了投资者，阻止了市场流动信息，让联邦和州政府不能及时采取行动来缓解数据泄露造成的影响。

在公布了数据泄露事件后，Equifax和IRS就被关于即将签署的720万美元的合同的新闻所淹没。Senator
Warren的调查发现Equifax公司利用合同的漏洞迫使IRS签署了合同，该合最终在IRS得知Equifax的安全能力可能危及纳税人数据时被及时取消了。

3. 原因和问题分析：

• 补丁管理程序：对于软件和应用中的许多漏洞，Equifax只使用了软件补丁来秀股漏洞，并限制对易受感染系统的访问。同时发现，无数的软件漏洞修复的时间长达几个月，这就给了攻击者一个巨大的攻击窗口期。对于直接导致数据泄露的Apache
  Struts漏洞，Equifax并没有有效地使用简单、低成本的补丁来保护消费者数据。比如，使用邮件通知职员修复该补丁，但并不是所有职员都收到了该邮件。之后的扫描只评估了Equifax公司系统的一部分，也没有找出Apache
  Struts漏洞是否修复。

• 对终端和邮件安全的无力的监控：黑客常会利用系统中某个消费者的安全漏洞来黑进系统，比如通过邮件的鱼叉式攻击。为了检测系统中的攻击，必须能够监控笔记本和其他可以访问系统的网络设备。但Equifax没有采用严格的终端和邮件安全措施。

• 敏感信息泄露：除了没有严格的终端和邮件安全措施，Equifax还没有采取有效的措施来确保敏感信息安全。比如，当银行晚上关门后，不会把现金留在柜台，而是会锁在保险柜里。Equifax却把敏感信息保存在最容易访问的系统中，当黑客利用Apache
  Struts漏洞获取Equifax系统的权限后，就发现了一个客户信息库。

• **网络分段脆弱：**Equifax没有预防黑客从不安全的直面互联网的系统跳转到含有更加有价值的数据的后台系统的安全措施。企业的网络分段措施没能采取适当的措施来阻止攻击者访问消费者信息，也就是没有保护有价值的数据。

• 不适当的证书授权：Equifax系统中的每个消费者都有一些适当的权限。在一个严格的安全标准下，Equifax会限制消费者对重要数据系统的访问，这让公司免受内部攻击。但是黑客攻击进系统后，会获取消费者凭证（消费者名和密码），然后利用这些消费者凭证来访问大量的敏感信息。

• **日志记录：**Equifax没有采用健壮的日志记录技术，该技术可以将黑客从系统中驱除，并且可以限制数据泄露的大小和范围。日志不能预防系统入侵或数据泄露事件，但是在发现入侵后可以进行快速响应。

4. 总结：

数据泄漏对我们的危害很大：

• 对我们用户的人身财产收到安全：

近几年，大大小小的网上个人信息泄露事件频发，信息安全问题比以往任何一个时代都更为突出。越来越多的公民个人言息成为不法分子争抢的"香饽饽"，要么被直接出卖非法获利，要么被犯罪分子利用，从事电信诈骗、非法讨债甚至绑采勒索等犯罪活动。犯罪分子通过各种途径收集到人们被泄露出去的隐私，经过筛选分析用户特征，进行精准犯罪。

• 会威胁国家和公司的安全

隐私泄露对个人所造成的影响毕竟是有限的，但对公司和国家造成的危害则是巨大的。不法分子通过各种途径收集对方公司到的某些重要信息，将信息兜售给其竞争对手从而对公司造成巨大损失，如果是重点行业的公司机密被泄露那不仅对公司来说是致命的，还会对国家安全造成威胁

• 用户思想容易被裹挟：

隐私泄露虽然对个人、公司和国家的安全造成严重威胁，但更为可怕的是隐私泄露还能裹挟用户思想，改变其三观，最终引导整个社会朝着某个设计好的方向发展。

因此，在面对开发软件时，应该软件进行测试，填补软件缺陷

• 使用开源的框架必须实时关注其动态，特别是安全漏洞方面

• 任何公开的入口，都必须进行严格的安全检查

• 框架的选型十分重要，必须将安全考察进去

黑盒测试方法案例

1. 题目：

某报表处理系统要求用户输入处理报表的日期，日期限制在2001年1月至2013年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。系统日期规定由年、月的6位数字字符组成，前四位代表年，后两位代表月。用等价类划分法设计测试用例,来测试程序的日期检查功能。

2. 步骤：

（1）第一步:分析规格说明，依据等价类划分的原则，找出等价类原则

原则1:
如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。

原则2:
如果输入条件规定了输入值的集合，或者是规定了"必须如何"的条件，这时可确立一个有效等价类和一个无效等价类。

原则3:
如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

原则4:
如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确定一个有效等价类，此外针对这组值确定一个无效等价类，它是所有不允许的输入值的集合。

原则5:
如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若千个无效等价类（从不同角度违反规则）。

对于刚刚开始的设计等价类，为了设计测试用例，我们需要确定输入日期的正确范围，然后将输入日期划分为等价类。在这种情况下，日期的正确范围为2001年1月至2013年12月。我们可以将输入日期划分为以下几个等价类：输入日期位于2001年1月至2013年12月之间。输入日期小于2001年1月。输入日期大于2013年12月。后来发现这样子太过于宽泛，考虑到输入输出格式，我又设计一个更细致的，分成10个等价类的表格，如表1：

表1

（2）第二步:为有效等价类设计测试用例如表2

（3）第三步:为无效等级类设计测试用例如表2

---

输入数据 期望结果 覆盖范围

---

201311 有效输入 (1) (2) (3)

2003SD 无效输入 (4)

20032 无效输入 (5)

2004112 无效输入 (6)

200001 无效输入 (7)

200906 无效输入 (8)

200500 无效输入 (9)

200514 无效输入 (10)

表2

（4）编写程序：

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        System.out.println("请输入日期（YYYYMM）：");
        String date = scanner.nextLine();

        if (date.length() != 6) {
            // 检查字符串长度是否为 6
            System.out.println("日期输入错误：字符串长度不为 6。");
            return;
        }

        try {
            // 将字符串转换为整数
            int year = Integer.parseInt(date.substring(0, 4));
            int month = Integer.parseInt(date.substring(4, 6));

            // 检查年份和月份是否在有效范围内
            if (year < 2001 || year > 2013 || month < 1 || month > 12) {
                System.out.println("日期输入错误：年份或月份超出有效范围。");
                return;
            }
        } catch (NumberFormatException e) {
            // 如果无法将字符串转换为整数，则输出错误信息
            System.out.println("日期输入错误：字符串中包含非数字字符。");
            return;
        }

        // 如果程序执行到这里，则说明输入的日期是有效的
        System.out.println("输入的日期是有效的。");

    }
}

（5）结果（只列举四个）：

图20

图21

图22

图23

3. 总结

在等价类传说中，要懂得如何区分等价类：

等价划分类：将不能穷举的测试过程进行合理分类，从而保证设计出来的测试用例具有完整性和代表性，把所有可能的输入数据(有效的和无效的)划分成若干个等价的子集(称为等价类)，使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同

有效等价类：对于程序的需求规格说明书来说是合理的，有意义的的输入数据组成的集合。利用有效性等价类可以检验程序是否实现了规格说明书中所要求的功能或性能。

无效等价类:与有效等价类正好相反，无效等价类指对程序的规格说明是不合理的或无意义的数据所构成的集合。无效等价类至少应该有一个，也可能有多个。

如何划分等价类：首先从程序的规格说明书种找出各个输入条件，在为每个输入条件划分两个或多个等价类，形成若干的互不相交的子集，确定等价类划分法设计测试用例通常分两步进行：

白盒测试方法案例

1. 题目：插入排序，用基本路径覆盖测试程序如图24

图24

2. 步骤

（1）画出控制流程图，如图25：上面代码图左边就是排序

图25

（2）计算出流图 G 的环路复杂性V(G)：

根据 McCabe度量法 ,环路复杂性等于控制流图中的区域数

方法一：根据流图中区域的数量得v(G) = 4；

方法二：v(G) = E - N + 2 = 11 – 9 + 2 =
4；（E为流图中边的个数，N为节点的个数）

方法三：v(G) = P + 1 = 3 + 1 = 4；（P为流图中判定条件的个数）

（3）确定线性无关的基本路径集，如图26：

图26

（4）生成测试用例, 确保基本路径集中每条路径的执行。

• 空数组. 此时Array_size = 0; i = 1时，i<
  Array_size的条件不成立，执行第一条路径 3.1–3.2–12

• 数组只有一个元素. Array_size = 1，当i = 1时，i<
  Array_size的条件不成立，执行第一条路径 3.1–3.2–12

• 数组中至少有两个元素，且元素递增，执行第三条路径
  3.1–3.2–4,5–6.1–6.2–10–3.3–3.2–12

• 数组中至少有两个元素，且非递增元素排序，执行第四条路径
  3.1–3.2–4,5–6.1–6.2–7,8–6.1–10–3.3–3.2–12

• 因为程序中6.1在未进入while循环自减是j=1恒成立，故不存在任何数据能使程序走第二条路径.

测试用例1，空数组，执行第一条路径

int[] arr1 = {};

测试用例2，一个元素，执行第一条路径

int[] arr2 = {1};

测试用例3，两个元素，且按递增的顺序排列，执行第三条路径

int[] arr3 = {1,5};

测试用例4，三个元素，非递增顺序排列，执行第四条路径

int[] arr4 = {4, 1, 2};

结果如图27

图27

代码：

import java.util.Arrays;
import java.util.Scanner;
    public static void test(){
        int[] arr1 = {};
        int[] arr2 = {1};
        int[] arr3 = {1,5};
        int[] arr4 = {4,1,2};
        insert a = new insert();
        a.insertionSort(arr1, arr1.length);
        a.insertionSort(arr2, arr2.length);
        a.insertionSort(arr3, arr3.length);
        a.insertionSort(arr4, arr4.length);
        System.out.println("arr1排序后输出结果为："+ Arrays.toString(arr1));
        System.out.println("arr2排序后输出结果为："+ Arrays.toString(arr2));
        System.out.println("arr3排序后输出结果为："+ Arrays.toString(arr3));
        System.out.println("arr4排序后输出结果为："+ Arrays.toString(arr4));
    }
}

3. 结论：

路径测试就是从一个程序的入口开始，执行所经历的各个语句的完整过程。从广义的角度讲，任何有关路径分析的测试都可以被称为路径测试。完成路径测试的理想情况就是做到路径覆盖，但对于复杂性较大的程序要做到所有的路径覆盖（测试所有可执行路径）是不可能的。在不能做到所有路径覆盖的情况下，如果某一程序的每一个独立路径都被执行到，那么就可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。这种测试方法就是通常所说的基路径测试法。基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径的集合，从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次。

测试工具案例

1. 工具：Junit

2. 简介：

JUnit是一个开源的Java语言的单元测试框架，专门针对Java设计，使用最广泛。JUnit是事实上的单元测试的标准框架，任何Java开发者都应当学习并使用JUnit编写单元测试。使用JUnit编写单元测试的好处在于，我们可以非常简单地组织测试代码，并随时运行它们，JUnit就会给出成功的测试和失败的测试，还可以生成测试报告，不仅包含测试的成功率，还可以统计测试的代码覆盖率，即被测试的代码本身有多少经过了测试。对于高质量的代码来说，测试覆盖率应该在80%以上。此外，几乎所有的IDE工具都集成了JUnit，这样我们就可以直接在IDE中编写并运行JUnit测试。JUnit目前最新版本是5。本人在软测比赛中，也是运用到这一工具对代码进行覆盖。

3. 安装：几乎所有的IDE工具都集成了JUnit，这样我们就可以直接在IDE中编写并运行JUnit测试。

4. 测试开始：

以Eclipse为例，我们创建一个Calculate.java文件：

import java.util.Arrays;  
import java.util.Scanner;  
	  
public class Main {  
	public static void main(String[] args) {  
    int[] arr1 = {}; 
    int[] arr2 = {1};  
    int[] arr3 = {1,5};  
    int[] arr4 = {4,1,2}; 
    insert a = new insert();  
    a.insertionSort(arr1, arr1.length);  
    a.insertionSort(arr2, arr2.length);  
    a.insertionSort(arr3, arr3.length);  
    a.insertionSort(arr4, arr4.length);  
    System.out.println("arr1排序后输出结果为："+ Arrays.toString(arr1));  
    System.out.println("arr2排序后输出结果为："+ Arrays.toString(arr2));  
    System.out.println("arr3排序后输出结果为："+ Arrays.toString(arr3));  
    System.out.println("arr4排序后输出结果为："+ Arrays.toString(arr4));  
	}  
}  

之后，我们想对其进行测试，需要编写一个对应的CalculateTest.java文件：

package net.mooctest;

import static org.junit.Assert.*;

import org.junit.Test;

public class CalculateTest {

	private Calculate cal;
	
	@Test
	public void testadd() {
		cal = new Calculate();
		assertEquals("正正加法有问题", 4, cal.add(1,3));
		assertEquals("负负加法有问题", -2, cal.add(-1,-1));
		assertEquals("正负加法有问题", 0, cal.add(1,-1));
		assertEquals("负正加法有问题", 0, cal.add(-1,1));
	}
	
	@Test
	public void testminus() {
		cal = new Calculate();
		assertEquals("正正减法有问题", 2, cal.minus(3,1));
		assertEquals("负负减法有问题", 0, cal.minus(-1,-1));
		assertEquals("正负减法有问题", 2, cal.minus(1,-1));
		assertEquals("负正减法有问题", -2, cal.minus(-1,1));
	}
	
	@Test
	public void testmulti() {
		cal = new Calculate();
		assertEquals("正正乘法有问题", 3, cal.multi(3,1));
		assertEquals("负负乘法有问题", 1, cal.multi(-1,-1));
		assertEquals("正负乘法有问题", -1, cal.multi(1,-1));
		assertEquals("负正乘法有问题", -1, cal.multi(-1,1));
	}
	
	@Test
	public void testdivide() {
		cal = new Calculate();
		assertEquals("正正除法有问题", 3, cal.divide(3,1));
		assertEquals("负负除法有问题", 1, cal.divide(-1,-1));
		assertEquals("正负除法有问题", -1, cal.divide(1,-1));
		assertEquals("负正除法有问题", -1, cal.divide(-1,1));
	}
}

之后运行：

结果如图28：

图28

testTime有错表示运行时间超出规定的100ms。

5. 总结：

注意事项：

（1）核心测试方法要加上了@Test注解，这是JUnit要求的，它会把带有@Test的方法识别为测试方法。

（2）assertEquals(expected,
actual)是最常用的测试方法，它在Assertion类中定义。Assertion还定义了其他断言方法，例如：assertTrue():
期待结果为true；assertFalse(): 期待结果为false；assertNotNull():
期待结果为非null；assertArrayEquals():
期待结果为数组并与期望数组每个元素的值均相等

关于单元测试：

（1）单元测试可以确保单个方法按照正确预期运行，如果修改了某个方法的代码，只需确保其对应的单元测试通过，即可认为改动正确。此外，测试代码本身就可以作为示例代码，用来演示如何调用该方法。

（2）使用JUnit进行单元测试，我们可以使用断言（Assertion）来测试期望结果，可以方便地组织和运行测试，并方便地查看测试结果。此外，JUnit既可以直接在IDE中运行，也可以方便地集成到Maven这些自动化工具中运行。

（3）在编写单元测试的时候，我们要遵循一定的规范：单元测试代码本身必须非常简单，能一下看明白，决不能再为测试代码编写测试；每个单元测试应当互相独立，不依赖运行的顺序；测试时不但要覆盖常用测试用例，还要特别注意测试边界条件，例如输入为0，null，空字符串" "等情况。