系统分析师16：系统测试与维护

1 内容概要

2 软件测试类型

2.1 测试类型

• 动态测试【计算机运行】

  • 白盒测试法：关注内部结构与逻辑
  • 灰盒测试法：介于两者之间
  • 黑盒测试法：关注输入输出及功能

• 静态测试【人工监测和计算机辅助分析】

  • 桌前检查
  • 代码审查
  • 代码走查
  • 以上三个都是做的【静态分析】
    • 控制流分析：是否存在没有使用的语句/无法达到的语句/调用并不存在的子程序
    • 数据流分析：引用未定义的变量、对以前未使用的变量再次赋值。
    • 接口分析：模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性。
    • 表达式分析：括号不配对、数组引用越界、除数为零。

2.1.1 白盒测试

• 白盒测试【结构测试】：主要用于单元测试阶段。
  • 控制流测试【逻辑覆盖测试(语句覆盖最弱，路径测试覆盖最强)
  • 数据流测试
  • 程序变异测试【错误驱动测试】
    

2.1.2 黑盒测试

• 黑盒测试【功能测试】∶主要用于集成测试、确认测试和系统测试阶段
  • 等价类划分：不同等价类，揭示不同问题；有效等价类/无效等价类。
  • 边界值分析：1<=x<=10,可取x的值为0、1、10和11作为测试数据
  • 错误推测：依靠测试人员的经验和直觉
  • 判定表：最适合描述在多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同的动作
  • 因果图：根据输入条件与输出结果之间的因果关系来设计测试用例

例1
软件测试一般分为两个大类∶动态测试和静态测试。前者通过运行程序发现错误，包括（)等方法;后者采用人工和计算机辅助静态分析的手段对程序进行检测，包括（）等方法。
A:边界值分析、逻辑覆盖、基本路径
B:桌面检查、逻辑覆盖、错误推测
C:桌面检查、代码审查、代码走查
D:错误推测、代码审查、基本路径

A:边界值分析、逻辑覆盖、基本路径
B:桌面检查、逻辑覆盖、错误推测
C:桌面检查、代码审查、代码走查
D:错误推测、代码审查、基本路径

解析
软件测试一般分为两个大类：动态测试和静态测试。
动态测试是通过运行程序来发现错误的方法。它包括以下几种方法：

• 边界值分析：测试输入域的边界值，因为错误往往发生在边界附近。
• 逻辑覆盖：通过测试用例覆盖程序的逻辑路径，确保每条路径都被测试到。
• 基本路径：通过分析程序的控制流图，设计测试用例以覆盖所有基本路径。

静态测试是采用人工和计算机辅助静态分析的手段对程序进行检测的方法。它包括以下几种方法：

• 桌面检查：人工检查代码，查找错误。
• 代码审查：通过团队评审代码，查找错误和改进建议。
• 代码走查：通过模拟程序的执行过程，人工检查代码的逻辑和结构。

答案：A、C。

例2
用边界值分析法，假定10≤X≤30，那么X在测试中应取的边界值是（ ）。
A：X=11，X=29
B：X=9，X=10，X=30，X=31
C：X=10，X=30
D：X=9，X=31

解析

• 边界值分析法要求测试边界值及其附近的值；
• 对于范围10≤X≤30，边界值及其附近的值包括：
  • 下边界：10
  • 下边界减1：9
  • 上边界：30
  • 上边界加1：31
  • 因此，X在测试中应取的边界值是9、10、30、31。

答案：B。

2.2 测试方法

• AB测试
  多版本同时使用，利于收集各版本的用户反馈，评估出最好版本。故也算是一种 【网页优化方法】

• Web测试
  web系统测试与其他系统 测试测试内容基本相同只是测试重点不同
  Web代码测试包括：源代码规则分析、链接测试、框架测试、表格测试、图形测试等方面

• 链接测试
  链接测试可分为3个方面:

  • 测试所有链接是否按指示的那样 确实链接到了该链接的页面
  • 测试所链接的 页面是否存在
  • 保证Web应用系统上 没有孤立的页面

3 测试阶段

• 回归测试：测试软件变更之后，变更部分的正确性和对变更需求的符合性

• 测试阶段

  • 单元测试：依据 【详细设计】，模块测试，模块功能、性能、接口等
  • 集成测试：依据 【概要设计】，模块间的接口
  • 系统测试：依据 【需求文档】，在真实环境下，验证完整的软件配置项能否和系统正确连接
  • 确认测试：依据 【需求文档】，验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试
    

• 集成测试策略

  • 一次性组装【风险高】
  • 增量式组装【测试全面】
    • 自顶向下【需要桩模块】
    • 自底向上【需要驱动模块】
    • 混合式【都需要】

例3
在单元测试中，( ) 。
A：驱动模块用来调用被测模块，自顶向下的单元测试中不需要另外编写驱动模块
B：桩模块用来模拟被测模块所调用的子模块，自顶向下的单元测试中不需要另外编写桩模块
C：驱动模块用来模拟被测模块所调用的子模块，自底向上的单元测试中不需要另外编写驱动模块
D：桩模块用来调用被测模块，自底向上的单元测试中不需要另外编写桩模块

解析
在单元测试中，驱动模块和桩模块的作用如下：

• 驱动模块
  驱动模块（Driver Module）是用来调用被测模块的代码。它通常用于自底向上的单元测试中，因为自底向上的测试是从最底层的模块开始测试，逐步向上测试更高层次的模块。在这种情况下，需要编写驱动模块来调用被测模块。
• 桩模块
  桩模块（Stub Module）是用来模拟被测模块所调用的子模块的代码。它通常用于自顶向下的单元测试中，因为自顶向下的测试是从最高层次的模块开始测试，逐步向下测试更低层次的模块。在这种情况下，需要编写桩模块来模拟被测模块调用的子模块。
• 选项分析
  A: 驱动模块用来调用被测模块，自顶向下的单元测试中不需要另外编写驱动模块。这个选项是正确的，因为在自顶向下的单元测试中，通常需要编写桩模块而不是驱动模块。
  B: 桩模块用来模拟被测模块所调用的子模块，自顶向下的单元测试中不需要另外编写桩模块。这个选项是错误的，因为在自顶向下的单元测试中，通常需要编写桩模块来模拟被测模块调用的子模块。
  C: 驱动模块用来模拟被测模块所调用的子模块，自底向上的单元测试中不需要另外编写驱动模块。这个选项是错误的，因为在自底向上的单元测试中，通常需要编写驱动模块来调用被测模块。
  D: 桩模块用来调用被测模块，自底向上的单元测试中不需要另外编写桩模块。这个选项是错误的，因为桩模块来模拟被测模块调用的子模块，而不是用来调用被测模块，在自底向上的单元测试中，通常不需要编写桩模块，而是需要编写驱动模块。

答案: A。

3.1 系统测试

3.1.1 系统测试分类

• 功能测试

• 性能测试

  • 负载测试：各种工作负载下系统的性能
  • 压力测试【测上限】：系统的瓶颈或不能接受的性能点强度测试【测下限】：系统资源特别低的情况下运行
  • 容量测试【并发测试】：同时在线的最大用户数
  • 可靠性测试：MTTF之类的参数

• 健壮性测试

• 用户界面测试

• 安全性测试

• 安装与反安装测试

例4
软件性能测试有多种不同类型的测试方法，其中，(）用于测试在限定的系统下考查软件系统极限运行的情况，（）可用于测试系统同时处理的在线最大用户数量。
A:强度测试
B:负载测试
C:压力测试
D:容量测试

A:强度测试
B:负载测试
C:压力测试
D:容量测试

解析

• 强度测试（Stress Testing）
  强度测试用于测试在限定的系统下考查软件系统极限运行的情况。它通过模拟极端条件下的负载，测试系统在超出正常工作负载时的表现，以确定系统的极限和稳定性。
• 负载测试（Load Testing）
  负载测试用于测试系统在正常和预期峰值负载条件下的性能。它通过逐渐增加负载，测试系统在不同负载水平下的响应时间和资源使用情况。
• 压力测试（Stress Testing）
  压力测试与强度测试类似，也是用于测试系统在极端条件下的表现。它通过超出系统正常工作负载的负载，测试系统的极限和稳定性。
• 容量测试（Volume Testing）：同时在线的最大用户数。
  根据题目描述：

1. 用于测试在限定的系统下考查软件系统极限运行的情况的测试方法是强度测试。
2. 可用于测试系统同时处理的在线最大用户数量的测试方法是容量测试。

答案：A、D。

3.1.2 系统测试步骤

• 制定系统测试计划
  进行人员以及任务的确定，明确测试范围、测试方法、测试环境与辅助工具

• 设计系统测试用例
  如:等价类划分、边界值分析等测试方法的应用

• 执行系统测试
  执行设计好的测试用例，并记录结果

• 缺陷管理与改错
  消除已发现的错误

3.2 面向对象测试

• 算法层（单元测试)︰包括等价类划分测试、组合功能测试（基于判定表的测试)、递归函数测试和多态消息测试
• 类层(模块测试)︰包括不变式边界测试、模态类测试和非模态类测试
• 模板层/类树层（集成测试)︰包括多态服务测试和展平测试

4 软件调试

• 软件调试方法
  • 蛮力法:主要思想是“通过计算机找错”，低效，耗时
  • 回溯法:从出错处人工沿控制流程往回追踪，直至发现出错的根源。复杂程序由于回溯路径多，难以实施
  • 原因排除法:主要思想是演绎和归纳，用二分法实现
• 软件测试与软件调试区别

  • 软件测试

    • 目的是找出存在的错误
    • 从一个已知的条件开始，使用预先定义的过程，有预知的结果
    • 测试过程可以事先设计，进度可以事先确定

  • 软件调试

    • 目的是定位错误并修改程序以修正错误
    • 从一个未知的条件开始，结束的过程不可预计
    • 调试不能描述过程或持续时间

5 系统转换计划

5.1 遗留系统演化策略

• 开发新系统时,需要完全兼容遗留系统的功能模型和数据模型

• 低水平、高价值：继承

• 低水平、低价值：淘汰

• 高水平、高价值：改造

  • 改造包括系统功能的增强和数据模型的改造两个方面

• 高水平、低价值：集成

  • 针对“信息孤岛”

例5
遗留系统的演化可以采用淘汰、继承、改造和集成四种策略。若企业中的遗留系统技术含量较高，业务价值较低，在局部领域中工作良好，形成了一个个信息孤岛时，适合于采用（）演化策略。
A:淘汰
B:继承
C:改造
D:集成

解析

• 低水平、高价值：继承
• 低水平、低价值：淘汰
• 高水平、高价值：改造
• 高水平、低价值：集成

答案：D。

5.2 新旧系统的转换策略

在系统转换过程中，选择合适的转换策略至关重要，因为它直接影响到转换的顺利进行和系统的稳定性。以下是三种常见的系统转换策略：

5.2.1 直接转换策略（Big Bang Approach）

定义: 直接转换策略是指在某个特定的时间点，旧系统被完全停止，新系统立即接管所有功能。

优点:

• 快速: 转换过程迅速，可以在短时间内完成。
• 成本低: 不需要同时维护两个系统，节省了资源和成本。

缺点:

• 风险高: 如果新系统出现问题，可能会导致业务中断，影响正常运营。
• 缺乏过渡期: 没有时间进行逐步适应和调整，可能会导致用户不适应。

适用场景:

• 适用于小型系统或对业务影响较小的系统。
• 适用于新系统已经过充分测试，确保其稳定性和可靠性。

5.2.2 并行转换策略（Parallel Approach）

定义: 并行转换策略是指在一段时间内，新旧系统同时运行，并比较两者的输出结果，直到确认新系统稳定可靠后，再完全切换到新系统。

优点:

• 风险低: 即使新系统出现问题，旧系统仍然可以继续运行，确保业务连续性。
• 可靠性高: 通过并行运行，可以验证新系统的准确性和稳定性。

缺点:

• 成本高: 需要同时维护两个系统，增加了资源和成本。
• 复杂性高: 需要确保两个系统之间的数据同步和一致性。

适用场景:

• 适用于关键业务系统，确保转换过程中的业务连续性。
• 适用于新系统尚未完全验证，需要通过并行运行来逐步确认其可靠性。

5.2.3 分段转换策略（Phased Approach）

定义: 分段转换策略是指将系统转换过程分为多个阶段，逐步将新系统的各个模块或功能替换旧系统，最终完成整个系统的转换。

优点:

• 风险可控: 通过分阶段进行，可以逐步验证新系统的各个模块，降低整体风险。
• 灵活性高: 可以根据实际情况调整每个阶段的转换计划。

缺点:

• 时间长: 转换过程较长，可能需要数月甚至更长时间。
• 复杂性高: 需要详细规划每个阶段的转换步骤和时间表。

适用场景:

• 适用于大型复杂系统，逐步验证和部署新系统。
• 适用于需要逐步适应新系统的用户和业务流程。

5.3 数据转换与迁移

6 系统运行与维护

• 影响可维护性的因素

  • 【可理解性】是指通过阅读源代码和相关文档，了解软件的功能和如何运行的容易程度
  • 【可修改性】是指修改软件的难易程度
  • 【可测试性】是指验证软件程序正确的难易程度
    可测试性好的软件，通常意味着软件设计简单，复杂性低。因为软件的复杂性越大，测试的难度也就越大
  • 【可靠性】一个软件的可靠性越高,需要维护的概率就会越低
  • 【可移植性】是指将软件从一个环境移植到新的的环境下正确运行的难易程度
    软件运行环境的变化是软件维护的一种常见情形，可移植性好的软件会降低维护的概率

• 维护类型

  • 正确性维护【修BUG】︰识别和纠正软件错误/缺陷，测试不可能发现所有错误
  • 适应性维护【应变】∶指使应用软件适应环境变化【外部环境、数据环境】而进行的修改
  • 完善性维护【新需求】︰扩充功能和改善性能而进行的修改。
  • 预防性维护【针对未来】∶为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使用系统适应各类变化而不被淘汰。经典实例:【专用】改【通用】。

例6
软件的维护并不只是修正错误。为了满足用户提出的增加新功能、修改现有功能以及一般性的改进要求和建议，需要进行（），它是软件维护工作的主要部分;软件测试不可能揭露旧系统中所有潜在的错误，所以这些程序在使用过程中还可能发生错误，诊断和更正这些错误的过程称为（);为了改进软件未来的可维护性或可靠性，或者为了给未来的改进提供更好的基础而对软件进行修改,这类活动称为( ) 。

A:完善性维护
B:适应性维护
C:预防性维护
D:改正性维护

A:完善性维护
B:适应性维护
C:预防性维护
D:改正性维护

A:完善性维护
B:适应性维护
C:预防性维护
D:改正性维护

解析
根据题目描述，我们可以将软件维护的不同类型与各个描述进行匹配：

1. 为了满足用户提出的增加新功能、修改现有功能以及一般性的改进要求和建议，需要进行（），它是软件维护工作的主要部分。

• 这种维护类型主要是为了增强软件的功能或性能，属于完善性维护。
• 答案：A:完善性维护

2. 软件测试不可能揭露旧系统中所有潜在的错误，所以这些程序在使用过程中还可能发生错误，诊断和更正这些错误的过程称为（)。

• 这种维护类型主要是为了修正已经发现的错误，属于改正性维护。
• 答案：D:改正性维护

3. 为了改进软件未来的可维护性或可靠性，或者为了给未来的改进提供更好的基础而对软件进行修改，这类活动称为( )。

• 这种维护类型主要是为了预防未来的问题，属于预防性维护。
• 答案：C:预防性维护

答案：A、D、C。

7 附录 思维导图