测试报告是QA进行监督的重要依据，为项目负责人提供软件质量信息的报告。在实际工作中，如何编写有效的测试报告供整个团队的相关人员进行参考？

感谢会员252090366提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至7月4日17：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	卖烧烤的鱼	当当购物卡50元	12#
二等奖	dabeixiong	300论坛积分	8#
	sun_0910		10#
三等奖	charles	100论坛积分	11#
	duola1119		19#
	godn_1981		20#

一般的公司都有相应的模版的，写报告的时候注意，把你测出来的BUG、相应的建议等，标明就可以了
请补充

一份完整的测试报告应该包括:
测试时间
测试人员
测试项目及内容
测试环境
测试结果
分析结果
总结或结论
测试问题及建议

需求分析和用例的设计比较关键
选择适合的方法，可以提高效率

引用:

原帖由 whj99154562 于 2008-6-28 15:37 发表
一份完整的测试报告应该包括:
测试时间
测试人员
测试项目及内容
测试环境
测试结果
分析结果
总结或结论
测试问题及建议

同意3楼的测试报告应该含有的内容。但是从楼主的题目上面来看，如何编写有效的测试测试报告。围绕“有效”这个方面来说，我关注的点是在分析结果上面：
1，设计了多少用例？执行了多少条用例？如果用例没全部执行完，写出原因，为将来的项目做参考。
2，发现了多少BUG？解决了多少BUG？抛弃了多少BUG？遗留了多少BUG？
3，写出为什么出现了那么多BUG？抛弃bug的原因？为什么遗留了剩下的BUG？解决BUG所花费的时间。
4，根据上面分析的结果得出总结。
学习中，大家有想法多多说出来，一起分享下。

测试报告的结果分析应该分成两个方面
其一是对项目测试情况的一个分析与总结，也就是对项目或产品自身质量现状的分析与描述，其中也应该包含对遗留问题的分析，应该包括遗留问题的严重性，发生频率，分析对系统的影响程度，评审的意见以及解决办法等
其二是对测试工作自身的评价，包括测试的进度、工作效率、得到的经验与教训等等
再有还可以统计一些比较详细的度量数据，可以为下次测试工作策划作为理论基础，并且长期进行测试工作的度量与统计分析，还可以帮助组织建立起测试工作的基线与模型
如有效bug比率、严重级别以上bug的所占比率、平均每千行代码发现的有效bug数、修正问题占问题总数的比率等等

每个公司都应该有自己的模板，根据模板来填写，
5楼说的很好，此外个人感觉还应该包括BUG的分布情况以及在测试中遇到的问题，结项后的一些风险等。

1.谁将是这份报告的读者
对于团队成员，这次项目我们哪里做得好，哪里还需要改进。一个项目结束后对于项目的进展大家心里应该都有数了，可以将每个人的想法汇总起来，并给出可行的解决方案，下次项目进行改进；在测试过程中遇到了什么问题，我们怎么处理的，这样做的结果是好的还是坏的等等，这样我想团队是在不断的向前走。
对于领导，可能更关心这个项目经过测试后是个什么样子，我觉得可以提供一些图表进行分析。比如缺陷分布啊，缺陷趋势啊。

2.报告的阶段
不同公司可能报告的阶段不同，不同的阶段报告内容应该也会不同。
据我所知像系统测试啊性能测试啊之类的测试结束以后都有相应的报告，甚至会分得更细。
像我们公司每天都要汇报工作状态，而且根据项目不同和阶段的还有差异，大体上内容包括今天都作了什么，测试环境，测试的范围，发现了什么问题，提交了什么bug，项目进程等等。
另外项目结束也要实现定义，还要给测试定一个结果。比如，所有已知的问题都已经解决掉、产品可以发布、验收测试客户满意程度为优秀等等...
如果定义所有已知bug都已关闭才能结束此阶段的话，那么如果仍有bug状态为active的话是不能结束的，可以考虑推迟或者won't fix...这些问题有可能都要考虑放在报告里，以便决策者更好的控制及相关的人员能够知情。

3.如何报告
报告是真实的，尽量避免报告的内容出错导致麻烦，比如一些数字啊，语法措辞之类的。自己看了之后，可以找人review一下。听听别人的观点，从多方面角度考虑一下，也能够多衡量一些方面吧。
报告是给人看的，所以应该充分考虑到人的情绪，如果死气沉沉的套用模板而没什么实际意义的话让人会觉得很枯燥很反感，最终可能就变成应付差事，起不到什么作用。需要写什么就写什么。
另外还要注意对事不对人，尽量多说些鼓励团队的话，提高气势，比如我们比预定计划提前了n天完成任务啊，再比如测试过程中我们哪里犯了个可大可小的错误，找一些借口啊或者玩一些文字游戏等手段来说明啊之类的，大家心里明白就行了。基本上我们团队的report一出来就会出现n多从来没冒过泡的领导出来说些greeeeeeeeat work, wooooooooo!!!thanks a lot for ur hard work之类的话。
但是，如果真出现不得不说的问题那也不要客气，大胆的提出来让大家知道并合力解决。

其实大部分测试报告并不是很难写，关键还得看测试活动执行的状况。就像在学校学习时，学得好自然成绩就好，那么学期结束后的感言就可以写成好学生的心得体会，否则就会写成检查了。

希望大家能过多写好的心得，少些检查... 就算检查也要写的惊天地泣鬼神...

简明　扼要　通俗　易懂　＋　特殊情况

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

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、执行测试活动的类型（单元、代码走查、功能测试、接口测试、验收测试、性能测试、上线前验证测试。。。。）；
3、报告的对象（开发人员、领导or客户）；

    *对于领导来说，他们没有时间也不会关注太过详细的东西，只要说明本次测试是否达到了测试目的，系统能否达到版本发布的标准，系统能否上线，几年后随着业务量的增长系统可能存在的风险、硬件环境是否需要扩容等等，让领导看的报告要简洁明了，一针见血的对测试下个结论就足矣。
    *对于开发人员需要越详细越好，对测试目标、测试环境（硬件环境、软件环境及测试系统的版本）、测试策略、测试结果分析、测试过程中发现的问题及建议，描述的越详细越清楚越好，开发人员需要根据报告来评估系统是否达到目标、测试发现的问题是否必须修正、如何定位这些问题并为进一步解决这些问题提供依据。
    *对于客户的测试报告，按照一些规范的测试报告模板编写就成了，客户更关注的报告是否规范美观，测试结论一般情况下肯定满足客户的要求，需要一些官方语言，针对测试问题的列表是需要仔细斟酌的，如果把严重问题都列出来，可以想象后果是什么样的。。。。

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

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 如何编写更佳的bug report
http://blog.csdn.net/imlogic/archive/2006/06/22/821733.aspx
2 SOFTWARE TEST REPORT
http://www.pogner.demon.co.uk/mil_498/str-did.htm
3测试报告编写指南
http://www.51testing.com/html/43/777.html

[ 本帖最后由 卖烧烤的鱼 于 2008-7-2 15:59 编辑 ]

照着模板填东西，就能算是有效的测试报告吗？
多用图表、多用数据说明问题，不要光靠自己的文字去写

楼上说的都有道理

做个记号，改日再来仔细看

很赞同10楼的说法，讲的相当不错，很多的东西也是我们常碰到的问题，看了很受启发。12楼讲的是测试报告的模板吧，回答顶楼的这个问题，感觉有点离题目太远了，太偏了。呵呵！

其实，我在的公司，很多测试报告都稍微夸大缺陷，其实也是不对的。

呵呵，并非测试报告模板，你细心的看下，就明白我的意思，我是针对“如何编写有效的测试报告？”的提问来回答的！
像10楼回答，个人认为并非最佳，我上面表明的态度一直强调二点“了解你的听众”和分而“制”治，如果你这份报告是编写给客户的或是经理或是开发或是Boss，哪么你认为测试报告包含的东西越多越好吗？
我上面贴的图test report.gif 是一个相当完备的测试报告，这样的报告通常是在比较大型的项目采用，但是我们的做法是将其划分为下面几大类，针对每一个软件生命周期，每个开发阶段，每个测试类型，报告的对像分别去定制合适的测试报告

呵呵!,10楼和15楼的朋友好像是一个公司的吧^_^

[ 本帖最后由 卖烧烤的鱼 于 2008-7-3 11:15 编辑 ]

我觉得测试报告把一些需要写到的东西写到了就可以了，再根据不同情况稍作增减。一些最基本的我就不说了，我想说下我自己在工作上的做法。
1、需要列出具体数据，总共BUG数、解决数和遗留数，最好附上图表；再列出遗留BUG的详细列表，并把严重级高的放在前面。
2、最重要的是测试结论部分，测试结论中列出这次测试遗留问题中比较严重的BUG，并写明我们的建议方案和同意上线或发布的理由。
3、如果是增量测试的，那把上次版本的BUG数和这次版本测试的BUG数做比较，若增多了，给予分析和建议方案。

测试报告里记录的就是我们测试的成果，不需要夸大也不需要掩藏，只要实事求是的把真实情况反映出来就可以了。

这是我以前设计的一个测试报告，我觉得可以回答你的问题了。

看着大家都答得挺热闹，我也来凑凑热闹。。
我的答案：http://www.51testing.com/?1592/action_viewspace_itemid_86636.html
我就不粘贴在这里了~~~~，欢迎光临点评指教。。。。

[ 本帖最后由 godn_1981 于 2008-7-3 23:35 编辑 ]