【测试基础】晕晕乎乎的bug

作为一名软件测试人员,找bug就是我们工作职责所在。

狭义来讲,bug是软件程序的漏洞或缺陷

广义来讲,它是测试工程师或用户所发现和提出的软件可改进的细节或需求文档存在差异的功能实现

不论咋讲,测试人员的工作就是找bug,提给开发,然后让开发修复。

首先,bug类型有:

       代码功能类

       界面优化类

       产品设计缺陷

代码功能类,它是最常见的bug,也是优先级最高的;

界面优化类,在ui测试范畴,优先级相对来说偏低一点;

产品设计缺陷类,对于需求不合理的地方,我们能给出建议,此类问题优先级偏低。

其次,bug也是有一定等级的,开发会依据我们提出bug等级去修复。有:

        致命错误

        严重错误

        一般错误

        改进错误

致命错误通常见于:由常规操作引起的崩溃、闪退、死机循环;由数据泄漏造成的安全问题;进行不下去的测试,就是连冒烟通过不了的

严重错误通常见于:错误涉及面比较广,影响其他重要功能正常使用;非常规操作导致的崩溃、闪退等;界面让人无法接受的;密码明文显示;偶现致命bug

在大田看来,上述两类错误边界可以不用那么明显,只要出现就是需要解决的,用户是没有耐心的。

一般错误常见于:次要功能不正常实现、操作界面功能和语义提示不一致、查询结果和数据不匹配、一些输入未放在前端限制、删除不给出友好提示、

注意:一般错误可以理解为不影响产品运行,不会造成大故障。

改进意见常见于:提高产品质量建议,界面不规范,提示窗口不使用行业用语等

以上说了这些,不知道对你是否有所启发😄

再次,再看下bug生命周期

是指被发现到被关闭的过程

而我们应如何管理bug呢?

当我们发现bug后,去禅道提bug,指派给开发,由开发确认bug,解决bug,开发将bug指派给测试,测试去验证并进行回归测试,若没问题则关闭bug,若还有问题继续指派给开发。

在管理bug中间我们应如何跟踪bug 呢?我通常的做法是,根据bug状态跟踪。

【发现bug】要先确认,防止环境问题、操作问题等一些外因引起的bug。会被开发认为是无效Bug。

【新建(new)】提bug的人或测试老大指派(开发或开发老大),跟进bug,推进开发修复Bug

【重复bug(duplicated)】要求开发备注一下重复bug的 id,方便测试人员确认是不是一个问题,如果是重复的,要加备注,关闭。如果不是一个bug,重新激活(reopened),重新指派开发。

【不是缺陷(invalid)】(1)By

design设计如此(2)对需求理解不一致导致操作失误--要讨论一下:①拿到需求,再次需求分析,从用户角度开发,找到证据,罗列证据,尝试说服开发。②无果,找产品或项目经理确认,若是bug,开发修复,不是bug,别纠结,但也留好证据(邮件截图,备注到bug里)。

【无法复现(un-reproduced)】(1)开发无法复现:确认测试环境可否再复现,若可以复现,帮助开发复现,仍无法复现,让他到测试环境调试定位(2)测试和开发都无法复现,要尝试跟踪3-5个版本,每个版本复现超过10次,仍然无法复现,在Bug中加备注(我复现的次数、跟踪版本数),关闭该bug,记录到自己的笔记中。

【开发确认Bug后,不予解决(wontfix)】原因bug级别低(建议性Bug、ui的bug),(1)首先要站在用户角度,说服开发,无果的话(2)找产品确认(3)加备注留证据,最后关闭bug

【延期(delayed)】(1)建议性的bug,作为下一个版本的需求(2)上线之前,修复影响较大(性价比低),此时,要分析①对用户的影响,影响用户体验,就要修复②bug严重级别高,找项目经理、产品拍板确认。若不修复,备注(留证据)。---延期bug不关闭--挂起状态

【已修复(resolved-fixed)】开发修复后,指派给测试,测试验证(bug步骤、结果重新操作一遍),验证后(1)已验证(verified)加备注--项目结束(closed)(2)仍然存在,reopened重新激活,指派开发,开发确认bug,解决Bug。加备注

注意:每次操作记得加备注方便跟踪阅读bug

最后,我们应如何提bug呢?

提bug工具有:禅道(zentao)、bugzilla、jira、bugfree、Readmine、easybug、Mantis、QC(QualityCenter)、TD

以禅道为例,讲下大田每次提bug都会注意的7点有:

【bug标题】标题要清晰简洁, 写明bug描述;如果没有选择功能模块,最好在标题中标注功能模块。让查有bug的人员清楚知道你所表达的意思。bug的功能模块+ bug的操作+ bug的结果。

【重现步骤】详细写下发现bug的测试步骤-结果-预期。能指导开发重现这个bug。附上测试数据。实际结果用截图直观。

【实际结果】出现bug的结果,粘贴bug截图、日志截图--直观,证据(有图有真相)。

【预期结果】记得写清楚预期----参照测试用例的预期结果。

【bug类型和严重程度】便于后续测试结果分析, bug的统计。

【bug测试环境】什么系统,哪个版本等。兼容性问题、难以重现问题。

【附件】日志文件, 文件测试数据。图片、崩溃日志文件等。

开工第一天,这是大田公司发的红包,祝大家在2022年升职加薪,实现自己的价值,加油!

好啦,今天的分享就到这里啦,如果还有其他问题,请直接留言,大田希望和大家共同成长~~~

Tester大田 

2022.02.08 ,日更的  3/365 天

感谢支持,多多交流

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,490评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,581评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,830评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,957评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,974评论 6 393
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,754评论 1 307
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,464评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,357评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,847评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,995评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,137评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,819评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,482评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,023评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,149评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,409评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,086评论 2 355

推荐阅读更多精彩内容