测试中Bug的管理流程和禅道

一、Bug的定义
软件的bug，狭义概念是指软件程序的漏洞和缺陷，广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节，或与需求文档存在差异的功能实现等。
我们的职责就是，发现这些bug，并提交给开发，让开发去修改。
二、bug的类型
要确定一个bug的类型，需要对项目或产品有比较深的理解，这个划分对于开发定位问题影响很小，但对于问题类型的统计就比较重要了。
常见的bug类型划分（禅道系统为例，）：
代码功能错误 （例：闪退、提交保存后，回显信息不对、异常关机、登录报错）
设计缺陷 （例：需求说明书文档上有某功能，开发并未开发、UI设计缺陷、代码设计缺陷）
界面优化 （例：写作业错别字，界面信息不完整）
其他（性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本）
其他划分：功能类、界面类、性能类、易用性类、兼容性类、其他
三、bug的等级
要bug等级，这个划分有分三级或四级，也有分五级的，如果是等级越高，那么可能被修复的等级也会高一些，然后有些公司还会根据你提的bug数量和bug等级来考察你的绩效，很多情况下，我们提交的bug大致等级差不对即可，没有严格区分。
如何判断bug的等级（严重程度），一般可以参照下面的判断条件。
（1）致命错误： 等级1
1、常规操作引起的系统崩溃、死机、死循环
2、造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
3、涉及金钱计算
4、阻断性测试，所有测试工作进行不下去
（2） 严重错误： 等级2
1、重要功能不能实现
2、错误的波及面广，影响到其他重要功能正常实现： 功能交互
3、非常规操作导致的程序崩溃、死机、死循环
4、外观（界面）难以接受的缺陷
5、密码明文显示：（界面+数据库），例：网页链接后显示为Uscmamc=334378721@qq.com&Password=123456 安全泄露
（3） 一般错误： 等级3
不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷。
1、次要功能不能正常实现 （例：登录旁边的帮助或者是找回密码）
2、操作界面错误（包括数据窗口内列名定义、含义不一致）
3、查询错误，数据错误显示 （例：查询12306出现12315）
4、简单的输入限制未放在前端进行控制，（格式限制）长度，例：输入框输入20位正常登录，输入21位，点了提交没反应，没有登录进去，也没有任何错误提示，说明只控制了后端没有对前端进行控制。
5、删除操作未给出提示
(4) 细微错误：
程序在一些显示上不美观，不符合用户习惯，或者是有一些文字的错误
1、界面不规范
2、辅助说明描述不清楚
3、提示窗口未采用行业术语
4、界面存在文字错误
改进建议：可以提高产品质量的建议，包括新需求和对需求的改进。
练习：bug的类型以及等级判断
1、用户输入正确的用户名和密码不能登录网站 >代码错误，1等级
2、客户需求要有充值功能，但是网络没有做 >设计缺陷，2等级
3、网站首页的图片在IE8浏览器上显示不完整，火狐、谷歌正常 >界面错误,3等级
4、网站充值后，出现金额错误 >代码错误，1等级
5、在某购物APP上进行商品搜索时，闪退回到手机桌面 >代码错误，1等级
6、在某购物APP上进行商品搜素时，手机卡死 >代码功能错误，1等级
7、关闭按钮在弹窗左侧 >界面错误，等级4
8、APP某个图标显示太小或者像素失真 >界面优化，等级4
9、某个提示语需要改进一下，用户对专业术语不太懂 >界面优化，等级4
10、密码找回功能点击无反应 >代码错误 ，3等级
11、web点击查询，无反应 >代码功能错误 3等级
12、输入12306，点查询，查询结果显示12315 >代码功能错误，3等级
四、 bug的生命周期(管理流程)
面试/笔试过程中经常会被问到的问题，bug的生命周期，就是一个bug被发现到这个bug被关闭的过程，步骤：
生命周期中一般缺陷状态：新建（测试人员干的活）->指派(测试人员干的活)（开发，测试老大，开发经理）->已解决（开发人员）->待验（测试人员）->关闭.
如果待验的bug在验证时没有解决好，我们需要重新打开（激活）->指派->已解决->待验,循环这个过程。
中间其他状态：拒绝、延期等
五、 bug的跟踪管理-缺陷管理工具
常见的缺陷管理平台：
禅道（zentao）
bugzilla 、redmine、 jira都还不错，也比较强大，但是搭建起来很困难
bugfree
easybug免费开源，在线网站类型的
Mantis这个还可以用
QC(QualityCenter)、TD
禅道的介绍：
覆盖测试用例管理，发布管理，文档管理等，将产品，项目，测试这三者的概念明确分开，产品人员，开发团队，测试人员，这三者分立，互相配合，又互相制约，通过需求，任务，bug来进行交相互动，最终通过项目拿到合格的产品。
六、 bug的跟踪管理-如何提交bug
发现bug后，接下来你提交到bug管理平台，提交一个bug包含哪些内容？
bug标题——标题要清晰简洁，写明bug描述，如果没有选择功能模块，最好在标题中标准功能模块。
让查看bug的人员知道你所表达的意思。 Bug的功能模块+bug的操作+bug的结果
重现步骤——详细写下bug的测试过程。能指导开发重现这个bug，附上测试数据
实际结果——出现bug的结果，粘贴bug截图、日志截图
预期结果——记得写清楚预期
bug的类型和严重程度——便于后续测试结果分析，bug的统计
bug测试换——例如：什么系统，哪个版本等。兼容性问题，难以重现问题
附件——日志文件，文件测试数据。图片、崩溃日志文件等

所有以上，参照公司前辈写的bug，依葫芦画瓢，拓展测试思维
七、 bug的跟踪管理-状态处理
1、已经指派的 bug—已经指派给开发的，请大家注意bug的走向，随时关注并进行跟踪！如果一直未修复，提醒开发修改，以免开发忘记，如果已经修复等待测试环境更新后进行验证，催着改bug
2、已解决的bug—等待测试环境更新后进行验证，验证通过则关闭，验证不通过则重新打开指派给开发
3、重复bug—先去查看下是否跟开发指派的bug重复？如果确定是重复则关闭；如果不重复，说明原因，重新打开指派给开发
4、不是缺陷—确认开发环境是否跟测试环境一致，如果如开发所说不是缺陷则进行关闭；如果确认是缺陷跟开发沟通，沟通未达成一致找产品确认，确认是bug注明情况并再次指派给开发。
5、无法重现—确认开发环境是否跟测试环境一致？包括操作步骤，浏览器，环境，特定账号，输入数据等，如果多个版本验证之后，如开发所说重现不了，依据bug的严重程度跟产品、开发一起确认关闭；如果找到重新原因，注明清楚并再次指派给开发
6、不予解决—找产品经理进行确认，确认不予解决进行关闭，确认需要解决请备注原因并打开指派给开发
7、设计如此—找产品经理进行确认。确认设计如此进行关闭，确认是问题，备注原因重新指派给开发
8、延期修改—请看下bug严重程度，是否影响到当前版本发布？与产品经理进行确认。不予延期请根据情况进行激活与情况说明；延期请做好记录，后续版本进行关注——不关闭

常见笔试面试题
1、有没有你印象深刻的bug？bug的原因/bug当时怎么解决
2、bug的生命周期（笔试）
3、当你开了一个bug，但是开发不认为是bug，如何处理？
4、你在发现bug并确认bug的过程中，对于复现率不高的bug怎么处理？