[概述]

　　可维护性测试，我们常常将重点关注在软件产品新增功能或者缺陷修改以后的产品动态测试上面，而文档的可维护性测试往往被遗忘在某个角落。

　　[正文]

　　可维护性指的是软件产品可被修改的能力，这里的修改包括纠正、改进或者软件对环境、需求和功能规格说明变化的适应能力。因此，测试人员在面临各种变更的时候，都需要进行相应的可维护性测试，例如：

　　● 软件产品在用户使用现场发现了缺陷，需要开发团队快速的解决或者提供可替换的解决方案；

　　● 软件产品需要在新的操作环境中使用，例如：原来的软件是运行在操作系统Solaris 9下的，为了使得该软件在更新的操作系统版本Solaris 10上正常运行，需要对该软件产品进行一定的修改；

　　● 软件产品本身工作的很好，但是随着用户新需求的不断出现，需要对软件产品根据用户的新需求进行不断的完善；

　　针对上面三种维护活动进行的可维护性测试，是测试过程中测试人员经常执行的测试，它们都是被动的。为了避免缺陷的发生或者提高软件的可维护性，我们还可以进行有效的预防性可维护性测试。这样的维护活动通常由负责软件维护的团队自己发起，而使得软件更容易理解，进而使得将来可能的维护任务更容易。本文将针对文档的可维护性测试，提出笔者的一些观点和建议。

　　软件的维护都发生在系统开发完成后，而当初负责系统开发的人员可能已经转移到其他项目中去，甚至已经离开了公司。所以文档成为维护人员获得相关信息的重要渠道。这里的文档既包括开发文档，也包括操作规程。维护人员在对软件进行维护之前，必须通过阅读相关文档，尽可能多的了解需要维护的对象。维护人员可以通过文档了解系统的具体功能、设计、实现和其他维护相关的问题。但是有时系统的文档可能并不准确或者已经过时了，和当前的软件并不一致。在这种情况下，维护人员不得不通过代码来还原相关的文档。为了提高文档的可维护性，可以从以下几个方面考虑：

　　● 写作风格：使用清晰、易理解的文字，例如：尽量使用主动句，减少使用被动句；对于复杂的对象，可以通过多个角度进行解释；

　　● 符合文档规范：采用标准的字体、章节编号可以使得维护人员能够很容易的从系统文档中获得信息，而且维护人员在阅读不同的文档时，能够很快适应；同时标准的封面和历史记录都有助于跟踪文档的变化信息。

　　● 提供工具支持：采用合适的工具可以提高文档的可维护性，将文档和具体的实现相关联，当软件实现发生变化的时候，可以通知作者及时更新文档。

　　下面是针对系统需求规格说明的可维护性要求，即它可以作为文档可维护性测试的检查表，对系统需求规格说明进行有效的测试。

　　1）一致性

　　在产品内部或在不同产品之间是否存在相互矛盾或容易引起误解的需求描述。这需要对一些名词和术语进行清楚而一致的定义，避免在设计和执行阶段产生不一致。随着软件功能的不断加强，现在的软件系统需求越来越庞大。一个软件的需求可能由多个团队共同开发完成，因此，不同的团队之间也要保证一致性。

　　2）可测试性

　　需求的条目可以通过测试用例进行验证，并且测试的输出可以进行明确的判断。假如不能进行需求的测试，至少需要在文档中明确标识，并评估可能存在的风险。不可测试的需求包括“工作正常”、“良好的用户界面”和“通常应该发生”之类的描述。因为“正常”、“良好”、“通常”等不易定义，因此，这些需求不可能被测试。

　　3）可修改性

　　系统需求应该具有连贯和方便使用的结构，包括目录、索引以及清晰的相互引用，这样能够保证对任何需求进行修改都比较容易。需求中尽量减少冗余，尽管冗余本身不是缺陷，但它容易导致错误。尽管少量的冗余可能有助于系统需求的可读性，但当对存在冗余的内容进行更新时，可能会引起问题，例如：可能对多次出现的某个需求仅在一处进行了修改，导致需求内容的不一致。当需要冗余的时候，可以采用交叉索引表的形式，以增加可修改性。

　　4）可跟踪性

　　系统需求和系统中与之相关的其他部分能够相互关联。对某个需求的修改，应该能够知道系统中所有与之相关或受影响的部分。比较好的一种方法是将需求划分为可管理的不同需求组。这样，需求之间的关联存在两种情况：需求组内的关联和需求组间的关联。同时，每个需求都要有一个明确的标识，这样有利于跟踪关系的建立。