记住这些测试人员常踩的坑，别再往里跳了_测试人员通常会遇到那些坑-CSDN博客

本文链接：https://blog.csdn.net/weixin_50271247/article/details/108712963

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

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

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

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

在这里插入图片描述

2.不重视偶发性的问题

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

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

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

在这里插入图片描述

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

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

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

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

在这里插入图片描述
导致的不良影响：

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

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

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

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

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

在这里插入图片描述

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

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

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

在这里插入图片描述
上面是我收集的一些视频资源，在这个过程中帮到了我很多。如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以加入我们扣扣群【313782132 】，里面有各种软件测试资源和技术讨论。

在这里插入图片描述
当然还有面试，面试一般分为技术面和hr面，形式的话很少有群面，少部分企业可能会有一个交叉面，不过总的来说，技术面基本就是考察你的专业技术水平的，hr面的话主要是看这个人的综合素质以及家庭情况符不符合公司要求，一般来讲，技术的话只要通过了技术面hr面基本上是没有问题（也有少数企业hr面会刷很多人）
我们主要来说技术面，技术面的话主要是考察专业技术知识和水平，上面也是我整理好的精选面试题。