软件测试：考点总结

引言 ⭐⭐

软件

软件是计算机系统中与硬件相互依存的另一部分。包括程序、数据及其文档的完整集合。

• 程序：按实现设计的功能和性能要求执行的指令序列。
• 数据：使程序能正常操纵信息的数据结构。
• 文档：与程序开发、维护和使用有关的图文材料。

软件的分类（按系统功能划分）：

• 系统软件：Unix、Windows
• 支撑软件：数据库，驱动，文件系统
• 应用软件

测试

用任何一种可能采取的方法进行的直接实际实验。

• 验证特性
• 查找错误

软件测试

通过一些经济有效的方法，发现软件中存在的缺陷，从而保证软件质量。

软件调试/排错（Debug）

• 利用测试结果和测试提供的信息进行全面的分析。
• 找到错误的根源和出现错误的原因。
• 纠正已发现的问题。
  • 弄清了出错原因和错误根源，立即修正。
  • 不确定出错原因，作出推测，再次进行测试。

软件缺陷

即指程序中存在的错误，也指可能出现在软件设计过程中，甚至需求分析、规格说明或其他的文档中的种种错误。

---

软件测试概述 ⭐⭐

软件测试的概念 ⭐

• 定义1：1983年IEEE(国际电子电气工程师协会)提出的软件工程标准术语中给软件测试下的定义是：“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。
• 定义2：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去执行程序，以发现软件故障的过程。该定义强调寻找故障是测试的目的。
• 定义3：软件测试是一种软件质量保证活动，其动机是通过一些经济有效的方法，发现软件中存在的缺陷，从而保证软件质量。

软件测试过程 ⭐

1. 单元测试
   • 目的：检测程序模块中有无故障存在。
   • 对象：软件设计的最小单位，与程序设计和编程实现关系密切。
2. 集成测试
   • 目的：发现与接口有关的模块之间的问题。
   • 方法：非增式集成测试法和增式集成测试法。
3. 确认测试
   • 目的：对软件产品进行评估以确定其是否满足软件需求的过程。
4. 系统测试
   • 目的：针对系统中各个组成部分进行的综合性检验，证明系统的性能。
   • 对测试人员的要求：
     • 系统开发人员不能进行系统测试。
     • 系统开发组织不能负责系统测试。
5. 验收测试
   • 目的：向用户表明所开发的软件系统能够像用户所预定的那样工作。

软件测试与软件开发的关系 ⭐

软件开发过程

• 第一阶段 计划：确定软件开发的总目标。
• 第二阶段 需求分析：对开发的软件进行详细的定义。
• 第三阶段 设计：软件工程的技术核心。
  • 概要设计：把已确定的各项需求转换成相应的体系结构，在结构中每一组成部分都是功能明确的模块。每个模块都能体现相应的需求。
  • 详细设计：对每个模块要完成的工作进行具体的描述，包括确定使用的数据结构等。
• 第四阶段 程序编写：把软件设计转换成计算机可以接受的程序。
• 第五阶段 测试：测试开发的软件是否符合规格说明的要求，它是保证软件质量的重要手段。
• 第六阶段 运行和/维护：已交付给用户的软件投入正式使用以后便进入运行维护阶段。

软件测试在软件开发各阶段中的作用

• 项目规划阶段：负责整个测试阶段的规划。
• 需求分析阶段：确定测试需求分析，制定系统测试计划。测试需求分析是指产品生存周期中测试所需的资源、配置、各阶段评审通过的标准等。
• 概要设计和详细设计阶段：制定集成测试计划和单元测试计划。
• 编码阶段：开发相应的测试代码或测试脚本。
• 测试阶段：实施测试，并提交相应的测试报告。

软件测试应贯穿于软件定义与开发的整个期间：

软件开发经过制定计划、需求分析、设计阶段之后，才能进入编写程序阶段。但是，表现在程序中的故障，并不一定是编码所引起的，很可能是详细设计、概要设计阶段，甚至是需求分析阶段的问题引起的。即使针对源程序进行测试，所发现故障的根源也可能在开发前期的各个阶段。解决问题、排除故障也必须追溯到前期的工作。因此，软件测试应贯穿于软件定义与开发的整个期间。

在确认软件需求并通过评审后，概要设计和制定测试计划可以并行工作，当系统模块划分好后，对各模块的详细设计、编码、单元测试等也可以并行工作。其测试与软件开发并行工作的流程如下图：

软件测试过程模型

V 模型

V 模型非常明确地表明了测试的不同级别，清晰地展示了软件测试与开发之间的关系。

W 模型

W 模型形象地说明了软件测试与开发的并行关系，体现了测试贯穿于整个开发过程的思想。从 W 模型很容易看出测试的对象不仅仅是程序，需求和设计阶段形成的文档同样是软件测试的对象。

W 模型也有局限性。在 W 模型中，开发、测试活动都保持着一种前后关系，只有上一阶段结束，才可以正式开始下一阶段的工作，因此无法支持迭代软件开发模型。

H 模型

在 H 模型中，软件测试的活动过程完全独立，形成了一个完全独立的流程，贯穿于整个产品的周期，与其他流程并发进行。

某个测试点准备就绪后就可以从测试准备阶段进行到测试执行阶段，软件测试可以根据被测产品的不同分层进行。

X 模型

X 模型是对 V 模型和 W 模型的改进。X 模型提出针对单独的程序片段进行相互分离的编码和测试，通过频繁的交接，最终集成为可执行的程序。

软件测试环境的搭建

测试环境是指用来运行软件的环境。

测试环境 = 硬件+软件+网络+数据准备+测试工具

• 硬件环境
  主要是指PC机、笔记本电脑、服务器、各种PDA终端等。
• 软件环境
  主要是软件运行的操作系统。还有Java虚拟机，MySQL等。
• 网络环境
  主要指的是C/S结构还是B/S结构。
• 数据准备
  主要指的是测试数据的准备。测试数据应考虑数据量和真实性，即尽可能获得大量的真实的数据，包括正确和错误的数据。当无法取得真实数据时应尽可能模拟出大量的数据。
• 测试工具
  静态测试工具、动态测试工具、黑盒测试工具、白盒测试工具、测试执行评估工具、测试管理工具等。

搭建软件测试环境还应注意：

• 尽量模拟用户的真实使用环境；
• 测试环境中尽量不要安装其它与被测软件无关的软件，但最好安装杀毒软件，以确保系统中没有病毒；
• 测试环境应与开发环境独立。

总之，搭建的软件测试环境应与软件生产运行环境一致，但还要从软件开发环境中独立出来。

软件测试工具

• 测试管理工具：帮助完成测试计划，跟踪测试运行结果。
  • 白盒测试工具：单元测试，集成测试。（静态测试工具，动态测试工具）
  • 黑盒测试工具：集成测试，系统测试。（功能测试工具，系统测试工具）
  • 专用测试工具：其他测试。
• 测试辅助工具：
  • 测试设计和开发工具：选择并生成测试用例。
  • 测试执行和评估工具：执行测试用例并对结果进行评估。

软件测试的原则 ⭐

1. 尽早地和不断地进行软件测试：缺陷存在放大趋势。问题发现越早，解决问题的代价就越小，这是软件开发过程中的黄金法则。
2. 不可能完全的测试：
   • 不可能测试程序对所有可能输入的响应。
   • 不可能测试到程序每一条可能的执行路径。
   • 无法找出所有的设计错误。
   • 不能采用逻辑来证明程序的正确性。
3. 增量测试，由小到大：单元测试 → 集成测试 → 系统测试。
4. 避免测试自己的程序。
5. 注意错误集中的现象。
6. 确认BUG的有效性：有时候测试人员提交的BUG并不是真正的BUG。一般由A测试人员发现的BUG，一定要由另外一个B测试人员来进行确认。
7. 合理安排测试计划：严谨、准确。

---

软件缺陷 ⭐⭐

软件缺陷概述 ⭐

软件缺陷的定义

按照缺陷的来源，软件缺陷分为文档缺陷、代码缺陷、测试缺陷、过程缺陷。

• 文档缺陷
  • 文档在静态检查过程中发现的缺陷，通过测试需求分析、文档审查对被分析或被审查的文档发现的缺陷。
• 代码缺陷
  • 对代码进行同行评审、审计或代码走查过程中发现的缺陷。
• 测试缺陷
  • 由测试执行活动发现的被测对象的缺陷。（被测对象一般是指可运行的代码、系统，不包括静态测试发现的问题）
  • 测试活动：内部测试、连接测试、系统集成测试、用户验收测试。
• 过程缺陷
  • 通过过程审计、过程分析、管理评审、质量评估、质量审核等活动发现的关于过程的缺陷和问题。过程缺陷的发现者一般是质量经理、测试经理、管理人员等。

软件缺陷的种类

1. 输入/输出缺陷
   • 输入：不接受正确输入、接受不正确输入、描述有错或遗漏、参数有错或遗漏；
   • 输出：格式有错、结果有错、在错误的时间产生正确的结果、不一致或遗漏结果、不合逻辑的结果、拼写/语法错误、修饰词错误。
2. 逻辑缺陷
   • 遗漏情况、重复情况、极端条件出错、解释有错、遗漏条件、外部条件有错、错误变量的测试、不正确的循环迭代、错误的操作符。
3. 计算缺陷
   • 不正确的算法、遗漏计算、不正确的操作数、不正确的操作、括号错误、精度不够、错误的内置函数。
4. 接口缺陷
   • 不正确的中断处理、I/O时序有错、调用了错误的过程、调用了不存在的过程、参数不匹配、不兼容的类型、过量的包含。
5. 数据缺陷
   • 不正确的初始化、不正确的存储/访问、错误的标志/索引值、不正确的打包/拆包、使用了错误的变量、错误的数据引用、缩放数据范围或单位错误、不正确的数据维数、不正确的下标、不正确的类型、不正确的数据范围、传感器数据超出限制、出现1次断开、不一致数据。

软件缺陷的产生

• 疏忽造成的错误（Carelessness Defect，CD）
• 不理解造成的错误（Misapprehend Defect，MD）
• 二义性造成的错误（Ambiguity Defect，AD）
• 遗漏造成的错误（Skip Defect，SD）

软件缺陷数目估计

1. 散播模型

$\frac{N}{N+M}=\frac{n}{n+m}$

$N=\frac{n}{m}\ast M$

$N：固有缺陷$

$M：人工植入的缺陷$

2. 静态模型
3. 覆盖率预测模型
   1. 错误与时间曲线
   2. 错误与覆盖率曲线
   3. 覆盖率与时间曲线

软件缺陷管理

缺陷管理的目标

• 确保每个被发现的缺陷都能够被解决。
  • 这里解决的意思不一定是被修正，也可能是其他处理方式(例如，在下一个版本中修正或不修正)。
• 收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段。
• 收集缺陷数据并在其上进行数据分析，作为组织的过程财富。
  • 找出预防和修复它们的方法，以及预防引入新的缺陷。

缺陷报告

缺陷报告的用途

• 记录缺陷
• 缺陷分类
• 缺陷跟踪

缺陷报告的特点

• 书面的：供日后对修改后的程序j进行测试时使用。
• 已编号的：依据唯一的编号跟踪问题报告。
• 简单的：一份报告应只描述一个问题。
• 可重现的：一定要强调 Bug 的可重现性。
• 不做判断的：对程序员的评价要三思而后行，本着合作的精神，做出合理的判断。

软件缺陷管理流程 ⭐

缺陷的生命周期 ⭐

• 评估(Review)是缺陷处理的核心。由项目经理或者委员会组决定缺陷如何处理。
• 缺陷一旦被发现并且记录下来 就处于开放(Open)状态。
• 经过评估，决定是否解决，由谁来解决。
• 找到解决方案的软件缺陷 (Resolved)，必须经过评估和测试验证，才能最终关闭 (Closed)。

基本流程 ⭐

• 关键状态：
  • 未经确认（Unconfirmed）
    • 直接来自最终用户或系统外部。
  • 活跃（Active/Open）
    • 新的缺陷。
    • 直接来自内部（开发或测试）团队。
    • 曾经关闭的缺陷，被重新激活。
  • 已分配（Assigned）
    • 经过评估，分配给相关开发人员处理。
    • 开发人员自己发现的缺陷。
    • 未通过测试的解决方案，需要进一步研究。
  • 已解决（Resolved）
    • 经过评估确认的解决方案。
  • 已验证（Verified）
    • 测试通过，但是需要后续处理 - 归档，完善测试覆盖，原因分析。
    • 测试不通过，重新分配给开发人员。
  • 关闭（Close）
    • 处理完毕。
• 实际情况不必经过每一个状态。

---

黑盒测试 ⭐⭐⭐⭐

黑盒测试的基本概念 ⭐

• 黑盒测试：不考虑内部实现，依据输入输出设计实验。
• 白盒测试：依据内部的实现逻辑设计测试。
• 灰盒测试：在实际工作中，需要结合黑盒测试和白盒测试。

测试用例：为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定的集合。

黑盒测试是从一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。其基本观点是：任何程序都可以看作是从输入定义域到输出值域的映射，这种观点将被测程序看作一个打不开的黑盒，黑盒里面的内容(实现)是完全不知道的，只知道软件要做什么。

黑盒测试是从用户观点出发的测试，其目的是尽可能发现软件的外部行为错误。

黑盒测试的两个显著优点：

• 黑盒测试与软件具体实现无关，所以如果软件实现发生了变化，测试用例仍然可以使用。
• 设计黑盒测试用例可以和软件实现同时进行，因此可以压缩项目总的开发时间。

等价类划分法 ⭐

完全不考虑程序的内部结构，只根据程序规格说明书对输入范围进行划分，把所有可能的输入数据，即程序输入域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据构成测试用例，然后进行测试。

等价类划分法的原理

所谓等价类是指输入域的某个互不相交的子集合，所有等价类的并便是整个输入域。

1. 划分等价类

   • 有效等价类：检验程序是否实现了规格预先规定的功能和性能。
   • 无效等价类：检查软件功能和性能的实现是否有不符合规格说明要求的地方。

2. 常用的等价类划分原则

   • 按区间划分；
   • 按数值划分；
   • 按数值集合划分；
   • 按限制条件或规则划分；
   • 细分等价类。
   • 同样，可按输出条件，将输出域划分成若干等价类。
   • 列出所有划分出的等价类表。（| 输入条件 | 有效等价类 | 无效等价类 |）

3. 等价类划分测试用例

   • 确定输入需求及输入项。
   • 为每个等价类规定一个唯一的编号。
   • 设计一个新的测试用例，尽可能多地覆盖尚未被覆盖的有效等价类，直到测试用例覆盖了所有的有效等价类（包括输出域）。
   • 设计一个新的测试用例，使其覆盖并且只覆盖一个还没有被覆盖的无效等价类，直到测试用例覆盖了所有的无效等价类。

4. 等价类测试的两个问题

• 规格说明往往没有定义无效测试用例的期望输出应该是什么样的。因此，测试人员需要花费大量时间来定义这些测试用例的期望输出。
• 强类型语言没有必要考虑无效输入。

等价类划分法的测试运用

示例一：三角形问题

示例二：保险公司保费计算程序

边界值分析法 ⭐

大量的软件测试实践表明，故障往往出现在定义域或值域的边界上，而不是在其内部。

为检测边界附近的处理专门设计测试用例，通常都会取得很好的测试效果。

边界值分析法的原理

1. 边界条件

• 边界是一些特殊情况。
  • 程序在处理大量中间数值时都是正确的，但是在边界处可能出现错误。边界条件就是软件计划的操作界限所在的边缘条件。
• 一些可能与边界有关的数据类型有：数值、速度、字符、地址。位置、尺寸、数量等。

边界值和等价类密切相关，从等价类中选取测试数据时应该关注边界值。

在等价类划分基础上进行边界值分析测试的基本思想是：选取正好等于、刚刚大于或刚刚小于等价类边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

2. 边界值分析测试

边界值分析利用输入变量的最小值（min），稍大于最小值（min+），域内任意值（nom），稍小于最大值（max-），最大值（max）来设计测试用例。

对于一个n变量的程序，边界值分析测试会产生4n+1个测试用例。

3. 健壮性边界值测试

健壮性测试是边界值分析的一种扩展。考虑一个略超过最大值（max+）以及一个略小于最小值（min-）的取值，看看超过极限值时系统会出现什么情况。

对于一个n变量的程序，健壮性边界值测试会产生6n+1个测试用例。

健壮性测试最有意义的部分不是输入，而是预期的输出，观察例外情况如何处理。（是否会失控或出现可怕的情形）

对于强类型语言，健壮性测试可能比较困难。

4. 边界值分析法的局限性

• 基于函数输入定义域的测试方法，是所有测试方法中最基本的。
• 这类测试方法都有一种假设，即输入变量是真正独立的。
• 如果不能保证这种假设，则这类方法不能产生令人满意的测试用例。

边界值分析法的测试运用

示例一：三角形问题

边界值分析测试：4*3+1=13

示例二：加法器

测试用例不全，少了10个：4*2+7*2+1=23

因果图法 ⭐

等价类划分法和边界值分析法都是着重考虑输入条件，如果程序输入之间没有什么联系，采用等价类划分和边界值分析是一种比较有效的方法。

如果输入之间有关系，例如，约束关系、组合关系，这种关系用等价类划分的边界值分析是很难描述的，因此必须考虑使用一种适合于描述对于多种条件的组合，产生多个相应动作的测试方法。

因果图法的原理

1. 因果图

2. 约束

在实际问题中，输入状态之间可能存在某些依赖关系，称之为约束。

• 输入条件的约束：
  • 异或（Exclusive，E）；
  • 或（Inclusive，I）；
  • 唯一（One and Only，O）；
  • 需要（Require，R）；
• 输出条件的约束：
  • 强制（Mask，M）。

3. 因果图法测试用例的设计步骤

• 确定软件规格中的原因和结果。
• 确定原因和结果之间的逻辑关系，根据这些关系画出因果图。
• 确定因果图中的各个约束，在因果图上用一些记号表明约束或限制条件。
• 把因果图转换为决策表。
• 根据决策表设计测试用例。

因果图法的测试运用

决策表法 ⭐

在所有的黑盒测试方法中，基于决策表的测试是最严格的，最具有逻辑性的测试方法。

决策表法的原理

1. 决策表

决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。

它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。

决策表通常由条件桩、条件项、动作桩和动作项四部分组成。动作项和条件项紧密相关，指出在条件项的各组取值情况下应该采取的动作。

规则是指：任何一个条件组合的特定取值及其相应要执行的操作。

• 决策表的组成：

2. 决策表的构造

   1. 列出所有的条件桩和动作桩；
   2. 确定规则的个数；
   3. 填入条件项；
   4. 填入动作项，得到初始决策表；
   5. 简化决策表，合并相似规则。

3. 决策表的化简

对于n个条件的决策表，相应有$2^n$个规则(每个条件分别取真、假值)，当n较大时，决策表很繁琐。实际使用决策表时，常常先将它简化。

决策表的简化是以合并相似规则为目标。即若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。

决策表法的测试运用

状态图法

1. 画出状态图

   1. 列出被测系统的输入事件；
   2. 对空闲状态（程序刚启动时的状态）加所有可能的输入，判断产生哪些新状态；
   3. 对上一步产生的每个新状态分别加所有可能的输入。

2. 编写测试用例

   1. 每种状态至少访问一次；
   2. 测试看起来最普遍的状态转换；
   3. 测试状态之间最不常用的分支；
   4. 测试所有错误状态及其返回值；
   5. 利用工具自动执行状态转换测试。

其他黑盒测试方法

• 特殊值测试
• 故障猜测法

黑盒测试方法的比较与选择 ⭐

• 等价类分析测试中，通过等价类划分来减少测试用例的绝对数量。
• 边界值分析方法则通过分析输入变量的边界值域设计测试用例。
• 因果图测试方法考虑到输入条件和输出结果间的依赖关系和制约关系。
• 决策表方法全面的列出可能输入组合，并通过制约关系和合并的方法来减少测试用例。
• 状态图法侧重于过程间的转换动作及转换状态。

测试工作量

1. 测试用例数量（边界值分析>等价类划分>决策表）
   • 边界值分析：不考虑数据或逻辑依赖关系，机械地根据各边界生成测试用例。但会生成大量测试用例，机器执行时间长。
   • 等价类划分：则关注数据依赖关系和函数本身，考虑如何划分等价类，随后也是机械地生成测试用例。
   • 决策表技术：最精细，既要考虑数据，又要考虑逻辑依赖关系。但生成的测试用例少，机器执行时间短。
2. 设计测试用例的工作量（边界值分析<等价类划分<决策表）
   • 决策表：测试用例生成所需的工作最大。但生成的测试用例少，机器执行时间短。
   • 边界值分析：测试方法使用简单，但会生成大量测试用例，机器执行时间长。

测试方法研究的目的就是在开发测试用例工作量和测试执行工作量之间做一个令人满意的折中。

测试有效性

解释测试有效性是很困难的。我们能够做的，只是根据不同类型的故障，选择最有可能发现这种缺陷的测试方法。

• 如果变量引用的是物理量，可采用边界值分析测试和等价类测试。
• 如果变量是独立的，可采用边界值分析测试和等价类测试。
• 如果变量不是独立的，可采用决策表测试。
• 如果可保证是单缺陷假设，可采用边界值分析和健壮性测试。
• 如果程序包含大量例外处理，可采用健壮性测试和决策表测试。
• 如果变量引用的是逻辑量，可采用等价类测试和决策表测试。

黑盒测试工具

• QTP
• Selenium

黑盒测试练习题

---

白盒测试 ⭐⭐⭐⭐⭐

白盒测试概述 ⭐

白盒测试的特性

• 又称透明盒测试、结构测试、逻辑驱动测试或基于程序的测试。
• 是测试被测单元内部如何工作的一种测试方法。
• 允许测试人员根据程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑结构进行测试。
• 可覆盖全部代码、分支、路径和条件等。

白盒测试与黑盒测试的比较

白盒测试和黑盒测试都是软件测试的一个方面，白盒测试与黑盒测试的区别如下：

白盒测试	黑盒测试
需要源代码	不需要源代码，需要可执行文件
无法检验程序的外部特性，无法测试遗漏的需求	从用户的角度出发进行测试
关心程序内部结构、逻辑以及代码的可维护性	关心程序的外在功能和非功能表现
编码、集成测试阶段进行	确认测试、系统测试阶段进行

白盒测试的策略

1. 桌前检查（Desk Check）：程序员检查自己的程序；检查变量、常量、风格等，补充桌前检查文档。
2. 同行评审（Peer Review）：召开程序审查会，程序员逐句讲解程序的逻辑，其他成员提问，展开讨论。
3. 代码走查（Walk Through）：走查小组集体扮演计算机的角色，让测试用例沿程序的逻辑运行一遍，记录轨迹，供分析讨论。
4. 静态分析（Static Analyse）：结构分析、质量度量、模式匹配。
5. 单元测试（Unit Testing）：逻辑覆盖、功能验证、辅助插装(插桩instrumentation)、程序变异。

逻辑驱动覆盖测试 ⭐

特性

• 针对程序的内部逻辑结构设计测试用例；
• 通过运行测试用例达到逻辑覆盖目的；
• 是最传统最经典的白盒测试技术；
• 要求测试人员对程序逻辑结构非常清楚。

基本概念

函数的控制流图：通常一个程序控制流图可表示为（N，E，entry，exit）：

• N：节点的集合，反映程序中的语句；
• E：有向边的集合，反映程序中语句间的控制流关系；
• entry：程序的固定的唯一入口节点；
• exit：程序唯一的退出节点。

控制流图即是具有单一的，固定的入口节点和出口节点的有向图。

控制流覆盖准则（重点）

• 覆盖准则
  • 评价白盒测试中测试用例的好坏。
  • 测试结束的量化指标。
• 语句覆盖准则
  • 语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次。
• 分支覆盖准则
  • 设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次。
• 谓词覆盖准则
  • 原子谓词覆盖准则
    • 设计足够多的测试用例，运行所测程序，使程序中每个复合谓词所包含的每一个原子谓词都至少获得一次“真”值和一次“假”值。
  • 分支——谓词覆盖准则
    • 设计足够多的测试用例，运行所测程序，使程序中不仅每个复合谓词所包含的每一个原子谓词都至少获得一次“真”值和一次“假”值，而且每个复合谓词本身也至少获得一次“真”值和一次“假”值。
  • 复合谓词覆盖准则
    • 设计足够多的测试用例，运行所测程序，使程序中每个谓词中条件的各种可能都至少出现一次。
• 路径覆盖准则
  • 设计足够多的测试用例，覆盖被测试对象中的所有可能路径。
• 各种覆盖准则间的关系（重点）
  • 箭头表示包含关系。
  • 原子谓词覆盖不包含语句覆盖或分支覆盖。

控制流覆盖准则：应用举例

代码审查 ⭐

• 代码审查（Code Review）是软件静态测试中常用的软件测试方法之一，更容易发现架构以及时序相关等较难发现的问题。
• 帮助团队成员统一编程风格，提高编程技能等。
• 代码审查被公认为是一个提高代码质量的有效手段。

代码审查的意义

代码审查包含对错误代码的检查，和不好的编码风格代码的检查。

• 可靠性
• 可读性/维护性
• 移植性

代码审查的内容

• 可追溯性
• 逻辑
• 数据
• 接口
• 文档
• 注释
• 异常处理
• 内存
• 其它

代码审查的过程

• 代码审查策划阶段
• 代码审查实施阶段
  • 代码讲解
  • 静态分析
  • 规则检查
  • 正式代码检查
  • 更改确认
• 代码审查总结阶段

代码走查 ⭐

代码走查（Code Walkthrough???）是软件静态测试方法之一，是通过对代码的阅读，检查发现程序代码中的问题。

具体方法

由测试人员组成小组，准备一批有代表性的测试用例，集体扮演计算机的角色，沿程序的逻辑，逐步运行测试用例，查找被测软件缺陷。

代码走查的意义

• 经验表明，代码走查通常能够有效地查找出**30%~70%**的逻辑设计和编码错误。
• 一旦发现错误，通常就能在代码中对其进行精确定位，降低了调试的成本。
• 代码走查过程通常可以发现成批的错误，这样错误就可以一同得到修正。

代码走查的过程

• 准备阶段
• 生成实例
• 执行走查
• 形成报告

程序变异测试

对于给定程序 P，假定程序中存在一个错误 e 使 P 变成 P’。理论上，如果 P 是正确的，那么 P’ 肯定是错误的。对测试数据 C，运行 C，如果对于每个 C，P 都是正确的，P’ 都是错误的，这说明 P 的正确性较高。如果对某个 Ci，P 是错误的，而 P’ 是正确的，这就说明 P 存在错误，而错误就是 e。这里 P’ 称为 P 的变异因子。

变异测试的关键是如何产生变异因子。常用的方法是通过对原来的被测程序作用变异算子来产生变异因子。

一个变异算子是一个程序转换规则，它把一种语法结构改变成另一种语法结构，保证转换后的程序的语法正确，但不保证语义的一致。

• 表达式a < b 换成 a > b、a=b、a!=b。
• 把变量设成某常量C。
• 把常量C1换成C2。

程序强变异测试：缺点是需要大量的计算机资源来完成测试充分性分析。对于一个中等规模的软件，所需的存储空间也是巨大的，运行大量的变异因子也导致了时间上巨大的开销。
程序弱变异测试：主要差别是弱变异强调的是变动程序的组成部分。

白盒测试工具

• Emma
• C++test
• JUnit
• Testbed

单元测试工具CTS

白盒静态测试

代码检查

• 规则类
• 疑问类
• 故障类

静态结构分析

• 控制流分析
• 数据流分析
• 调用关系分析

代码质量度量

• 采用度量统计的方法分析程序的某些质量因素。
• 质量模型的建立：
  • 规则（Metrics）：量化的行为规范
  • 分类标准（Criteria）：由一系列质量规则组成
  • 质量因素（Factor）：根据各分类标准取值组合权重来计算
• 规则Kiviat图
• 分类标准Kiviat图

---

基于缺陷模式的软件测试 ⭐⭐⭐

基于缺陷模式的软件测试概述 ⭐

缺陷模式

• 程序中经常发生的错误或缺陷所呈现的语法及语义特征。
• 通常由具有领域程序设计经验的程序员或者测试人员总结出来。
• 不同的编程语言，往往对应于不同的缺陷模式集。

基于缺陷模式的软件测试技术特点

• 针对性强。
  • 如果说某种模式的缺陷是经常发生的，并且在被测软件中是存在的，则面向缺陷的测试可以检测出此类缺陷。
• 往往能发现其他测试技术难以发现的故障。
• 工具自动化程度高以及测试效率高。
• 缺陷定位准确。

缺陷模式及实例 ⭐

以缺陷产生后果的严重性高低为评判标准，从程序的源代码形式着眼，对缺陷模式进行分类：

• 故障模式
• 安全漏洞模式
• 疑问代码模式（Book：缺陷模式）
• 规则模式

故障模式

一经产生，会导致系统异常或出错。

1. 存储泄露的故障模式（Memory Leak Fault，MLF）
   • 遗漏故障：申请的内存没有被释放。
   • 不匹配故障：申请函数和释放函数不匹配。
   • 不相等的释放错误：释放的空间和申请的空间大小不一样。
2. 数组越界故障模式（Out of Bounds Array Access Fault，OBAF）
3. 使用未初始化变量故障模式（Uninitialized Variable Fault，UVF)
4. 空指针使用故障（NULL Pointer Dereference Fault，NPDF）
5. 非法计算类故障（Illegal Computing Fault，ILCF）
6. 死循环结构模式（Dead Loop Fault，DLF）
7. 资源泄露故障（Resource Leak Fault，RLF）
   • 当一个资源被打开后，如果并不是在所有的可执行路径上对其进行了显式的释放操作，则是一个资源泄露故障。
8. 并发故障模式

安全漏洞模式

此类缺陷会给系统留下安全隐患，为攻击该系统开了绿灯。

1. 缓冲区溢出（buffer overflow）漏洞模式
   • 主要类型：
     • 数据拷贝造成的缓冲区溢出。
     • 格式化字符串造成的缓冲区溢出。
2. 未验证输入（Tainted Data）
   • 程序从外部获取数据时，这些数据可能含有欺骗性或者是不想要的垃圾数据，如果在使用这些数据前不进行合法性检查则将威胁到程序的安全。
   • 主要类型：
     • 使用的数据来自外部的全局变量。
     • 使用的数据来自输入函数。
3. 竞争条件（Race Condition）
   • 如果程序中有两种不同的I/O调用同一文件进行操作，而且这两种调用是通过绝对路径或相对路径引用文件的，那么就容易出现Race Condition问题。在两种操作进行的间隙，黑客可能改变文件系统，那么将会导致对两个不同的文件操作而不是同一文件进行操作。
   • 发生在用户拥有不同的权限运行的程序中（例如：setuid程序、数据库和服务器程序等）。
4. 风险操作（Risky Operation）
   • 不恰当地使用了某些标准库函数（例如：rand（）生成的口令很容易被猜测到）。

疑问代码模式（缺陷模式）

PPT：此类问题未必会造成系统的错误，可能是误操作造成的，或者是由工程师不熟悉开发程序造成的，起到提示作用。

Book：此类缺陷是不应该发生的，它未必会造成系统的错误，但可能会隐含某些故障。

1. 性能缺陷（低性能模式）：此类缺陷会降低系统的性能，导致软件运行效率低下，可以采用更高效的代码来完成同样的功能。
   • 低效函数/代码
   • 多余函数
   • Java中的显式垃圾回收
   • 冗余代码
   • 头文件中定义的静态变量
   • 不必要的文件包含
   • 字符串低效操作
   • 更简单的运算符替代
2. 争议代码：让人费解的代码。

规则模式

1. 声明定义
2. 版面书写
3. 分支控制
4. 指针使用
5. 运算处理

---

集成测试 ⭐

集成测试概述

集成测试的概念 ⭐

• 集成（Integration）：把多个单元组合起来形成更大的单元。
• 集成测试（Integration Testing）：在假设各个软件单元已经通过了单元测试的前提下，检查各个软件单元接口之间的协同工作（参数、全局数据结构、文件、数据库）是否正确。
  • 通常采用黑盒测试用例设计方法、灰盒测试方法。

集成测试主要关注的问题

• 模块间的参数传递是否正确？（参数个数、类型、次序）
• 一个模块的功能是否会对另一个模块的功能产生错误的影响？（资源内容及操作）
• 全局数据结构是否有问题，会不会被异常修改？（使用一致性）
• 集成后各个模块的累积误差是否会扩大，是否达到不可接受的程度？（精度缺失、逻辑错误）
• 模块组合起来的功能是否满足要求？（需求覆盖）

模块分析

集成测试的第一步，也是最重要的工作之一。

一般将模块划分为3个等级：高危模块、一般模块和低危模块，高危模块应该优先测试。

模块的划分常常遵循下列几个原则：

• 本次测试希望测试哪个模块。
• 把与该模块最紧密的模块聚集在一起。
• 再考虑划分后的外围模块，并分析外围模块和被集成模块之间的信息流是否容易模拟和控制。

集成测试与系统测试的区别 ⭐

测试对象	集成	系统
测试时间	开发过程	开发完成
测试方法	黑白结合	黑盒
测试内容	接口（各模块之间的接口，以及集成后的功能）	需求（整个系统的功能）
测试目的	接口错误	需求不一致
测试角度	开发者	用户

集成测试与开发的关系

软件开发的 V 模型：

• 需求分析->概要设计->详细设计->编码
• 系统测试<-集成测试<-单元测试<-编码

集成测试与软件开发过程中的概要设计阶段相对应，软件概要设计中关于整个系统的体系结构是集成测试用例输入的基础。

集成测试的层次与原则

集成测试的层次

• 传统软件按集成粒度不同：
  • 模块内集成测试
  • 模块间集成测试
  • 子系统内集成测试
  • 子系统间集成测试
• 面向对象的应用系统按集成粒度不同：
  • 类内集成测试
  • 类间集成测试

集成测试的原则

• 所有公共接口必须被测试到
• 关键模块必须进行充分测试
• 集成测试应当按一定层次进行

集成测试策略 ⭐

辅助模块

• 驱动模块（Driver）：用以模拟待测模块的上级模块；
• 桩模块（Stub）：用以模拟待测模块工作过程中所调用的模块。

非渐增式集成

首先对每个子模块进行测试（单元测试），然后将所有模块全部集成起来一次性进行集成测试。

该方法只适用于规模较小的应用系统，在大、中型系统中一般不推荐使用这种方法。

渐增式集成

把下一个要测试的模块同已经测试好的模块结合起来进行测试，然后再把下一个待测试的模块结合起来进行测试。

可以同时完成单元测试和集成测试。

• 容易定位和改正错误；
• 对接口可以进行更彻底的测试；
• 可以使用系统化的测试方法。

目前在进行集成测试时普遍采用渐增式集成方法。

• 自顶向下集成
• 自底向上集成
• 三明治集成

自顶向下集成

从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。

使用深度优先的策略，或者使用宽度优先的策略。

1. 对主控制模块进行测试，测试时用桩模块代替所有直接附属于主控制模块的模块。
2. 根据选定的结合策略（深度优先或宽度优先），每次用一个实际模块替换一个桩模块（新结合进来的模块往往又需要新的桩模块）。
3. 为了保证加入的模块没有引入新的错误，可能需要进行回归测试（即，全部或部分地重复以前做过的测试）。

优点：

1. 可以及早发现主控模块的问题并解决。
2. 如果选择深度优先的结合方法，可以在早期验证一个完整的功能，增强开发人员和用户双方的信心。

缺点：用桩模块代替了低层次的实际模块，没有重要的数据自下往上流。

自底向上集成

从“原子”模块（即最底层的模块）开始组装和测试。

不需要桩模块。

1. 把底层模块组合成实现某个特定的软件子功能的族。
2. 写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出。
3. 对由模块组成的子功能族进行测试。
4. 去掉驱动程序，沿软件结构自下向上移动，把子功能族组合起来形成更大的子功能组。

三明治集成

• 混合增量测试策略，综合了自顶向下和自底向上两种集成方法的优点。
• 桩模块和驱动模块的开发工作都比较小。
• 代价：一定程序上增加了定位缺陷的难度。

1. 确定以哪一层为界来进行集成，如 B 模块。
2. 对模块 B 及其所在层下面的各层使用自底向上的集成策略。
3. 对模块 B 所在层上面的层次使用自顶向下的集成策略。
4. 对模块 B 所在层各模块同相应的下层集成。
5. 对系统进行整体测试。

示例：

1. 对模块 E、F、G 分别进行单元测试；
2. 对模块 A 进行测试；
3. 把模块 E、F 同 B 模块集成并进行测试；
4. 把模块 C、G 集成并进行测试；
5. 对所有模块集成并进行测试。

集成测试用例设计

1. 为系统运行设计测试用例
   • 达到合适的功能覆盖率和接口覆盖率
   • 测试分析技术：
     • 等价类划分
     • 边界值分析
     • 基于决策表的测试
     • 正交实验法
     • 状态图法
2. 为正向集成测试设计用例
   • 测试目标：验证集成后的模块是否按照设计实现了预期的功能
   • 测试分析技术：
     • 输入域测试
     • 输出域测试
     • 等价类划分
     • 状态转换测试
     • 规范导出法
3. 为逆向集成测试设计用例
   • 测试目标：分析被测接口是否实现了需求规格没有描述的功能，检查规格说明中可能出现的接口遗漏等
   • 测试分析技术：
     • 错误猜测法
     • 基于风险的测试
     • 基于故障的测试
     • 边界值测试
     • 特殊值测试
     • 状态转换测试
4. 为满足特殊需求设计用例
   • 测试目标：接口的安全性指标、性能指标等
   • 测试分析技术：规范导出法
5. 为覆盖设计用例
   • 测试分析技术
     • 功能覆盖分析
     • 接口覆盖分析

集成测试过程

• 计划阶段
• 设计阶段
• 实施阶段
• 执行阶段
• 评估阶段

---

系统测试 ⭐⭐⭐

开发的软件只是实际投入使用系统的一个组成部分，还需要检测它与系统其它部分能否协调地工作，这就是系统测试的任务。

系统测试实际上是针对系统中各个组成部分进行的综合性检验，很接近人们的日常测试实践。

性能测试 ⭐

性能测试的基本概念

性能：是一种表明软件系统或构件对于及时性要求的符合程度的指标。是软件产品的一种特性，可以用时间来度量。性能及时性通常用系统对请求做出响应所需要的时间来度量。

性能测试：检验软件是否达到需求说明书中规定的各类性能指标，并满足一些性能相关的约束和限制条件。

性能测试的目的：通过测试，确认软件是否满足产品的性能需求，同时发现系统中存在的性能瓶颈，并对系统进行优化。

性能测试包括以下几个方面：

• 评估系统的能力
• 识别系统中的弱点
• 系统调优

性能测试方法

性能测试方法：

• 基准法
• 性能下降曲线分析法

基准法中关于性能测试的基准：

• 响应时间：对用户来讲，响应时间的长短没有绝对的区别，合理的响应时间取决于实际的用户需求。
• 并发用户：系统用户数，同时在线用户数，同时操作用户数（并发用户数）。
• 吞吐量：指单位时间内系统处理的客户请求数量。可以直接体现系统的性能。
• 性能计数器：是描述服务器或操作系统性能的一些数据指标。计数器在性能测试中发挥着监控和分析的关键作用。
  • e.g. Windows 系统管理器就是一个性能计数器，它提供了测试机 CPU、内存、网络和硬盘的使用信息。

性能测试执行

1. 计划阶段
2. 测试阶段
3. 分析阶段

压力测试 ⭐

压力测试的基本概念

压力测试（Stress Testing）是指模拟巨大的工作负荷，以查看系统在峰值使用情况下是否可以正常运行。

压力测试是通过逐步增加系统负载来测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，一次来获得系统性能提供的最大服务级别的测试。

压力测试的特点

• 压力测试是检查系统处于压力情况下的能力表现。通过不断增加系统压力，来检测系统在不同压力情况下所能够到达的工作能力和水平。压力测试一般通过模拟方法进行。
• 压力测试是一种极端情况下的测试，所以为了捕获极端状态下的系统表现往往采用模拟方法进行。通常在系统对内存和 CPU 利用率上进行模拟，已获得测量结果。
• 压力测试一般用于测试系统的稳定性。
• 与性能测试的联系与区别：
  • 压力测试用来保证产品发布后系统能否满足用户需求，关注的重点是系统整体；
  • 性能测试可以发生在各个测试阶段，即使是在单元层，一个单独模块的性能也可以进行评估。
  • 压力测试是通过确定一个系统的瓶颈，来获得系统能提供的最大服务级别的测试，是极端情况下的系统能力的表现；
  • 性能测试是检测系统在一定负荷下的表现，是正常能力的表现。

压力测试方法

• 重复：一遍又一遍地执行某个操作或功能。
• 并发：同时执行多个操作的行为，即在同一时间执行多个测试线程。
• 量级增加：压力测试可以重复执行一个操作，但是操作自身也要尽量给产品增加负担。
• 随机：对上述测试手段进行随机组合，以便获得最佳的测试效果。

压力测试执行

• 检查是否有足够的磁盘空间。
• 检查是否有足够的内存空间。
• 创造极端的网络负载。
• 制造系统溢出条件。

健壮性测试 ⭐

健壮性测试的基本概念

健壮性测试（Robustness Testing）：

• 主要用于测试系统抵御错误的能力。
• 这里的错误通常是指由于设计缺陷而带来的系统错误。测试的重点为当出现故障时，是否能够自动恢复或忽略故障自动运行。

健壮性有两层含义：一是高可靠性，二是从错误中恢复的能力。

• 可靠性体现了软件系统的质量，需要根据符合规格说明的数据选择测试用例，用于检测在正常情况下系统输出的正确性。
• 从错误中恢复的能力体现了软件系统的适应性，需要在异常数据中选择测试用例，检测非正常情况下的系统行为。

健壮性测试方法

评估系统的健壮性：

• 通过
• 灾难性失效
• 重启失效
• 夭折失效
• 沉寂失效
• 干扰失效

自动化实现测试内容时需要把握的原则：

• 可移植性
• 覆盖率
• 可扩展性
• 测试结果的记录

安全性测试 ⭐

安全性测试的基本概念

安全性测试：检查系统对非法侵入的防范能力，其目的是为了发现软件系统中是否存在安全漏洞。软件安全性是指在非正常条件下不发生安全事故的能力。

系统安全设计的准则：使非法侵入的代价超过被保护的信息的价值，从而令非法侵入者无利可图。

安全性测试手段

测试者扮演一个是试图攻击系统的角色：

• 尝试通过外部的手段来获取系统的密码。
• 使用能够瓦解任何防护的客户软件来攻击系统。
• 把系统“制服”，使别人无法访问。
• 有目的地引发系统错误，期望在系统恢复过程中侵入系统。
• 通过浏览非保密的数据，从中找到进入系统的钥匙。

安全性测试层次

• 应用程序级别的安全性：对数据或业务功能的访问。
• 系统级别的安全性：对系统的登录或远程访问。

二者的关系：应用级别的安全性可确保在预期的安全性情况下，操作者只能访问特定的功能或用例，或者只能访问有限的数据。系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的入口来访问。

安全性测试方法

• 功能验证
• 漏洞扫描
  • 主机漏洞扫描器（Host Scanner）
  • 网络漏洞扫描器（Network Scanner）
• 模拟攻击
  • 冒充
  • 重演
  • 消息篡改
  • 拒绝服务
  • 内部攻击
  • 外部攻击
  • 陷阱
  • 木马
• 侦听技术

可靠性测试 ⭐

可靠性测试的基本概念

• 软件可靠性：在规定时间、规定的运行剖面上运行规定的软件，测试其是否能够正常执行的能力。
• 度量指标：
  • 平均无故障时间是否超过规定时限
  • 因故障而停机的时间在一年中不应超过多少时间
• 可用软件可靠性模型来评估这些指标的有效性。

可靠性测试的基本参数

• 故障率（λ）：总失效次数/总工作时间
• 维修率（μ）：总失效次数/总维护时间
• 平均无故障时间（MTBF）：总工作时间/总失效次数
• 平均维护时间（MTTR）：总维护时间/总失效次数
• 有效度（A）：总工作时间/(总工作时间+总维护时间)
• 残留的缺陷数目（N0）
• 可靠性：R（t）= e ^ {-f^t_0 λ(t)dt}

恢复性测试 ⭐

主要检查系统的容错能力。

当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种方法强迫系统失败，然后验证系统是否能尽快恢复。

备份测试 ⭐

备份测试是恢复性测试的一个补充，也是恢复性测试的一个部分。

备份测试的目的是验证系统在软件或者硬件失败时备份数据的能力。

兼容性测试 ⭐

兼容性测试是指检查软件之间是否能够正确地进行交互和共享信息。

软件兼容性测试需要解决的问题：

• 软件设计需求与运行平台的兼容性。
• 软件的行业标准或规范，以及如何达到这些标准和规范的条件。
• 被测软件与其它平台、其它软件交互或共享的信息。

兼容性测试：

• 向前和向后兼容
• 不同版本之间的兼容性
• 标准和规范
• 数据共享兼容性

安装性测试 ⭐

软件运行的第一件事就是安装（嵌入式软件除外），安装测试是软件测试首先需要解决的问题。

安装测试需要不仅要考虑在不同的操作系统上运行，还要考虑与现有软件系统的配合使用问题。

可用性测试 ⭐

可用性测试（Usability Testing）：对于用户友好型的测试，是指在设计过程中被用来改善易用性的一系列方法。

可用性测试方法：

• 一对一用户测试
• 启发式评估
• 焦点小组

配置测试 ⭐

配置测试（Configuration Testing）：

• 验证系统在不同的系统配置下能否正确工作。
• 配置包括：软件、硬件、网络等。

配置测试的目的：促进被测软件在尽可能多的硬件平台上运行。有时经常会与兼容性测试或安装测试一起进行。

文档测试

软件产品有可运行的程序、数据和文档组成。文档是软件的一个重要组成部分。

软件文档的分类：

• 用户文档
• 开发文档
• 管理文档

一个好的软件文档能从以下3个方面提高软件产品的整体质量：

• 提高可用性
• 提高可靠性
• 降低支持费用

文档测试（Document Testing）：针对系统提交给用户的文档进行验证，目标是验证软件文档是否可以正确记录系统的开发全过程的技术细节。通过文档测试可以改进系统的可用性、可靠性、可维护性和安装性。

文档测试的内容：

• 文档的正确性
• 文档的完备性
• 文档的可理解性

文档测试方法：

• 走查：只通过阅读文档，不必执行程序。
• 验证：对比文档和程序执行结果。

GUI 测试

图形用户界面（Graphical User Interface，GUI）测试是功能测试的一种表现形式，不但要考虑 GUI 本身的测试，也要考虑 GUI 所表现系统功能的测试。

• 一般来说，当一个软件产品完成 GUI 设计后，就确定了它的外观架构和 GUI 元素，GUI 本身的测试工作就可以进行。
• 而 GUI 对应的功能完成之后，才进入功能测试阶段。
• 有时可以把上述两个阶段加以合并，待功能代码完成后一并进行。
• GUI 测试可以采用手工测试方法和自动化测试方法完成。

验收测试

验收测试是部署软件之前的最后一项测试，目的是确保软件准备就绪，并且可以让最终用户使用。

验收测试的常用策略：

• 正式验收测试
• 非正式验收测试（内部测试人员）
• Beta 测试

回归测试

回归测试是在软件发生变动时保证原有功能正常运作的一种测试策略和方法。

• 不需要进行全面的测试，而是根据修改的情况进行有选择性的测试。
• 保证软件原有功能正常运作：
  • 所做的修改达到了预期的目的。
  • 软件的修改没有引入新的缺陷，没有影响原有的功能实现。

回归测试方法：

• 测试用例库的维护
• 回归测试包的选择
• 回归测试的基本过程
  1. 识别出软件中被修改的部分。
  2. 从原基线测试用例库 T 中排除所有不再适用的测试用例，确定对新版本依然有效的测试用例，其结果是建立一个新的基线测试用例库 T0。
  3. 依据一定的策略从 T0 中选择测试用例测试被修改的软件。
  4. 生成新的用例集 T1，用于测试 T0 无法充分测试的部分。
  5. 用 T1 执行修改后的软件。
     • 第2步和第3步测试验证修改是否破坏了现有的功能。
     • 第4步和第5步测试验证修改后的功能。

网站测试

• 文字测试
• 链接测试
• 图形测试
• 表单测试
• 动态内容测试
• 数据库测试
• 服务器性能和加载测试
• 安全性测试