从BUG库看一个测试开发团队的自我修养

程序员不喜欢BUG，每当有人说这里有个bug的时候，就不自觉的启动了自我防御机制，开始在想是不是这家伙不会用什么的，其实恰恰是程序员创造了bug；如果每个程序员都能写出完美的代码，测试人员就该失业了，事实是测试人员越来越重要。人无完人，首先承认自己的不完美，接受bug的存在；程序不可避免的会存在bug，但这不妨碍程序员不断的最求完美，努力写出高质量代码。

BUG不可避免，因此记录BUG的系统就不可或缺。我经常说，看一个团队够不够专业只要看他们的BUG系统就可以了。如果一个开发了近半年的项目还没有一个BUG库，或者BUG系统里记录的内容乱糟糟的，你又如何能认为这样的团队能开发出高质量的产品。

一个BUG的生命周期

关心BUG的就有测试，开发，项目经理，他们在一个BUG的一生中扮演着自己的角色。提出BUG（提出者）－》解决BUG（开发者）－》证实BUG是否解决（测试）－》已解决（测试人员）－》已发布（项目经理，SCM）。

提出BUG的可以是任何人，产品开发内部人员以及外部人员，比方：内部人员有测试，项目经理，开发人员，测试团队；外部人员有老板，客户，用户。事实说明，外部人员无法专业的描述一个bug，建议专门建立一个面向外部的bug录入系统，可以由测试人员，或技术支持来管理整个系统里的BUG。如果确实是BUG，再由测试人员和技术支持人员录入到内部BUG系统中。

项目经理会进一步指派谁解决某个BUG，以及解决的优先级。项目经理判断的依据有：1，根据bug所属的模块，指定最属性这一块的开发者；2，根据大家手里的任务的多少，指定一个开发者；3，根据一个bug的影响程度，严重的bug需要优先解决，测试，立即上线。

接着就是开发人员进行bug的修复，开发人员首先要做的是，仔细阅读bug的描述（具体格式如下），并在开发环境中重新bug，有的时候可能需要专门配置对应的开发环境；重现问题后，分析问题，解决问题，并在开发环境中验证问题是否的确解决了。然后测试人员从某个开发分支获取相应的补丁，有的时候也可能直接在开发搭建的环境中，进行bug修复验证；首先要做的是，仔细阅读开发人员解决bug的描述（如下），然后开始测试验证，注意的是，如果代码影响的范围很多，需要做相关模块的回归测试，防止引入新的问题。测试没有问题，那么就可以标示为“已解决”。

项目经理或SCM从开发分支上获取已验证的代码合并到主干，然后发布新的版本，同时将bug状态标示为“close”。

测试人员必须完整的描述一个BUG

看一下BUG里的描述，就能看出开发团队的素养：专业程度，是否足够负责任：

• 
  BUG标题：简洁且突出重点，好比给一篇文章起个好名字
• 
  所属的功能模块：
• 
  复现的前提条件：
• 
  复现的步骤：
• 
  提供问题的截图以及日志：
  

• 
  问题发生的前提条件：
• 
  严重程度：从发生的频率，对系统的影响程度，对用户的影响程度几个方面进行评估。
• 
  问题原因：
• 
  解决方案：
• 
  代码影响到的模块：
• 
  如何确认问题是否已解决：从日志里确认？开发环境测试？
• 
  总结：系统中其他地方是否存在类似问题？引入该问题的原因？下次如何避免类似问题？