• 0
  • 0
分享

  一 现状及场景

  1、缺失bug根因分析环节

  工作10年,虽然不是一线城市,也经历过几家公司,规模大的、规模小的都有,针对于测试行业很少有Bug根因环节,主流程基本上都是测试提交bug-开发修改-测试验证-发送报告,测试环节结束。

  往往有下面几个原因:

  · 时间压力: 在项目开发周期紧张的情况下,测试团队可能会因时间压力而忽略深入的BUG根源分析。解决方案:合理规划测试时间,将足够的时间用于分析和解决问题。

  · 技能和经验不足: 一些测试人员可能缺乏足够的技能和经验来进行深入的BUG根源分析。解决方案:提供培训和指导,提升团队成员的技能水平。

  · 沟通不畅: 缺乏与开发团队和其他相关团队的有效沟通,可能导致问题的根本原因难以获得。解决方案:加强跨团队沟通,确保问题描述准确传达。

  · 工具和资源不足: 没有合适的工具和资源来支持深入的BUG根源分析。解决方案:投入适当的工具和资源,提升分析效率。

  · 重视程度不足: 一些团队可能在BUG根源分析环节没有足够的重视,将其视为次要环节。解决方案:强调BUG根源分析的重要性,确保每个问题都得到适当的分析。

  · 缺乏流程和规范: 缺乏明确的BUG根源分析流程和规范,可能导致分析过程不一致或混乱。解决方案:建立明确的分析流程和规范,确保每个团队成员都按照标准进行分析。

  · 缺乏反馈机制: 没有及时的反馈机制,测试人员可能难以得知他们提出的问题的分析结果和解决方案。解决方案:建立反馈机制,确保分析结果被及时传达给相关人员。

  · 忽视根本原因: 有时测试团队可能只关注问题的表面症状,而忽视了问题的根本原因。解决方案:鼓励团队进行深入分析,追溯问题的根本原因。

  2、适用场景

  本篇内容针对系统上线后对所有相关系统进行的数据流业务测试发现的bug

  针对这些线上bug进行分析汇总,大概50个左右,找到一些底层的原因及规律。

  二 Bug 分析四步走

  BUG根因分析的核心思路是要从中发现测试策略问题并及时改正,避免下次再犯同样的问题

  下面是我如何针对这50个bug进行分析的过程

  记录-》缺陷原因分析-》角色归因-》提升方案

  1、记录环节

  记录环节也就是测试过程中发现的bug进行记录整理到buglist中,以excel 表格形式呈现,如下图:

1-1.png

  2、标记缺陷原因分析

  增加一列:缺陷原因分析

  针对每一个bug,分析根本原因,有一些自己测试过程中就已经了解了可以写上,不了解的或者记不起的内容可以统一咨询相关开发人员,他们是最了解问题的第一人。

  3、针对角色归因

  查了一些分析方法,其中有鱼骨图法、Whys(5个为什么) 这两个分析方法还可,但感觉都不太适用我们公司,初步阶段不需要弄的那么复杂,所以采用最简单的方式  主要责任人就两类:开发和测试,所以以此为基准展开如下几大类

  开发人员:

  · 缺少自测

  · 自测不足

  · 系统间联调不充分

  测试人员:

  · 漏测

  · 测试人员业务理解不足

  具体包括:

  1)公共方法名称重复,忘记删除

  2)生产文件不是最新

  3)通过接口调,未走实际流程

  4)代码逻辑错误

  5)用例不详细

  6)开发、测试业务理解不透

1-2.png

  4、可提升方案

  针对测试方面想到几点可提升点如下:

  用例详细:

  1)增加工作台列表校验;2)测试结果 现象需描述清晰;3)功能与功能之间页面名称需要统一。

  测试流程

  1)原理--维护功能梳理表格   

  从需求阶段到测试整个过程中一直维护这个表格,对所有疑难点梳理清晰

  2)跑主流程使用全新的基础数据环境  

  这次发现的一部分问题之前没发现的原因也是我们实际测试过程中,环境都在已搭建基础上开始,或者经过很多次测试,所以像这种联调测试在测试环境尽量保证数据的

  3)增加源数据修改流程   

  有几个重要问题都是修改源文件导致其他功能不好用

  所以在写用例时需要考虑修改数据后,接下来流程的正确性

  4)redmine 添加bug原因(必填项)

  这个主要目的应用于平时项目中,每一个bug流程开发修改完成后点击已修改前,添加bug根因,目的其一可以对bug产生原因有跟踪,方便测试后续统计,其二开发对自己本身技能提升也有帮助。

  三  总结

  在写文档前,我也犹豫了一下要不要具体分析?万一分析完成后全是测试漏测怎么办,大多数都是测试原因呢?分析的不专业怎么办?事开头难,奔着提升的心态,发现一个问题解决一个问题,我们才能够成长,只要迈出这一步,重复的进行慢慢的就有了经验。


作者:M&T.    

来源:http://www.51testing.com/html/34/n-7798934.html

  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          •  时间都去哪里了敏捷迭代和团队协作,前后端分离的工作模式几乎是每个互联网公司的常规工作模式。前后端分离,各自开发的优点很多,其中一项是它只需要提供一个统一的API接口,即可被web,iOS,Android等多个客户端使用,效率大大提高。但生于敏捷,死于迭代,困于团队协作常常是这种软件研发模式的一大弊病。 随着项目不断推进、变更,项目越来越大,维护成本也越来越高。由于某些公司接口文档管理方式采用wiki及html,openapi形式,版本迭代较快,接口常常变更,成员间update和文档维护却常常跟不上。在API管理方面越到后期越存在着可观且隐形的“人力资源”浪费:文档老旧不可用,新人上...
            13 13 1594
            分享
          •   前言  jmeter 这个工具既可以做接口的功能测试,也可以做自动化测试,还可以做性能测试,其主要用途就是用于性能测试。但是,有些公司和个人,就想用 jmeter 来做接口自动化测试。  你有没有想过呢?  下面我就给大家讲讲,用 jmeter 如何做接口自动化测试。  jmeter 与接口自动化测试  如果要你用 jmeter 来做接口自动化测试,你是不是把几乎每一个测试用例,都是用一个取样器来实现?  相信很多人都是这么想的,也是这么干的。  但是,很遗憾,你这种,是初级入门做法。你能实现所有的测试用例都被执行,但是,你写脚本和维护脚本的时间,可能比你用手工执行所有的测试用例时间还要长...
            0 0 1143
            分享
          •   51Testing测试行业调查问卷得不得填一下吧。这套问卷能够对未来的行业发展趋势做出权威的分析,只要点击链接参与,还能获得实用软件测试资料。链接:http://vote.51testing.com/  最近发生了一起生产事故,究其根源,事故本身属于架构或者需求层面需要规避的问题,测试人员的责任其实是非常小的,但实际情况是:相关测试人员因此承担了很大的压力,成为质量问题的“背锅侠”。  实际上,测试人员一直处于“背锅侠”的处境,今天就来聊聊,测试人员究竟背了哪些锅?  测试背的第一层锅:产品不能如期交付的锅  我们知道,产品交付排期一般是固定的,很多时候,我们在这个基础上,进行开发测试排期...
            0 0 800
            分享
          •   Web方面的测试,就是我们通常所说的是对在浏览器运行的页面进行测试。也即是B/S结构的测试。  Web测试,其实是前人通过总结而来。具体指下面几个方面:web测试点  1、链接  指方面的URL地址;要点:  1) 检测是否正确;  2) 检测是否明文或者加密显示;  3) 修改URL的子路径,如输入不存在的URL地址,检测页面是否有404错误页面提示。  4) 检测URL地址是否能正常跳转等等。  2、界面  1) 检测UI排版是否正确;  2) 检测界面的按钮或者可操作的功能,是否显眼;重要的功能或者文字是否高亮显示。  3) 图片是否快速显示;  4) 数据是否快速加载显示等等  3...
            0 0 652
            分享
          • 一、前言在当前主流的前端后端分离模式开发下,拥有一个接口文档并且是好用的接口文档是很有必要的一个东西。PS:?以下观点是真实开发场景下碰到并且悟出来的痛点。1、在项目的开发过程中,有一个接口文档的存在能让前端后端工程师保持的数据信息概念是统一的。例如:”项目需求的接口字段,参数字段。所有只要请求的返回参数记录到文档中的情况后,前后端工程师编写代码的同时就能统一对照接口文档去编写各自的逻辑,那么在各个信息的命名都是统一的情况下,在各自的代码中就不会发生前端在一个需求功能的请求接口命名是与后端返回接口的命名信息不一致的情况。这样可以大大避免了导致排查问题的时候不能很快速的定位问题。2、好的接口文档...
            2 2 920
            分享
      • 51testing软件测试圈微信