Bug的编写及管理流程

一、Bug的起源
1945年，一只小飞蛾钻进了计算机电路里，导致系统无法工作，一位名叫格蕾丝.赫柏的人把飞蛾拍死在工作日志上，写道，就是这个Bug（虫子），害我们今天的工作无法完成——于是，Bug一词成了电脑系统程序的专业术语，形容那些系统中的缺陷或问题。

二、Bug的定义
Bug的定义：电脑程序里的错误，而现在更是将其延伸为漏洞，错误，可改进的细节、或与需求文档存在差异的功能实现等。

三、Bug的分类
1、功能缺陷（业务流程未实现）
2、代码错误（错误页404/500）
3、界面优化（UI问题，图文显示）
4、安装部署（安装失败，无法访问等）
5、性能问题（响应时间久，加载慢）
6、安全相关（密码：123456******）
7、其他划分（易用性类、兼容性类）
8、设计缺陷（需求问题）

四、Bug的严重程度
1、致命的-最高：系统崩溃(请求直接把服务器搞坏)、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失，重要的一级菜单功能不能使用等。
2、严重的-高：系统主要功能部分丧失、数据库保存，提交调用错误，功能设计与需求严重不符，自动退出，稳定性差数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。
3、一般的-中：功能菜单没有完全实现存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多)。
4、轻微的-低：兼容性，界面优化，不影响操作功能的执行，错别字，页面显示重叠，提示语丢失(此类问题在测试初期较多，优先程度较低)登录。
5、建议性-低

五、Bug的优先级
1、非常紧急
2、紧急
3、一般
4、不重要
（作用：开发修复Bug的先后顺序）

六、Bug的状态标准
1、待处理（提交-激活）：测试人员或用户发现新问题后提交的状态。
2、已确认：经测试人员及研发人员讨论后确认是BUG，提交的状态，由开发点击确认按钮。
3、已处理=已解决：经研发人员确认是BUG后修复的状态，修改还没有验证，由开发人员来设置。
4、已修改=已关闭---最终Bug状态：测试人员认为问题已经修改，通过验证，由测试人员设置。
5、仍存在=重新打开：测试人员认为BUC未修复成功，问题仍然存在，由测试人员设置。
6、不是Bug：研发人员确认不是BUG，或者建议与意见决定不采纳，由开发人员来设置。
7、暂不处理=挂起：当前版本不做修改，后续版本再考虑，或者一时不确定是解决不解决，需要过一天两来决定，这样的BU就需要一个挂起状态由研发人员或测试人员设置。

七、Bug生命周期状态流程管理
Bug状态（Status）：
指缺陷通过一个跟踪修复过程的进展情况。包括New、Open、Reopen、Fixed、Closed及Rejected（不是Bug）等。

八、Bug的基本要素
缺陷ID，状态，类型，所属项目，所属模块，缺陷提交时间，缺陷提交人（检测者），严重程度，优先级别，缺陷描述信息，测试步骤，测试前置条件，测试数据，期望结果，实际结果。

九、Bug的描述概要、详细说明
Bug的描述概要

Bug的描述说明
【项目】●根据项目名称选择
【问题类型】●Bug，需求Bug或建议
【主题】●【模块或功能】
【严重等级】●根据缺陷严重情况选择
【优先级】●期望研发响应Bug解决的速度
【影响版本】●当前测试的版本
【附件】●Bug截图或文件
【模块】●初步判断Bug所属的模块
【前提条件】●服务器环境、本机型号、浏览器及版本、分辨率、子系统版本、操作时间
【测试机型】●终端测试设备描述
【描述】●格式参考详细说明
【经办人】●分配给对应模块的研发负责人
【抄送】●根据实际情况选择抄送人员
【标签】●当前测试功能模块名称，建议填写，方便Bug统计
说明：表示为测试必填项
描述  格式
【测试环境】手机型号、浏览器及版本、分辨率、子系统版本、操作时间
【前提条件】测试前置条件、账号信息、车辆MN等
【再现步骤】便用1.2.3的形式进行说明
【实际结果】操作后出现的问题现象
【期望结果】操作后系统应该出现的正确现象
【说明】相关的一些现象的说明为开发分析问题跟踪问题提供帮助
【在线本】问题再现的概率，概率问题至少尝试次以上

十、高质量Bug的编写
1、标题:主要简明扼要地描述了Bug，可以让人快速了解问题。
2、测试环境:什么环境下发现的，软件和硬件系统，什么版本，如果需要，还应注明哪个、硬件平台。
3、前提条件:用户测试步骤前的系统环境信息(Bug在什么环境或者设置下出现的)。
4、测试步骤:在执行什么操作时，发现的问题。
5、实际结果:在测试软件的过程中，软件本身表现出的结果，可能与预期结果有出入。
6、预期结果:软件设计所要求达到的需求本身达到的目的，预期目标。
7、附件---主要
①跟开发交流形式。
②测试自身定位Bug，方便多维度统计Bug。

十一、怎样与开发进行沟通
1、确保自己提交的是个BUG，并且能重现这个BUG。
2、如果开发有疑问，或者说没有问题的时候，我们可以从用户的角度解释使用系统时，用户的操作怎样的不便。
3、Bug步骤需要写清楚，或者描述清楚，开发人员在了解问题所在后，可以准确定位。
4、跟研发确认清楚，修改这块后，主要影响哪里，会对其他的模块有影响没，有的话，我们需要重新关注。
5、注意话语，“你这个Bug很大，赶紧修改吧”“你敢说这不是Bug”  建议“帮忙看下是不是我哪里操作的不正确“。