精华内容
下载资源
问答
  • 软件测试缺陷定义,缺陷(Defect):存在于软件之中偏差,可被激活,以静态形式存在于软件内部。 故障(Fault):当缺陷被激活后,软件运行中出现的状态,可引起意外情况,若不加处理,可产生失效,是一种动态行为...
  • 缺陷生命周期

    2021-03-23 11:50:32
    缺陷生命周期(K3)根据IEEEStd1044-1993定义的异常管理生命周期进行缺陷管理。(K3)根据IEEEStd1044-1993评估缺陷报告和缺陷分类以改进缺陷报告的质量  缺陷生命周期  (K3)根据IEEEStd1044-1993定义的异常管理生命...
  • 缺陷管理工具”禅道—升华Bug处理流程与相关属性 作为一个软件测试工程师,对缺陷管理工具(缺陷:Bug)的认识和准确操作是有所必要的,缺陷管理工具现在行业中有很多:禅道、QC、Clear Quest、TestLink、Bugfree...

    “缺陷管理工具”禅道—升华Bug处理流程与相关属性

    作为一个软件测试工程师,对缺陷管理工具(缺陷:Bug)的认识和准确操作是有所必要的,缺陷管理工具现在行业中有很多:禅道、QC、Clear Quest、TestLink、Bugfree、Bugzilla、Jira等。本文选择根据禅道带大家认识Bug处理流程以及Bug的相关属性:Bug标题、重现步骤、Bug类型、Bug严重程度、Bug优先级、Bug来源、Bug根因等重大属性。
    0

    1 BUG处理流程

    打开缺陷管理工具——禅道,软件测试工程师选择在“测试”视图页,选择好测试项目后,点击“Bug”,会看到测试流程状态:指派给我、由我创建、由我解决、未指派、未解决、未关闭、久未处理、被延期、需求变动等。
    1
    针对测试工程师的Bug状态:激活中、已解决、已关闭等。
    针对开发工程师的Bug解决方案:已解决、延期处理、重复Bug、外部原因、无法重现、不予解决、设计如此等。
    根据状态,我们来熟悉下Bug处理流程(即:缺陷生命周期)。
    2
    Bug处理流程(Bug的生命周期):

    • (1)测试工程师发现Bug,查证Bug无重复提交过,然后尽可能完善Bug的相关属性,接着再提交Bug,把缺陷的状态置为:new;
    • (2)开发工程师确认提交的Bug,进行Bug的重现与分析,如果不是Bug,拒绝Bug,把状态置为:rejected;如果是Bug,指派给具体的开发人员解决,把状态置为:open;
    • (3)开发人员看到指派给自己解决的Bug,进行修改Bug,修改完后提交给测试工程师进行返测,开发人员自己把Bug状态置为:fixed;
    • (4)测试工程师对修改的Bug进行返测,如果返测成功,则关闭Bug,把Bug状态置为:closed;如果返测不成功,则重新激活Bug,让开发工程师修改,把Bug状态改为:reopen。
    • (5)若经过多次返测后,测试工程师与开发工程师对该Bug有一定程度的争议,则测试工程师决策是否让项目经理来校验下是不是Bug,如果是Bug,则开发工程师必须进行修改;如果不是Bug,则测试工程师关闭Bug。

    在Bug处理过程中,项目中不同的角色应该关注的相应状态与处理态度不一样。

    针对开发工程师,应关注测试工程师所置状态:new、reopen、closed。new:开发工程师要对激活状态的Bug进行处理,根据处理过程,将其状态置为rejected、open、fixed以及“已解决”、“延期处理”、“重复Bug”、“外部原因”、“无法重现”、“不予解决”、“设计如此”等;reopen:重新打开的Bug是经过处理修改后的Bug通过测试工程师返测后表明没有修改正常,进而需要继续做相应的修改;closed:表明修改Bug成功,无缺陷。

    针对测试工程师,应关注开发工程师所置状态:rejected、open、fixed以及“已解决”、“延期处理”、“重复Bug”、“无法重现”、“外部原因”、“不予解决”、“设计如此”等,根据不同状态做出响应反馈操作。特别说明下,对于开发工程师说明由于外部原因、设计如此,甚至不予解决的Bug,要及时决策通知到项目经理那里,由项目经理来决定修改与否。

    2 Bug相关属性

    在这里插入图片描述
    禅道缺陷管理工具中,从测试人员界面可以很清楚的知道Bug的相关属性:产品模块、所属项目、影响版本、当前指派、Bug标题、重现步骤、相关需求、相关任务、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷根因、系统/浏览器、抄送、关键词、附件。
    3

    2.1 产品模块

    测试出的Bug所在的系统模块,如:职工管理系统 — 系统设置。

    2.2 所属项目

    测试的软件产品所属的项目名称。

    2.3 影响版本

    当前的测试版本。如:Trunk。

    2.4 当前指派

    当清楚该产品模块是哪个开发人员的情况下,直接指派到相应的开发人员;不清楚时,则直接指派给开发经理,由开发经理进一步分配指派。

    2.5 Bug标题

    Bug标题的确定,以产品模块 + 问题的简要描述。如:职工登录界面——登录出现问题,错误账号或密码也能登录。

    2.6 重现步骤

    从重现操作步骤、操作结果以及预期期望等3个方面去重现Bug。部分Bug能够容易的重现,但部分Bug则需要通过截图、打断点、日志、抓取网络包等去捕获有助于重现Bug的信息,尽可能的为Bug所属产品模块的开发工程师提供有效信息。在重现Bug描述过程中,应该精准定位Bug、准确列出操作的所有步骤、准确解释必须条件,甚至列举出示例。

    尽量排除无效的Bug,避免误报Bug。考虑Bug是不是程序所引起的?Bug征兆是不是假象?是不是网络问题导致数据不能连接?是不是应用软件的配置错误而导致数据不能连接?是不是外部特殊原因引起的问题?等方面去考虑,尽可能缩小出错的范围。

    2.7 缺陷类型

    根据测试的Bug,明确其类型,便于问题类型的统计、项目的总结。点击禅道的“缺陷类型”下拉菜单,可以列举出以下的缺陷类型:

    • 功能问题:功能错误、功能缺失、功能超越、设计二义性、算法错误
    • 接口问题:模块间接口、模块内接口、公共数据使用
    • 逻辑问题:分支不正确、重复的逻辑、忽略极端条件、不必要的功能、误解、条件测试错误、错误的变量检查、计算顺序错误、逻辑顺序错误、公共数据使用
    • 计算错误:等式错误、缺失运算符、错误的操作数、括号用法不正确、精度不够、舍入错误、符合错误
    • 收费问题:初始化错误、存取错误、引用错误的变量、数组引用越界、不一致的子程序参数、数据单位不一致、数据维数不正确、变量类型不正确、数据范围不正确、操作符数据错误、变量定位错误、数据覆盖、外部数据错误、输出数据错误、输入数据错误、数据检验错误
    • 用户界面问题:界面风格不统一、屏幕上的信息不可用、屏幕上的错误信息、界面功能布局和操作不合常规
    • 文档问题:描述含糊、项描述不完整、项描述不正确、项缺少或多余、项不能验证、项不能完成、不符合标准、与需求不一致、文字排版错误、文档信息错误、注释缺陷
    • 性能问题:严重、一般、轻微
    • 配置问题:配置管理问题、编译打包缺陷、变更缺陷、纠错缺陷
    • 标准问题:不符合编码标准、不符合软件标准、不符合行业标准
    • 环境问题:设计与编译环境、运行环境
    • 兼容问题:严重、一般、轻微
    • 其他问题:严重、一般、轻微

    2.8 缺陷严重程度

    不同的公司划分的缺陷严重程度不同,大致划分为3-5个级别,具体的等级划分可灵活调整。现在按照个人所处的环境进行5类划分,大致如下:

    严重级别:轻微
    增加用户使用体验的建议性问题
    风格不统一,例如:相近流程的页面布局不统一、相同问题点的提示信息不一致,但对用户的操作习惯或操作方法不会造成影响
    对齐方式不一致,例如:文字对齐以及页面挂列项不一致
    界面错误,例如:显示格式不规范、页面描述显示错误、字体错误等
    长时间操作的功能未给用户进度提示
    按钮或标签上有拼写错误的字符,例如:汉字、单词、字母等错误拼写
    错误定位及信息提示不准确,例如:出错后前台后台的信息提示错误、错误判断的顺序、错误出现的光标定位等
    严重级别:一般
    业务流程对应的功能未实现,但在不影响实际使用的前提下有替代方法解决
    简单业务的功能实现错误,例如:默认显示内容的错误、辅助说明描述不清楚、查询匹配的错误、查询列表初始查询条件的错误等
    页面输入限制错误,例如:文本框输入长度以及字符的限制错误、文件图片上传格式大小的限制错误,以及特殊输入要求判断的错误等
    日期和时间初始值错误,以及业务操作流程先后时间判断的错误
    严重级别:严重
    业务流程的功能未实现,但不影响到系统稳定性
    操作正确性不受影响,但影响到系统性能和响应时间
    功能实现与需求不一致,但影响流程中其他模块
    数据库建库或升级的脚本错误,丢失相关表或字段,影响系统正常运行
    存储过程不能正常执行对应的设计功能
    性能测试过程中,大数据量和并发压力大时,系统处理缓慢、网络异常以及少量数据丢失(低于0.5%)等情况
    严重级别:非常严重
    系统中未实现相应需求,以及密码明文显示
    业务流程对应的功能未实现,且无任何替代方法
    数据连接未释放,以及与其它模块接口的调用错误
    产生错误的结果,进而致使系统不稳定
    页面出现编译错误,甚至404页面
    性能测试过程中,大数据量和并发压力大时,系统停止处理,甚至大量数据丢失(大于0.5%)等情况
    严重级别:致命
    功能设计与需求设计严重不符
    主流程无法跑通,系统无法正常运行
    正常的用户操作流程,导致系统崩溃或者严重资源不足
    内存泄漏,数据泄漏的安全性问题
    应用模块无法启动或者非法退出
    致使通讯中断
    循环报错,使得无法正常退出

    2.9 缺陷优先级

    缺陷严重程度和缺陷优先级是2个含义不同但又密切联系的概念,分别从不同方面去描述软件缺陷对软件质量和最终用户的影响程序和处理方式。缺陷的严重程度与缺陷优先级不一定是一一对等。

    • 优先级别:低
      适当考虑,延迟处理,尽可能在发布前进行修复
    • 优先级别:中
      在软件开发工程师的阶段性任务完成后进行修复
    • 优先级别:高
      任务正常排队,但又不会影响到开发测试的工作进度
    • 优先级别:非常高
      软件开发工程师如果当前开发任务不是特别紧急的情况下,应该优先修复该缺陷;如果当前开发任务相对重要,则在完成这个开发模块后,应该优先修复该缺陷
    • 优先级别:紧急处理
      软件开发工程师必须先停止当前的开发任务,修复好该缺陷

    2.10 缺陷来源

    有需求、设计、编码、测试、集成、用户、其他等7个方面。

    2.11 缺陷根因

    有需求、设计、编码等3个方面。

    2.12 系统/浏览器

    操作系统(OS,Operating System),基本上是所有软件产品必须依赖的。软件所需求的操作可能存在差异,则需要针对性的设计开发。有如下操作系统:Windows、Linux、Unix、MAC、CentOS linux以及相应的不同版本。

    B/S(Browser/Server,浏览器/服务器结构),在互联网产品中,浏览器的兼容性显得十分重要,不同浏览器之间(IE、Firefox、Chrome、Opera、Safari等以及相应不同的版本)都可能存在兼容性问题,所以浏览器环境也是Bug重现的前提条件之一。

    2.13 抄送

    根据项目情况,选择抄送。

    2.14 关键词

    提炼出该Bug的几个重要关键词,以便后期查询、验证。

    2.15 附件

    重要的日志、文件、截图包等选择性的以附件提交,有助于开发工程师重现Bug。


    • 致谢
      若对大家有用,感谢点赞或评论;若有不足或补充之处,也感谢大家评论进行指正,后期我将对本文进行补充完善。相信这是互相进步的开始!
    展开全文
  • 缺陷生命周期

    2019-09-22 21:59:28
  • 禅道缺陷类型

    千次阅读 2019-03-19 10:01:59
    缺陷类型: 代码错误:需求中的功能设计没有在系统中实现 系统错误:存在或产生于所开发的系统之外的软硬件错误 设计变更/新增需求:由设计和需求变动引起的问题 界面优化:排版不整齐、不美观、相同或相近功能...

    缺陷类型:

    1. 代码错误:需求中的功能设计没有在系统中实现
    2. 系统错误:存在或产生于所开发的系统之外的软硬件错误
    3. 设计变更/新增需求:由设计和需求变动引起的问题
    4. 界面优化:排版不整齐、不美观、相同或相近功能风格不统一等
    5. 其他:测试人员误操作确认为发现问题

    缺陷严重程度:

    P1:(严重缺陷)给不能执行正常业务功能或重要功能,使系统崩溃或资源严重不足。

    1. 由于程序所引起的死机,非法退出。
    2. 死循环
    3. 数据库发生锁死,与数据库连接错误
    4. 错误操作导致的程序中断
    5. 严重的数值计算错误
    6. 数据通讯错误
    7. 数据丢失

    P2:(较严重缺陷):严重的影响系统要求或基本功能的实现,且没有办法更正。(重安装或重启动该软件不属于更正办法)

    1. 功能不符
    2. 重要功能未完全实现
    3. 程序接口错误
    4. 数据流错误
    5. 轻微的数值计算错误

    P3:(一般性缺陷)非重要功能无法正常执行,实现不正确、不完全,但是不影响总体功能:影响系统要求或基本功能实现,但存在合理更正办法。

    1. 界面错误
    2. 打印内容、格式错误
    3. 简单的输入限制未放在前台进行控制
    4. 删除操作未给出提示
    5. 数据输入没有边界值限定或限定不合理
    6. 某个不重要的菜单不起作用

    P4:(较小缺陷)操作界面的错误,使操作作者不方便或遇到麻烦,但它不影响执行工作或功能实现。

    1. 辅助说明描述不清楚
    2. 显示格式不规范
    3. 系统处理未优化
    4. 长时间操作未给用户进度提示
    5. 提示窗口文字未采用行业术语
    6. 提示信息显示有误

    缺陷优先级:

    P1:需要立即解决问题

    P2:需要在指定时间内解决的问题

    P3:产品开发计划内解决的问题

    P4:资源充沛时解决的问题

    展开全文
  • 使用禅道的具体方法,用一个项目作为例子,在整个生命周期内:产品、项目经理、研发、测试需要做的事情。 转载于:...

    使用禅道的具体方法,用一个项目作为例子,在整个生命周期内:产品、项目经理、研发、测试需要做的事情。

     

    转载于:https://www.cnblogs.com/zhaokunbokeyuan256/p/9598679.html

    展开全文
  • bug的生命周期

    千次阅读 2019-08-30 18:20:45
    广义概念: 除软件程序的漏洞或缺陷之外,还包括测试工程师或者用户发现和提出的软件可改进的细节,或与需求文档存在差异的功能实现等 测试人员的职责就是,发现这些bug,并交给开发人员,让开发人员进行修改 二. bug的...
  • BUG生命周期流程图

    2008-11-26 15:58:37
    关于BUG管理的流程,在不同公司可以依据实际需要的不同更改.
  • 一个BUG(缺陷)的生命周期

    万次阅读 2018-06-01 15:05:15
    缺陷状态 对于一个问题,其处理过程是一个周期周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。打开 : 表示问题被提交等待有人处理。重新指派 : 问题被重新指派给某人处理...
  • 禅道的下载地址
  • 目录大纲一、测试计划1.1 测试计划包括什么内容二、缺陷报告2.1 缺陷报告的八大要素2.2 bug的生命周期 一、测试计划 ① 测试时间、工作量、人员 ② 由于每个人的思维存在局限性,每项测试最后安排不少于2个人测试,...
  • 文章目录一、缺陷的基本概述1.1缺陷的定义1.2缺陷的属性1.2.1缺陷的类型1.2.2缺陷的严重程度1.2.3缺陷的修复优先级二、缺陷生命周期三、缺陷的识别四、缺陷报告 一、缺陷的基本概述 1.1缺陷的定义 软件未实现产品...
  • 缺陷管理--软件缺陷生命周期

    千次阅读 2013-06-14 17:54:36
    发现缺陷 开发人员检查缺陷 确认缺陷 修正缺陷 返回发现者 缺陷验证 完成 关闭缺陷
  • 生命周期中一般缺陷状态:新建、指派、已解决、待验、关闭。如果待验的bug在验证时没有解决好,我们需要重新打开(激活)->指派->已解决->待验,循环这个过程。中间其他状态:重新打开、拒绝、延期等 2:...
  • 禅道BUG提出及处理流程规范

    万次阅读 多人点赞 2019-09-27 11:41:31
    禅道BUG提出及处理流程规范 版本说明 版本 作者 时间 备注 1.0 _冷冷 2019/9/27 首版本提交 目录 1 概述 1 2 目的 1 3 作用 1 4 缩略词 1 5 适用范围 1 ...8.1 BUG生命周期 5 8.2 BU...
  • 一、软件测试的生命周期 1.软件测试的生命周期 需求分析–>测试计划–>测试设计、测试开发–>测试执行–>测试评估 2.软件测试&软件开发的生命周期 需求阶段 测试人员需要了解需求,对需求进行分解...
  •  从刚工作时接触的第一个缺陷管理工具禅道,到redmine、JIRA、bugzilla,再到现在的QC,当然还有其它种的开源的或商业的缺陷管理工具,它们的本质是一样的,就是来管理缺陷生命周期。  其实,你理解任意的一款...
  • 1.Bug的属性: .Bug出现的环境:指这个Bug是在什么系统环境下出现的,如:国内几大....Bug的类型:对于一个缺陷来说,有可能是编码人员实现时代码错误,也可能是功能未实现完全,或者UI上与UI设计图不符合等。 ...
  • 禅道BUG编写及处理流程规范

    千次阅读 2020-09-12 17:06:21
    本文档规范bug的提出及管理流程,定义BUG的整个生命周期。帮助测试、研发等人员了解BUG的处理流程。提高测试人员工作效率以及产品缺陷修复效率,避免出现搁置和遗漏的缺陷,从而提高产品的质量,降低质量检查和缺陷...
  • 软件测试的生命周期&测试流程

    千次阅读 多人点赞 2019-04-29 21:47:16
    一、软件的生命周期 二、开发模型 三、测试模型 四、测试流程 五、缺陷管理流程 六、软件和质量 一、软件的生命周期(基于瀑布模型的生命周期) 软件的生命周期:是指从产生到淘汰的过程 包括:计划(开发方与需求...
  • 狭义概念就是软件程序的漏洞或缺陷。 2.bug的类型:需要对项目有比较深的理解。 代码(功能)错误 界面优化 设计缺陷 3.bug的等级 致命错误 1.常规操作引起的系统崩溃,死机,死循环、闪退----必现非偶现 2.造成数据...
  • 禅道是国产的开源项目管理软件,专注研发项目管理,内置需求管理、任务管理、bug管理、缺陷管理、用例管理、计 划发布等功能,实现了软件的完整生命周期管理。 禅道的安装教程: 禅道官方网址: ...
  • 软件测试管理神器之zentao(禅道)-BUG管理 禅道在遵循其管理方式基础上,结合国内研发...禅道是一个软件全生命周期管理工具,但作为测试人员,可能梗关注其中的bug管理及测试用例管理的模块,本文就重点说下bug管理。
  • 11.缺陷Bug (1).什么是Bug 狭义概念:是指软件程序的漏洞或缺陷 广义概念:除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节(增强性,建议性)、或与需求文档存在差异的功能实现等 软件的bug指的...
  • 禅道,bug管理工具

    2017-11-14 15:40:43
    禅道 项目管理软件 是国产的开源项目管理软件,专注研发项目管理,内置需求管理、任务管理、bug管理、缺陷管理、用例管理、计划发布等功能,实现了软件的完整生命周期管理。已部署在linux服务器,测试可用,因为禅道有...
  • 为了在短时间内交付高质量应用程序,软件开发人员正在遵循一套通用的实践,称为DevOps生命周期。 那么,DevOps在软件应用程序开发领域中扮演着什么角色? 让我们深入了解其含义、用途以及DevOps生命周期中的每个...
  • 测试用例管理工具-禅道: 细分需求、任务、缺陷和用例 完整覆盖研发项目核心流程 完整软件生命周期管理
  • 禅道项目管理软件是国产的开源项目管理软件,专注研发项目管理,内置需求管理、任务管理、bug管理、缺陷管理、用例管理、计划发布等功能,实现了软件的完整生命周期
  • 如何高效完成产品生命周期管理

    千次阅读 2018-08-15 20:41:54
    本文会对几种不同的产品研发流程进行分析,结合自身的业务提出一套合适的产品研发生命周期管理流程。 项目管理方法论 CMMI  对于项目的研发流程,CMMI是专门针对软件研发提出的管理方法论,在国内CMMI...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,038
精华内容 415
关键字:

禅道缺陷的生命周期