软件产品包含的是可运行的程序、文档、数据三部分。文档是其不可或缺的一部分，其重要性不言而喻。
一般将其分为两大类：
· 开发实施文档：需求说明书、概设、详设、数据库设计文档、实施方案、测试方案，测试报告、用户操作说明书，安抓部署手册等
· 管理文档：计划文档、实施方案、项目总结报告、阶段工作报审表(甲乙方/监理三方盖章）、项目变更文档、会议纪要、周报/月报。
1.1 测试目的是检查文档的完整性、正确性、一致性、易理解性、易浏览性。
完整性
给用户的文档必须是完整的，能完整描述软件程序的业务逻辑、所有功能。就像我们购买一个衣柜，如果没有使用说明书或者说明书不全，只描述了外框架部分，有几个板子没有描述，那大家组装时估计都要骂娘了吧。用户使用说明书是最直观的学习使用软件程序的文档，任何遗漏或者缺失对用户来说都是不可忍受的。因此一定要测试文档的完整性。
我们在测试用户文档时依据先大后小的原则进行（先看大的框架，然后再看具体细节），具体如下：
· 交付文档与招投标和合同的验收交付要求是否一致完整。
· 会议纪要最后日期与项目初验和完成日期是否一致。
· 周报、双周报、月报与合同验收要求频次是否一致。
· 先看目录。一般目录对应软件程序的各个模块；我们用软件程序与目录一一比较，看是否齐全，先比较一级目录，无误后二级目录，依次类推。如果目录有缺失，那文档显然是有问题的。此时我们要分析下是章节内容提炼的有问题（目录写的有问题）还是真的没有这部分。
· 再看每章节内容。确认目录与软件程序模块能一一对应后那基本可以确认从功能点上来说文档是完整的。接下来，我们就要查看其内容是否完整，比如有些小的功能点太小了，可能就不会出现在目录中，那么手册里是否有描述？需要依据需求说明书与软件程序为依据，来逐行检查用户文档的完整性。
正确性
举例来说，还是上述例子，想象下，工作人员在编写使用说明书时候把一个木板画错了，长板画成了短板，那大家根据他的这个说明书还能组装起来么？即使能组装也会麻烦很多是吧。如果组装不起来那么大家一般会怎么样？退款？退款且差评？卖家的损失是显而易见的。由此可见正确性的重要性。
具体测试要注意如下几点：
· 先确认文档的完整性，再确认每个模块的正确性，即每一章节的正确性。
· 根据文档手册描述逐步操作，确认文档是否描述正确。
· 针对配置部分，复制手册上面的配置信息看是否能配置成功，这样做是因为标点符号存在中英文标点，不同格式的标点和空格都有可能导致结果的不同。
一致性
一致性表现在术语一致性和内容一致性。
1. 术语一致性：
· 用到的术语要适用于用户群，且最好在文档中的附录部分或者专门章节有术语介绍。
· 所有的文档以及软件程序中术语描述一致。
· 所有的术语应该是大众认可的，最好不私自创造术语，除非市面上没有相应产品或者概念。
2. 内容一致性：
· 用户文档中的内容与实际软件程序要相符合，包括提示语、结果、帮助信息等等。
· 用户文档中的图与真实界面保持一致。
· 功能模块在需求文档、设计文档、测试报告中是否一致；测试
· 测试报告结论与招投标、合同、需求文档、变更文档要求是否一致。
· 目录与内容是否一致
· 项目名称，公司名称，logo是否与招投标和合同要求是否一致
如有任何不符，那么即是文档bug。
易理解性
用户文档要通俗易懂，如果写的很高深，业界人士觉得很有水平，但是对于普通人士来讲完全不明白，那么这个文档就是一堆无用的垃圾，文档无用，相应的软件程序也就无用了，因为大家都不会用啊。
· 用户文档文字描述一定要考虑受众，也就是用户群，根据用户群水平来编写。
易浏览性
用户文档不仅要易理解，还要易读，易看，比如直接给用户一个长达两万的文字说明，估计没人会看吧。易浏览性的测试点如下：
· 用户文档需要图文并茂，最好图能多过文字，图为指导，文字作为辅助说明。
· 介质：通常电子版的我们需要用pdf格式，首先是因为pdf好的兼容性，另外是为了杜绝用户非法篡改我们的文档。
1.2 产品说明书用语检查清单说明:对问题的描述通常表现为粉饰没有仔细考虑的功能---可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一-种情况都可视为软件缺陷 9.总是，每- -种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可 以着手设计针锋相对的案例 10.当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。 11.某些，有时，常常,通常,惯常,经常，多,几乎。这些话太过模糊，"有时"发生作用的功能无 法测试。 12.等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确, 以免让人迷惑，不知如何推论。 13.良好,迅速，廉价，高效,小,稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现, 就必须进一步指明含义。 14.已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。 15.如果..那么.没有否则)。找出有"如果...那么...而缺少配套的"否则"结构的陈述，想一想 如果"没有发生会怎样。
3. 桌面检查、代码审查、代码走查、代码审计设计评审和：设计上，要验证其是否遵守软件开发标准，是否具有国际化特性的一些基本功能；
桌面检查： 人工检查的第二种古老的检查方式。其方法是由一个人，一般是开发员自己对照错误列表进行对比检查，对程序推演测试数据。
代码审查，代码审查：代码审查由高级管理人员来领导评审小组的活动。代码审查：代码审查是一种正式的评审活动。代码审查：代码审查除了检查代码中是否有错误，还要检查程序与设计文档的一致性
代码走查: 静态分析技术或评审过程，在此过程中，设计者或程序员引导开发组的成员通读已书写的设计或编码，其他成员负责提出问题并对有关技术、风格、可能的错误、是否违背开发标准等方面进行评论。有测试人员的参与，需要有结构简单,数量不多的测试用例，代码走查：代码走查的讨论过程是非正式的。代码走查：代码走查只检查代码中是否有错误。
代码审计：由某人、某小组或借助某种工具对源代码进行的独立的审查，一般第三方参与，以验证其是否符合软件设计文件和程序设计标准。还可能对正确性和有效性进行估计。//教材
