前面已经提到了什么是Bug，Bug即软件错误。当软件规格说明书存在且正确时，若程序与规格说明书不一致则视为软件错误，对于软件规格说明书中没有提到的部分功能，则以用户需求与预期为主，不符合用户合理预期的视为软件错误；
对于一名测试人员而言，可以狭义的认为其工作就是不断地发现bug和提交bug，本文将进一步介绍与Bug相关的内容：
描述一个bug
一般情况下，一个合理的bug描述主要包含下面几个部分：
- 发现问题的版本
对于开发人员而言，只有清楚测试人员提出bug时的对应版本，才可以根据相应的版本对应的代码来查找问题出处； - 问题出现的环境
对于web项目而言，环境就代表浏览器的版本、客户机的操作系统等；若是APP项目，环境则包含了操作系统的版本、APP安装的机型等； - 发现的问题的步骤
为了让开发人员更快更好地复现bug，就需要测试人员在bug的描述中清楚体现Bug出现的详细步骤； - 预期结果的描述
预期结果的描述是bug为什么是bug的有力证明，也是为了让开发人员清楚什么样的是正确的，需要得到什么样的效果才是修改成功； - 错误行为的描述
对实际情况进行描述，也是证明Bug的有力证据；
要清楚创建bug的目标是为了让开发人员或其他人员可以复现以此来修改，因此对于bug的描述要尽可能清楚明了，一般包括但不限于上面几点，一般还会根据不同企业的具体要求增加其他要素；
Bug的级别
关于bug的定级，一般不同的企业要求不同，这里只做普遍情况下的简单介绍：
- 崩溃
直接导致开发或测试工作无法开展，系统崩溃，死机，数据库数据丢失，主要功能模块缺失等； - 严重
系统主要功能部分丧失，功能设计与需求严重不符，安全存在问题，系统稳定性存在问题等； - 一般
功能实现不完全但又不影响正常使用，一般级别大致就是存在问题但又不影响正常使用； - 次要
功能可以正常使用，但可以进一步优化，用户体验一般，进行优化更好；
Bug的生命周期
测试人员在提交一个bug之后，应该持续关注bug的状态转换，直到其生命周期结束；下面是bug的状态转换图：
new：测试人员新发现的bug；
open：确认时bug，交由开发人员进行修改；
rejected：不被认为是bug，开发人员拒绝修改；
fixed：开发人员进行修改；
delay：因为一些原因延后修改bug；
closed：经测试人员再次测试，确认修改成功，关闭bug；
reopen：经测试仍未修改成功，重新开启bug；
与开发产生争执的解决办法
不可否认的是，测试人员每提出一个bug，对于开发人员就意味着工作量的增加，因此由于bug的提出而与开发产生争执在所难免，下面提供了一些解决思路：
- 对自己提出的bug进行确认，是否描述不够清楚，是否提出了一个无效bug；
- 检查自己的bug定级是否合理，参考bug级别和用户体验；
- 以用户的角度引导开发人员，作为用户是否可以容忍这样的bug存在；
- 尽可能提高自己的业务水平，在提出bug的同时，可以给出bug修改的参考意见（只是建议，不可以喧宾夺主）；
- 经上述流程，依然不被开发认为是有效bug，可以发起bug评审（邀请产品代表、开发代表、测试代表参加），共同沟通，解决bug如何修改以及如何避免此类问题发生等问题；
over！