BUG管理.docVIP

保密级别 内部资料 版 本 号 V1.0 CMMI Bug创建管理指南 文档种类：CMMI 撰写时间：2011年 6月23 日 撰写部门：EPG组 发行范围：全公司 变更记录 版本号 修改点说明 变更人 变更日期 审批人 审批日期 V0.1 全部新增 黄小胜、王卉 2011.6.23 何江 V0.2 规范格式定义 黄小胜 2011.9.28 V1.0 公司研发体系全范围发行 EPG组 注：对该文件内容增加、删除或修改均需填写此修订记录，详细记载变更信息，以保证其可追溯性。 目 录 1. BUG管理 4 1.1. BUG说法来源 4 1.2. Bug创建标准 4 1.3. Bug跟踪管理原则 10 BUG管理 BUG BUG—常称为“缺陷”，简单来说就是程序错误，是指在软件运行中因为程序本身有错误而造成的功能不正常、体验不佳、死机、数据丢失、非正常中断等现象。 BUG说法来源 故事发生在1945年9月9日，下午3点.一个炎热的夏天，房间没有空调，所有的窗户都敞开散热.Grace Hopper中尉正领着她的小组构造一个称为MARK II的计算机.这还不是一个完全的电子计算机，它使用了大量的继电器.Grace Hopper的小组日以继日的工作，机房是一间第一次世界大战时建的老房子.突然，MARK II 死机了.技术人员试了很多办法，最后定位到板子F第70号继电器出错.Grace Hopper 观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死.她小心的用镊子把它夹出，用事件记录本中，并注明第一个发现虫子的实例，然后计算机又恢复了正常从此以后，人们将计算机错误戏称为虫子(BUG)或臭虫，而把寻找错误的工作称为找臭虫(DuBug).Grace Hopper的事件记录器，连同这个飞蛾现在已经被陈列在美国历史博物馆中Bug创建标准 一、BUG描述Condense-精简，清晰而简短Accurate-准确，确定是BugNeutralize-用中性的语言描述事实，不带偏见，不用幽默或者情绪化的语言Precise-精确Isolate-定位，尽量缩小这个问题的范围Generalize-还有没有其他的某些地方存在这样的问题Re-Create-如何引发和重现这个Bug?(环境，步骤，前提条件)Impact-影响，这个缺陷对客户的影响以及对测试的影响DeBug-怎么做才可以让开发更容易来修改这个Bug?(跟踪，截图，日志，直接访问等等)Evidence-证据精简，清晰而简短首先，去掉不必要的词其次，不要添加无关的信息。 包含相应的信息是最重要的，但是确保这些信息都是有用的。对于那些没有描述清楚如何重现或者难以理解的问题，都应该提供更多的信息。但也要避免写过多的不必要的信息。 图形用户接口准确，确定是Bug确信是一个Bug，避免因为其他原因，导致错误的Bug，需要考虑： 是否会因为安装的某个原因导致这个问题?例如，是否安装了正确的版本而且各种先决条件也已经满足?是否登陆，安全设定，命令或者操作的顺序有错误? 是否存在清除不干净，或者结果不完整，或者因为上次测试的某些更改导致? 是否是网络或者环境的问题? 是否理解了期望的结果? 中性的语言 客观的描述Bug，不要使用幽默的或者其他带有感情色彩的语句。在提交Bug之前，仔细阅读Bug的描述，删除或者修改可能让人产生歧义的句子。 精确当Bug的描述很长时，例如：“我按了回车键，然后现象A出现，接着按了后退键，现象B出现，接着输入命令‘XYZ’，现象C出现”，看到这样的说明，很难明白到底想说明什么问题，三个现象中哪一个是错误的。清晰准确并且客观的描述Bug，而不是简单说明发生了什么。Printing Ipds From……” （说明：这个描很难让人知道到底是什么问题，是打印端口延时还是打印机没有准备好或者是打印机的显示面板的信息不正确） 恰当描述：当打印机正在打印时，取消打印会让打印机挂起——问题发生在取消打印时打印端口延时，打印机的就绪灯始终不亮，此时打印机显示面板上显示“Printing Ipds From……” （说明：在描述之前，用简短的语言概述时如何发生的这个问题） 定位，尽量缩小这个问题的范围定位发现的问题。在试图隔离一个问题的时候，需要考虑下面的几点： 尝试找到最短，最简单的步骤来重现这个问题。 查看是否是外部的什么特殊的原因引起的这个问题?例如，系统挂起或延时，会不会是因为网络的问题? 对于一个存在多种输