记住这些测试人员常踩的坑，别再往里跳了 | 干货

在笔者做软件测试的几年里，项目做了无数个，踩过的坑也越积越多。部分原因是前期业务不熟练造成的，还有一部分原因则是因为经验不足，粗心大意。

因此，关于测试人员常踩的坑小编特地总结了以下几点：

1.尽量避免进行随机测试

在非特殊情形下，应尽量避免在没有用例而进行的随机测试。虽然有时候随机测试也能发现一些问题，但是随机测试是比较随意的，既不严谨，效率也不高。还可能会导致有的功能点出现重复测试的情况，而有的业务流程却没有覆盖到，出现漏测，一旦上线后出现bug，后果就会很糟糕，实在是有点得不偿失。

2.不重视偶发性的问题

作为一个测试人员，需要牢牢记住一条：所有偶发的问题，都只是暂时没有找到发生的规律！

别以为偶发的问题，出现次数很少，就没有影响可以忽略，如果等到用户发现这个问题，就不是小问题了，那责任肯定是测试的。

建议遇到问题时先截好图或者录个视频，保留好证据，再分析原因，然后把问题提交给开发。如果遇到偶发的问题没有及时保留证据，那很难说服开发去重视这个问题。

3.bug的复现步骤描述尽量要详细

小编之前提交过一个bug，因为对bug的复现描述比较简单，在后期给开发复现的时候，耗费了许多精力。如果能在bug描述中，准确描述bug的复现步骤，那么在后续的复现过程中就可以明显缩短开发分析问题、定位问题的时间，也能大大节约自己的时间。

4.自认为对业务逻辑非常了解，实际上只是流于表面

工作一定时间，产品迭代跟的久了，功能上闭着眼睛都能说清楚就容易飘飘然，自以为自己已经很了解，而实际上可能连这个功能使用的协议，调用的接口都说不清楚，所以看到的问题也容易浮于表面，看不到本质。

导致的不良影响：

（1）修改bug后对影响范围评估不够准确。

（2）容易提相同的bug，与开发的沟通会增添许多麻烦。

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

要 “遵守” 之前的业务逻辑，现有的业务逻辑尽量不要和之前的冲突。

在实行了现有的业务逻辑之后，也不要更改之前的业务逻辑。因为更改过程会非常的复杂，不仅开发需要改代码，而且测试人员也需要重新再进行测试，所以，尽量不要动之前的业务逻辑。

6.认为bug越多测试效果越好

测试出的bug数量并不能说明测试的有效性，反而说明了开发人员的技术水平。bug数量越多则意味着需要修改的代码就越多，修改的越多，越可能引发其他问题，甚至最后可能会导致bug越来越多，原本没有问题的模块也开始出现问题。测试的有效性不该是以发现bug的数量来定性的，而应该是根据问题的隐蔽性或严重性来定性。

以上是小编总结的一些测试人员容易踩的坑，仅供参考，大家有则改之，无则加勉！更多软件测试资讯可关注本账号，持续更新！

另外，欢迎加入软件测试技术交流群 313782132 ~进群可领取软件测试资料以及群内测试大牛解惑！

测试工程师职业发展路线图

功能测试 ——接口测试–自动化测试 --测试开发–测试架构师

加油吧，测试人！如果你需要提升规划，那就行动吧，在路上总比在起点观望的要好。事必有法，然后有成。

资源不错就给个推荐吧~