其实，楼上的几位51Testing会员已经谈的不错了，针对测试报告，我也来谈谈自己的一些想法：

　　1、必须说清楚测试报告的操作系统环境：

　　比如说XX软件运行的操作系统是什么？是Windows 98、Windows2000、WindowsXP, 还是Linux操作系统等等。很多时候，大多数的软件只能够在某个系统上存在缺陷，而在其它版本的系统上可能不存在缺陷。

　　2、测试报告结果只对发布的版本和配置库的SVN号负责：

　　也许同行们都有这种尴尬，很多测试的时候，发现了Bug，并将Bug记录到Bug跟踪系统上，结果开发人员说，自己的机器上不存在这个Bug。要求测试人员重新验证Bug是否存在。一种可能是开发人员发现测试人员递交缺陷后，修改了该缺陷，还有一种情况是版本的发布不规范，开发人员忘了递交代码到配置库，结果就发布了。所以，测试报告只对特定的版本和环境负责。

　　3、指出测试的浏览器：

　　特别是Web类似的软件，不同的浏览器，测试出来的问题不一样。同样的一种浏览器，不同的版本，测试结果报告也有时候不一样，我们部门以前碰到过IE6.0和IE7.0同样的一个功能，页面显示不太一样的现象。故，Web类似软件的测试报告，最好是说明出现问题的浏览器。

　　4、测试结论和测试建议，对于一个有效的测试报告非常关键：

　　测试结论和测试建议要求简短和准确，甚至有时候决定该版本是否可以发布，特别是测试的负责人，对被测试软件的报告一定要仔细斟酌，小心为佳。

　　5、测试用例的执行情况：

　　针对软件测试报告的几种类型，如：单元测试、集成测试、功能测试、性能测试和压力测试分别编写测试报告。编写报告时，已经执行或未执行的的用例数目。用例通过的百分比，未执行的测试用例，必须说明不能执行的原因。对于测试阻塞的测试用例，必须加以说明，最好用粗体字表明，让人一看就比较清楚。

　　6、一般都要附上缺陷列表（Buglist）：

　　某个软件的测试版本，测试中共发现了多少问题，缺陷的严重等级和优先级如何，已经关闭和Fix掉的Bug有哪些？哪些问题是该版本遗留的问题？哪些是下一个版本解决的问题？哪些是重复打开的缺陷？有了Buglist，一看就一目了然，简单并且很清晰。

　　7、测试结果的图形和数据分析情况：

　　测试报告递交一定要分清递交对象，不同类型的人，递交不同版本的测试报告。如果是递交给研发部的人员，最好要附上缺陷隔离等相关方面的解释，方便开发人员迅速定位缺陷，解决问题。如果递交对象是客户，你就详细说明客户关心的功能和常用模块是否已经实现，是否存在问题即可。如果递交的对象是公司领导和客户领导，他们根本就没有很多时间来看你的文字，主要看看测试图表，最好用缺陷管理工具，如：TestDerector和QAcenter自动生成不同的图表，并且附带上各个功能模块的缺陷情况，就可以应付了，呵呵！！

　　8、测试报告也可以附带缺陷度量的相关分析：

　　如缺陷密度呀等等之类的，增加缺陷报告的技术含量，哈哈。

　　我想到的就这么多，望同行批评指正！！

转载请保留：本文出自51Testing软件测试论坛每周一问活动，感谢会员sun_0910的精彩回答。

查看更多活动详情请点击：http://bbs.51testing.com/forum-157-1.html