当前位置:首页 » 《资源分享》 » 正文

软件测试的缺陷管理与分析,小白福利拿走不谢!_myh919的博客

20 人参与  2021年10月27日 15:03  分类 : 《资源分享》  评论

点击全文阅读


软件测试过程中提交缺陷是测试工程师最常做的一件事,也是开发工程师解决问题的依据,所以需要对缺陷进行管理和分析。缺陷管理主要是管理从提交缺陷到解决缺陷这一系列的过程,包括流程中角色的变换。

缺陷分析主要对测试过程中所发现的缺陷进行分类分析,分析缺陷分布的情况,并对缺陷产生的原因进行归纳分类,为改善研发和测试过程提供依据。本章节我们先讲解“缺陷管理与分析”的内容。

缺陷报告的发展:早期并没有缺陷的概念,直到第一台计算机诞生后才有人提出Bug一词。那时仅仅是将缺陷使用Bug这个词来描述,而并未真正对缺陷的产生进行详细的描述。1945 年美国的哈珀将军第一次通过报告的形式来描述缺陷。

Bug的由来

Bug一词的原意是“臭虫”或“虫子”,现在在软件测试过程中所有发现的问题,我们都喜欢使用“Bug”这个词来描述。

早期第一代的计算机是由许多庞大且昂贵的真空管组成,并利用大量的电子真空管发光,可能正是由于计算机运行产生的光和热,导致一只小虫子钻进了一支真空管内,使整个计算机无法工作。

研究人员花费很长时间才找到小虫子所在的真空管,将其取出后,计算机又恢复正常。后来“Bug”这个名词就沿用下来,表示计算机系统或程序中隐藏的错误、缺陷或问题。与Bug 相对应,人们将发现Bug 并加以纠正的过程称为“Debug”,即“捉虫子”或“杀虫子”。

遗憾的是,在中文中一直没有找到一个恰当的词来准确地翻译“Bug”的意思,因此就一直使用“Bug”一词来表示,所以测试中所有的问题我们都称之为“Bug”。

一份简单的缺陷报告

从计算机诞生之日起,就存在Bug。但早期并没有针对缺陷的相关报告,第一个使用缺陷报告的方式来记录Bug 的是美国海军编程员、编译器的发明者格蕾斯· 哈珀(Grace Hopper)。哈珀后来成为了美国海军的一个将军,领导了著名计算机语言Cobol 的开发。

1945年9月9日下午15点,哈珀中尉正带领着她的小组构造一个称为“马克二型”的计算机。

当时的计算机并不完全是电子计算机,还使用着大量的继电器。那时正处于第二次世界大战期间,哈珀的团队在一间第一次世界大战时建造的老建筑中工作,夏天很炎热又没有空调,所有的窗户都敞开散热,突然“马克二型”死机了,研究员想尽了办法,最后定位到第70 号继电器出现故障,仔细研究发现原来是一只飞蛾在继电器里面,当然飞蛾被继电器电死了,她小心地使用镊子将飞蛾取出来,并用透明胶布贴到记录本中,这是第一次对缺陷进行描述。

早期的缺陷报告描述是很简单的,只对缺陷的步骤进行描述,下面是一份简单的缺陷报告。

缺陷标题:Arial、Wingdings 和Symbol 字体会破坏新文件缺陷产生的步骤:

  • (1)启动WordEdit 编辑器,然后创建新文件;
  • (2)输入四行文本,如重复输入内容“The quick fox jumps over the lazy brown dog”;
  • (3)选中所有四行文本,然后选择字体下拉菜单,并选择“Arial”字体。所有文本被转换成控制字符、数字和其他明显的随机二进制数据。

这是一份简单的缺陷报告,现在的缺陷报告所包含的元素已经丰富了很多。

一份好的缺陷报告

一份好的缺陷报告应该包含以下元素:缺陷ID 号、严重等级、归属版本、归属模块、简要描述、详细描述、附件、提交日期、提交人、当前状态、当前负责人和当前测试环境。

(1)缺陷ID号

  • 缺陷ID号即提交Bug 的ID号,一般情况下,当我们在缺陷管理系统中提交Bug 时,缺陷管理系统会自动生成一个ID 号,并不需要人为的定义,当然不同的缺陷管理系统生成缺陷ID 号的方式有所不同。

(2)严重等级

  • 缺陷严重等级是缺陷报告中最重要的属性之一,缺陷的严重等级分为:致命、严重、一般和建议四类,衡量缺陷的严重等级必须考虑两个维度:该功能在客户端使用的频率和缺陷带来的影响详见7.3.1 小节。

(3)归属版本

  • 归属版本是指当前测试的版本,即发现该Bug 所测试的系统版本。

(4)归属模块

  • 归属模块是指测试哪个模块发现Bug 的,即该Bug 是由哪个模块引起的。

(5)简要描述

  • 简要描述即使用一句话简要地概述该Bug 的内容,简要描述要简单明了,最好是一看便知道其含义,一般不超过15 个字。

(6)详细描述

  • 详细描述是Bug报告中的核心内容之一,需要通过详细的步骤来介绍发现Bug 的过程,一般分步骤地描述,这样让读Bug 的人更轻松、更省时且易理解。对于一些建议的问题,在详细描述里面还应该写明建议将功能修改成什么样。

(7)附件

  • 附件是用来辅助描述Bug的内容,一般包括以下几种形式:图片、日志文件、配置文件等。对于一些操作步骤或Bug 的结果,如果不能很准确地描述,应该借助图片来帮助描述,图片可以让开发工程师很简单地了解Bug 的步骤和结果;日志文件主要是将出现Bug 时的日志文件附带给开发工程师,这样便于分析Bug 出现的原因;相关配置文件主要是在出现Bug 时,将系统的相关配置文件附带给开发工程师,便于分析Bug 出现的原因。

(8)提交日期

  • 提交日期是指提交Bug时的日期,一般情况下缺陷管理工具会自动生成。

(9)提交人

  • 提交人是指提交该Bug 的测试工程师。

(10)当前状态

  • 当前状态是指Bug 当前的状态,Bug 状态在7.3.4 节有详细的介绍,每到一个步骤Bug 都有一个对应的状态,而这个状态一定要更新正确。

(11)当前负责人

  • 当前负责人是指该Bug 由哪些开发工程师负责修复。

(12)当前测试环境

  • 当前测试环境是指发现该Bug 时所处的环境,测试环境主要包括使用的浏览器、分辨率、操作系统和相关硬件信息。
  • 1)浏览器是指当前测试使用的是哪个厂家的浏览器及相关的版本,主要用于分析一些浏览器兼容的问题。
  • 2)分辨率是指当前测试时系统的分辨率。主要用于分析一些关于界面显示的问题。
  • 3)操作系统是指当前测试时的操作系统,应该介绍是什么操作系统以及是32 位还是64 位。
  • 4)相关硬件信息更多的是用于嵌入式系统的描述上,在纯软件的系统中一般不需要描述此项内容,对于嵌入式的测试应该描述清楚主板、电源板、接口板等其他硬件的版本信息。

缺陷报告应该遵循以下几个原则:

  • Correct(准确):每个组成部分的描述应该准确无误,不会引起误解。
  • Clear(清晰):每个组成部分的描述应该清晰,易于理解。
  • Concise(简洁):只包含必不可少的信息,不包括任何冗余的内容。
  • Complete(完整):包含修改该缺陷的完整步骤和其他本质信息。
  • Consistent(一致):按照一致的格式书写全部缺陷报告。

本章节关于“软件测试—缺陷管理与分析”的内容就学习到这里,大家觉得文章有用的话记得每天来这里和小编一起学习涨薪技能哦。

最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

关注我的公众号:程序员小濠免费获取~

码字不易,文章对你有帮助的话,点个赞收个藏,给作者一个鼓励。也方便你下次能够快速查找。

 


点击全文阅读


本文链接:http://zhangshiyu.com/post/30184.html

缺陷  描述  测试  
<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1