如何写一份良好的缺陷(Bug)报告
作者:网络转载 发布时间:[ 2012/7/17 10:55:32 ] 推荐标签:
差:“你的应用”
好:”Kifu v1.01″
平台:告诉我们软件运行在什么平台。尤其是操作系统的名字及版本和游览器名称版本。特别是web应用,这些信息对我们很重要。
差:“Windows”
好:“Windows7,IE9”
是否能重现:有些恼火的Bug是间歇性的出现,我们想预先知道,如果我们正在处理一个灵异事件或者正逢Bug出现时。
差:留空白
好:“每次”,“偶然”,“不重现”
描述:这部分是很多人拿不定的地方,不知道怎么描述问题,在描述中做到包括下面的内容:
● 总结:用简洁的语言概括出Bug出现时你正在做的事情。从上下文开始,在操作应用的哪个部分。聚焦在你做的时候软件做了什么?
差:“系统不能用了”
好:在“honor report”页面单击“打印按钮”,但是报表是空的。
● 发生了什么:一步一步描述你做的事情当bug出现时,为什么你认为是错误的。事无巨细,打印出菜单的名称,页面标题,点击时的按钮或者链接的名称。做相同的操作是不是出现一样的错误。
差:“空白报表”
好:“点击 ‘File/Save as…’,’Save‘对话空弹出,然后点击‘OK’按钮,但是文件没有保存”
● 错误时什么:如果错误消息出现时,拷贝粘贴整个信息,这样更有利于我们跟踪错误。
差:“有个错误,点击它始终读不出”
好:“Error 403:访问拒绝”
● 复现的步骤:如果你可以让bug重现,那太好了,这能提供很大的帮助。一步步描述如何重现次bug。
差:“打印没法使用”
好:“从‘Honors Report’页面,点击‘打印按钮’”
● 预期结果:描述你预期发生的结果当bug发生时,这部分特别有用如果程序没有按照你期待的结果发生时,因为它很诡异。
差:“我期待能正常工作”
好:“我期待能看到‘Honors Reports’的PDF文件”
真实结果:当bug发生时是怎么发生的,什么错误,为什么有错,或者如果错误抛出,抛出什么错。
差:“没法用”
好:“我收到是空的PDF文件,或者’403错误,访问拒绝’”
● 附件:如果你知道怎么截屏,做吧,附上一个简短的错误,截屏可以是错误之前或者发生错误之后,我们的开发者能够看到究竟发生了什么。如果应用有崩溃的日志,同样附上它。
● 联系方式:附上你的名字和email,我们可以让你提交的报告及时的得到答复,在我们不理解问题的描述时还能够询问你,如果你忘记附联系方式了,我们也没法联系到你,也没法修复bug。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11