2.4维护测试

一旦部署到生产环境中，软件和系统就需要维护。在交付的软件和系统中，各种各样的变更几乎是不可避免的，或者是为了修复在运行使用中发现的缺陷，或者是为了添加新的功能，或者是为了删除或更改已经交付的功能。为了在整个生命期间维护或改进组件或系统的非功能质量特性，特别是性能效率、兼容性、可靠性、安全性、兼容性和移植性，维护也是必须的。
作为维护一部分的任何变更，都应该进行维护测试，以评估变更是否成功，以及检查在系统中保持不变的部分（通常占有系统的大部分）的副作用(例如：回归）。维护测试的重点是测试系统的变更，以及测试可能受到更改影响的未变更部分。维护可以包括计划的版本和未计划的版本（缺陷修复）。
根据维护版本的范围，维护测试可能需要在多个测试级别上进行各种测试类型的测试。维护测试的范围取决于：
• 变更的风险程度，例如：软件的变更区域与其他组件或系统通信的程度
• 已有系统的规模
• 变更的规模
2.4.1 维护的触发
有几个原因会要求软件维护，从而导致维护测试，不管是计划内的还是计划外的变更。
维护的触发原因分类如下：
• 修改，如计划中的增强改进(例如：基于版本的)、纠正和紧急变更、运行环境的改变(例如：计划中的操作系统或数据库升级)、COTS软件升级以及缺陷和漏洞的补丁
• 移植，例如从一个平台迁移到另一个平台，这可能需要对新环境和已变更的软件进行操作测试，或在将来自另一个应用程序的数据迁移到正在维护的系统时进行数据转换测试
• 退役，如应用程序到其生命周期结束时
当应用程序或系统退役时，如果需要较长的数据保存时间，则可能需要测试数据迁移或存档。可能还需要在长时间保存后进行恢复规程的测试。此外，可能需要进行回归测试，以确保任何仍在使用的功能依然有效。
对于物联网系统，维护测试可能是由于在整个系统中引入了全新的或经过修改的东西，如硬件设备和软件服务。这类系统的维护测试特别强调不同层面的集成测试(例如网络层面、应用层面)和安全方面，特别是与个人数据有关的方面。
2.4.2 维护的影响分析
影响分析针对维护版本的变更进行评估，以确定变更的预期后果以及变更的预期和可能的副作用，并确定系统中将受变更影响的领域。影响分析还有助于确定变更对现有测试的影响。系统中的副作用和受影响的区域需要进行回归测试，可能是在更新任何受变更影响的现有测试之后。
根据系统其他领域的潜在后果，可以在作出变更之前进行影响分析，以帮助决定是否应作出变更。
影响分析会很困难，假如：
• 规格说明（如业务需求、用户故事、架构）过时或缺失
• 测试用例没有文档化或过时
• 没有维护测试与测试依据之间的双向可追溯性
• 工具支持薄弱或不存在
• 参与的人员不具备领域和/或系统知识
• 开发过程中对软件的可维护性关注不够