|
|
知识路径： > 测试技术的分类 > 文档测试 >
|
|
相关知识点：6个
|
|
|
|
|
对于软件用户来说，程序之外的部分也是软件的一部分，他们并不管这些东西是由程序员、作家还是图形艺术家创建的。他们关心的是整个软件包的质量。
|
|
|
|
|
|
. 文档常常得不到足够的重视，文档的开发缺乏足够的资金和技术支持，而文档的测试更得不到重视。一个好的软件项目，一定要为文档测试留出预算，像对程序一样对文档给予关注。对文档中发现的缺陷，也需像发现程序缺陷一样给出报告。
|
|
|
|
. 编写文档的人可能并不是软件特性方面的专家，对软件功能可能了解得并不深入。其结果就是写出来的产品说明书可能并不到位，或者不能解释复杂的产品特性。软件文档测试人员可以与文档作者紧密合作，保证文档中所包含信息的质量，并随着产品的更新而更新。更重要的是，测试人员可以发现并指出程序中难以使用或难以理解之处，让文档作者在文档中作出更好的解释。
|
|
|
|
. 由于文档的印刷需要花费不少的时间，可能是几周，如果追求印刷质量的话可能需要几个月。而在这段时间内，软件发现的错误可以有时间修改，程序很可能已经发生了改变，而文档无法反映最终的修改。Readme文件的发明正因为如此，它是将最后的改动通知用户的方式。它能使文档保持到最后一刻发布，从而保证与软件程序的同步。同时，随软件发布的联机帮助信息也可以尽可能地反映最新的修改。如果文档测试不够充分，大量的错误将不得不随着印刷精美的手册到达用户手中，而Readme文件就不是最新特性的发布而是长长的勘误表了。
|
|
|
|
. 文档测试不仅仅是对文字的校对，更可以辅助找到更多的程序错误。文档编写人员与文档测试人员审视程序的角度与程序员和程序测试人员并不相同，因此由文档测试揭示的问题也不同于程序员和程序测试人员所发现的问题，文档测试往往会发现其他测试无法发现的严重错误，例如，功能实现错误、易用性不好、用户手册与程序实现不吻合等问题。当然，这是在全面测试的基础上，而全面测试意味着每3～5页花费1小时的时间。测试人员审看文档的速度越快，从文档和程序中发现问题的机会就越少。加强测试监督、重新培训测试人员，甚至更换测试人员能有助于解决这一问题。
|
|
|
