bug的管理（bug的生命周期）

关于bug的管理，简单做个总结。bug的管理包括bug 的新建，编辑，删除等方面。

bug，俗称缺陷。还有其他比如说是新需求，改进，任务。现在我所在公司使用的是jira，于是我这里以jira来说明。其他的bug管理工具还有QC等，也有用excel管理。jira可以进行用户管理，用户组管理，主要管理缺陷，不能管理测试用例，当前我们的测试用例是用excel，属于用完即废的状态。

1，什么时候可以新建bug。

在开发提交代码交付测试后，马上会测试出一些问题，如果开发能立马着手修改，这些问题我们暂时不会记录到jira中，等当前需求的功能本完成或开发没有时间修改，则会记录到jira中。

在记录时要添加好优先级，优先级以紧急为最高级，其次重要，其次一般，默认选择一般，当bug为页面样式调整，不涉及功能情况下，我会选择“次要”，突然想到页面样式应该也是很重要的。

这里需要注意的一点是：尽可能的将发现的bug记录到jira中，先抛开开发的眼光。。（尤其是快上线的时候，开发会很急眼，盯着jira。）就我个人来说，我曾经因为开发的“威胁”，不敢去提bug，后来就发现有些bug记着记着就忘记了。。后面跟产品一次聊天，发现个解决办法：先把bug提进去，（系统的bug可以用永无止境来形容吗==呵呵哒），写好优先级，如果是新需求就标好问题类型。跟开发确定好哪些是马上要修改的，哪些可以放一放，下个版本修改。

嗯，现在简单说下开发，开发分几种：技术强的，成了老鸟，有时会跟测试抬杠，这很容易引起旁边的开发跟测试较劲；很好说话的，一般是刚入职一两年的；还有一类是不愿意沟通交流的，之前项目组遇到过。这里说的抬杠、较劲，是我自己的说法，大家自行翻译成自己理解的。。

2，bug 的编辑。

bug，在我们发现的时候一般来说是bug，但可能过了一段时间（可长可短）可能就不再是bug了，这时需要添加备注说明。还有随着测试的深入，会发现bug的引起原因，也需要添加备注，还会遇到的情况是，多个测试（甚至同一个测试）发现同一个bug，导致bug重复，这个时候的正确方法是，标注“与bugxx号重复”字样，并且备注说明。我之前曾经有主动将自己的bug（那个bug是我先记录的）编辑改成了新发现的别的bug。

jira里的bug链接方法如下图，找到才发现里面的内容很丰富。。如果翻译不合适，先多谢纠正（献花）

想说的一点是，在发现记录bug 后，记得提醒开发关注处理。与开发的沟通也一直是我比较关心的，后续再总结下（前面也有说过）。

3，bug的删除

一般情况下不删除，都是留作记录，回顾总结。

上面提到的是项目上线前的bug的管理。后面还有很重要的一步，就是对于版本发布后客户反馈过来的bug的收集整理。（明天要找他们收集下了。）

线上的反馈过来的分为几类：bug、操作不当、新需求、外部原因。

多总结，多思考，相信会越来越好。

---

---

下面是更全面的讲到bug的其他的状态。（20170727补充，参照《软件测试技术大全》P146）

bug的管理，即测试人员应跟踪一个bug的整个生命周期，从新建（new)到关闭（closed），通常一个典型的缺陷状态如图：

虚线是我后添加的

New：新建的Bug，未经评审需决定是否指派给开发人员进行修改。虚线就表示经沟通，不是bug，所以直接关闭。

Open：确认是bug后，并且认为需要进行修改，指派给相应的开发人员。

Fixed：开发人员修改后标识为修改字体，需测试人员近回归测试验证。

Delay：确认为暂时不需要修改后续需要修改的bug

Closed：修改的bug经测试人员进行回归测试通过验证，关闭bug。虚线：其他的状态的bug已经不需要修改，例如：需求有变动，已经不再是bug，直接关闭。

Reopen：经验证后发现bug未修改或未修改完，则重新打开，让开发人员重新修改

---在我们实际工作中，没有open状态，在New bug时，直接就指定给了相关的模块负责人/项目负责人。由模块负责人直接修改bug，或项目负责人（分给项目负责人是因为不确定要分给哪个开发）再分配给相关的开发人员。如果出现bug不需要修改的状态，直接由开发人员填写备注：不是bug，改为Fixed。

---我们实际工作中，Fixed不叫这个名，叫  resolved

所以，如图为基本流程，每个项目团队的实际做法可能会有偏差，结合自己的情况来使用。

Bug的跟踪以及状态变更应遵循一些基本原则：

1）测试人员对每一个缺陷的修改必须重新取一个包含更改后代码的新版本进行回归测试，确保相同的问题不再重现，才能关闭缺陷。----这点我要注意，之前有刚新建一个bug，开发发现后立即修改，然后让我测试，测试通过后，就直接关闭bug了。还是出新版本后回归测试保险。

2）对于拒绝修改和延迟的bug，需要经过包含测试人员和开发人员和用户方代表（或代表用户角度的产品）的评审。