可维护性测试

可维护性测试，可维护性指的是软件产品可被修改的能力，修改包括纠正、改进或者软件对环境、需求和功能规格说明变化的适应能力。为了更好地理解可维护性测试，首先需要了解软件产品有哪些维护活动。

维护活动的分类

虽然软件的维护有时也可以被看成是新的开发，但是从测试的角度看与新的开发活动存在很大不同，维护测试的工作受到已经存在系统的制约和限制。软件的维护活动是软件开发生命周期的一个重要环节，其主要意义如下。
（1）提供持续的服务：软件在发布以后不可避免地会在用户使用过程中发现缺陷，维护活动可以修复这些缺陷并不断提高软件的质量，为用户使用该产品提供可靠的保障。
（2）支持必要的升级：软件一旦完成，外部运行环境不会一成不变。无论是运行环境，还是政策法规的变更都可能导致用户要求升级该软件，维护活动可以有效地延长软件服务期限。
（3）支持用户的改进请求：随着用户体验的不断增加或者用户业务的不断发展，现有软件可能无法满足用户的需求。这种情况下重新开发新的软件，无论从进度和成本角度都不如改进已有软件。
（4）为将来的维护工作提供便利：即使用户本身暂时没有改进的需求，维护团队也可以优化软件，为将来可能的维护活动奠定基础。

随着信息技术的不断发展，硬件在整个系统成本中所占的百分比逐渐降低，而软件成本则逐渐提高，尤其是软件维护成本，如图所示。

可以看出到1985年软件维护成本已经达到并超过了软件开发的成本。

软件产品在发布后，并非保持不变。无论是遗留的缺陷，还是用户要求的功能增强，都可能导致软件的变更。在软件产品的维护过程中需要进行的活动有很多，经过分析归纳可分为如下4类。
（1）纠正
纠正类的维护活动主要由在软件中发现的缺陷所触发，这里的缺陷可能是设计缺陷、逻辑缺陷或编码缺陷，所有这些可能的缺陷都会导致用户无法实现其期望的功能。而通常在维护过程中发现的缺陷由于受到客户的压力很大，其严重程度或优先级都很高，需要开发团队快速解决或者提供可替代的解决方案。
（2）适应
即使软件没有因为缺陷而变更，也可能为了适应新的操作环境而改变，适应类的维护活动就是为了使得软件能够在新的操作环境下正常运行而需要进行的变更。这里操作环境的范围很广，可能是商业规则、政府策略、工作模式或者软硬件操作平台等。例如，原来的软件运行在操作系统Solaris 9下，为了使得该软件在更新的操作系统版本Solaris 10上正常运行，需要对该软件产品进行一定的修改。
（3）完善
软件产品本身工作得很好，但是随着用户新需求的不断出现，需要对软件产品根据用户的新需求进行不断地完善。当然要想后期能够不断地增加软件的新功能，就需要更完善的软件架构设计。
（4）预防
上面3种维护活动都是被动的，而预防是主动的维护活动，通常是为了避免缺陷的发生或者提高软件的可维护性。这样的维护活动通常由负责软件维护的团队发起，使软件更容易理解，进而使将来可能的维护任务更容易，如优化代码或者更新文档等。

原则上，上述的4种软件维护活动是互相独立的。但在实际的软件开发过程中，很多时候是交织在一起的。例如，某软件需要在新的操作系统上运行（属于适应类的维护活动），在修改过程中可能引入新的缺陷（修复这些缺陷属于纠正类的维护活动）。还有在一个数据处理软件中采用更有效的排序算法（属于完善类的维护活动）可能需要重构已有软件（属于预防类的维护活动）。这几种维护活动的潜在关系如图所示。

软件的维护并不一定一次完成，在整个软件开发生命周期中可能需要很多次维护。针对一个紧急的缺陷或需求，可能会单独发布新的版本或补丁，而大部分情况下软件的维护可能包括多个变更。

IBM提供的维护活动（部分）
硬件维修服务是指在接到设备故障报告后IBM工程师将及时赶赴现场，并根据设备的不同状况采取适当的维护措施，主要包括如下措施。
（1）记录和分析错误，并实施故障诊断。
（2）携带备件及时现场维修与更换。
（3）升级系统板卡和设备的微代码。
（4）采取系统检测诊断（Diagnostic Online/Offline）。
（5）对设备实行定期的预防性维护。
（6）提供设备维护、维修记录和报告。
（7）辅导掌握系统的基本操作，并给予技术支持。
（8）为用户提供技术培训和传授经验。

系统软件维护服务的内容如下。
（1）提供系统软件操作方面的24小时电话答疑。
（2）提供系统维护、调整及安全性设置等方面的技术支持。
（3）记录与分析错误，为操作系统做故障诊断。
（4）实施系统增强和修补程序（PTFs）的分发、安装和测试。
（5）辅导掌握系统软件的基本操作，并给予技术支持。
（6）对系统软件运行实施定期预防性的维护和检查。
（7）提供系统优化和性能调整。
（8）提供设备维护、维修记录和报告。

提高软件的可维护性

软件产品的维护不仅仅是修复软件代码，还包括文档和操作手册。软件产品的组成如下表所示。

（1）软件的可维护性
维护程序时，不可避免地需要分析代码，而代码的易读性和易分析性将直接影响该软件的可维护性。软件的易读性和易分析性涉及命名规则、注释、嵌套的深度、简单性、分解结构和编码规范等。

各个变量、常量、函数和文件名等直接影响到软件的易读性。命名最好与其能够提供的功能或相关的对象相关联，这样便于维护人员对代码的理解。下面这段代码很难理解：

A:=FALSE;
WHILE NOT A DO
    IF B.C=B.J THEN
        B.E:=B.E+D.F;
        IF G.EOF THEN
            A:=TRUE;
        ELSE
            ReadBlock(G,D) ;
        END;
    ELSE
        WriteBlock(H,B) ;
        ReadBlock(I,B) ;
    END;
END;

如果变量、函数或类的名称能与其要表达的功能相关，那么易读性将会大大增强。优化后的上述代码如下：

EndOfUpdate:=FALSE;
WHILE NOT EndOfUpdate DO
    IF UserRec.id=UserRec.UpdateNumber THEN
        UserRec.Used:=UserRec.Used+UpdateRec.ResourcesUsed;
        IF UpdateFile.EOF THEN
            EndOfUpdate:=TRUE;
        ELSE
            ReadBlock(UpdateFile,UpdateRec);
        END;

    ELSE
        WriteBlock(NewUsersFile,UserRec);
        ReadBlock(UserFile,UserRec)
    END;
END;

通过优化，可以发现增强了代码的可维护性。除了优化命名外，还可以通过增加注释的方式来增强软件的可维护性。不仅要为每段代码增加注释，为每个函数、类或者文件均应增加相应的注释，注释可以包括实现的功能、采用的算法、输入输出的数据和一些注意事项。有时软件的代码是维护人员获得信息的惟一渠道，这种情况下提供准确而丰富的注释信息就显得更为重要。

（2）文档的可维护性
软件维护发生在系统开发完成后，开发人员可能已经开始其他项目，甚至已经离职。此时文档成为维护人员获得相关信息的重要渠道，这里的文档包括开发文档和操作规程等。维护人员在维护软件之前必须通过阅读相关文档尽可能多地了解需要维护的对象，可以通过文档了解软件的功能、设计、实现和其他与维护相关的问题。如果文档不准确或者已经过时，即与当前的软件并不一致，维护人员不得不通过代码还原相关文档。为了提高文档的可维护性，可以从以下几个方面考虑。

• 写作风格：使用清晰且易理解的文字。例如，尽量使用主动句，减少被动句，而且应当通过多个角度解释复杂的对象。
• 符合文档规范：采用标准的字体和章节编号可以使得维护人员能够很容易地从文档中获得信息，而且在阅读不同的文档时能够很快适应；同时标准的封面和历史记录都有助于跟踪文档的变化信息。
• 提供工具支持：采用合适的工具可以提高文档的可维护性，将文档和具体的实现相关联，当软件实现变化时可以通知作者及时更新文档。

系统需求规格说明的可维护性要求
（1）一致性：在软件产品内部或不同软件产品之间是否存在相互矛盾或容易引起误解的需求描述，为此需要清楚而一致地定义一些名词和术语，避免在设计和执行阶段产生不一致。随着软件功能的不断加强，现在的软件系统需求越来越庞大。一个软件的需求可能由多个团队共同开发完成，因此不同的团队之间也要保证一致性。
（2）可测试性：需求的条目可以通过测试用例验证，并且可以明确地判断测试的输出。如果不能测试需求，至少需要在文档中明确标识并评估可能存在的风险。不可测试的需求包括“工作正常”、“良好的用户界面”和“通常应该发生”之类的描述，因为“正常”、“良好”和“通常”等不易定义，因此这些需求不可能被测试。
（3）可修改性：需求应该具有连贯和方便使用的结构，包括目录、索引及清晰的相互引用，这样能够保证修改任何需求都比较容易。需求中尽量减少冗余，尽管冗余本身不是缺陷，但容易导致错误。尽管少量的冗余可能有助于系统需求的可读性，但更新存在冗余的内容时可能会引发问题。例如，可能对多次出现的某个需求仅在一处进行了修改，导致需求内容的不一致。当需要冗余时，可以采用交叉索引表的形式增加可修改性。
（4）可跟踪性：系统需求和软件产品中与之相关的其他部分能够相互关联，修改某个需求应该能够知道所有与之相关或受影响的部分。比较好的一种方法是将需求划分为可管理的不同需求组，这样需求之间的关联存在两种情况，即需求组内的关联和需求组间的关联；同时每个需求都要有一个明确的标识，这样有利于建立跟踪关系。

酷客教程相关文章：

• 效率测试
• 易用性测试
• 可靠性测试
• 辅助性测试