2.4维护测试

鼻屎噶的滑滑丹

2.4维护测试

要想弄明白维护测试首先需要搞清楚它的定义：针对运行系统的更改，或者新的环境对运行系统的影响而进行的测试。这个定义里面涉及到一个“运行系统”（operational system)。所谓“运行系统“指的是这个系统已经在用户或者客户环境中使用了。那么相对应的，如果这个系统还只是在开发阶段，没有部署到客户环境中，那么就不是”运行系统“。一旦运行系统需要进行变更，或者运行系统的环境发生了变化，那么就需要进行维护测试。
所以纯粹从理论上来判断一个测试是否属于维护测试的关键是看被测试对象是否已经是运行系统。这里大家可以看到维护测试是一个新的测试活动维度，是从被测试对象是否是运行系统来区分的。这个维度和我们上面提到的测试类型和测试级别又是不同的。搞清楚他们的观察点不同后，我们可以很容易的知道：维护测试中可以用到上面提到的所有测试类型和测试级别。
根据维护版本的范围，维护测试可能需要在多个测试级别上进行各种测试类型的测试。维护测试的范围取决于：

• 变更的风险程度，例如：软件的变更区域与其他组件或系统通信的程度
  
• 已有系统的规模
  
• 变更的规模
  

2.4.1 维护的触发

针对一个运行的系统，什么时候会触发维护呢？常见的原因分类如下：

• 修改：计划中的增强改进(例如：基于版本的)、纠正和紧急变更、运行环境的改变(例如：计划中的操作系统或数据库升级)、COTS软件升级以及缺陷和漏洞的补丁；
  
• 移植：例如从一个平台迁移到另一个平台，这可能需要对新环境和已变更的软件进行操作测试，或者将来自另一个应用程序的数据迁移到正在维护的系统时进行数据转换测试；
  
• 退役，如应用程序到其生命周期结束时，当应用程序或系统退役时，如果需要较长的数据保存时间，则可能需要测试数据迁移或存档。可能还需要在长时间保存后进行恢复规程的测试。此外，可能需要进行回归测试，以确保任何仍在使用的功能依然有效。
  

对于物联网系统，维护测试可能是由于在整个系统中引入了全新的或经过修改的东西，如硬件设备和软件服务。这类系统的维护测试特别强调不同层面的集成测试(例如网络层面、应用层面和安全方面)，特别是与个人数据有关的方面。
2.4.2 维护的影响分析

影响分析针对维护版本的变更进行评估，以确定变更的预期后果以及变更的可能的副作用，并确定系统中将受变更影响的领域。
影响分析会很困难，常见的一些挑战包括：

• 规格说明（如业务需求、用户故事、架构）过时或缺失
  
• 测试用例没有文档化或过时
  
• 没有维护测试与测试依据之间的双向可追溯性
  
• 工具支持薄弱或不存在
  
• 参与的人员不具备领域和/或系统知识
  
• 开发过程中对软件的可维护性关注不够
  

为了更好的进行维护的影响分析，可以分别从下面两个方面来考虑：

• 从对已有的业务方面：这个方面的分析主要是从技术方向，针对变更，一方面对新修改、增加的地方进行全面测试；另一方面是分析这些变更对已有的系统的影响，从而确定需要回归测试的范围和深度；
  
• 从对已经在使用的用户方面：维护版本发布时，已经有用户在使用该系统了，那么就需要测试系统的变更对已经使用该系统的用户是否造成了不必要的影响。例如，需要对用户数据进行向前兼容等。
  

云深在何处

呵呵，低调，低调！