文档测试

最近整理一些文档测试的内容，收集资料完毕后，在此总结一下。

文档测试是指直接针对软件工程中各环节文档，检查其正确性的测试。

文档测试范畴

软件产品由可运行的程序、数据和文档组成。文档是软件的一个重要组成部分。

在软件的整个生命周期中，会用到许多文档，在各个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依据。在软件的开发过程中，软件开发人员需根据工作计划和需求说明书由粗而细地进行设计，这些需求说明书和设计说明书构成了开发文档。为了使用户了解软件的使用、操作和对软件进行维护，软件开发人员需要为用户提供详细的盗料．这些资料称为用户文档。而为了使管理人员及整个软件开发项目组了解软件开发项目安排、进度、资源使用和成果等，还需要制定和编写一些工作计划或工作报告，这些计划和报告构成了管理文档。

文档内容

测试方案

主要设计怎么测试什么内容和采用什么样的方法，经过分析，在这里可以得到相应的测试用例表。

测试执行策略

可以主要包括哪些可以先测试，哪些可以放在一起测试之类的。

测试用例

主要根据测试用例列表，写出每一个用例的操作步骤、紧急程度、预置结果和备注信息。

BUG描述报告

主要可以包括，测试环境的介绍，预置条件，测试人员，问题重现的操作步骤和当时测试的现场信息。

整个项目的测试报告

从设计和执行的角度上来对此项目测试情况的介绍，从分析中总结此次设计和执行做的好的地方和需要努力的地方和对此项目的一个质量评价。

用户文档测试要点

1、读者群。文档面向的读者定位要明确。对于初级用户．可能需要从鼠标的用法、  点击确定按钮等讲起：对于中级用户，重要界面的截图和关键步骤每一个参数  的选择方法都需要介绍：对于高级用户．则没有必要给出太多的界面截图，但对重要参数的讲解一定要深入．用词要专业。特别是不论用户群定位如何．文档都不可以写成散文、诗歌或者侦探、言情小说．文档的目的是要让用户看得懂．能理解。

2、术语。文档中用到的术语要适用于定位的读者群。用法一致。标准定义与业界规范相吻合。如果有索引或交叉引用，所有的术语都应能够进行索引和交叉引用。如果术语较多，在纸介质手册的末尾应给出术语索引：如果被测软件提供二次开发功能．有大量函数．则有必要编写独立的函数手册和开发指南。

3、正确性。这是非常重要的．会占用文档测试的大量时问和人力。测试中需检查所有信息是否真实正确，查找由于过期产品说明书和销售人员夸大事实而导致的错误。检查所有的目录，索引和章节引用是否已更新，尝试链接是否准确，产品支持电话、地址和邮政编码是否正确。

4、完整性。慢慢地仔细阅读文字．完全根据提示进行操作，不要作任何假设。对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到，耐心补充遗漏的步骤。用户不会知道遗漏了什么信息，直到有一天他使用软件时走到了这个分支。对于极其熟悉被测软件的人来说，这项测试相当困难，因为思路己固定地按照一定的流程去测试．极易忽略不常用的部分。因此．可以考虑让不是很熟悉被测软件的人员进行此项目的测试。

5、一致性。按照文档描述的操作执行后，检查软件返回的结果是否与文档描述相同。要留意软件界面上出现的版本号与手册、帮助上的信息是否一致。

6、易用性。纸介质文档可以通过目录、关键词索引提高用户使用的易用性。条理清晰、结构合理的文档是优质软件的一个显著特征。对关键步骤以租体或背景色给用户以提示．合理的页面布局、适量的图表都可以给用户更高的易用性。电子文档或帮助系统显然比纸介质在这方面有更大的优势。需要注意的是．文档要有助于用户排除错误．只描述正确操作而不描述错误处理办法的文档是不负责任的。与程序大多用于错误处理一样．文档对于用户看到的错误信息应当有更详细的文档解释，而且不应让用户花费太多的时间去寻找所需的解释。

7、图表与界面截图。检查所有图表与界面截图是否与发行版本相同。对于成熟的软件开发商来说．界面在设计阶段就应基本确定，不应在软件开发后期有大的变动。而此项测试就是要发现在文档完成后是否有界面变动．确保屏幕截圈源于发行版本。测试中还要注意图表标题的正确性。

8、样例和示例。像用户一样载入和使用样例。如果是一段程序．就输入数据并执行它。以每一个模板制作文件．确认它们的正确性。想像一下样例不能执行的问题交给技术支持人员时的情景……

9、语言。对于英语文档来说，拼写和语法检查器太常见了．一般不会出现拼写和语法错误。但对于中文文档来说，可以采用一些校对工具辅助人工检查，并进行细致专业的校对．不要让用户发现错别字，不要出现有二义性的说法。特别耍注意的是屏幕截图或绘制圈形中的文字．不能想当然．没有任何工具能够从图形中找出语法错误．

10、印刷与包装。文档铡试似乎完成了，文档终于变成精美的册子，这时．测试人员还需抽查印刷质量，看看手册厚度与开本是否合适．翻看起来是否方便，包装盒的大小是否合适，光盘盘的固定有没有问题，有没有零碎易丢失的小部件等等。这时发现的问题．如果不是太严重．己不可能在这个版本中进行改进．但对下一个版本的制作来说是非常有价值的。

文档测试注意事项

1、文档常常得不到足够的重视，文档的开发缺乏足够的资金和技术支持，而文档  的测试更得不到重视。一个好的软件项目．一定要为文档测试留出预算，像对程序一样对文档给予关注。对文档中发现的缺陷．也需像发现程序缺陷一样给出报告。

2、编写文档的人可能并不是软件特性方面的专家，对软件功能可能了解得并不深入。其结果就是写出来的产品说明书可能并不到位．或者不能解释复杂的产品特性。软件文档测人员可以与文挡作者紧密合作．保证文档中所包含信息的质量，并随产品的更新而更新。更重要的是，测试人员可以发现并出程序中难以使用或难以理解之处，让文档作者在文档中作出更好的解释。

3、由于文档的印刷需要花费少的时间，可能是几周．如果追求印刷质量的话可能需要几个月。而在这段时间内，软件发现的错误可以有时问修改，程序报可能已经发生了改变，而文档无法反映最终的修改。Readme发明正因为如此，它是将最的改动通知用户的方式。它能使文档保持到最后一刻发布．从而保证与软件程序的同步。同时，随软件发布的联机帮助信息也可以尽可能地反映最新修改。如果文档测试不够充分．大量错误将不得不随着印刷精美的手册到达用户手中．而Readme文件就不是最新特性的发布而是长长的勘误表了。

4、文档测试不仅仅是对文字的校对．更可以辅助找到更多的程序错误。文档编写人员与文档测试人员审视程序的角度与程序员和程序测试人员井不相同，因此由文档测试提示的问题也不同于程序员和程序测试人员所发现的问题，文档测试往往会发现其他测试无法发现的严重错误，例如，功能实现错误、易用性不好、用户手册与程序实现不吻合等问题。当然，这是在全面测试的基础上．而全面测试意味着每3—5页花费l小时的时间。测试人员审看文档的速度越快，从文档和程序中发现问题的机会就越少。加强测试监督、重新培训测试人员，甚至更换测试人员能有助于解决这一问题

用户手册文档测试

用户手册是用户文档中最重要的一部分。在对用户手册进行测试时，应拿着它坐在计算机前，进行如下操作。

1、准确地按照手册的描述使用程序。在每个例子中如实地进行每个键盘操作。用户在按照手册运行程序时可能会进行错误的操作，因此铡试时测试人员也可以随心所欲地“犯错误”。检查计算机对错误的处理和手册对错误处理的描述应当占用测试人员的大部分精力。

2、尝试每一条建议。即使建议并没有完全表达清楚，仍应按步骤去尝试。用户依照建议会做什么，测试人员就应当做什么，甚至尝试更多的可能性。

3、检查每条陈述。测试人员需要对每条陈述进行检查．园为用户手册是产品最终的规范．是用户检查程序运行是否正确首先求证的地方。查找容易误导用户的内容。有些示例和特征描述得并不准确。一般的读者可能会从中归纳出错误的结论。用户可能对程序的能力抱有过高的期望．或是凭空想象一些实际并不存在的约束条件。尽早标识出易被人误解的内容．这一点极其重要。

帮助文档测试

帮助文档的测试在很大程度上与用户手册测试相同．但帮助并不只是用户手册的电子版．因此再给出以下几点补充说明。

1、准确性。对帮助准确性检查的细致程度至少要接近于对用户手册的检查。通常帮助文本都没有得到良好的处理和充分涮试．无法受到用户的欣赏。一旦用户发现帮助中存在明显的错误．他可能对帮助系统的信任程度大大下降。

2、帮助是文档编写和程序编写的结合。不仅要检查文本的准确性．还要检查程序的可靠性，制作帮助的人员往往并不是专业的程序员，他们在使用帮助制作工具的技巧．与程序的接口等问题上不可能达到完美。

3、帮助索引。如果帮助系统包含了索引或主题列表，允许用户由索引进入到主题中．测试人员就必须逐条进行检查。

4、超链接。陈非是早期开发的软件或开发商对帮助过于不重视，超链接是在线帮助中必须的功能。测试人员必须对每个链接都测试到．复杂的超链接可能会对一个主题形成树状结构展开的若干页面．甚至构成网状结构。测试人员有义务检查每条分支。

5、链接的意义。索引和链接的条目应当是有意义的，测试人员需要发现是否有一些帮助主题未出现在索引里．或出现的名称不恰当。如果用户不能迅速找到所需的信息．只能说帮助系统在一程度上是失败的。

6、帮助的风格。很少会有用户能悠用地查看帮助，帮助的阅读者是带着问题、焦躁不安而缺乏耐心的。帮助文本需要比用户手册更为简洁，风格也应更为简单。良好的帮助系统应该是面向任务或面向操作的．它必须提供一些有意义的信息．让用户能立即开始或继续他的操作。任何在帮助中出现的令人迷惑或离题的内容都可以作为测试问题

电话：153 5058 3815  QQ：119006626