缺陷报告是不是可以随意写
一、测试人员的主要职责编写测试计划编写测试用例执行测试,发现缺陷提交缺陷报告验证所发现的缺陷是否得到修改编写测试总结报告二、缺陷报告的组成缺陷编号(Defect ID):提交缺陷的顺序;缺陷标题(summary):简明扼要的描述一下缺陷;缺陷的发现者(Detected By): 测试人员自己;发现缺陷的日期(Detected date):一般为当天;缺陷所属的模块(subjecy):在测试哪个功能模块的时候发现的bug,开发组可以据此决定由谁负责修改该bug;发现缺陷版本(Detected in release):在测试哪个版本的时候发现的bug;指派给谁处理(Assigned to):测试人员指派给开发经理,开发经理根据缺陷所在的模块,需再次指派具体的开发人员;缺陷的状态(status):缺陷此时所处的处理阶段或处理情况;测试人员发现缺陷,提交缺陷报告,把缺陷的状态置为:new (新发现的bug);开发经理验证新提交的 bug ,如果是 bug ,把状态改为 open (打开的bug,开发组承认的bug),指派给具体的开发人员解决;如果不是bug,把状态改为rejected(拒绝的bug);开发人员看到指派给自己解决的bug,进行 bug 修复,修改完后,把状态改为:fixed(已经修复的 bug ,可以返测得 bug )测试人员对修复得 bug 进行返测,返测成功,把状态改为closed(关闭得缺陷,归档得 bug);如果返测不成功,把状态改为:reopen (重新打开得 bug);缺陷的严重程度(severity):bug 对软件的影响有多大Urgent:造成系统死机、重启、崩溃的缺陷;Very High:非常严重的缺陷;High:严重的缺陷;Medium:中等程度的缺陷;Low:小的缺陷;每一个等级到底包括哪些缺陷,最好在专门的文档中进行详细说明,这样可以使开发和测试人员达成共识。Bug Level (等级、级别)Definition (定义)性能 Performance缺陷的优先级(priority)测试人员希望该缺陷程序员在什么时间内或在哪个版本中解决Urgent:立刻修改(影响开发或者测试的进度)Very High:本版本修改;High:下版本修改;Medium:发布之前修改;Low:允许在发布中存在的缺陷描述 (description)把发现 bug 的步骤、使用的数据等记录下来,是程序员通过该描述清楚所发生的事情;
一条软件缺陷(或者叫Bug)记录都包含了哪些内容如何提交高质量的软件缺陷(Bug)记录
一个缺陷报告必须包含以下核心要素:1)测试环境2)软件版本3)缺陷标题(问题描述)4)测试步骤5)期望结果6)实际结果7)详细日志及界面截图一篇高质量的软件缺陷记录应该考虑一下方面:1) 通用ui要统一、准确缺陷报告的ui要与测试的软件ui保持一致,便于查找定位。2) 尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。3) 每条缺陷报告只包括一个缺陷每条缺陷报告只包括一个缺陷,可以使缺陷修正者迅速定位一个缺陷,集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。4) 不可重现的缺陷也要报告首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现,若尽力之后仍不能重现,仍然要报告此缺陷,但在报告中要注明无法再现,缺陷出现的频率。5) 明确指明缺陷类型根据缺陷的现象,总结判断缺陷的类型。例如,即功能缺陷、界面缺陷、数据缺陷,合理化建议这是最常见的缺陷或缺陷类型,其他形式的缺陷或缺陷也从属于其中某种形式。6) 明确指明缺陷严重等级和优先等级时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决,小装饰性问题可能被当作高优先级。7) 描述 (Description) ,简洁、准确,完整,揭示缺陷实质,记录缺陷或缺陷出现的位置描述要准确反映缺陷的本质内容,简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷,包含缺陷发生时的用户界面(ui)是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。8) 短行之间使用自动数字序号,使用相同的字体、字号、行间距短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。9) 每一个步骤尽量只记录一个操作保证简洁、条理井然,容易重复操作步骤。10) 确认步骤完整,准确,简短保证快速准确的重复缺陷,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。11) 根据缺陷,可选择是否进行图象捕捉为了直观的观察缺陷或缺陷现象,通常需要附加缺陷或缺陷出现的界面,以图片的形式作为附件附着在记录的“附件”部分。为了节省空间,又能真实反映缺陷或缺陷本质,可以捕捉缺陷或缺陷产生时的全屏幕,活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置,通常要求附加中文对照图。 附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或缺陷,则必须附加该文档,从而可以迅速再现缺陷或缺陷。有时,为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现,可以附加个人的修改建议或注解。12) 检查拼写和语法缺陷在提交每条缺陷或缺陷之前,检查拼写和语法,确保内容正确,正确的描述缺陷。13) 尽量使用短语和短句,避免复杂句型句式软件缺陷管理数据库的目的是便于定位缺陷,因此,要求客观的描述操作步骤,不需要修饰性的词汇和复杂的句型,增强可读性。以上概括了报告测试缺陷的规范要求,随着软件的测试要求不同,测试者经过长期测试,积累了相应的测试经验,将会逐渐养成良好的专业习惯,不断补充新的规范书写要求。此外,经常阅读、学习其他测试工程师的测试缺陷报告,结合自己以前的测试缺陷报告进行对比和思考,可以不断提高技巧。14) 缺陷描述内容缺陷描述的内容可以包含缺陷操作步骤,实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正,有些开发的再现缺陷能力很差,虽然他明白你所指的缺陷,但就是无法再现特别是对系统不熟悉的新加入开发人员,介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么,期望结果可以让开发了解正确的结果应该是如何。
撰写缺陷报告注意事项有哪些
缺陷报告是测试与开发沟通的桥梁,它记录了软件测试过程中发现的缺陷并能跟踪该缺陷从创建到关闭的全过程。错误的缺陷报告会误导开发人员,影响开发人员工作效率,进而加深开发与测试的敌对关系;错误的缺陷报告会影响测试人员的声誉(尤其是测试自身业务不熟悉提出的缺陷)。那么怎么写好一个缺陷报告呢,我们应该注意以下3点:1.尽量确保缺陷可以重现(注意标记上测试环境信息,如操作系统、浏览器等信息)2.简介、准确、完整3.一个缺陷一个报告当初在传智播客培训时候就讲过这个知识点特别重要,后来教别人也都会着重说一下。