有些工程师心想:“作为测试工程师我怎么不知道提交bug吗?难道还要你来教我吗?好low的问题。”

正因为软件测试工程师的这种傲慢,这种傲慢直接导致和开发人员冲突,经常碰到开发人员抱怨测试提交的bug看不懂。

我先声明下,我今天不是替软件开发工程师说话,我只是站在一个客观的角度看待问题。我刚开始做测试的时候也是不理解软件开发的抱怨和责怪,随时时间的推移才明白做人真的不易,每个岗位每个人都有他的难处,多理解他人的处境,要知道软件开发整天面对密密麻麻的代码很费脑,再碰到测试提交的很多bug,他们的内心是排斥、抗拒的。

01、现在我们站在软件开发人员的角度,看软件测试工程师有哪些毛病?

1.描述bug不清晰,就一句话,没有具体的操作步骤。

比如:拨打电话出现死机。(就简单的一句话,就啥都没了,拨打什么号码–没写,在什么情况下拨打电话–没写)

2.提交的bug看不懂啥意思,不知所云。

这种bug只有测试工程师自己能看懂,别人根本看不懂,他却以为别人能懂。

3.没有写出现的概率。

偶发的bug没有log和其他更多信息,有的bug概率很小,小到不影响用户使用,如果不写清楚,开发人员将浪费大量时间去定位问题。

4.bug发生的前提条件都不写。

比如:bug描述是充电图标显示重叠。但是没有写什么条件下出现,开机状态?还是关机状态?开发工程师懵逼,还要自己去一个个去试,浪费开发人员的时间,描述不详细但是测试工程师还觉得自己没毛病,一切挺好。

5.bug等级乱定位

比如一个很小的甚至是建议性的问题,把bug等级提到最高。软件开发一看,全是致命性1级bug,仔细一看很多小问题也被提为1级bug,此时开发人员的心情肯定的奔溃的。

6.测试工程师描述bug,却不写预期结果。

开发都不知道要修改成什么样,一脸懵逼。结果开发理解错了,修改的结果不是预期的结果,这就浪费开发的时间了,你想想此刻开发人员的心情是怎样的?

7.出现问题的软件版本没写清楚,开发人员不知道是在哪个软件版本出现的。

8.bug出现的模块没有划分清楚,所有的bug都提到一块,看的眼花缭乱。

02、正确的提交bug才是我们和开发人员友好的沟通的最好方式。

1.bug标题要简洁明了,不要啰嗦一堆。

2.要写出现问题的前提条件。

什么情况才会出现,必须要写清楚。

3.操作步骤要分步骤一步步写清楚,不要怕麻烦。比如步骤1,步骤2,步骤3。

4.要写实际结果和预期结果,让开发清楚要修改bug到达的预期效果。

5.要写出现的概率,比如操作10次出现1次。

6.提供必要的截图和log,甚至复杂的操作步骤要提供视频。

7.bug等级要分类好,致命性bug、严重bug、一般性bug、建设性意见,必须严格按照标准划分。

8.出现bug的软件版本号,要写清楚。

9.bug出现的模块要写清楚。

比如app–设置模块出现了bug,就把bug归类为设置模块的bug,这样分类让人一目了然。

03、以下是完整的bug:

前提条件:

操作步骤:

1.

2.

3.

实际结果:

预期结果:

概率:

版本号:

log、截图、视频等

04、bug的分类严格遵守,如下:

1、致命(1级bug)

通常表现为:系统无法运行,崩溃。

应用模块无法启动或异常退出,主要功能模块无法使用。

比如:1.内存泄漏;2.系统容易崩溃;3.系统无法登陆;4.循坏报错,无法正常退出。

2、严重(2级bug)

通常表现为:影响系统功能或操作,主要功能存在严重缺陷,但不会影响到系统稳定性。

比如:1. 功能未实现;2.功能存在报错;3.数值轻微的计算错误;4.乱码;

5.程序里有有危害国家安全或带有政治色彩的字样。

3、一般(3级bug)

通常表现为:界面、性能缺陷。

比如:1.边界条件下错误;2.极限条件下容易无响应;4.大数据操作时,没有提供进度条;出现错别字,但是不影响功能

4、建设性意见(4级bug)

通常表现为:易用性及建议性问题