以下是个人对于测试报告自己的一份理解，诸如何时写、如何写等。同时也希望大家在看到这篇博客时能写下你们的想法，大家一起分享下。
　　什么时候写测试报告？测试报告如何写？或许觉得这个问题问的很怪，因为一般测试计划或者项目总体计划里都会写明何种频率，何时完成测试报告，因为测试报告将作为一个里程牌点的结束的标志，同时组织级规程里也对测试报告做了规定，必须按照测试报告模板来写。但这次我所有表述的是对测试报告的一种理解，而不是作为测试的一项工作。

　1、测试报告可以作为一种电子式任务分配

　在测试报告中写明本次测试任务的测试重点、通过标准及人员分配，然后将此文档提交给测试团队中的其他人，由实际测试人员填写完相应报告。测试组长以此作为质量监控依据。当然这个只适用于小型维护单测试。下面我粗劣画图下测试报告的格式说明下。（所有文档在我另一台电脑上，上次说要传的数据流向图、需求用例矩阵都还没上传，下面临时做下表格，呵呵）

  这个最大的好处是某些没有测试工作管理平台时，通过一份文档解决任务分配、测试指导、测试结果监控的效果。同时也可以培养测试成员的测试方案填写。

　2、测试报告之阶段报告

　写测试报告很多时候亦可当做是一次验收测试和回归测试，当在测试报告中填写本次测试点，总结本次测试遗留问题、bug趋势图时，从侧面可以在检验你是否测试覆盖全。另外最主要的一点就是：建议多写一些测试阶段报告，并未项目结束的测试报告。

　测试的工作一定程度上是输入、分析、改进、输出一连串工作，执行测试用例和前期预定的测试方案，分析bug的分布情况、增长趋势、项目验收情况对测试满意度、改进测试规程，最终测试能力提升，项目质量达标。之所以我建议多写测试阶段报告，最主要是能对一段时间内的测试工作加以总结，总而了解测试团队效率、项目质量情况、测试方案调整依据。下面举例说下阶段报告中一个我习惯总结的数据，画个图容易说明，呵呵。

　这种情况是一般小型项目都会出现的，开发人员习惯简单模块简单问题优先处理，这势必会导致项目后期测试人员工作加重，同时这B模块需要作为异常模块第一时间进行团队沟通。

　这个图Y轴是表示的是bug量/工作量，通过各个阶段测试人员发现bug的效率，作为评定工作质量的一个指标，跟个人绩效挂钩，从一定程度上可以调配各个测试人员的工作任务和激励。当然其他图还有很多，例如bug严重级分布，这些都非常有用的。在各个测试报告模块中都要求填写，我这边讲的是阶段报告，因而更注重的对当前的工作的总结，调整未来工作的发展。

　3、测试报告作为以后测试的依据

　一个测试报告的完成，并不表示当前测试工作的结束。我这里建议大家务必在测试报告中对测试环境、最终测试通过版本号、遗留问题分析处理结果等写明，这个的重要性并不比最后的测试结论要低。举几个个例子，产品发布后出现问题，测试人员优先可以拿测试报告中的环境、版本号跟发现问题比对，查找原因。维护任务因为测试人员的不确定，能够第一时间找到上次版本的程序和环境，要知道测试环境搭建所花费的时间代价是很高的，同时可以跟踪遗留问题处理。