零基础软件测试员骗局干了几年项目一个接着一个，一路从一个坑跳入另一个坑有些是开发问题，一些是测试本人问题大家在测试过程中踩过哪些坑尼？

1.自以为了解业务逻辑实际浮于表面

这是个深坑，产品迭代跟的久了功能上闭着眼睛都能说清楚就自以为很了解，实际上连该功能使用的协议調用的接口都不知道，所以看到问题都是表面的问题

你只看到了两个操作的入口不一样，提示信息不一样你就以为是两个问题，而这兩个问题都是调同一个接口引起的但你分析不出来。

①修改bug后对影响范围评估不够

②提相同的bug，碰上特别注重bug数量的开发真是揪心。

我们公司对于bug定期要做bug根因分析，这在一定程度上也是帮助测试更深入的了解产品因为每次bug单上开发写的产生原因和解决方案，真昰言简意赅。

2.思维定死不会向前多走一步

比如同一个账号添加之后删除再添加，同一份文档导入之后导出再导入密码修改成功之后洅修改，等等向前多走一步，就可能有意外收获

测试要记住：所有偶现的问题，都只是没有找到必现的规律！

不要以为偶现的问题沒有出现，就不提出来等上线后用户发现这个问题，你再说曾经遇到过只是没有提出来，那测试不背锅还有谁背？

提出问题但不解決测试就可以甩锅给产品，给开发完美！（这个真是从踩过的坑里得出血淋淋的教训）

这里有个好的习惯：遇到问题先截图！！！先錄视频！！！再分析原因，再提交给开发最怕偶现的问题口说无凭，又没有证据证明开发说你逗我呢？？

避免没有用例而进行的随機测试虽然随机测试能发现一些问题，但是它的特点是我们测试人员想到什么就测试什么这样就会导致有些功能点重复测试，而有的業务流程却没有覆盖到出现漏测，一旦上线后出现Bug就不好说了。

5.Bug的复现步骤描述必须要详细

这个其实算不上坑只是个人总结。之前提交过一个BugBug描述非常简单，在后期给开发复现的时候费了很大的劲儿，如果我们能在Bug描述中准确描述Bug的复现步骤，就可以明显缩短開发分析问题、定位问题的时间

6.不要 “动” 之前的业务逻辑，因为会 “牵一发而动全身”

要 “遵守” 之前的业务逻辑现有的业务逻辑盡量不要和之前的冲突，为啥呢

因为啊，一旦按照现在业务逻辑的话就得把之前的改了，改之前的业务逻辑会非常的复杂不仅开发需要改代码，而且我们测试要重新再测所以，不要动之前的业务逻辑