本篇文章，来分享Bug管理的内容。
现在，假设我们已经进入了这么一个阶段，测试用例写完了，可能有人用Excel写，可能也有人用禅道或者其他的管理工具来写。而且，用例已经评审过了，那就开始执行测试用例了。
在执行用例的时候，可能会遇到一个问题，这个测试用例不通过，这就形成一个Bug了。
Bug的定义

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

那么Bug 与缺陷有什么区别或者联系吗？
Bug是缺陷的一种表现形式，而一个缺陷是可以引起多种Bug的。

Bug的分类
对Bug的划分，可以分为以下：

功能缺陷：指业务流程未实现
代码错误：页面跳转时报404、500
界面优化：UI 问题，图文显示的问题
安装部署：安装失败或者无法访问等
性能问题：响应时间久，页面加载慢
安全问题：用户身份验证，数据备份等
设计缺陷：需求问题
其他：易用性及兼容性的问题


Bug 的严重程度
1、致命：系统崩溃（请求直接把服务器搞坏）、死机、死循环等，会导致数据库丢失，与数据库连接错误，主要功能丧失，基本模块缺失，重要的一级菜单功能不可使用等问题。
2、严重：系统主要功能部分丧失，数据保存失败，提交调用错误，功能设计与需求严重不符，自动退出，稳定性差等。
3、一般：功能菜单没有完全实现，存在缺陷但不会影响系统稳定性。如操作时间长、查询时间长、格式错误、边界条件错误、删除没有确认框、数据库表的字段过多等。
4、轻微：兼容性，界面优化，不影响操作功能的执行，错别字，页面显示重叠，提示语丢失等，此类问题在测试初期较多，优先程度低。
Bug的优先级
主要是指开发修复Bug的先后顺序，可以分为：


非常紧急
紧急
一般
不重要


Bug的优先级，最终的决定权还是掌握在开发或者产品经理的手上，测试人员只是起到建议的作用。
Bug的跟踪处理流程

根据Bug的跟踪处理流程，Bug存在以下的状态：

待处理
已确认
已处理
已修改
仍处在，代表被重新激活
拒绝
挂起，代表暂不处理

Bug的描述概要
发现Bug之后，需要将Bug描述清楚，转交给开发处理。
关于Bug的描述，主要包含以下：

Bug的所属项目
Bug的所属模块
Bug产生的前提条件
问题类型
标题：尽量详细，方便后续快速查询
严重级别
优先级
复现步骤
期望结果
实际结果
附件：如有必要，可添加截图与视频等

关于高质量的Bug：


标题：简明扼要地描述Bug，可以让负责修复的人员快速了解，定位问题
测试环境：清晰描述在什么环境下发现Bug，包括软件和硬件系统
前提条件：用户测试步骤前的系统环境信息等
测试步骤：在执行怎么样的操作时，发现问题
预期结果：软件设计所要求达到的需求、预期目标
实际结果：在测试软件的过程中，软件本身表现出的结果，可能会与预期结果有差异


与开发的沟通
1、确保自己提交的Bug是有意义的，并且是可重现的
2、如果开发有疑问，或者认为这不属于Bug时，可以从用户角度进行解析
3、Bug 步骤要写清楚，方便开发人员定位Bug
4、与开发确认，修改Bug后，会影响到哪些模块，重点关注
5、注意沟通技巧

以上就是本篇文章所要分享的内容，欢迎各位大牛指正。你的指正，能让我在测试之路上快速成长。
Leo Never Stop Fighting！

1.描述测试用例设计的完整过程？

首先，拿到需求后要详细的理解需求，在理解需求的基础上编写测试计划，要考虑到测试的时间、测试环境等等。 

其次，要根据需求编写测试用例。根据测试对象的不同采用不同的测试用例编写方法，用例编写完后要进行评审。 

然后，要搭建测试环境，比如说拿到一台裸机的时候要安装客户所需要的系统，并安装所需要的软件并且进行一些必须的配置。 

最后，执行测试。



2.功能测试用例需要详细到什么程度才是合格的？

测试用例覆盖到所有的测试点。



3.您认为做好测试用例设计工作的关键是什么？

白盒测试设计测试用例的关键是以最少的测试用例覆盖尽可能的多的内部逻辑。 

黑盒测试设计测试用例的关键是以最少的测试用例覆盖尽可能多的模块的输入输出接口。 

总之就是以最少的用例覆盖尽可能多的测试点，并在最短的时间内找出最多的bug。



4.您所熟悉的测试用例设计方法都有哪些？

等价类划分：就是把所有的测试数据分成若干个集合，在每个集合中挑选具有代表性的数据进行测试。这样就节省了测试时间。 

边界值分析：很多错误都是发生在数据范围的边界上，并不是发生在数据范围的内部或者外部，边界值分析可以找出更多的bug。 

错误推测：凭借自己的测试经验推测是错误应该存在的地方。



5.一个缺陷测试报告的组成？

缺陷编号、缺陷标题、缺陷描述、缺陷的优先级、缺陷的重要程度、缺陷所属的模块、缺陷所属的版本、缺陷所属的开发人员、输入数据、输出结果、缺陷分析等。



6.简述一下缺陷的生命周期？

首先是测试人员对开发人员已经开发的模块进行测试，如果发现有错误或者功能与需求上不一致的地方就提出 一个bug，然后由项目经理决定把这个bug安排给所属开发人员，开发人员修复完成后将bug重新提交给测试人员进行测试，如果测试结果正确的话测试人员就将这个bug关闭，如果仍然存在问题的话就让开发人员重新进行修复直至问题解决。



7.针对缺陷采取怎样管理措施？

首先要引入bug管理工具，如jira，bugzilla等。其次测试人员最好可以找出这个bug所出现的位置。 

然后要及时更新bug的状态，每天进行统计。



8.测试结束的标准是什么？

所有测试用例执行完毕。 

测试用例覆盖到所有的测试点。 

没有存在重大的缺陷，一些小缺陷存在的比例不超过客户需求的。



9.测试用例通常包括那些内容？

用例编号、测试环境、用例标题、用例描述、输入数据、预期结果等



10.写出bug报告流转的步骤，每步的责任人及主要完成的工作

测试人员发现bug，提交在bug管理工具中，状态为new。 

项目经理把这个bug分配给相应的开发人员，状态为open。 

开发人员修改完bug后重新提交给测试人员测试，状态为fixed。 

如果bug暂时无法解决，仍然为open状态。 

测试人员重新测试bug，如果没有问题的话将bug关闭，既close。 

如果问题仍然存在的话将bug重新打开给开发人员修改，状态为reopen。

记得前面写过一篇关于bug的文章，这里只是稍作升华。

首先，一个好的bug需要满足什么标准？4个字，简单具体。尽量把问题描述得简单，让开发、测试、项目经理、需求等等参与人员都能很好理解，描述问题要具体，不能说是有错误，而是要具体到是什么错误，比如404，段错误，卡死之类。

bug要遵循一个什么样的流程？新建，修复，持续跟踪，关闭，重开，延迟，不修改，无效等，遵循的是一个闭环的流程。项目发布之前，需要确保每个bug都得到了处理，达到了闭环的要求。

偶发问题是否有复现方法？有句话说的好，任何偶发问题都是一定条件下的必发。这就说明了偶发问题肯定是有复现可能的。为了增大这种可能性，我作了如下总结：
1、问题出现时，保留现场，记录测试环境，根据沟通结果，详细记录bug内容；
2、在bug库中查找类似问题，共同作分析；
3、分析测试方法，争取测试资源，共同复现偶发问题；
4、针对复现过程，反复和开发沟通，缩小范围，直至问题重现。

待续。。。