前言

开发人员与测试人员齐心协力，相爱相杀， 荣辱与共，方能打造出优秀的产品。

若是bug描述不知所云，bug修复仓促随意，bug管理如同儿戏，则金玉其外已是造化，败絮其中当属必然。

bug描述

好的描述能降低沟通成本，让人审题时如沐春风，解题时酣畅淋漓。bug描述的主体，应该包含如下部分：

标题：指明所测模块，简明扼要地描述问题现象

[前提条件] 说明完成测试的预设条件是什么

[重现步骤] 句子简练，步骤清晰，表达无歧义

[实际结果] 按照步骤执行下来，实际结果是什么；不要有主观色彩

[期望结果] 正确的结果应该是什么；应该有说服力，不要唯经验论

Tips:

其他如所测版本，附件信息，bug优先级等，不一而足，也是bug描述的一部分。

bug修复

望闻问切，才能直达病灶。解决问题是手段，预防问题再现才是目的。bug修复应该包含如下部分：

[根本原因] 造成这个bug的实际原因是什么；不能讳疾忌医

[解决方案] 通过何种方式修复；不要语焉不详，不要选择性发言误导测试人员

[更改文件] 此次修改更改了哪些文件，以便代码后期维护，历史追溯

[代码审查] 向检查者描述问题和解决方案，这种二次检查机制，不为事后追责，只为找出思维盲点，排除潜在风险

[影响范围] 描述此次修改影响的功能范围，便于测试人员验证时覆盖到更多的测试点

Tips:

根本原因、解决方案、影响范围，是bug修复的3个核心要素。

明晰这3点，才能切中肯綮，收放有度，提高代码质量，避免regression。

bug的生命周期

一个bug的典型生命周期有这样几种样态：

创建-> 调查 -> 确认 -> 排期 -> 修复 -> 验证 -> 关闭

创建-> 调查 -> Not a Bug

重开，再次轮回...

bug管理系统

常见的bug管理系统有：禅道、JIRA、Bugzilla等。

也可按需自行研发一套管理系统，系统无好坏之分，适合自己的才是最好的。

结语

好的产品应该是能解决用户需求的，好的代码应该是可维护的。

当一个产品走过三五年、十来年，乃至更长，当码农换了一茬又一茬，在软件产品的生命中，过往的bug看似雪泥鸿爪，微不足道。

可当你小心翼翼的维护代码，当你搜寻bug管理系统，查阅代码版本库时，却发现前人的思路清晰可辨，那些bug还残留着当初的温度。

作者：苏州-微尘

原文链接：https://blog.csdn.net/wangnan537/article/details/77785449