前段时间接了一个客户报上来的bug, 因为涉及到与操作系统相关的安装问题，修复该bug可能要涉及到架构的一些变化，所有产品的安装component都会受到牵连，所以最终选择了在read me文档中添加说明项来解决用户使用过程中遇到的不便。
文档测试，说起来很简单，就是因为其简单的表象，很容易使测试人员心里麻痹而忽视一些细节。从直觉判断，我觉得这个看似简单的问题也不能简单的对待，于是查阅了一些书籍，对文档测试进行了一些深入的理解。
作为一个软件测试人员，一定要具备宏观的质量意识，不仅仅是专注于业务和技术。随着软件产品的日趋复杂化，文档已经成为软件产品的重要组成部分之一，其中包括：
1. Package text and graphics.
2. Marketing material, ads, and other insert.
3. Warranty/registration.
4. EULA- end user license Agreement.
5. Labels and stickers.
6. Installation and setup instructions.
7. User's manual.
8. Online help.
9. tutorials, wizard, and CBT(computer base training).
10. Samples, examples, and templates.
11. Error messages.
所有的这些item都是大部分专业客户在使用过程中密切关注的，如果任何一项出现错误或者低可用性，都会严重影响客户的使用感，从而对我们的产品质量产生不好的感觉。因此，文档测试必须和代码测试，功能测试等一样同等重视。
那么，一个好的文档测试可以给软件产品带来什么好处呢？ 首先，提高了软件的可用性；其次，提高了软件稳定性；最后，降低了技术支持的成本。
为什么这么说呢？如果客户在文档中找不到软件使用的说明，那么势必会对使用产生一些疑惑，或者因为错误使用而导致不可预知的结果。最终客户将会致电客服技术支持来寻求解决。如果在一开始文档就有比较完善的测试，就不会导致上面一系列的结果。
就像software testing里面所说：A very effective approach to testing it is to treat it just like a user would. Read it carefully, follow every step, examine every step, examine every figure, and try every example. If there is sample code, type it in and make sure it works as described. With this simple real-world approach, you'll find bugs both in the software and the documentation.
基于这些理解，最终我是怎么来测试这个read me文档的呢？
1. 可用性测试：我首先重现了这个客户报上来的bug，并且理解了问题的原因，然后仔细阅读了read me文档里面添加的内容，按照里面所描述的逻辑进行操作，看问题是否被修复了。
2. 进行了拼写检查，和描述清晰度检查，考虑是否有第二种理解，或者歧义，然后根据第二种或者第三种理解进行操作，看是否会出现不可预知的错误；
3. 检查文档是否安全，是否带有威胁性的病毒或者不安全因素；
4. 检查所有的问题都被描述到，并且在制定的build里面已经包含了该文档；
最后我发现这个添加的描述存在理解歧义，客户容易产生疑惑，并且不能很快的解决问题。我试图和文档开发人员进行了沟通，最终他认可了我的建议，将这段文字进行了修改。
似乎整个过程表面上看起来略显繁琐，有点吹毛求疵的嫌疑。但是我觉得作为一个软件测试人员，就是需要将质量意识贯穿到每一个日常工作中，才能够提高客户满意度，建立真正的“customer driven”意识。
本文出自rose62yl的51Testing软件测试博客：http://www.51testing.com/?109108
版权声明：原创作品，转载请保留链接，标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关阅读：
