如何提交高质量的软件缺陷(Bug)记录?

2021-09-27 10:55发布

12条回答
香蕉牛油果酸奶
2楼 · 2021-09-28 09:17

高质量的Bug记录:

通用UI要统一、准确缺陷报告的UI要与测试的软件UI保持一致,便于查找定位。

尽量使用业界惯用的表达术语和表达方法使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。

每条缺陷报告只包括一个缺陷每条缺陷报告只包括一个缺陷,可以使缺陷修正者迅速定位一个缺陷,集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。

不可重现的缺陷也要报告首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现,若尽力之后仍不能重现,仍然要报告此缺陷,但在报告中要注明无法再现,缺陷出现的频率。

明确指明缺陷类型根据缺陷的现象,总结判断缺陷的类型。例如,即功能缺陷、界面缺陷、数据缺陷,合理化建议这是最常见的缺陷或缺陷类型,其他形式的缺陷或缺陷也从属于其中某种形式。

明确指明缺陷严重等级和优先等级时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决,小装饰性问题可能被当作高优先级。

描述 (Description) ,简洁、准确,完整,揭示缺陷实质,记录缺陷或缺陷出现的位置描述要准确反映缺陷的本质内容,简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷,包含缺陷发生时的用户界面(UI)是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

短行之间使用自动数字序号,使用相同的字体、字号、行间距短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。

每一个步骤尽量只记录一个操作保证简洁、条理井然,容易重复操作步骤。

确认步骤完整,准确,简短保证快速准确的重复缺陷,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。

根据缺陷,可选择是否进行图象捕捉为了直观的观察缺陷或缺陷现象,通常需要附加缺陷或缺陷出现的界面,以图片的形式作为附件附着在记录的“附件”部分。为了节省空间,又能真实反映缺陷或缺陷本质,可以捕捉缺陷或缺陷产生时的全屏幕,活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置,通常要求附加中文对照图。 附加必要的特殊文档和个人建议和注解如果打开某个特殊的文档而产生的缺陷或缺陷,则必须附加该文档,从而可以迅速再现缺陷或缺陷。有时,为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现,可以附加个人的修改建议或注解。

检查拼写和语法缺陷在提交每条缺陷或缺陷之前,检查拼写和语法,确保内容正确,正确的描述缺陷。

尽量使用短语和短句,避免复杂句型句式软件缺陷管理数据库的目的是便于定位缺陷,因此,要求客观的描述操作步骤,不需要修饰性的词汇和复杂的句型,增强可读性。以上概括了报告测试缺陷的规范要求,随着软件的测试要求不同,测试者经过长期测试,积累了相应的测试经验,将会逐渐养成良好的专业习惯,不断补充新的规范书写要求。此外,经常阅读、学习其他测试工程师的测试缺陷报告,结合自己以前的测试缺陷报告进行对比和思考,可以不断提高技巧。

缺陷描述内容缺陷描述的内容可以包含缺陷操作步骤,实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正,有些开发的再现缺陷能力很差,虽然他明白你所指的缺陷,但就是无法再现特别是对系统不熟悉的新加入开发人员,介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么,期望结果可以让开发了解正确的结果应该是如何。


人间何须值得
3楼 · 2021-09-28 10:15

一条bug信息至少需要以下几条:
bug编号;
bug严重级别,优先级;
bug产生的模块;
首先要有bug摘要,阐述bug大体的内容;
bug对应的版本;
bug详细现象描述,包括一些截图、录像....等等;
bug出现时的测试环境,产生的条件即对应操作步骤;

嘿呦嘿呦拔萝卜
4楼 · 2021-09-29 09:04

一个缺陷报告必须包含以下核心要素:
1)测试环境
2)软件版本
3)缺陷标题(问题描述)
4)测试步骤
5)期望结果
6)实际结果
7)详细日志及界面截图

一篇高质量的软件缺陷记录应该考虑一下方面:
1) 通用ui要统一、准确
缺陷报告的ui要与测试的软件ui保持一致,便于查找定位。
2) 尽量使用业界惯用的表达术语和表达方法
使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。
3) 每条缺陷报告只包括一个缺陷
每条缺陷报告只包括一个缺陷,可以使缺陷修正者迅速定位一个缺陷,集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。

不吃鱼的猫
5楼 · 2021-09-29 21:31

做好每一个步骤,比如测试用例什么的都提前准备好,打有准备的仗

希希
6楼 · 2021-09-30 10:32

1、唯一性。一个bug说明一个问题,如果有能力的话,一个bug说明一类问题,这一类问题一定要能判断出是一条代码错误引起。 2、可重现。提供这个bug的精确步骤,使开发人员容易看懂。 3、一致性。bug描述及所有信息要前后一致,不可有歧义。 4、完整性。最好能抓图,一目了然;测试环境和特定条件一定要描述清楚,许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节但又必要的特定条件。 5、简洁性。通过使用关键词,可以使软件缺陷的标题描述短小简练,又能准确解释产生缺陷的现象。 6、跟踪性。也许随着版本的变化,或者测试的深入,对bug有了新的认识或者新的判断,及时补充相关信息,能够提供给开发更有用的信息。 7、客观性。软件缺陷描述不要带有个人观点,不要对开发人员进行评价,软件缺陷报告是针对产品的。 其实在平时测试中,经常会遇到不能重现的bug,这些问题有不能提交bug,如果放过往往上线后出现的概率很大,问题也一般比较不可接受。所以我觉得对于重现不可重现的bug是做好测试很重要的能力。 1、保留信息。遇到问题,最好抓图,搜集错误日志,保留测试现场环境,一旦发现此问题不可重现,这些数据和信息将很重要。 2、提高意识。很多人在遇到这类问题时,往往觉得后来操作不可重现了,因此就忽视了。这样往往会把此类bug遗留到产品发布后。欠的帐总要还得。 3、自我分析。对于自己分析这类问题,其实对自己的提高是最大的。分析思路:环境问题和操作顺序。 4、寻求帮助。如果研发可以帮忙,并且研发是负责任的话,只有信息全,研发分析往往是最快的途径。如果研发忙或者不乐意做,也是不可厚非的。但就要寻求组内能力强的人员或者组内讨论分析,集中大家的力量往往可以事半功倍。 在我的经历中,通过上面的方法,几乎能把所有的不可重现的问题变成可重现的并且提交bug。

一个Ai
7楼 · 2021-09-30 13:54

一条 Bug 记录最基本应包含:编号、Bug 所属模块、Bug 描述、Bug 级别、发现日期、发现人、修改日期、修改人、修改方法、回归结果等等;

要有效的发现 Bug 需参考需求以及详细设计等前期文档设计出高效的测试用例,然后严格执行测试用例,对发现的问题要充分确认肯定,然后再向外发布如此才能提高提交 Bug 的质量。


我是大脸猫
8楼 · 2021-09-30 14:56

一条Bug记录最基本应包含:

bug编号;

bug严重级别,优先级;

bug产生的模块;

首先要有bug摘要,阐述bug大体的内容;

bug对应的版本;

bug详细现象描述,包括一些截图、录像…等等;

bug出现时的测试环境,产生的条件即对应操作步骤;

高质量的Bug记录:


通用UI要统一、准确

缺陷报告的UI要与测试的软件UI保持一致,便于查找定位。

尽量使用业界惯用的表达术语和表达方法

使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。

每条缺陷报告只包括一个缺陷

每条缺陷报告只包括一个缺陷,可以使缺陷修正者迅速定位一个缺陷,集中精力每次只修正一个缺陷。校验者每次只校验一个缺陷是否已经正确修正。

不可重现的缺陷也要报告

首先缺陷报告必须展示重现缺陷的能力。不可重现的缺陷要尽力重现,若尽力之后仍不能重现,仍然要报告此缺陷,但在报告中要注明无法再现,缺陷出现的频率。

明确指明缺陷类型

根据缺陷的现象,总结判断缺陷的类型。例如,即功能缺陷、界面缺陷、数据缺陷,合理化建议这是最常见的缺陷或缺陷类型,其他形式的缺陷或缺陷也从属于其中某种形式。

明确指明缺陷严重等级和优先等级

时刻明确严重等级和优先等级之间的差别。高严重问题可能不值得解决,小装饰性问题可能被当作高优先级。

描述 (Description) ,简洁、准确,完整,揭示缺陷实质,记录缺陷或缺陷出现的位置

描述要准确反映缺陷的本质内容,简短明了。为了便于在软件缺陷管理数据库中寻找制定的测试缺陷,包含缺陷发生时的用户界面(UI)是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

短行之间使用自动数字序号,使用相同的字体、字号、行间距

短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。

每一个步骤尽量只记录一个操作

保证简洁、条理井然,容易重复操作步骤。

确认步骤完整,准确,简短

保证快速准确的重复缺陷,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。

根据缺陷,可选择是否进行图象捕捉

为了直观的观察缺陷或缺陷现象,通常需要附加缺陷或缺陷出现的界面,以图片的形式作为附件附着在记录的“附件”部分。为了节省空间,又能真实反映缺陷或缺陷本质,可以捕捉缺陷或缺陷产生时的全屏幕,活动窗口和局部区域。为了迅速定位、修正缺陷或缺陷位置,通常要求附加中文对照图。

 附加必要的特殊文档和个人建议和注解

如果打开某个特殊的文档而产生的缺陷或缺陷,则必须附加该文档,从而可以迅速再现缺陷或缺陷。有时,为了使缺陷或缺陷修正者进一步明确缺陷或缺陷的表现,可以附加个人的修改建议或注解。

检查拼写和语法缺陷

在提交每条缺陷或缺陷之前,检查拼写和语法,确保内容正确,正确的描述缺陷。

尽量使用短语和短句,避免复杂句型句式

软件缺陷管理数据库的目的是便于定位缺陷,因此,要求客观的描述操作步骤,不需要修饰性的词汇和复杂的句型,增强可读性。

以上概括了报告测试缺陷的规范要求,随着软件的测试要求不同,测试者经过长期测试,积累了相应的测试经验,将会逐渐养成良好的专业习惯,不断补充新的规范书写要求。此外,经常阅读、学习其他测试工程师的测试缺陷报告,结合自己以前的测试缺陷报告进行对比和思考,可以不断提高技巧。

缺陷描述内容

缺陷描述的内容可以包含缺陷操作步骤,实际结果和期望结果。操作步骤可以方便开发人员再现缺陷进行修正,有些开发的再现缺陷能力很差,虽然他明白你所指的缺陷,但就是无法再现特别是对系统不熟悉的新加入开发人员,介绍步骤可以方便他们再现。实际结果可以让开发明白错误是什么,期望结果可以让开发了解正确的结果应该是如何。


IT学习
9楼 · 2021-10-08 11:30

1.唯一性

一个bug代表一个问题,最好代表一类问题

2.可重复性

附加完整的复现步骤,让开发容易复现

3.完整性

提交的缺陷最好附加截图或者录屏或者日志,方便开发定位问题

4.一致性

提交的bug描述及所有信息要前后一致,不要引起歧义


相关问题推荐

  • 回答 157

    虽然从事开发行业的女生越来越多,但女生的比例还是远比不上男生。软件测试的男女生比例则基本相当,软件测试要求细心、耐心,大部分女生也是比较适合学的。而且软件测试课程分为手工测试和自动化测试,手工测试分为功能测试、性能测试、接口测试。自动化测试...

  • 回答 121

    需要。很多人当初抱着测试不需要懂代码,才选择了这个行业,这个就要看对自己的职业定位了,是止步于月薪过万就可以了,还是往20k、30k去突破,如果这样的话,是肯定要会接口、会自动化,就必然要涉及到代码。如果真的看不懂代码,实际的测试后期的工作会出现...

  • 回答 91

    在我看来游戏开发挺难的,尤其像手游一类的还有网游,里面有很多的程序代码而且伤神又费力,不过也有女生在这方面做的很好的,如果你感兴趣,非常想学,可以试试

  • 回答 80

    软件测试专业现在很火热,很缺少人才,25岁学软件测试能学会,就业薪资也高,工作也相对轻松

  • 回答 11
    已采纳

    测试类型有:功能测试,性能测试,界面测试。功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用...

  • 回答 15
    已采纳

    这个其实和接口测试的场景密不可分的,比如说:外部接口测试:    必须先接口测试通过了,才能执行功能测试子系统或者各个模块之间的联调测试:    必须各子系统后台代码完成,并提供接口才可以完成测试,一般来说都要求各子系统功能测试通过后再进行...

  • 回答 6
    已采纳

    这个是会因为公司的架构不同而不同的,并不是固定的,但是一般是会有专门的测试部门,或者叫质量保证部,也有可能是叫别的名字。

  • 回答 43
    已采纳

    移动端测试,包括App兼容性测dao试,7*24小时稳定性测试,功耗性能测试,UI测试,交互测试等,课程主要学习的内容有:1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库,学习目标是掌握软件测试核心理论,结合Linux、数据库等可实现移动端、w...

  • 回答 1

    标题  1. 首先要做一个标题党(此标题党非彼标题党)。标题一定要清晰简洁易理解,不应该臃长  2. 尽量前缀要规范,例如模板: [Product][Version]_[Feature]_[Title],这样描述会很清晰,也方便查找  3. 缺陷的标题一定要描述在什么情况下发生了什么问...

  • 回答 1

    1、 缺陷报告可以记录缺陷2、可以对缺陷进行跟踪管理3、可以对缺陷报告进行分类 总结 统计

  • 回答 1

    1、缺陷编号(Defect ID),提交BUG的顺序。2、缺陷标题(summary),简明扼要的说明一下这个BUG。3、缺陷的发现者(DetectedBy) ,一般是自己。4、发现缺陷的日期(Detected on date),一般是当天。5、缺陷所属的模块(subject), 在测试哪个模块的时候发现的BUG...

  • 回答 1

    缺陷标题好的缺陷标题需要让相关人员一目了然,一般建议的格式是条件+失败。缺陷类型缺陷类型也是根据具体的项目而定的。但一般情况下分为功能、界面、建议。重现步骤重现步骤的编写规则可以参考测试用例中的操作步骤 ,一定要足够详细、说明清楚问题的操作顺...

  • 回答 1

    工具:NoSQLUnitJsTestDriverQTRunnerVenusFluintBuster.JSSQLUnitECUTQTestlibUnitilsgreatestDbUnitAbbotGoogleTest框架:JUnitMoqJSCaptureMockCUnitPyUnitCppUTestCppUnitzCUTcipra

  • 回答 1

    JunitTestNGGoogleTestpytestunittestJmockitJaCoCogcov、lcov、gcovrCoverage.pyEvoSuiteDiffblue Cover

  • 回答 1

      React Hooks测试库( Testing Library)是一个简单而完整的React Hooks测试工具。  React Hooks测试库让用户可以为React钩子创建简单的测试工具,自定义钩子的输入和检索输出,以处理在功能组件体内运行的情况。  使用React Hooks,用户不必为了测试而去担...

  • 回答 1

    1、单元测试注重代码逻辑,接口测试注重业务逻辑;2、单元测试的粒度最小,是测试最小独立的单元模块(不依赖其他模块);接口测试不是,会覆盖很多;3、单元测试是白盒测试,接口测试是黑盒测试;4、单元测试关注的是代码的实现和逻辑,测试范围较小,保证实...

没有解决我的问题,去提问