概念

原始概念： 

bug是计算机领域专业术语，bug原意是“臭虫”，现在用来指代计算机上存在的漏洞，原因是系统安全策略上存在的缺陷，有攻击者能够在未授权的情况下访问的危害。

常规概念：

显然对于测试工程师来说，BUG的概念要更加广泛，把它局限于安全漏洞上在实际工作中是片面的。BUG是不符合设计初衷，违反逻辑，违反用户常规习惯，违反架构初衷，违反开发约定，不能满足性能需要的因素。

BUG提交的规范：

bug的提交无论以那种形式，口头描述，文字描述，文档，web工具等，都必须遵循以下规范：

1、划分模块，因为开发的习惯是分块分工开发，不同模块由不同的人员负责开发，前后端分离，在提交BUG的时候需要给BUG同样划分模块，以便于测试管理人员以及开发管理人员对总体的质量和工作压力的偏重很快做出评估。

2、标题要精炼，BUG的标题要精炼，标题不要写得过长，有时为了一目了然，我们会在标题前面先用括号注明模块和环境，如"【XX环境-XX模块--某某子模块】XXXXXXXXX问题"，主要是要体现问题，越具体越好。

3、同类问题要汇总提报。有时候因为同一个原因，比如某个服务的接口内部算法有问题，但是受牵连的模块较多。或者因为某个开发人员的开发习惯，有大量写死的数据返回。那么类似的同类问题在发现2个以上的时候，就不能急于提交BUG了，应该统一做一个汇总性的BUG，这样也方便开发人员统一排查，也许解决一个点就全部解决了，也许通过大量的表象迅速定位到一个交集点，也许是统一拿出时间进行排查。

4、BUG步骤应该清晰。BUG的复现步骤应该力求精炼清晰，并且做好给开发人员提供测试账号。首先要有操作步骤，然后是结果现象，最后是预期结果。这是黑盒测试必须掌握的规范。当然测试对于问题定位得越深，开发人员解决问题的速度就越快。级别高一点的测试，可能会把前后端问题做好区分，比如接口某些参数的问题，比如前端对于接口调用错误的问题，接口调用错误包含参数错误，调用次数错误，调用时机错误。再比如测试根据接口，反查源码，找到了代码上的处理空白，找到了sql的拼写错误等。但测试要做的事情主要是找到BUG，而不是解决BUG，这个没有具体的时间规范，但是原则上，三到五分钟内就应该执行下一条测试用例了，如果时间有限，测试也没有必要把时间浪费在精确定位BUG上，这个量力而为。除非我们所有的测试执行都完成了，但是大量的BUG修复时间让我们新一轮的测试迟迟不来，这个时候测试就可以花些时间把BUG定位得深一些。

5、不稳定BUG应该有复现概率。原则上，BUG应该有百分百的复现概率。如果实在不能百分百的复现，也需要给出一定的概率，比如50%，30%。其实往往这类BUG是因为有特定的环境没有发现，或者特定的干扰因素没有被发现。这类BUG测试需要尽可能去找到提升复现概率的方法，以及BUG的表现，app的BUG可以开启调试模式，如果产生BUG看控制台有没有报错信息。WEB页面可以打开控制台去捕获，接口问题可以开启抓包工具去捕获，或者进入服务器去实时观察日志信息，把有利的信息补充到BUG里。如果时间紧迫，那么可以注明，让开发在排查这个BUG的时候，联系测试人员进行操作配合，有时候开发人员自己写的逻辑，自己就会有更深层的分析。

6、BUG应该有合理的分级。bug的常规分级分为，严重程度分级：低，中，高，严重。紧急程度分级也分为四档，次要，一般，严重，紧急。先说严重程度，低的一般指的是一些字符串的错误，闪屏，抖动，提示不合理，越界，提示消失过快，以及一些美感，操作体验明显不好的地方，而相对主观的地方我们成为建议，应该提给产品设计人员进行审核，由设计人员决定是否更改。中等严重程度一般指的是逻辑存在缺陷，或者并不严格符合产品设计要求。严重程度为高的，一般指的是逻辑的不完整性，阻断性，易产生垃圾数据。优先级为严重的，一般指的是造成程序崩溃，或者服务崩溃的问题，以及主要功能没有完成开发或者忘记开发。紧急程度这一环，基本与严重程度成正比，而也有特例，比如我进行了非常规的操作，比如两个按钮一起按，比如我超出系统的承受范围给予压力测试导致崩溃，严重程度高，但是优先级不高。再比如我做了提交操作，但是由于我点击了两下，提交了两次，造成了垃圾数据或者重复扣款，严重程度不高，但是优先级高，因为这涉及到了垃圾数据或者用户利益，但是从程序的角度来看，只要前端增加一个点击按钮后置灰，或者接口做一个3秒内不能重复提交的限制就可以解决了，有些可能只是一个小问题，但是却对后续的测试流程产生阻碍，那么它的定位就是严重程度中，紧急程度为紧急。BUG分级的目的是为了让开发优先解决影响进度的问题，也是根分级去做分工，因为开发也有级别的区分。另外测试也能对整体质量有一个评估，在上线的时间不能改变的情况下，根据严重程度做适当取舍，往往不会因为一个不重要的BUG而影响整体的上线计划。

BUG生命周期：不同的BUG管理平台说法不一样，但是基本较全的生命周期如下

1、提交

刚刚提交的BUG为打开状态

2、分配/认领/确认

开发看到BUG，如果确认不是自己的工作范围，可能会指派给其它人，指派后确认是有效BUG，一般需要确认

3、解决/驳回/延期/待定

已经解决的，指派给BUG提交者。确定是无效BUG的话，一般予以驳回，延期和待定一般是一个意思，就是暂时不予修改，延期的BUG需要产品经理确认。最后挂在开发人员的名下。

4、重启/验证

已经解决或者驳回的BUG需要测试进行验证或者确认。如果没有修复成功的BUG需要重启再指派回开发者。

5、关闭/取消

已经验证通过或者确认是无效的BUG，需要关闭。如果测试在开发认领之前发现BUG无效，则可以主动取消。

下一篇我们说一下普遍的互联网企业的组织架构和测试工程在企业中的一般的工作流程。