测试报告

1 了解你的听众：通常情况下测试报告主要由以下几类人员查看：“用户”着重点在于测试结论部分；“开发人员”着重点在于缺陷结果以及分析得到产品质量的信息；“项目管理者”着重点在于测试中资源，时间和成本；“高层经理”着重点在于项目当前的状况与其他项目比较。

2 分而“制”治所以针对不同的听众，你需要制定不同的“测试报告”，报告的内容是关于它们最为关心的哪么先来看看一份比较详细的测试报告，目前是我为公司制定的：图在下面已贴出以上测试报告，将我们之前所列的“听众”均包括在内，所以这样的测试报告比较规范，但是存在如果我们测试报告的对像并非前面所列的“听众“，突显出内容过稍显多余所以测试报告应分为以下几大部分：缺陷报告，测试分析报告，测试评估报告，针对不同的听众有效的去报告！如我们公司目前采用的有以下模板：XXX公司_技术中心_测试_缺陷报告.docXXX公司_技术中心_测试_测试分析报告.docXXX公司_技术中心_测试_测试评估报告.doc不同的项目测试阶段制定不同的测试报告单元测试，集成测试，系统测试和验收测试分别制定不同的测试报告，当然前面所列举的测试报告的元素需要完备，具体要看公司要求，如下面所示XXX公司_技术中心_测试_单元测试报告.docXXX公司_技术中心_测试_集成测试报告.docXXX公司_技术中心_测试_系统测试报告.docXXX公司_技术中心_测试_验收测试报告.doc不同的项目测试类型制定不同的测试报告某些公司仅要求测试人员出某特定类型的测试报告，如功能测试，性能测试，安全性测试和用户可接受度测试等分别制定不同的测试报告，当然前面所列举的测试报告的元素需要完备，具体要看公司要求，如下面所示XXX公司_技术中心_测试_功能测试报告.docXXX公司_技术中心_测试_性能测试报告.docXXX公司_技术中心_测试_安全性测试报告.docXXX公司_技术中心_测试_用户可接受度测试报告.doc为什么我没有写很多编写测试报告的实例呢？因为仅提供思考方法及角度，具体的“有效测试报告”还需要你结合公司实际情况制定，当然你可以参考我上面所提及的看到有人提到这个问题，就来凑凑热闹，结合实践谈谈我的看法。

既然是说到如何编写有效的测试报告，那么我的重点就是在于有效，而不是一般的洋洋洒洒几千字的非常八股文的测试报告，有时候怎么说呢，唉，生在中国就不得不搞一些形象工程，所以，一说到报告大家的概念好像就必须是洋洋洒洒罗罗嗦嗦繁冗复杂的数千字……不过，我在这里不想谈那个“政绩报告”。

偶是一个非常实用主义者。

废话少说，我们要说的是如何做有效的测试报告。

既然说到有效，我觉得要有两个特点：完整和实用，突出重点。

引用一句广告词就是说“简约而不简单”，就是说要完整但又不说废话，能肥则肥，能瘦则瘦，重点部分要突出，要细说，非重点部分，一笔带过，只是为了保证一个文档的完整性。

说到一个测试报告，是对测试的过程和结果的汇总描述，所以其核心内容是两个，一个是测试结果的汇总报告，一个是测试过程的汇总总结，前者是针对所测软件本身，是给所测软件一个客观真实的评价；后者则是针对过程改进，回顾测试流程中存在的不足，加以总结改进。

除了这两项核心内容之外，其他的内容都是次要的，但是为了保持文档的美观性和周全性，其他各部分还是要写写的。

具体说一般一个测试报告有如下部分构成，下面一一细说。

（下面也是我在我们公司执行的模板）1.引言这个不用多说了，一般包括编写目的，项目背景介绍，参考资料等等，该项基本可以随便写写。

（只是为了保持文档的完整性）2.测试用例设计对用例设计做一个简单的描述，包括测试范围阿，测试目标阿，测试重点阿等。

该项基本可以随便写写。

（只是为了保持文档的完整性）3.测试环境主要描述测试所用环境，包括硬件环境和软件环境，服务端和客户端。

该项比较重要。

4.测试方法主要描述测试过程中自己用到什么测试方法，白盒还是黑盒，哪些部分用了自动化，用多少。

该项比较重要。

6.测试时间安排（执行情况）主要描述测试过程，每个时间段都做了什么事情。

该项必不可少。

7.缺陷汇总及分析7.1缺陷总结一般按照严重程度，功能模块进行划分。

能画图就画个图吧，直观一点。

该项很重要，绝不可少。

7.2缺陷分析通过上面7.1的总结，对bug进行分析。

这项是测试报告的核心所在，一般有缺陷功能模块分析，缺陷类型分析和缺陷发现阶段分析，具体更多方法参见我的另一篇博文：/?1592/action_viewspace_itemid_85427.html该项很重要，绝不可少。

7.3遗留问题目前软件残存的已知问题。

有些是解决不掉的问题。

该项很重要，绝不可少。

7.4测试结论基于以上分析，给被测软件一个全面客观真实的结论，功能如何，性能如何，稳定性，安全性等等给出一个评价。

该项最重要，绝不可少。

8.测试过程改进对整个测试活动进行一个总结，有哪些得失，测试方法和流程需要哪些改进，测试过程中暴露出哪些问题，有哪些好的地方值得发扬等等。

该项很重要，绝不可少。

9.附录一般附上缺陷列表以及执行过的测试用例地址等。

该项基本可以随便写写。

（只是为了保持文档的完整性）上面这个只是我个人比较常用的模板，仅供参考。

我觉得写文档要有模板，但模板只限于统一规范和格式（一般公司内部的文档要统一规范，要不大家各写各的就乱了），模板还有一个好处是引导思路，但是写文档不要拘泥于模板，还是要根据自己的需要，实用一点。

最后，啰嗦一句，其实测试总结报告不是仅仅为了应付测试经理或者领导，任何事情好好去做了就又是一回事，我觉得作为一个测试人员，静下心来对自己几个月的测试工作有一个深入的总结，也能够使经验得到积累，意识得到升华，何乐而不为呢？不能抱着应付的态度，总结是提高自己的必经之路。

这就是如何才“有效”！如何编写测试报告，网上的模板很多也很全面，所以测试报告的内容在此不在一一列出。

个人感觉编写测试报告之前首先应该明确的方面：1、测试活动的目标；2、执行测试活动的类型（单元、代码走查、功能测试、接口测试、验收测试、性能测试、上线前验证测试。

）；3、报告的对象（开发人员、领导or客户）；*对于领导来说，他们没有时间也不会关注太过详细的东西，只要说明本次测试是否达到了测试目的，系统能否达到版本发布的标准，系统能否上线，几年后随着业务量的增长系统可能存在的风险、硬件环境是否需要扩容等等，让领导看的报告要简洁明了，一针见血的对测试下个结论就足矣。

*对于开发人员需要越详细越好，对测试目标、测试环境（硬件环境、软件环境及测试系统的版本）、测试策略、测试结果分析、测试过程中发现的问题及建议，描述的越详细越清楚越好，开发人员需要根据报告来评估系统是否达到目标、测试发现的问题是否必须修正、如何定位这些问题并为进一步解决这些问题提供依据。

*对于客户的测试报告，按照一些规范的测试报告模板编写就成了，客户更关注的报告是否规范美观，测试结论一般情况下肯定满足客户的要求，需要一些官方语言，针对测试问题的列表是需要仔细斟酌的，如果把严重问题都列出来，可以想象后果是什么样的。

明确了这几个方面就大概知道测试报告该如何下手了。

其实，楼上的已经谈的不错了，针对测试报告，我也来谈谈自己的一些想法：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、测试报告也可以附带缺陷度量的相关分析：如缺陷密度呀等等之类的，增加缺陷报告的技术含量，哈哈。

我想到的就这么多，望同行批评指正！！1.谁将是这份报告的读者对于团队成员，这次项目我们哪里做得好，哪里还需要改进。

一个项目结束后对于项目的进展大家心里应该都有数了，可以将每个人的想法汇总起来，并给出可行的解决方案，下次项目进行改进；在测试过程中遇到了什么问题，我们怎么处理的，这样做的结果是好的还是坏的等等，这样我想团队是在不断的向前走。

对于领导，可能更关心这个项目经过测试后是个什么样子，我觉得可以提供一些图表进行分析。

比如缺陷分布啊，缺陷趋势啊。

2.报告的阶段不同公司可能报告的阶段不同，不同的阶段报告内容应该也会不同。

据我所知像系统测试啊性能测试啊之类的测试结束以后都有相应的报告，甚至会分得更细。