如何写好测试报告

发表于:2007-04-22来源:作者:点击数: 标签:报告测试写好如何
最近读Cem Kaner,James Bach,Bret Pettichord合著的《 软件测试 经验与教训》受益颇多,因此根据文中的部份内容总结出来与大家共享,希望能达到知识交流与共享的目的。如果感兴趣,也可以阅读原书。 测试报告是产品部与技术部进行沟通的主要手段,测试报告

最近读Cem Kaner,James Bach,Bret Pettichord合著的《软件测试经验与教训》受益颇多,因此根据文中的部份内容总结出来与大家共享,希望能达到知识交流与共享的目的。如果感兴趣,也可以阅读原书。

测试报告是产品部与技术部进行沟通的主要手段,测试报告的好坏直接影响BUG的修改速度和程序员的心情。如果下苦功夫研究并写好报告,则所有阅读这些报告的人都会受益。因此我整理并撰写此文,希望对于能修直产品部与技术部的桥梁有所帮助。

一、 缺陷报告的原则

1、 有些错误永远也不会改正。测试员的责任不是保证所有错误都得到改正,而是准确报告问题,使程序员能够理解问题的影响。而深入研究并写出好的报告,常常对错误改正的可能性产生巨大的影响。

2、 及时报告缺陷。不要等到第二天或是下周才报告程序错误,不要等到忘记了一些关键细节才报告。拖延的时间越长,程序错误被解决的可能性就越小。

3、 每个程序错误都需要单独报告。不要努力把不同的程序错误合并到同一份报告,来减轻项目经理或程序员对重复错误报告的不断抱怨。如果多个程序错误写到一份报告中,有些错误就可能得不到修改。

4、 小缺陷也值得报告。小错误会使客户感到困惑,并降低客户对产品其他部份的信心。被认为是很小的缺陷可能包括拼写错误、小的屏幕格式问题,鼠标遗迹、小的计算错误,图形比例不准、在线帮助错误、不适当的灰掉了的菜单选项、不起作用的快捷键、不正确的错误信息,以及其它程序员认为不值得花精力去修改的缺陷。

5、 努力使错误报告有更高的价值。由于有很多人都要阅读并依赖错误报告,因此要下功夫丰富每个错误报告的信息。提高报告的可理解性。如:A、清楚列出错误报告的前置条件与实现的每一个步骤,避免前后语言混乱,它应该只需要描述现象,不要在产生错误的步骤中试图给出程序员的解决办法。这样会使错误报告看来冗长而难于理解。如果有好的解决办法或建议可以附在错误报告描述之后。B、要始终保持中立语气。C、不要开玩笑,否则有可能造成误解。

6、 永远都要报告不可重现的错误,这样的错误可能是时间炸弹。不可重现的错误可能会是公司能够支付的最昂贵的缺陷。有时错误无法重现。看到程序错误一次,但不知道如何使其再次出现。如果产品交付客户还出现这种情况,会影响客户对产品的信心,如果技术支持人员需要很长时间评估客户的数据或环境,客户则会更加厌烦。如果测试员清晰地报告错误征兆,程序员通过研究测试员怎么得到特定消息,或当测试员查看对话框或点击特定控件时可能会出现的情况。从而能够跟踪代码,相信程序员能够改正报告中“不可重现”缺陷中的20%。但在报告此类BUG时,一定要明确说明自己不能重现这个程序错误。

二、 缺陷报告的注意事项

1、 引用别人的错误报告要小心。如果没有得到错误报告的提交者的允许,可以补充评论,但不能编辑别人的材料。对于其他测试员的错误报告即使很糟糕也不要擅自修改。任何时候需要在错误报告中做补充,都要注明自己的姓名和日期。

2、 看似极端的缺陷可能是潜在的安全漏洞。如在一个在预期接受一个1~99的字段中,输入65536个9会导致程序崩溃。会有人真的这么干吗?是的,有人当然要这样做。有人会认为“如果有人愚蠢到这样做,程序崩溃会教训他“而忽略该错误,但实际上白痴不是惟一滥用程序的人。任何会产生严重后果的问题都应该解决,不管其多么“不可能”发生,当熟练的攻击者利用程序中的缺陷得手后,会写下这个消息并广为传播,使得其所有生手都可以使用脚本。

3、 立即对程序错误延迟决定上诉,如果决定据理力争,就一定要赢。如果测试员对某个BUG的处理有意见,确实需要上诉,不要依赖自己最初错误报告中的语言和信息,报告是不可更改的,但是测试员需要列举更有效的例子,测试员需要与其他产品项目相关人员沟通,补充做一些后续测试,寻找该程序错误可能存在的更严重的错误。程序员所做的每个上诉都必须是有说服力的。即使不能赢得所有上诉(当然不可能赢得所有上诉)也应该得到自己的所有上诉理应获胜的好名声。

至此,上面罗列的条款都与我们实际工作有着密切的关联,希望能借助此篇文章,让你能有兴趣读完本书的全部内容,相信一定能让你获益匪浅。

回复:如何写好测试报告 曾盛开(技术部)

我看完了,总是觉得程序员和测试员之间在问题分歧上存在很多不同之处,其中包括个人专业知识的深度,对软件理解的能力,对业务、程序的理解能力,产品开发成本、周期与bug之间的协调。

诸多方面加起来,使我的脾气在沟通协调bug问题上变得很容易激昂,或者说发火,头脑发热。程序员多少都有些自大,不甘屈服的情绪,而且确实很多东西由于变得和以前写好、定好的需求有出入,导致做好的东西可能又被推翻。。。心里那种滋味很不好受的。。。毕竟每个地方和环节都是自己努力去想过的,有时候一个问题可能是花去几天时间确保那样做没有漏洞和正确。

我感觉到两个部门之间协调缺少更多互动,比如产品部在测试之前或者有空时候可以培训一下技术部,一般会测试哪些东西,如何测试的,这样子程序员心里多少有更多的底,在写程序的时候会有一种警惕性,从而产品部也会轻松一些,双方有利,应该是三方有利,公司最有利。。产品部也要考虑如何帮助程序员快速有利地处理bug,而不是一味为了bug而找bug,这根本背离了两个部门合作的基调;技术部也同样有责任去帮助产品部理解好系统运行的流程,找出隐藏的bug 。

另外,我想说的是在文档细节上面不要过分苛求,否则一方面是开发进度和成本,另一方面是使Xp轻量级文档开发流程又变成重量级文档开发,程序员为了文档忙于疲命。。我深有体会的,文档花去的时间几乎占用了1/4-1/3。

我觉得在测试的同事面前谈测试,有些班门弄斧,关公卖刀,但有些话不得不说,那就开诚布公拿出来,就算贻笑大方也好吧~~~

回复:回复:如何写好测试报告 李鹏

文档花去的时间几乎占用了1/4-1/3:这个时间我不觉得多,我觉得不够。花在需求定义,开发文档方面的时间应该是1/2以上
我觉得XP编程不适合我们,理由有三:
1、我们的8.0项目跨度有近2年,可以说是个中型项目,xp编程比较适合小项目(2-3个月)。
2、xp编程理论中基本上没有提到如何对程序进行系统的测试,而我们公司非常重视软件测试,程序员和测试员的比例近1:1。
3、xp中对文档的定义是“够用就好”,而在众多的工程理论(rupcmm)中都建议要有详尽得需求和开发文档。花在需求定义,开发文档方面的时间应该是1/2以上。

回复:回复:如何写好测试报告 黄为东

技术部和产品部的斗争性,有它的积极作用,但确实存在两个部门目标不一致性的问题,既存在内部损耗,又存在被共同忽视的中间地带。
大胆设想一下,假设把技术部和产品部合并为一个大部,每个小组都配2个测试员,是否会更好呢?这样测试人员对本组开发人员的配合密切程度也许会更高。问题是,测试的专业性、分工性是否会下降?
该怎么组织,是一个大问题。

回复:回复:如何写好测试报告 蒲冬梅

产品只有足够人性化,用户才会乐意使用此功能,而不是买回去就将其束之高阁。文档只有足够详细化,才能为产品部测试提供准确的依据。因此就需要产品部与技术部能够有更多沟通,更充分的文档准备,更大的耐心。

因为最终目标我们只有一个,做出来的产品要对得起用户。因此我们需要彼此体谅,理解与尊重。

如果技术部有时间或是计划能够安排接受产品部的测试培训,我想我们部门每个同事都会举双手双脚赞成的。这样应该能减少很大部份测试的工作量。

关于为了找BUG而找BUG的说法,我觉得是很有必要就此申明一两句的。现在产品部最终提交到技术部的BUG都是有人负责审核的(BUG的定位是否准确,BUG的描述是否清晰等)。由于BUG的数量,这项工作其实是相当费时与费力的,因此曾停过一段的时间,但是为了提高BUG的质量和减少为了BUG而需要与产品部沟通的时间,这部份工作我们依然坚持在做。但是难免会有部份BUG在产品部进行准确定位是很困难的,而如果改为由技术部来定位则仅仅只是几分钟的事情,因此我们并未严格控制每个BUG都会精确定位,但是我们的目标是尽可能减少技术部为了BUG的描述或定位而进行多次反复的沟通。

因此就BUG本身的问题,也欢迎技术部能多多提意见,我们一定坚绝改正。

原文转自:http://www.ltesting.net