如何写好测试报告

发表于:2014-08-20来源:uml.org.cn作者:蒲冬梅点击数: 标签:测试报告
最近读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的处理有意见,确实需要上诉,不要依赖自己最初错误报告中的语言和信息,报告是不可更改的,但是测试员需要列举更有效的例子,测试员需要与其他产品项目相关人员沟通,补充做一些后续测试,寻找该程序错误可能存在的更严重的错误。程序员所做的每个上诉都必须是有说服力的。即使不能赢得所有上诉(当然不可能赢得所有上诉)也应该得到自己的所有上诉理应获胜的好名声。

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

原文转自:http://www.uml.org.cn/Test/200512212.htm