基本原则

　　1、了解梗概：通过浏览目录，对文档内容有个大致了解

　　2、逻辑次序：文档主题以及相关步骤的先后顺序是相当重要的，在论述一个主题或者步骤之前，必须先完成另外一个主题或者步骤。

　　3、读者：注意该文档的读者是谁

　　● 这个文档是写给谁看的，文档里提供的信息是否适合这些读者？（这读者是个系统管理员？开发人员还是最终用户呢？）

　　● 这些信息是否过于专业化或者不够专业化呢？

　　● 读者是否需要其它一些类型的信息呢？

　　4、正式讨论：当你完成一个文档测试后，准备花10到15分的时间与文档的作者讨论一下你的意见和观点。

　　测试用户文档

　　注：这类型的文档主要是以面向用户为主，包括安装向导，管理工具指南，用户使用指南。

　　1、总览全部信息：检查信息描述是否专业化 - 即使是商业用途，也要有专业语言描述。

　　2、检查截图：

　　● 是否所有截图都是最新的？

　　● 是否包括所有必需的截图？

　　● 是否所有截图正确定义和标记？

　　● 是否截图所有的显示和菜单选项都与定义的相符合。（比如说，如果截图上有一个菜单显示为“Horizon System Administrator”，那么文档内容就不能写出“ Horizon Sys Admin”。）

　　3、链接到其他章节或文档：

　　● 该链接是否能够跳转到正确的页码和章节？

　　● 如果是要参考其他的文档的话，那该参考文档是否正确？

　　4、专用术语问题

　　● 是否由于遗漏或者不精确的技术信息，而令到某些段落或章节必须要编写呢（即原本不需要写的）？如果有的话，马上告诉文档的作者 – 不用等到你检查完整个文档之后再提出来。

　　● 如果有重要的技术信息遗漏，马上告诉文档的作者 – 不用等到你检查完整个文档之后再提出来。

　　● 对于第一个测试草稿 - 第二个草稿 – 可以再原稿上注明问题和关注点。

　　● 对于最终的测试草稿，除了再原稿上注明问题之后，如果你的部门有使用缺陷跟踪管理系统的话，也要把这些问题记录在系统里。

　　测试开发文档

　　注：开发文档包括API的信息，开发工具，开发模板等等。

　　1、检查列表：测试用户文档的检查列表同样适用于测试开发文档。

　　2、总览全部信息：在这类文档中，技术审查概述和总述章节的内容是非常重要的，因为与用户文档相比，它包括更多的技术内容。

　　3、功能准确性

　　● 文档是否准确描述系统操作流程？

　　● 文档是否描述怎样调用功能的方法？

　　● 文档是否描述同一功能用不同方法的结果，以及是否说明程序员为何选择这个方法而不选择其他方法的原因？