一个BUG的自我修养

前言：

在软件测试活动过程中，产生的缺陷（BUG）需要使用我们的语言进行描述和陈述复现步骤，经过沟通后对缺陷进行定位及评判。

那么一个BUG需要如何表现出来才能更加高效且直观呢？

BUG：

1.请用简介的陈述句来给我拟一个高冷的标题，比如：“bug先生凌晨2：00登陆某小视频网站被抓获。”

2.请给我的犯罪历史编号，如：“#20180321”

3.请把曝光者的狗仔（测试）和我的经纪人（研发叫我干的）列出来，并且通知警察（经理）和律师（PM）。

4.请把我犯罪时的环境描述清楚

    环境描述：软硬件（iphone7plus ios10.2.1，浏览器 Chrome Mobile v30.0）

    犯罪过程（复现步骤）：

    step1：打开登陆器访问www.heheda.me（一看就是小网站）

    step2：输入登陆信息{username：bigbug  password：wozuishuai} 及验证码（随机生成）

    step3：点击登陆（提示登陆失败，此时被抓拍并被制服。）

5.请给我定罪量刑（缺陷类型/严重程度）

6.请把罪证贴上来（图片/gif）

7.记得把口供（测试用例）带上。

一个BUG的判定要求对于测试的目的和影响模块及业务流程相对熟悉，尽量减少其他问题的影响因素（网络延迟、人为修改、其他模块的缺陷影响）有利于准确定位BUG产生的根本原因。（盲目的提交由一个根源问题产生的多个低级bug是没有意义的）

在测试过程中当你提交的问题没有办法通过同行评审，说明你的问题描述难以理解，请不要在测试描述中增加过多的口语化赘述，你一定不希望这种口语化文字出现在你的测试报告里。

BUG的性质判断可根据影响范围进行判断：

    a.致命问题----由此缺陷导致系统崩溃/卡死/清空持久层数据及配置文件如（页面崩溃、浏览器卡死、数据库数据丢失、核心设备数据丢失）。

    b.严重问题----由此缺陷会引起其他模块的连锁性问题，导致大范围模块出现异常，或者属于前置业务功能导致后续流程无法进 行。此外，功能未正常实现也属于此类问题。（如：购物车无法添加，导致无法进行结算业务。）

    c.普通问题：此缺陷常见于功能实现出现结果数据偏差，功能容错性小。（如登陆的认证失败。）

    d.低级问题：ui偏差，文字错误，已解决问题重现（代码合并错误）。

ps：关于安全性的问题要单独归类，每一个安全问题都应得到重视（这里面包含了行业里面的各种坑，谨慎测试）。

BUG鉴别的依据除了《需求》《设计》文档还有一份重要的知识理论-----ISO9000/90001 以及 “软件工程的27个特性”。

所以不要凭感觉去找bug，所有的bug都可以找到依据去佐证，也不要因为研发与需求的一面之辞而放弃对bug的性质认定。