如何编写有效测试报告.doc

1 了解你的听众： 通常情况下测试报告主要由以下几类人员查看： “用户”着重点在于测试结论部分； “开发人员”着重点在于缺陷结果以及分析得到产品质量的信息； “项目管理者”着重点在于测试中资源，时间和成本； “高层经理”着重点在于项目当前的状况与其他项目比较。 2 分而“制”治 所以针对不同的听众，你需要制定不同的“测试报告”，报告的内容是关于它们最为关心的 哪么先来看看一份比较详细的测试报告： 以上测试报告，将我们之前所列的“听众”均包括在内，所以这样的测试报告比较规范，但是存在如果我们测试报告的对像并非前面所列的“听众“，突显出内容过稍显多余 所以测试报告应分为以下几大部分：缺陷报告，测试分析报告，测试评估报告，针对不同的听众有效的去报告！ 如我们公司目前采用的有以下模板： XXX公司_技术中心_测试_缺陷报告.doc XXX公司_技术中心_测试_测试分析报告.doc XXX公司_技术中心_测试_测试评估报告.doc 不同的项目测试阶段制定不同的测试报告 单元测试，集成测试，系统测试和验收测试分别制定不同的测试报告，当然前面所列举的测试报告的元素需要完备，具体要看公司要求，如下面所示 XXX公司_技术中心_测试_单元测试报告.doc XXX公司_技术中心_测试_集成测试报告.doc XXX公司_技术中心_测试_系统测试报告.doc XXX公司_技术中心_测试_验收测试报告.doc 不同的项目测试类型制定不同的测试报告 某些公司仅要求测试人员出某特定类型的测试报告，如功能测试，性能测试，安全性测试和用户可接受度测试等分别制定不同的测试报告，当然前面所列举的测试报告的元素需要完备，具体要看公司要求，如下面所示 XXX公司_技术中心_测试_功能测试报告.doc XXX公司_技术中心_测试_性能测试报告.doc XXX公司_技术中心_测试_安全性测试报告.doc XXX公司_技术中心_测试_用户可接受度测试报告.doc 为什么我没有写很多编写测试报告的实例呢？ 因为仅提供思考方法及角度，具体的“有效测试报告”还需要你结合公司实际情况制定，当然你可以参考我上面所提及的 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自动生成不同的图表，并且附带