在代码测试中,通常一个 Bug 需要我们定义他们的优先级(即定义开发人员应该如何相应这个Bug) 和它的严重等级(即该 Bug 发生后对程序的影响). 专业的英文为 Priority -- 优先级:和Severity -- 严重等级. 优先级和严重等级不是紧密结合的 Bug 的两个属性,不是一个 Bug 的严重等级越严重那么它的优先级就越高. 具体为一个Bug 定义多少个 Severity 的值取决于不同项目/团队对其的定义.这里根据我个人的理解给出一些定义: Highest - 最高,通常当一

一听到初级Bug这个名字,很多开发工程师都会觉得很头痛,还有那个“初级Bug率”,让人随时受不了. 初级Bug这个概念,在多数缺陷跟踪工具中,是不存在的,可以说是淘宝研发部的特色.初级Bug对应Bug的一个属性:“Bug深度”,这个属性有三个选项:1很容易发现.2正常发现.3很难发现,其中“很容易发现”的Bug就是初级Bug.深度代表了发现Bug需要的成本和技术含量,初级Bug就是那些非常明显,通过简单的操作就能发现的Bug. 从初级Bug这个概念被提出,到现在大约有2年时间.最初的时候,在一次

尝试修改Mantis提交bug时“严重性”字段的内容,将原来的内容修改为A,B,C...等级: 在mantis/config_defaults_inc.php文件中查找$g_severity_enum_string字段,将其内容修改为:$g_severity_enum_string    = '10:A,20:B,30:C,40:D,50:E'; 在mantis/lang/strings_chinese_simplified.txt文件中查找$s_severity_enum_string字段,同

在软件工程理论中,BUG严重级别(severity)是用于指示软件质量问题导致的负面影响的程度.但在大部分实际的软件开发组织中,对BUG严重级别(severity)的定义和使用常常充斥着大量的争议和分歧.甚至有些组织即使有专门的BUG严重级别定义文档,但是由于其描述的宽泛和模糊性,使得争议和分歧并没有得到有效的减轻.本文将尝试探讨工程实践中的一些具体问题,并提出笔者的一些观点. BUG严重级别定义对于软件开发组织来讲,是一个非常重要的事情.因为它影响了如下几个方面: 影响修复某个BUG的必要性和

2021软工-调研作业-Notion 项目 内容 这个作业属于哪个课程 2021春季计算机学院软件工程(罗杰 任健) 这个作业的要求在哪里 案例分析作业要求 我在这个课程的目标是 学习软件开发的工业化流程,锻炼团队合作能力 这个作业在哪个具体方面帮助我实现目标 通过对现有软件的调研,了解软件工程在产品层面的作用 调研评测 调研背景 本次对 Notion 的调研基于 Notion 的 Windows 客户端,版本号 2.0.15:本机 Windows 版本为 Windows10 家庭版,版本号 2

2021S软件工程--案例分析作业 18231169 黄思为 项目 内容 这个作业属于哪个课程 2021春季软件工程(罗杰 任建) 这个作业的要求在哪里 案例分析作业 我在这个课程的目标是 了解并熟悉软件开发的具体流程,与团队共同开发一款实用的软件.在实践中增强自己的工程能力. 这个作业在哪个具体方面帮助我实现目标 通过实际体验已有产品,分析它们的优劣,从中获取软件开发的经验,用于自己接下来项目的开发. 1 选题 ​ 本次作业,我选择了CSDN APP.牛客APP.微信公众号三个产品体验并进行横

======================== 严重性定义缺陷: o 最先进的–造成执行中断(应用程序崩溃),该功能未预期实现,测试等工作无法进行. o 急-事件是非常重要的,须要立即给予关注. o 高级-事件是重要的,而且应该在紧急的事件处理之后尽快得到解决. o 中级-事件是重要的,可是因为解决这个问题须要花费一定的时间,所以能够用较长的时间解决. o 低级-事件不重要,能够在时间和资源同意的情况下再解决. o 建议性缺陷. 更为具体的划分例如以下: A类--严重错误,包含: o 因为程序

在测试过程中,不免会遇到开发人员因为一些原因不想修改个别bug的情况.那一般遇到这种问题时,我们该如何去推进开发修改bug呢? 我们先来分析下到底会有哪些原因会导致开发不修改bug 1. 开发与测试对bug的定义理解不一致产生的问题,例如暴力操作.非常规操作出现的问题.问题路径深.服务器返回的数据不规范.竞品同样有的问题.个别机型问题等情况,开发可能会不愿意修改. 2. 工作流程方面的原因,例如开发有更高优先级的任务没有时间修改.上线时间紧急,来不及修改.开发不关注名下的bug.开发认为目前的实

1. Bugger 2016 介绍 Bugger 2016 is the version of Bugger adding support fot Team Foundation Server bug databases, GitHub bug databases, in addition to the existing Product Studio support. Bugger 2016 tracks Team Fundation Server, GitHub and product Stu

又属于一篇普及文,希望自己在被各种技术吸引的同时,能时常来整理和总结软件测试最基本的知识. 从刚工作时接触的第一个缺陷管理工具禅道,到redmine.JIRA.bugzilla ,再到现在的QC,当然还有其它种的开源的或商业的缺陷管理工具,它们的本质是一样的,就是来管理缺陷的生命周期. 其实,你理解任意的一款工具,其它的工具也一定能无师自通.这不谈某款工具,单把它本质的一些东西抽离出来与大家分享. Bug的属性 Bug重现环境 这个应该是我们重现bug的一个前提,如果没有这个前提,我们可能会无法

昨天南京到客户服务数据库的优化调整,其中新上线,经过审查alert.log当日志现在是在过去一段时间内取得,每隔几个小时的时间滞后,班会报似的内容: Thu Aug 21 09:01:26 2014 WARNING: Heavy swapping observed on system in last 5 mins. pct of memory swapped in [8.42%] pct of memory swapped out [2.16%]. Please make sure there

人在江湖飘,哪能不挨刀. 我挨了重重一bug.严格来讲这可能是我职业生涯以来的首个悲惨经历,因为凭我的知识储备和经验,基本上任何可重现的bug都是可解的.然而这个bug却困扰了我三个月之久,它具有以下生理特征: 后台日志能统计到异常,偶发.低频 报异常的用户设备不具有规律性,什么手机都有 我们自己无法复现,任何设备.任何环境都没复现 打电话回访报异常的用户,确实存在问题 客服未接到用户主动反馈这个异常 此bug并不是js报错,而是一个业务逻辑的错误.表现是,用户提交的数据莫名缺失.场景是以下这个

一. Bug的严重等级定义: 1. Blocker 即系统无法执行.崩溃或严重资源不足.应用模块无法启动或异常退出.无法测试.造成系统不稳定. 严重花屏 内存泄漏 用户数据丢失或破坏 系统崩溃/死机/冻结 模块无法启动或异常退出 严重的数值计算错误 功能设计与需求严重不符 其它导致无法测试的错误, 如服务器500错误 2.Critical 即影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性. 功能未实现 功能错误 系统刷新错误 数据通讯错误 轻微的数值计算错误 影响功能及界面的错

译者按: 等待用户反馈BUG,一切都晚了!实时监控线上应用才是王道. 原文: Why relying on your users to report errors is the dumbest thing you’ll ever do 译者: Fundebug 为了保证可读性,本文采用意译而非直译.另外,本文版权归原作者所有,翻译仅用于学习. 我们热爱coding. 当我们coding的时候,就如同从零建造一栋大楼.新的特性.新的功能.绝佳的设计都在每一次更新后被用户所使用,期待他们的喜爱和赞美

BUG提交规范 1.标题 2.步骤描述 ①.步骤使用序号编排 ②.在特定情况下发生的问题,还需提供准确的前提条件 ③.精准的描述bug产生的路径后,再描述现象 如: >打开客户端进行首页->点击“我的”页面->点击用户头像进入个人资料页 >个人资料页点击头像选择拍照->拍照后点击保存头像 >从个人资料页返回 “我的”页面,查看头像是否更新④.若步骤并不能必现错误,需要说明出现错误的概率(需要多次测试的基础上,若必现则填写100%,若偶现,则执行多次后统计概率填写) 3.

写在前面的话 <Docker+SpringBoot+Mybatis+thymeleaf的Java博客系统开源啦> <Java开源博客My-Blog之docker容器组件化修改> My Blog项目已经开源了两个多月,也收获了不少star,在这里谢谢各位朋友的建议及帮助.由于个人原因,这个开源项目最初的定位其实是一个docker技术与springboot框架整合的Java博客系统实战项目,而且是一个容器技术的练手项目,技术的偏重也更多的在容器技术及容器编排上. 虽然上个版本做了一些改

用户往往对产品中各种各样的bug抱怨不已,而测试人员往往认为自己的职责就是揪出这些所有的bug并把它们全都修复.然而,这是一个误区.微软卓越测试工程总监Alan Page近日撰文,再次解释了有哪些bug是不会被修复的. AD:WOT2014:用户标签系统与用户数据化运营培训专场 本文来自微软中国官方博客,原文标题为<为什么Bugs没有被修复?>,作者Alan Page是微软卓越测试工程总监,译者为卢玥俪.陆梦嫣和汪宏. 近来我遇到越来越多的人对我们会发布还有bug的产品大为惊讶.而让我大吃一惊

在测试过程中,不免会遇到开发人员因为一些原因不想修改个别bug的情况.那一般遇到这种问题时,我们该如何去推进开发修改bug呢? 我们先来分析下到底会有哪些原因会导致开发不修改bug 1. 开发与测试对bug的定义理解不一致产生的问题,例如暴力操作.非常规操作出现的问题.问题路径深.服务器返回的数据不规范.竞品同样有的问题.个别机型问题等情况,开发可能会不愿意修改. 2. 工作流程方面的原因,例如开发有更高优先级的任务没有时间修改.上线时间紧急,来不及修改.开发不关注名下的bug.开发认为目前的实

关于BUG的沟通 一个人要去做一件事情,一般来说是按照自己的意愿去做的,如果不是自己想做而是被要求这么做的话,心里一定会留下点不愉快,特别是那种有自信有自己主见的人,比如说开发人员,当测试人员发现一个BUG,然后告知开发人员后,开发人员之所以会去修改BUG,是因为他自己认为的确需要修改,而不是因为你提到要改他才改的,所以当他认为不需要修改的时候,肯定是有自己的想法和理由,不妨理解下他们,合理的就可以接受,不合理的话,也不要强制的让他去修改,试着解释给他听,让他心甘情愿的去修改,这才不会让他心里产

摘 要:本文简要分析了无法重现的Bug的可能产生原因,包括环境不一致.缺少最准确的描述和浏览器的不当设置.针对这些原因,本文给出了相应的对策.通过这些措施,可以重现许多以前认为不可重现的Bug.        关键词:重现:Bug:环境 在测试人员提交bug后,最不希望看到的结果是它们被标记为INVALID,尽管你坚信这一定是Bug.开发人员查看了bug的Description后,最不希望的结果是你无法重现它们,尽管他使用了所有可能的方法去重现它.一旦出现这样的情况,测试人员会很伤心,开发人员也