大家好，我是十一。
我们想下，通常购物拿到的商品都包含什么？只有商品嘛？显然不是，应该还有使用说明书、三包之类的东西；软件也是一样的，它也是商品，那提供给用户的不仅仅是可运行的程序，还包含文档，除此之外，因为他是虚拟产品，需要的是数据支撑；所以他还得包含数据。
总结一下：软件产品包含的是可运行的程序、文档、数据三部分。文档是其不可或缺的一部分，其重要性不言而喻。
概念
文档测试是指直接针对软件工程中各环节文档，检查其完整性、正确性、一致性、易理解性、易浏览性的测试。
文档的范围
这里我们要明确的是软件过程中的文档并不只有交付给用户的这部分文档，通常《软件生命周期》和《测试生命周期》章节大家已经知道了在软件生产过程中也会产生很多文档。一般将其分为三大类：
· 开发文档：需求说明书和在开发阶段（开发＋测试）的相关文档（设计文档、方案等）我们称之为开发文档；
· 用户文档：最终交付给客户的相关文档，例如使用说明书，帮助文档等称其为用户文档；
· 管理文档：而在整个软件生命期中相关的项目进度安排、计划文档等这些称之为管理文档。
通常，所有的文档产生后我们都需要先经过测试，测试通过后才能作为下一阶段开始的依据。这样做的目的就是为了防止因为人员知识水平、经验高低等各类原因而使得项目偏离甚至崩溃；从上图也可以看出我们在各个阶段都会对产出物做评审，这其实就是在测试，只是执行人并不都是软件测试人员（不明白的可以回头去软件生命周期和测试生命周期这两篇看看）。
今天我们主要讲的是用户文档的测试。
用户文档的测试
测试目的是检查用户文档的完整性、正确性、一致性、易理解性、易浏览性。
完整性
给用户的文档必须是完整的，能完整描述软件程序的业务逻辑、所有功能。就像我们购买一个衣柜，如果没有使用说明书或者说明书不全，只描述了外框架部分，有几个板子没有描述，那大家组装时估计都要骂娘了吧。用户使用说明书是最直观的学习使用软件程序的文档，任何遗漏或者缺失对用户来说都是不可忍受的。因此一定要测试文档的完整性。
我们在测试用户文档时依据先大后小的原则进行（先看大的框架，然后再看具体细节），具体如下：
· 先看目录。一般目录对应软件程序的各个模块；我们用软件程序与目录一一比较，看是否齐全，先比较一级目录，无误后二级目录，依次类推。如果目录有缺失，那文档显然是有问题的。此时我们要分析下是章节内容提炼的有问题（目录写的有问题）还是真的没有这部分。
· 再看每章节内容。确认目录与软件程序模块能一一对应后那基本可以确认从功能点上来说文档是完整的。接下来，我们就要查看其内容是否完整，比如有些小的功能点太小了，可能就不会出现在目录中，那么手册里是否有描述？需要依据需求说明书与软件程序为依据，来逐行检查用户文档的完整性。
正确性
举例来说，还是上述例子，想象下，工作人员在编写使用说明书时候把一个木板画错了，长板画成了短板，那大家根据他的这个说明书还能组装起来么？即使能组装也会麻烦很多是吧。如果组装不起来那么大家一般会怎么样？退款？退款且差评？卖家的损失是显而易见的。由此可见正确性的重要性。
具体测试要注意如下几点：
· 我认为我们要先确认文档的完整性，再确认每个模块的正确性，即每一章节的正确性。
· 根据文档手册描述逐步操作，确认文档是否描述正确。
· 针对配置部分，复制手册上面的配置信息看是否能配置成功，这样做是因为标点符号存在中英文标点，不同格式的标点和空格都有可能导致结果的不同。
一致性
一致性表现在术语一致性和内容一致性。
1. 术语一致性：
· 用到的术语要适用于用户群，且最好在文档中的附录部分或者专门章节有术语介绍。
· 所有的文档以及软件程序中术语描述一致。
· 所有的术语应该是大众认可的，最好不私自创造术语，除非市面上没有相应产品或者概念。
2. 内容一致性：
· 用户文档中的内容与实际软件程序要相符合，包括提示语、结果、帮助信息等等。
· 用户文档中的图与真实界面保持一致。
如有任何不符，那么即是文档bug。
易理解性
用户文档要通俗易懂，如果写的很高深，业界人士觉得很有水平，但是对于普通人士来讲完全不明白，那么这个文档就是一堆无用的垃圾，文档无用，相应的软件程序也就无用了，因为大家都不会用啊。
· 用户文档文字描述一定要考虑受众，也就是用户群，根据用户群水平来编写。
易浏览性
用户文档不仅要易理解，还要易读，易看，比如直接给用户一个长达两万的文字说明，估计没人会看吧。易浏览性的测试点如下：
· 用户文档需要图文并茂，最好图能多过文字，图为指导，文字作为辅助说明。
· 介质：通常电子版的我们需要用pdf格式，首先是因为pdf好的兼容性，另外是为了杜绝用户非法篡改我们的文档。
好了，今天就到这里了，我们下期再见！Bye~
