一、编写Bugreport的原则
Bugreport是测试中最重要的一部分,也是测试人员价值的终极体现,一个有效的Bugreport,在编写的时候需要遵循以下原则:
Bug可重现,尽可能找到重现规律。测试人员在编写Bugreport之前必须在检查问题是否可重现,问题重现才可以让开发更有效地查找到原因并解决问题,对于比较复杂的问题,最好能够将Bug现场重现给开发人员,以方便问题追踪和原因定位。如果错误不可再重现,仍然应该写下来,但是必须说明问题的偶然性;
Bug描述简明准确,对于问题的描述,应该尽可能简明、准确。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤,不要出现在Bugreport中;
一个Bugreport只描述一个Bug,如果将几个问题都写在一个Bugreport中,开发人员很难有效发现自己的问题并解决,从而导致有些优先级别高的Bug没有得到及时的解决。因此在写Bugreport的时候,将Bug按照不同的优先级别将不同的问题指定给相应的开发人员;
Bug的唯一性,在提交Bugreport之前,要先确认这个Bug是否已经被其它人发现并报告。
衡量优秀的Bugreport的质量指标:
对管理层来说,是清晰明了的,特别是在主题概要这一级;
对于开发人员来说,是有用的,主要是提供能够让开发人员高效地调试问题的相关信息,使其可以很快的将Bug从“Opened”状态转变成“Closed”状态,提高测试和开发的工作效率;
对于后期的维护,能够有效从Bug信息查询出问题的描述和解决的方法。
二、如何编写Bugreport
Bugreport作为测试和开发之间沟通的桥梁,测试人员在报Bug的时候,有效的Bug描述,会更加容易帮助开发解决问题。一般来说,作为一个优秀的Bugreport,应该包括以下内容:
1、标题:简明扼要地对Bug进行一个概述,让人看标题就知道大概出现了什么问题。比如:“smfilter模块在压力测试时出现内存泄露。”
2、属性:Bug的属性应该包括:
产品名称:测试产品的名称;
产品子系统:测试产品的子系统,如果产品比较小,该项可以忽略;
产品模块:测试产品发现问题的模块的名称;
测试版本:当前的测试版本;
测试平台:Bug的产生跟平台有关,有些在suse下产生的Bug,在soralis下则正常,因为在报Bug的时候需要将当前测试的服务器的版本;
测试阶段:模块测试、内部集成测试、外部集成测试;
问题级别:紧急、严重、一般、轻微;
优先级别:高、较高、一般、低;
问题来源:测试、工程故障、升级、其他;
问题类型:功能问题、版本问题、遗留问题、新需求、低级错误、改进建议、移植修改、割接问题、配置错误、编译问题、性能问题、设计问题、兼容问题、新功能增强、偶发性出错。
这些属性在Bug跟踪管理系统中应该有默认值,在测试人员报bug的时候选择对应的属性值。
3、负责人:
开发人员:测试产品模块的开发人员;
测试人员:发现Bug的测试人员;
抄送:该Bug需要抄送给相关的开发人员或测试人员。一般来说,一个Bug除了发送给改Bug的开发负责人和测试负责人外,还需要抄送给项目经理、测试经理、该产品开发小组其他人员,该产品测试小组其他人员。
这些属性在Bug跟踪管理系统中也应该有默认值,在测试人员报bug的时候选择对应的负责人。
4、Bug的详细描述:这是Bug最重要的一部分,对Bug描述清晰准确,不仅有助于开发人员迅速定位解决问题,还对以后的维护工作有很大的帮助。一些比较简单的Bug,可以使用一两句话把问题准确描述,而对于一些比较严重或负责的Bug或者是新的需求,则应该详细说明。
5、附件:对于一些特殊的问题或者不能用语言很好地描述的问题,可以增加界面图形说明或参考资料或详细日志等附件。
6、其它属性:
BugID:Bug的唯一标志;
建档时间;
建档人;
Bug回复时间;
Bug关闭时间。
一般来说,在报bug之后,这些属性一般由bug跟踪管理系统自动生成。
最后: 下方这份完整的软件测试视频学习教程已经整理上传完成,朋友们如果需要可以自行免费领取 【保证100%免费】
这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!