软件测试人员的BUG论
- 2018-03-13 17:21:00
- 小熊 原创
- 4729
01 认识BUG
1、软件人员之硬实力
首先测试人员要有识别BUG的能力,你要知道怎么测,用什么方法测试,标准是什么。比如常见的界面测试,接口测试、流程测试等,就是所谓的测试人员硬实力。
就说界面测试吧,我们要知道页面显示的基本检查点,比如,字段大小和样式是否一致 ,页面的显示列表表头排序是否由主要到次要,显示列表内容排序是否正确。字段超长时,页面是否变形的基本常识。
2、软件人员之软实力
良好的逻辑思维和领悟力,可以使测试人员快速的学习和领悟业务知识,然后形成自己的理解,否则流程测试时跟本衔接不上,搞不懂对错,不断的问开发,问其它测试,会导致测试的效率和质量都很低,并且别人对测试的印象也大打折扣。搞不好会让人感觉测试是来添乱的。
如果软实力和硬实力都很强,那么测试人员对BUG的识别能力自然会提高。
02 捕捉BUG
1、熟悉业务和测试功能,按用例执行
测试前需要对测试业务和测试流程都了解,理解测试用例的目的,在测试过程中按标准(测试用例)测试,来不断展开测试。有时小熊也会边测边补充测试用例,因为深入测试时,对业务最熟悉。容易会发现测试用例的疏漏。
2、要有一颗怀疑的心
测试人员 要有一颗怀疑的心,凡事都要确认过才相信,不能想当然。
有时候,也会遇到一些情况,感觉不太对劲,但是又不能立马说出哪里不对,遇到这种情况,一定要认真分析,不能放过。很多问题就是这样被忽略了。其实你在仔细想一下,或者问一问,就会发现不妥,这样一个BUG就被捉住了。
有时候开发人员和测试人员的意见不统一,被开发人员三言两语的给说服了,两个人默默的达成一致,然后把测试用例的预期结果就给更改了,然后,一个不该有的BUG就这样华丽丽的产生了。。。
这是绝对不可取的,小熊是这么做的,因为小熊所在项目测试用例都是要经过评审的,测试中如果测试的实际结果和预期结果确实不一致,测试人员要拿出专业水平来说服他,但若不能说服开发人员,那么就找个相对权威的第三方再确认一下,当三个人分析后仍然不能统一意见的,那就找项目经理再确认。这样才能保证不会放过一个BUG。
3、细心和耐心
无论测试工具多么繁花似锦,手工测试还是不可避免的,所以测试用例执行一定要到位!
小朋友,请不要偷懒哦,所有偷过的懒在生产上都会被揭穿的,小熊坚信,生产是检验质量的唯一标准。
测试过程中,一旦发现问题,如果是页面上的问题,一定要及时截图,保留证据。然后下一步,就是要分析 ,定位啦~~
03 分析BUG
对于优秀的测试人员,一般发现问题时,首先去看看日志,看看数据库,然后分析一下这个问题是由什么原因导致的,在什么场景下出现的,如何重现这个问题,这个问题还可能会有哪些影响。这么一来二去,你就成了一个分析专家,逻辑思维和业务能力都会在一次次分析中得到提升。
有时候,一个BUG琢磨好久,也想不通,那么就可以先提出BUG,让开发去解决。
切记!对于偶然的问题不确定是否能够再现的,一定要保留现场,保留证据。
04 提出BUG
提BUG单时,要做到语言简洁、表达清晰,首先把问题场景和问题现象说清楚。
对于流程测试,还需要把测试数据提供一下,我习惯提供测试SQL,为了方便开发分析和确认问题,小熊通常会保留错误数据现场,这样开发看到BUG,很快就能定位,大大提升了解决问题的难度和速度。
小熊喜欢按下面的格式提出问题。尤其是BUG描述那段。
BUG主题:新增用户页面的用户名已存在时,提示SQL错误
问题类型:界面问题
功能模块:用户管理
经办人:XXX
BUG描述如下:
【测试步骤】:打开新增用户页面,用户名处录入已存在的用户名test1,其要素正确录入;
【预期结果】:新增失败,页面提示用户test1已存在。
【实际结果】:新增失败,页面提示SQL错误。如附件截图所示;
附件:上传错误截图
嘚啵这么多,最后总结一下,就是测试人员要有很好的BUG识别、捕捉、分析、提出的能力。
相信你对BUG也有一套自己独特的看法,欢迎留言交流哦~~
本站文章以及相关内容除注明 转贴外,均为本站 原创或 翻译。
如果本站转载的文章涉嫌侵犯了您的权益,请在评论区留言或是邮件联系管理员及时删除 【admin@luckyframe.cn】
本站原创或是翻译的文章欢迎任何形式转载,但请务必 注明出处以及链接,尊重他人劳动成果,拒绝剽窃从你做起。