• 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

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

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 功能上: 功能上:软件测试只要基本上的功能不出现问题,不影响交互就没太大的问题;游戏测试则不同出现一些及其细微的功能缺陷都会导致游戏的胜负结果。性能上 :性能上:软件测试讲究3-5-10的响应速度,3秒为良好优秀,5秒为一般,10秒为极差;但游戏在性能提供上讲究就会比较严格,一些细微的卡顿都会让游戏整体体验感大打折扣;安全上 :安全上:软件测试与游戏测试都会讲究到其的安全性上,软件测试讲究保护账号的安全性防止他人读取与使用;但是游戏测试不单单讲究账号更讲究一些道具与一些外挂的出现;兼容上: 兼容上:软件测试对比游戏测试上游戏测试的兼容性要求更高,游戏测试不单单要求设备的数量...
            0 0 1305
            分享
          • 在压力测试中,经常需要生成随机值来模拟用户行为。JMeter 提供了多种方式来生成随机值,本文来具体介绍一下。随机数函数JMeter 提供了多个用于生成随机数的函数,其中最常用的是__Random函数。该函数可以生成一个指定范围内的随机整数或浮点数。语法如下:${__Random(min,max)}其中,min 和 max 是生成随机数的范围,可以是整数或浮点数。例如,${__Random(1,100)} 会生成一个 1 到 100 之间的随机整数。以下是随机手机号最后 3 位数字的例子:查看传过去的数据:也可以用 BeanShell 来实现。添加前置处理器: BeanShell PrePro...
            0 0 3406
            分享
          • 常见状态码一、2xx 成功200 OK 请求成功,且返回了内容204 No Content 请求成功处理,但不返回内容二、3xx 重定向301 Moved Permanently 请求永久重定向302 Moved Temporarily 请求临时重定向304 Not Modified 文件未修改,可以直接使用缓存的文件三、4xx 请求错误400 Bad Request 客户端请求有语法错误,不能被服务器所理解401 Unauthorized 请求未经授权,认证未通过403 Forbidden 服务器收到请求,但是拒绝服务,通常会在响应正文中给出不提供服务的原因。通常跟权限有关404 Not F...
            0 0 683
            分享
          •        是不是憧憬过黑客,说真的,刚工作那几年有过,现在也只是佩服下人家做的具体事情,像ios越狱、破解某专业软件、高水平的0day等,羡慕已经谈不上了,因为有了一点工作经验,知道自己与黑客大牛之间的技术差距,看过一个黑客入门的技能树,已经心有余而力不足了,而且现实生活里所了解的黑客技术和电影中戏剧化手法呈现的黑客手段,往往是天差地别,想象中的黑客,像弹钢琴一样敲击着键盘,屏幕上满是飞速刷屏的命令行界面,进度条一满,机密数据下载完成,接管某高防御系统的管理权限,或是控制了几十辆汽车横冲直撞,我不知道在现实中是不是真有这样的情景,就算有那也是台上1分...
            3 6 4389
            分享
          •       最近因工作需要,开发了一个回归测试的小工具。可以根据配置读取不同交易报文并进行变量替换,然后自动发起交易并检查结果。自我感觉挺好用的,与大家分享一下设计思路。(代码要保密,就不上传了。有需要可以根据设计思路自己开发。      设计背景:      目前系统交易越来越多,需求改动也比较频繁。为防止代码改动影响旧需求,每次修改代码后都需要把相关交易回归测试一次。      目前此项回归测试工作主要靠程序员手工完成,存在以下问题:回归测试...
            0 0 2780
            分享
      • 51testing软件测试圈微信