|
|
|
|
知识路径： > 测试技术的分类 > 文档测试 >
|
|
|
被考次数：1次
|
|
|
被考频率：
低频率
|
|
|
总体答错率：
29%
|
|
知识难度系数：
|
|
|
考试要求：
掌握
|
|
|
相关知识点：6个
|
|
|
|
|
帮助文档的测试在很大程度上与用户手册测试相同，但帮助并不只是用户手册的电子版，因此再给出以下几点补充说明。
|
|
|
|
. 准确性。对帮助准确性检查的细致程度至少要接近于对用户手册的检查。通常帮助文本都没有得到良好的处理和充分测试，无法受到用户的欣赏。一旦用户发现帮助中存在明显的错误，他可能对帮助系统的信任程度大大下降。
|
|
|
|
. 帮助是文档编写和程序编写的结合。不仅要检查文本的准确性，还要检查程序的可靠性。制作帮助的人员往往并不是专业的程序员，他们在使用帮助制作工具的技巧、与程序的接口等问题上不可能达到完美。
|
|
|
|
. 帮助索引。如果帮助系统包含了索引或主题列表，允许用户由索引进入到主题中，测试人员就必须逐条进行检查。
|
|
|
|
. 超链接。除非是早期开发的软件或开发商对帮助过于不重视，超链接是在线帮助中必须的功能。测试人员必须对每个链接都测试到，复杂的超链接可能会对一个主题形成树状结构展开的若干页面，甚至构成网状结构。测试人员有义务检查每条分支。
|
|
|
|
. 链接的意义。索引和链接的条目应当是有意义的，测试人员需要发现是否有一些帮助主题未出现在索引里，或出现的名称不恰当。如果用户不能迅速找到所需的信息，只能说帮助系统在一程度上是失败的。
|
|
|
|
. 帮助的风格。很少会有用户能悠闲地查看帮助，帮助的阅读者是带着问题、焦躁不安而缺乏耐心的。帮助文本需要比用户手册更为简洁，风格也应更为简单。良好的帮助系统应该是面向任务或面向操作的，它必须提供一些有意义的信息，让用户能立即开始或继续他的操作。任何在帮助中出现的令人迷惑或离题的内容都可以作为测试问题。
|
|
|
