如何编写有效的测试报告？（08-06-27）（获奖名单已公布）

tengmy

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

能否把你那有目录的报告模板，以附件的形式粘贴出来，供我们新手下载，帮帮我们这些新手吧！！！

低头浅笑

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

khm0508

学习中

khm0508

mfecit

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

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

卖烧烤的鱼

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

mfecit

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

卖烧烤的鱼

这个要结合公司实际情况来说，研发团队5,10,50,100,200,500人要有针对性的对待，所以我前面讲述的报告中均注明了，要看“公司要求”

mfecit

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

252090366

谢谢大家帮我解惑，谢谢烤鱼大哥！

sundyhui0322

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

面对这么多受众,真要针对不同的用户编写测试报告，如果是互联网的项目，呵呵，估计就没有测试的时间了)

卖烧烤的鱼

我想不会占用多少时间，如果制定的相应模板评审通过，大家意见一致，写报告应是很快的

vivian2008

具体说一般一个测试报告有如下部分构成:
1.引言

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

2.测试用例设计

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

3.测试环境

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

4.测试方法

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

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

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

7.缺陷汇总及分析

7.1缺陷总结

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

7.2缺陷分析

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

7.3遗留问题

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

7.4测试结论

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

8.测试过程改进

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

9.附录

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

vivian2008

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

chuming

个人认为10#，比12#讲得好，版主有偏见！！！

likelovetest

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

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

baoshd

楼上这些都写了很多建议了，希望吸取好的地方，不要被别人误导

timfung