软件测试员这些坑一定要记住了,不要再往里面掉了
2018-01-19 19:33
501 查看
软件测试干了几年,项目一个接着一个,一路从一个坑跳入另一个坑,有些是开发问题,一些是测试本人问题,大家在测试过程中踩过哪些坑尼?
1.自以为了解业务逻辑,实际浮于表面
这是个深坑,产品迭代跟的久了,功能上闭着眼睛都能说清楚就自以为很了解,实际上连该功能使用的协议,调用的接口都不知道,所以看到问题都是表面的问题。
你只看到了两个操作的入口不一样,提示信息不一样,你就以为是两个问题,而这两个问题都是调同一个接口引起的,但你分析不出来。。
这样导致的问题有:
①修改bug后对影响范围评估不够
②提相同的bug,碰上特别注重bug数量的开发,真是揪心。。
我们公司对于bug定期要做bug根因分析,这在一定程度上也是帮助测试更深入的了解产品,因为每次bug单上开发写的产生原因和解决方案,真是言简意赅。。
2.思维定死,不会向前多走一步
比如同一个账号添加之后删除再添加,同一份文档导入之后导出再导入,密码修改成功之后再修改,等等,向前多走一步,就可能有意外收获。
3.忽略偶现的问题
测试要记住:所有偶现的问题,都只是没有找到必现的规律!
不要以为偶现的问题,没有出现,就不提出来,等上线后用户发现这个问题,你再说曾经遇到过,只是没有提出来,那测试不背锅还有谁背??
提出问题但不解决,测试就可以甩锅给产品,给开发,完美!(这个真是从踩过的坑里得出血淋淋的教训)
这里有个好的习惯:遇到问题先截图!!!先录视频!!!再分析原因,再提交给开发,最怕偶现的问题口说无凭,又没有证据证明,开发说你逗我呢???
4.避免随机测试
避免没有用例而进行的随机测试,虽然随机测试能发现一些问题,但是它的特点是我们测试人员想到什么就测试什么,这样就会导致有些功能点重复测试,而有的业务流程却没有覆盖到,出现漏测,一旦上线后出现Bug,就不好说了。
5.Bug的复现步骤描述必须要详细
这个其实算不上坑,只是个人总结。之前提交过一个Bug,Bug描述非常简单,在后期给开发复现的时候,费了很大的劲儿,如果我们能在Bug描述中,准确描述Bug的复现步骤,就可以明显缩短开发分析问题、定位问题的时间。
6.不要 “动” 之前的业务逻辑,因为会 “牵一发而动全身”
要 “遵守” 之前的业务逻辑,现有的业务逻辑尽量不要和之前的冲突,为啥呢?
因为啊,一旦按照现在业务逻辑的话,就得把之前的改了,改之前的业务逻辑会非常的复杂,不仅开发需要改代码,而且我们测试要重新再测,所以,不要动之前的业务逻辑。
1.自以为了解业务逻辑,实际浮于表面
这是个深坑,产品迭代跟的久了,功能上闭着眼睛都能说清楚就自以为很了解,实际上连该功能使用的协议,调用的接口都不知道,所以看到问题都是表面的问题。
你只看到了两个操作的入口不一样,提示信息不一样,你就以为是两个问题,而这两个问题都是调同一个接口引起的,但你分析不出来。。
这样导致的问题有:
①修改bug后对影响范围评估不够
②提相同的bug,碰上特别注重bug数量的开发,真是揪心。。
我们公司对于bug定期要做bug根因分析,这在一定程度上也是帮助测试更深入的了解产品,因为每次bug单上开发写的产生原因和解决方案,真是言简意赅。。
2.思维定死,不会向前多走一步
比如同一个账号添加之后删除再添加,同一份文档导入之后导出再导入,密码修改成功之后再修改,等等,向前多走一步,就可能有意外收获。
3.忽略偶现的问题
测试要记住:所有偶现的问题,都只是没有找到必现的规律!
不要以为偶现的问题,没有出现,就不提出来,等上线后用户发现这个问题,你再说曾经遇到过,只是没有提出来,那测试不背锅还有谁背??
提出问题但不解决,测试就可以甩锅给产品,给开发,完美!(这个真是从踩过的坑里得出血淋淋的教训)
这里有个好的习惯:遇到问题先截图!!!先录视频!!!再分析原因,再提交给开发,最怕偶现的问题口说无凭,又没有证据证明,开发说你逗我呢???
4.避免随机测试
避免没有用例而进行的随机测试,虽然随机测试能发现一些问题,但是它的特点是我们测试人员想到什么就测试什么,这样就会导致有些功能点重复测试,而有的业务流程却没有覆盖到,出现漏测,一旦上线后出现Bug,就不好说了。
5.Bug的复现步骤描述必须要详细
这个其实算不上坑,只是个人总结。之前提交过一个Bug,Bug描述非常简单,在后期给开发复现的时候,费了很大的劲儿,如果我们能在Bug描述中,准确描述Bug的复现步骤,就可以明显缩短开发分析问题、定位问题的时间。
6.不要 “动” 之前的业务逻辑,因为会 “牵一发而动全身”
要 “遵守” 之前的业务逻辑,现有的业务逻辑尽量不要和之前的冲突,为啥呢?
因为啊,一旦按照现在业务逻辑的话,就得把之前的改了,改之前的业务逻辑会非常的复杂,不仅开发需要改代码,而且我们测试要重新再测,所以,不要动之前的业务逻辑。
相关文章推荐
- 血的教训,一定不要再4.0以后在主线程里面访问网络NetworkOnMainThreadException
- 与老板谈薪酬时,一定不要犯这些错误
- 封装一下webform的公用方法:对于软件我把这些全封装在pagebase里面,这样所有的页面只调用一句 Init()即可,其他的全在页面上配置
- 预装Win10改Win7出错了?这些失误一定不要犯!
- asp 里面 sub 和function 的区别 已经很多次了 这次一定要记住
- asp 里面 sub 和function 的区别 已经很多次了 这次一定要记住
- SVNsvn文件里有问号,打勾,感叹号,蓝色的十字符号,这些符号分别代表什么意思?SVN里面的AD
- 程序设计一定不要忘了“设计”两字
- 《软件工程里面的大学十年》(转载上半部分)
- 有关stm32的问题,程序里面的u8、u16这些是什么意思啊
- 奉劝大家不要再用刷流量软件刷新浪博客等级了
- 关于软件文档 这些你知道吗?
- 请不要忽视这些基础知识
- 上网不要老是校内和QQ,这些没有登过你就白读大学了!
- Winform软件,不要在线程里操作UI
- 记录点滴之优化应用性能:Activity里面不要使用静态常量
- 【Android】Android清除本地数据缓存代码(这些功能很强大不要乱用)
- 软件项目经理新手上路(6) - 不要进行小改进
- 实战c++中的string系列--不要使用memset初始化string(一定别这么干)
- 一定要记住这20种PS技术!会让你的照片美的不行!