基本原则
1、了解梗概：通过浏览目录，对文档内容有个大致了解
2、逻辑次序：文档主题以及相关步骤的先后顺序是相当重要的，在论述一个主题或者步骤之前，必须先完成另外一个主题或者步骤。
3、读者：注意该文档的读者是谁
● 这个文档是写给谁看的，文档里提供的信息是否适合这些读者？（这读者是个系统管理员？开发人员还是最终用户呢？）
● 这些信息是否过于专业化或者不够专业化呢？
● 读者是否需要其它一些类型的信息呢？
4、正式讨论：当你完成一个文档测试后，准备花10到15分的时间与文档的作者讨论一下你的意见和观点。
测试用户文档
注：这类型的文档主要是以面向用户为主，包括安装向导，管理工具指南，用户使用指南。
1、总览全部信息：检查信息描述是否专业化 - 即使是商业用途，也要有专业语言描述。
2、检查截图：
● 是否所有截图都是最新的？
● 是否包括所有必需的截图？
● 是否所有截图正确定义和标记？
● 是否截图所有的显示和菜单选项都与定义的相符合。（比如说，如果截图上有一个菜单显示为“Horizon System Administrator”，那么文档内容就不能写出“ Horizon Sys Admin”。）
3、链接到其他章节或文档：
● 该链接是否能够跳转到正确的页码和章节？
● 如果是要参考其他的文档的话，那该参考文档是否正确？
4、专用术语问题
● 是否由于遗漏或者不精确的技术信息，而令到某些段落或章节必须要编写呢（即原本不需要写的）？如果有的话，马上告诉文档的作者 – 不用等到你检查完整个文档之后再提出来。
● 如果有重要的技术信息遗漏，马上告诉文档的作者 – 不用等到你检查完整个文档之后再提出来。
● 对于第一个测试草稿 - 第二个草稿 – 可以再原稿上注明问题和关注点。
● 对于最终的测试草稿，除了再原稿上注明问题之后，如果你的部门有使用缺陷跟踪管理系统的话，也要把这些问题记录在系统里。
测试开发文档
注：开发文档包括API的信息，开发工具，开发模板等等。
1、检查列表：测试用户文档的检查列表同样适用于测试开发文档。
2、总览全部信息：在这类文档中，技术审查概述和总述章节的内容是非常重要的，因为与用户文档相比，它包括更多的技术内容。
3、功能准确性
● 文档是否准确描述系统操作流程？
● 文档是否描述怎样调用功能的方法？
● 文档是否描述同一功能用不同方法的结果，以及是否说明程序员为何选择这个方法而不选择其他方法的原因？