实现和测试-第四节：集成测试

Posted 2022-02-06 快乐江湖

文章目录

• 一：概念
• • （1）方法分类
  • （2）非渐增测试的缺点（了解）
  • （3）渐增测试的优点（了解）
• 二：渐增式测试策略
• • （1）自顶向下集成
  • • A：定义
    • B：步骤（了解）
    • C：结合策略（了解）
    • • ①：深度优先
      • ②：宽度优先
    • D：优缺点
  • （2）自底向上集成
  • • A：定义
    • B：步骤（了解）
    • C：案例
    • D：优缺点
• 三：回归测试
• • （1）定义
  • （2）方法（了解）
  • （3）回归测试集（了解）

一：概念

（1）方法分类

非渐增测试： 先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序

渐增测试： 把下一个要测试的模块同已经测试好的那些模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试，每次增加一个模块。渐增式测试同时完成单元测试和集成测试

（2）非渐增测试的缺点（了解）

• 把所有模块放在一起，测试者面对的情况十分复杂
• 在庞大的程序中诊断定位一个错误非常困难
• 一旦改正一个错误之后，又会遇到新的错误，没有穷尽

（3）渐增测试的优点（了解）

• 把程序划分成小段来构造和测试，比较容易定位和改正错误
• 对接口可以进行更彻底的测试
• 可以使用系统化的测试方法

二：渐增式测试策略

（1）自顶向下集成

A：定义

从主控制模块开始，沿着程序的控制层次向下移动，逐渐把各个模块结合起来。在把附属于主控制模块的模块组装到程序结构中时，使用深度优先的策略或宽度优先的策略

B：步骤（了解）

• 对主控制模块进行测试，测试时用存根程序代替所有直接附属于主控制模块的模块
• 根据选的结合策略(深度优先或宽度优先)，每次用一个实际模块代换一个存根程序
• 在结合进一个模块的同时进行测试
• 为了保证加入模块没有引进新的错误，可能需要进行回归测试

C：结合策略（了解）

①：深度优先

深度优先的结合方法先组装在软件结构的一条主控制通路上的所有模块。步骤如下:

• 第一，选择一条主控制通路取决于应用的特点(如，选取左通路)
• 第二，结合模块$M_1$、$M_2$、$M_5$
• 第三，把$M_8$或$M_6$结合进来
• 第四，构造中央的和右侧的控制通路

②：宽度优先

宽度优先的结合方法是沿软件结构水平地移动,把处于同一个控制层次上的所有模块组装起来。步骤如下

• 第一，结合模块$M_2$、$M_3$、$M_4$
• 第二，结合下一个控制层次中的模块$M_5$、$M_6$、$M_7$
• 第三，继续进行下去，直到所有模块都被结合进来为止

D：优缺点

优点

• 不需要测试驱动程序
• 能够在测试阶段的早期实现并验证系统的主要功能
• 能在早期发现上层模块的接口错误

缺点

• 需要存根程序，可能遇到与此相联系的测试困难
• 低层关键模块中的错误发现较晚
• 在早期不能充分展开人力

（2）自底向上集成

A：定义

自底向上测试从软件结构最低层的模块开始组装和测试。因为是从底部向上结合模块，总能得到所需的下层模块处理功能，所以不需要存根程序

B：步骤（了解）

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

C：案例

• 把模块组合成族1、族2和族3
• 使用驱动程序（图中虚线方框）对每个子功能族进行测试
• 族1和族2中的模块属于模块$M_a$，去掉驱动程序$D_1$和$D_2$，把这两个族直接同$M_a$连接起来。同样在和模块$M_b$结合之前去掉族3的驱动程序$D_3$
• $M_a$和$M_b$这两个模块都与模块$M_c$结合起来

D：优缺点

优点

• 不需要存根程序，不会遇到与此相联系的测试困难
• 能较早发现低层关键模块中的错误
• 在早期能充分展开人力

缺点

• 需要测试驱动程序
• 不能够在测试阶段的早期实现并验证系统的主要功能
• 不能在早期发现上层模块的接口错误

三：回归测试

（1）定义

回归测试是指重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。它可以用于保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动

（2）方法（了解）

• 通过重新执行全部测试用例的一个子集人工地进行
• 利用捕获回放工具，捕获测试用例和实际运行结果，然后回放，并比较运行结果

（3）回归测试集（了解）

回归测试集(已执行过的测试用例的子集)包括下述3类不同的测试用例:

• 检测软件全部功能的代表性测试用例
• 专门针对可能受修改影响的软件功能的附加测试
• 针对被修改过的软件成分的测试