|
|
|
文档测试分为两类，如果是非程序，例如打印的手册或产品包装盒，其测试可以视为技术校对。如果文档和程序紧密结合，例如超链接形式的电子手册或联机帮助，或助手一类的帮助系统，就要进行与程序测试类似的测试。
|
|
|
|
无论是文档或是程序，作为文档测试人员，都必须像用户那样对待它，应该说像最仔细的用户那样，认真阅读，跟随每个步骤，检查每个图形，尝试每个示例。只有这样，才能尽可能找出软件和文档中的缺陷。
|
|
|
|
|
|
. 读者群。文档面向的读者定位要明确。对于初级用户，可能需要从鼠标的用法、点击确定按钮等讲起；对于中级用户，重要界面的截图和关键步骤每一个参数的选择方法都需要介绍；对于高级用户，则没有必要给出太多的界面截图，但对重要参数的讲解一定要深入，用词要专业。特别是不论用户群定位如何，文档都不可以写成散文、诗歌或者侦探、言情小说，文档的目的是要让用户看得懂，能理解。
|
|
|
|
. 术语。文档中用到的术语要适用于定位的读者群，用法一致，标准定义与业界规范相吻合。如果有索引或交叉引用，所有的术语都应能够进行索引和交叉引用。如果术语较多，在纸介质手册的末尾应给出术语索引；如果被测软件提供二次开发功能，有大量函数，则有必要编写独立的函数手册和开发指南。
|
|
|
|
. 正确性。这是非常重要的，会占用文档测试的大量时间和人力。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录、索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。
|
|
|
|
. 完整性。慢慢地仔细阅读文字，完全根据提示进行操作，不要作任何假设。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到，耐心补充遗漏的步骤。用户不会知道遗漏了什么信息，直到有一天他使用软件时走到了这个分支。对于极其熟悉被测软件的人来说，这项测试相当困难，因为思路已固定地按照一定的流程去测试，极易忽略不常用的部分。因此，可以考虑让不是很熟悉被测软件的人员进行此项目的测试。
|
|
|
|
. 一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述相同。要留意软件界面上出现的版本号与手册、帮助上的信息是否一致。
|
|
|
|
. 易用性。纸介质文档可以通过目录、关键词索引提高用户使用的易用性。条理清晰、结构合理的文档是优质软件的一个显著特征。对关键步骤以粗体或背景色给用户以提示，合理的页面布局、适量的图表都可以给用户更高的易用性。电子文档或帮助系统显然比纸介质在这方面有更大的优势。需要注意的是，文档要有助于用户排除错误，只描述正确操作而不描述错误处理办法的文档是不负责任的。与程序大多用于错误处理一样，文档对于用户看到的错误信息应当有更详细的文档解释，而且不应让用户花费太多的时间去寻找所需的解释。
|
|
|
|
. 图表与界面截图。检查所有图表与界面截图是否与发行版本相同。对于成熟的软件开发商来说，界面在设计阶段就应基本确定，不应在软件开发后期有大的变动。而此项测试就是要发现在文档完成后是否有界面变动，确保屏幕截图源于发行版本。测试中还要注意图表标题的正确性。
|
|
|
|
. 样例和示例。像用户一样载入和使用样例。如果是一段程序，就输入数据并执行它。以每一个模板制作文件，确认它们的正确性。想像一下样例不能执行的问题交给技术支持人员时的情景……
|
|
|
|
. 语言。对于英语文档来说，拼写和语法检查器太常见了，一般不会出现拼写和语法错误。但对于中文文档来说，可以采用一些校对工具辅助人工检查，并进行细致专业的校对，不要让用户发现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字，不能想当然，没有任何工具能够从图形中找出语法错误。
|
|
|
|
. 印刷与包装。文档测试似乎完成了，文档终于变成精美的册子，这时，测试人员还需抽查印刷质量，看看手册厚度与开本是否合适，翻看起来是否方便，包装盒的大小是否合适，光盘盒的固定有没有问题，有没有零碎易丢失的小部件等等。这时发现的问题，如果不是太严重，已不可能在这个版本中进行改进，但对下一个版本的制作来说是非常有价值的。
|
|
|
