51Testing软件测试论坛

标题: 如何编写有效的测试报告？（08-06-27）（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-6-27 17:51
标题: 如何编写有效的测试报告？（08-06-27）（获奖名单已公布）
测试报告是QA进行监督的重要依据，为项目负责人提供软件质量信息的报告。在实际工作中，如何编写有效的测试报告供整个团队的相关人员进行参考？

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

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

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

作者: sinakevin 时间: 2008-6-28 11:50
一般的公司都有相应的模版的，写报告的时候注意，把你测出来的BUG、相应的建议等，标明就可以了
请补充

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

作者: jency_moon 时间: 2008-6-28 23:16
需求分析和用例的设计比较关键
选择适合的方法，可以提高效率

作者: chenrong 时间: 2008-6-29 23:22

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

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

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

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

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

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

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

但是，如果真出现不得不说的问题那也不要客气，大胆的提出来让大家知道并合力解决。

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

希望大家能过多写好的心得，少些检查...

就算检查也要写的惊天地泣鬼神...

作者: magic_zhu 时间: 2008-7-1 18:01
简明　扼要　通俗　易懂　＋　特殊情况

作者: sun_0910 时间: 2008-7-2 10:49
其实，楼上的已经谈的不错了，针对测试报告，我也来谈谈自己的一些想法：

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、测试报告也可以附带缺陷度量的相关分析：
如缺陷密度呀等等之类的，增加缺陷报告的技术含量，哈哈。

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

作者: charles 时间: 2008-7-2 13:36
如何编写测试报告，网上的模板很多也很全面，所以测试报告的内容在此不在一一列出。
个人感觉编写测试报告之前首先应该明确的方面：
1、测试活动的目标；
2、执行测试活动的类型（单元、代码走查、功能测试、接口测试、验收测试、性能测试、上线前验证测试。。。。）；
3、报告的对象（开发人员、领导or客户）；

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

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

作者: 卖烧烤的鱼 时间: 2008-7-2 15:54
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 编辑 ]

作者: jasonxu 时间: 2008-7-2 16:45
照着模板填东西，就能算是有效的测试报告吗？
多用图表、多用数据说明问题，不要光靠自己的文字去写

作者: t_test 时间: 2008-7-2 18:26
楼上说的都有道理

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

作者: pepper 时间: 2008-7-3 09:37
标题: 我来说两句
很赞同10楼的说法，讲的相当不错，很多的东西也是我们常碰到的问题，看了很受启发。12楼讲的是测试报告的模板吧，回答顶楼的这个问题，感觉有点离题目太远了，太偏了。呵呵！

作者: pepper 时间: 2008-7-3 09:54
标题: 大家讲的都不错哦！！
其实，我在的公司，很多测试报告都稍微夸大缺陷，其实也是不对的。

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

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

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

作者: duola1119 时间: 2008-7-3 17:52
标题: 这个问题我用一个模板来回答你
这是我以前设计的一个测试报告，我觉得可以回答你的问题了。

作者: godn_1981 时间: 2008-7-3 23:34
标题: 我的答案
看着大家都答得挺热闹，我也来凑凑热闹。。
我的答案：http://www.51testing.com/?1592/action_viewspace_itemid_86636.html
我就不粘贴在这里了~~~~，欢迎光临点评指教。。。。

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

作者: tiantian010 时间: 2008-7-4 12:49
标题: 路过但不要错过
10#写的很详细也很具体,很多项目中都用到了这种分析思路,同时需要强调的是,要明确测试报告是给谁看的!这就决定了你的测试报告的形式\描述的重点还有内容的顺序.这点上12#给了很好的补充.都很好.呵呵!

[ 本帖最后由 tiantian010 于 2008-7-4 12:51 编辑 ]

作者: tengmy 时间: 2008-7-4 13:22
Bug 报告的要素

1．概要
   用最精简的话语，最好是一句来描述你发现的问题。一般逻辑为，哪里，进行了什么操作，本该出现什么，结果出现了什么。（比较严重的缺陷不需要说明期望结果）
2．步骤
   从第一步开始书写你的操作手顺。一般原则为：让一个不熟悉此操作的人，按照你的步骤能够再现这个bug.
**需要注意的是：需要书写的步骤不能含有冗余。也就是说，需要测试员在发现问题后对自己已经确定的再现操作步骤进行排除和分析。只保留缺一不可的步骤。
3．再现率
   一般为 X/Y的格式。即再现次数/操作次数。
4．发行依据
      就是参考文件，你是依据什么文件（权威文件，一般为需求文档或者开发方的说明文档等）而发行的这个bug.没有发行依据的bug发行是没有说服力的。
5．对比信息
      也叫做附加信息。包括类比和对比信息。一般会把同一功能，类似功能的模块做同样操作的表现来作为对比信息。
6．测试环境
      即发行bug时系统的环境信息。这对于bug的后期分析具有非常重要的意义。
7．使用的测试数据
8．测试附件
图片，录影（图片无法说明的），log文件。
9．其他
需要补充的其他信息。根据所测试的对象不同，会有个别不同信息地提供要求。

   以上是书写bug的重要要素。如果你写的bug  report包括了以上我所说的全部内容，基本上就算是一个比较全面的bug report了。

   当然，一个bug报告的组成还有以下：
bug的概要分析。分析这个bug属于什么范围的问题，什么模块的问题。是进行了什么操作而造成的。

Bug的优先级。有三级与五级这两种不同的区分。依据项目而定。这种级别一般是测试员没有权限决定但是有权利进行建议的。
Bug的分析过程。一般由开发和分析人员填写。后期测试可以看到并且参考这些信息。有针对性地做retest和回归测试。
Bug的再测试纪录。一般由测试人员填写测试经过，测试时间，步骤，结果然后会由PL进行确认和提交。

Bug的结束时间以及结束原因。
分四种情况，一种是因为测试员测试OK的，原因一般为修改完成等
一种是开发人员觉得有风险不修改，觉得没有必要修改，或者其他的原因不与修改的。这时候的原因就比较多，例如，延迟修改，不修改等。
第三种情况一般是因为测试人员自己的原因发行的误bug.比如说式样，需求，设计已经修改但是测试员没有及时参照。此时的结束原因就会是：操作错误，需求理解错误，涉及理解错误，数据错误等等。
最后一种其实也不算是bug.但是不能将结束原因归咎于测试员的误操作。比如需求变更，环境原因等。

作者: pepper 时间: 2008-7-4 14:18
标题: 12楼的版主
能否把你那有目录的报告模板，以附件的形式粘贴出来，供我们新手下载，帮帮我们这些新手吧！！！

作者: 低头浅笑 时间: 2008-7-4 16:09

都说的好棒阿,我要慢慢吸收阿.!

作者: khm0508 时间: 2008-7-6 10:21
学习中

作者: khm0508 时间: 2008-7-6 10:26

作者: mfecit 时间: 2008-7-7 10:41
有点要说明的地方
首先声明：我刚开始测试工作，所讲的可能不准确，还请大家多多指正，这也正是我在此发贴的原因，想了解下大家的看法，毕竟测试不是很统一，尤其在国内，问题还是很多的

测试报告与测试总结报告是不同的文档（至少我是这么认为的）
一、测试总结报告是项目完成后提交的总结性报告，内容涵盖点较多、篇幅也较大、也比较规范，前面不少高人亦讲得很清楚了
二、测试报告分几种情况
1.项目已完成，针对用户不断反馈的bug进行验证、修复，最终提交给用户、开发人员而编写的文档，我们公司是将报告提交给开发人员、测试负责人，并由开发人员审核修改（因为客户主要由他们直接沟通），最终由他们提交给用户。其实大部份情况开发人员不会作修改，不过他们会检查，如果有不清楚的随时问测试人员，当然有时他们也会针对用户作些修改，不过最终提交给用户的文档，我们测试人员很少看到
2.项目在开发阶段，开发人员可能急于了解他所编写的某个模块能否实现预期的功能而让测试人员辅助测试，最终提交给开发人员的文档
目前我们公司所编写的测试报告都要经开发人员之手，而且这种报告是要经常编写的，所以文档中以1-2页为最佳，至于模板什么的也不是那么统一，还在摸索阶段…

作者: 卖烧烤的鱼 时间: 2008-7-7 11:27
标题: 回复 27# 的帖子
有效的编写测试报告，其实最重要的就是要把握我说提及的两点
“了解你的听众”和“分而制治”；
如：测试中经验会碰到类似这样的测试：
功能验证测试
小补丁测试
运营上线测试
用户反馈测试
用户验收测试
回归测试
等等，其实这些均需要分开编写测试报告，试想下，如果你提交客户了一份报告，此项目以前发现了500个Bug，你认为客户看到此情景会是什么表情^_^

作者: mfecit 时间: 2008-7-7 13:38
“卖烧烤的鱼”讲的报告太多了
做软件测试，经常跟文档打交道，最好有统一的文档格式，太多了不是太好，而且重叠的部分比较多，报告嘛，弄来弄去，就那几点，把问题描述清楚就行了
我认为测试报告分对内与对外两种就可以了，对于具体的内容可以进行适当的修改
当然最适合公司现状的就是最好的了，有的做外包的可能对方会让提交满足他们要求的文档，那样的公司可能更规范些，而我们公司是自己开发软件，然后测试部来测试，相对来说，还是开发为主。你提交给用户的文档再好、再规范，如果用户在实际验收软件时发现了明显的bug，那就不好了。所以文档还是实用为好…

作者: 卖烧烤的鱼 时间: 2008-7-7 13:44
标题: 回复 29# 的帖子
这个要结合公司实际情况来说，研发团队5,10,50,100,200,500人要有针对性的对待，所以我前面讲述的报告中均注明了，要看“公司要求”

作者: mfecit 时间: 2008-7-7 13:45
“卖烧烤的鱼” 所在公司一定是做的比较大了，规范比较详细啊
只要方便管理，详细才好啊
不过许多公司做不到那一点，只能从简、实用…

作者: 252090366 时间: 2008-7-9 20:51
谢谢大家帮我解惑，谢谢烤鱼大哥！

作者: sundyhui0322 时间: 2008-7-11 13:45
I'm aggree with the grill-fish's appinion, the test report should concern to different 'customers', so as, it will depart to different report. as 22# ladie's said, it is just the one part of a report., to be specific, it only can say it's a discription for a bug, but not a complete report.

作者: liangjz 时间: 2008-7-14 12:43
标题: 回复 12# 的帖子
面对这么多受众,真要针对不同的用户编写测试报告，如果是互联网的项目，呵呵，估计就没有测试的时间了)

作者: 卖烧烤的鱼 时间: 2008-7-24 16:10
标题: 回复 34# 的帖子
我想不会占用多少时间，如果制定的相应模板评审通过，大家意见一致，写报告应是很快的

作者: vivian2008 时间: 2008-8-6 14:03
标题: 有效的测试报告
具体说一般一个测试报告有如下部分构成:
1.引言

这个不用多说了，一般包括编写目的，项目背景介绍，参考资料等等，该项基本可以随便写写。（只是为了保持文档的完整性）

2.测试用例设计

对用例设计做一个简单的描述，包括测试范围阿，测试目标阿，测试重点阿等。该项基本可以随便写写。（只是为了保持文档的完整性）

3.测试环境

主要描述测试所用环境，包括硬件环境和软件环境，服务端和客户端。该项比较重要。

4.测试方法

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

6.测试时间安排（执行情况）

主要描述测试过程，每个时间段都做了什么事情。该项必不可少。

7.缺陷汇总及分析

7.1缺陷总结

一般按照严重程度，功能模块进行划分。能画图就画个图吧，直观一点。该项很重要，绝不可少。

7.2缺陷分析

通过上面7.1的总结，对bug进行分析。这项是测试报告的核心所在，一般有缺陷功能模块分析，缺陷类型分析和缺陷发现阶段分析

7.3遗留问题

目前软件残存的已知问题。有些是解决不掉的问题。该项很重要，绝不可少。

7.4测试结论

基于以上分析，给被测软件一个全面客观真实的结论，功能如何，性能如何，稳定性，安全性等等给出一个评价。该项最重要，绝不可少。

8.测试过程改进

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

9.附录

一般附上缺陷列表以及执行过的测试用例地址等。该项基本可以随便写写。（只是为了保持文档的完整性）

作者: vivian2008 时间: 2008-8-21 23:13
具体说一般一个测试报告有如下部分构成：
1.引言
  这个不用多说了，一般包括编写目的，项目背景介绍，参考资料等等，该项基本可以随便写写。（只是为了保持文档的完整性）
2.测试用例设计
  对用例设计做一个简单的描述，包括测试范围阿，测试目标阿，测试重点阿等。该项基本可以随便写写。（只是为了保持文档的完整性）
3.测试环境
  主要描述测试所用环境，包括硬件环境和软件环境，服务端和客户端。该项比较重要。
4.测试方法
  主要描述测试过程中自己用到什么测试方法，白盒还是黑盒，哪些部分用了自动化，用多少。该项比较重要。
5.测试时间安排（执行情况）
  主要描述测试过程，每个时间段都做了什么事情。该项必不可少。
6.缺陷汇总及分析
6.1缺陷总结
  一般按照严重程度，功能模块进行划分。能画图就画个图吧，直观一点。该项很重要，绝不可少。
6.2缺陷分析
  通过上面7.1的总结，对bug进行分析。这项是测试报告的核心所在，一般有缺陷功能模块分析，缺陷类型分析和缺陷发现阶段分析
6.3遗留问题
  目前软件残存的已知问题。有些是解决不掉的问题。该项很重要，绝不可少。
6.4测试结论
  基于以上分析，给被测软件一个全面客观真实的结论，功能如何，性能如何，稳定性，安全性等等给出一个评价。该项最重要，绝不可少。
7.测试过程改进
  对整个测试活动进行一个总结，有哪些得失，测试方法和流程需要哪些改进，测试过程中暴露出哪些问题，有哪些好的地方值得发扬等等。该项很重要，绝不可少。
8.附录

作者: chuming 时间: 2008-8-27 18:35
标题: 个人认为版主有偏见
个人认为10#，比12#讲得好，版主有偏见！！！

作者: likelovetest 时间: 2008-10-8 11:35
标题: 你太有“才”了

原帖由 magic_zhu 于 2008-7-1 18:01 发表
简明　扼要　通俗　易懂　＋　特殊情况

你太有“才”了，就写几个字，晕倒！！！

作者: baoshd 时间: 2008-10-9 15:12
楼上这些都写了很多建议了，希望吸取好的地方，不要被别人误导

作者: timfung 时间: 2009-7-7 18:12

作者: iamcoldice 时间: 2013-9-22 10:50

作者: chenxl624 时间: 2013-10-18 09:08
看了这么的答案，应该吸收一下，结合自己所需！学习了

作者: TestingGirlzxh 时间: 2014-5-28 21:36
不错

作者: 1014552551 时间: 2014-8-18 17:35
mark

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)