文档测试的意义

首先引用网络上的一段对文档的分类：

文档测试有三大类分别是开发文件、用户文件、管理文件。
1. 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗等。
2.用户文件：用户手册、操作手册。
3.管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

在这里，我想阐述的文档测试主要针对开发文件（关于用户文件的测试资料已经不少了）。

测试开发文件的目的是什么？

第一个目的，预防缺陷。

记得在哪儿看过，测试的最高境界是“预防缺陷”（我一直认为这个理解不是很正确，应该说，质量保证的最高境界才是“预防缺陷”）。作为测试人员（也算一部分质量保证人员），这也是对我们的一种要求。而进行开发文件的测试（主要手段是评审），无疑能够帮助开发人员减少出现例如需求需求理解错误，异常边界保护错误等类型的BUG。

第二个目的，建立测试参照物。

我们团队犯过各种错误，其中之一是由于文档的不确定性，造成测试过程中的扯皮，而且这种与开发人员的分歧基本上要等到软件进行发布评审时才得到确认与解决，无形中增加了软件发布的风险。而及时进行开发文件的测试与评审，能够有效减少这种分歧，为测试执行时尽早确认一个参照物。

测试的尽早原则每个测试者都很清楚，但是受到环境、能力的影响（例如集成条件不够灵活、没有宿主环境、没有单元测试的能力等），必须等待到第一版测试软件发布才能进行测试。在开发过程中，测试无法体现在这个阶段的价值。而进行开发文档的测试，无疑是一个比较好的策略，从测试的角度评审文档，对软件工程而言，降低了缺陷产生的可能性，同时，确定了测试者与开发者的统一理解，为测试建立了一个良好的参照物，也为后续的测试降低了风险。

我们也必须看到，在实际工作中，文档可能永远无法完善到使所有人满意。但是了解了文档测试的目的后，我们应该有选择的进行测试，同时也必须避免走入“文档唯一化”的另一个误区。只要达到文档测试的目的，部分是可以妥协的。

运用之妙，存乎一心，不是么？