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

51testing

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

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

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

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

1014552551

mark

TestingGirlzxh

不错

chenxl624

看了这么的答案，应该吸收一下，结合自己所需！学习了

iamcoldice

timfung

baoshd

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

likelovetest

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

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

chuming

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

vivian2008

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

vivian2008

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

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

2.测试用例设计

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

3.测试环境

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

4.测试方法

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

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

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

7.缺陷汇总及分析

7.1缺陷总结

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

7.2缺陷分析

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

7.3遗留问题

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

7.4测试结论

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

8.测试过程改进

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

9.附录

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

卖烧烤的鱼

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

liangjz

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

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.

252090366

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

mfecit

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

卖烧烤的鱼

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

mfecit

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

卖烧烤的鱼

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

mfecit

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

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

khm0508