一 现状及场景
1、缺失bug根因分析环节
工作10年，虽然不是一线城市，也经历过几家公司，规模大的、规模小的都有，针对于测试行业很少有Bug根因环节，主流程基本上都是测试提交bug-开发修改-测试验证-发送报告，测试环节结束。
往往有下面几个原因：
·时间压力： 在项目开发周期紧张的情况下，测试团队可能会因时间压力而忽略深入的BUG根源分析。解决方案：合理规划测试时间，将足够的时间用于分析和解决问题。
· 技能和经验不足： 一些测试人员可能缺乏足够的技能和经验来进行深入的BUG根源分析。解决方案：提供培训和指导，提升团队成员的技能水平。
· 沟通不畅： 缺乏与开发团队和其他相关团队的有效沟通，可能导致问题的根本原因难以获得。解决方案：加强跨团队沟通，确保问题描述准确传达。
· 工具和资源不足： 没有合适的工具和资源来支持深入的BUG根源分析。解决方案：投入适当的工具和资源，提升分析效率。
· 重视程度不足： 一些团队可能在BUG根源分析环节没有足够的重视，将其视为次要环节。解决方案：强调BUG根源分析的重要性，确保每个问题都得到适当的分析。
· 缺乏流程和规范： 缺乏明确的BUG根源分析流程和规范，可能导致分析过程不一致或混乱。解决方案：建立明确的分析流程和规范，确保每个团队成员都按照标准进行分析。
· 缺乏反馈机制： 没有及时的反馈机制，测试人员可能难以得知他们提出的问题的分析结果和解决方案。解决方案：建立反馈机制，确保分析结果被及时传达给相关人员。
· 忽视根本原因： 有时测试团队可能只关注问题的表面症状，而忽视了问题的根本原因。解决方案：鼓励团队进行深入分析，追溯问题的根本原因。
2、适用场景
本篇内容针对系统上线后对所有相关系统进行的数据流业务测试发现的bug
针对这些线上bug进行分析汇总，大概50个左右，找到一些底层的原因及规律。
二 Bug 分析四步走
BUG根因分析的核心思路是要从中发现测试策略问题并及时改正，避免下次再犯同样的问题
下面是我如何针对这50个bug进行分析的过程
记录-》缺陷原因分析-》角色归因-》提升方案
1、记录环节
记录环节也就是测试过程中发现的bug进行记录整理到buglist中，以excel 表格形式呈现，如下图：
2、标记缺陷原因分析
增加一列：缺陷原因分析
针对每一个bug，分析根本原因，有一些自己测试过程中就已经了解了可以写上，不了解的或者记不起的内容可以统一咨询相关开发人员，他们是最了解问题的第一人。
3、针对角色归因
查了一些分析方法，其中有鱼骨图法、Whys（5个为什么） 这两个分析方法还可，但感觉都不太适用我们公司，初步阶段不需要弄的那么复杂，所以采用最简单的方式 主要责任人就两类：开发和测试，所以以此为基准展开如下几大类
开发人员：
·缺少自测
· 自测不足
· 系统间联调不充分
测试人员：
· 漏测
· 测试人员业务理解不足
具体包括：
1）公共方法名称重复，忘记删除
2）生产文件不是最新
3）通过接口调，未走实际流程
4）代码逻辑错误
5）用例不详细
6）开发、测试业务理解不透
4、可提升方案
针对测试方面想到几点可提升点如下：
用例详细：
1）增加工作台列表校验；2）测试结果 现象需描述清晰；3）功能与功能之间页面名称需要统一。
测试流程
1）原理--维护功能梳理表格
从需求阶段到测试整个过程中一直维护这个表格，对所有疑难点梳理清晰
2）跑主流程使用全新的基础数据环境
这次发现的一部分问题之前没发现的原因也是我们实际测试过程中，环境都在已搭建基础上开始，或者经过很多次测试，所以像这种联调测试在测试环境尽量保证数据的
3）增加源数据修改流程
有几个重要问题都是修改源文件导致其他功能不好用
所以在写用例时需要考虑修改数据后，接下来流程的正确性
4）redmine 添加bug原因（必填项）
这个主要目的应用于平时项目中，每一个bug流程开发修改完成后点击已修改前，添加bug根因，目的其一可以对bug产生原因有跟踪，方便测试后续统计，其二开发对自己本身技能提升也有帮助。
三 总结
在写文档前，我也犹豫了一下要不要具体分析？万一分析完成后全是测试漏测怎么办，大多数都是测试原因呢？分析的不专业怎么办？事开头难，奔着提升的心态，发现一个问题解决一个问题，我们才能够成长，只要迈出这一步，重复的进行慢慢的就有了经验。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
