在我测试生涯中，我注意到很少人对测试文档有足够的重视。总的来说对测试文档的态度就是任何一个有空闲时间的人都就可以做一些像测试用例，测试计划，测试报告，缺陷报告，项目建议书等等。

　　虽然我也不是特别重视记录文档，但是我有一个好习惯就是记录下来，并且更新。

　　与你分享一下我的经验：

　　我们把一个项目（有一个没有发现的问题）交给其中一个客户（很暴躁的一个客户），并且在客户那里找到了这个问题，这对我们来说是相当不利的，所有的指责都指向质量部门。这是个关于某个网站的兼容性的问题。当问题反馈回到我这里的时候，我正在从需求文档中寻找证据，证明我们的需求范围里面没有这个要求，当然，同时我也必须检查一下该站点的兼容性。谢天谢地，我是对的，需求文档里面没有要求这一点。这对我来说是一个教训，也是经验，从这以后，我认识到文档的重要性，并且开始着手于文档，创建一些诸如测试计划，测试用例，健壮测试的清单，缺陷报告等测试文档。

　　中国有句古话是“好记性不如烂笔头。”

　　软件测试文档到底是什么？

　　我们读过各种各样关于测试技术和方法的文章，但是关于文档的文章又有多少呢？毫无疑问，结果是少之又少。那是不是说文档就不重要呢？不是！那只是因为我们还没有意识到它的重要而已。

　　但是，如果我们仔细观察的话，就会发现，那些拥有文档的项目都达到了成熟的水平。许多公司一点儿也像他们重视软件开发过程那样重视文档。如果我们在网上搜索一下，就会发现各种关于如何创作各种类型文档的模板。但实际上又有多少公司或者个人真正利用了这些模板呢？

　　事实上，详细的文档可以节省项目的时间，提高工作效率，减少费用支出。这就是为什么各种认证中，都强调记录文档。正是因为文档对于客户，对于项目，对于公司的重要。除非你可以做到，不论你的产品如何，你都可以让你的客户满意。除非你有能力创作出令用户满意的文件，否则无论产品多好，没有人愿意接收。

　　用户说明书也有这样的问题。就拿微软来举例吧，他们发布的每一个产品，都有相应的文档，即使是Office 2007，也有一些解释性的并且用户容易理解的文档。这就是他们所有的产品都能获得成功的一个因素。

　　在一些小公司里面，我们经常听到“项目在提议或者是在启动阶段就被终止”，而原因就是因为提案文档缺少简明而清晰表达来体现公司的能力。并不是说小公司就不能生产出高质量的产品，而是他们在表现自己能力方面做的不够。（我也曾在一个只有80个人的公司工作过，类似的情况我见了很多很多）

　　我个人认为只有质量监督部门才可以解决这个问题，只有这个部门在这个问题上才具有说服力，可以为公司美好的未来提供保障。

　　我们从质量观点出发，把我们的讨论整理成几点：

　　-使质量目标和方法明确
　　-确保任务清楚以及性能持久
　　-确保在客户工作中的内部协调
　　-提供预防措施的反馈
　　-提供计划周期的反馈
　　-提供质量管理系统绩效的客观凭据

　　在软件开发和测试生命周期中，有数以百计的文档，下面我列出需要用到且比较重要的软件文档。

　　1）测试计划
　　2）测试设计和测试用例说明文档
　　3）测试策略
　　4）测试总结报告
　　5）测试周进度报告
　　6）用户说明书
　　7）用户接受报告
　　8）风险管理
　　9）测试日志
　　10）缺陷报告
　　11）测试数据
　　12）测试分析