测试员容易陷入的9大误区

1、把原型设计、UI效果图作为软件测试的标准，只要软件与其保持一致就没有问题

近几年，把原型设计、UI效果图作为测试的唯二参考标准越来越普遍，但实际上原型、UI效果图一样存在问题，也是静态测试的重要内容。

静态测试，大家忘了吗？静态地检查程序代码、界面或文档中可能存在的错误，借以发现编写的程序的不足之处，减少错误出现的概率。

2、既然是敏捷开发模式，那测试用例也不用写，或者随便写点应付了事

测试用例必须要有，可以不是标准式的用例（如必须包含 标题、前置条件、操作、期望结果、测试数据等），可以用思维导图、测试检查点代替，需求覆盖率要满足测试要求。

3、自动化测试一定能提高测试效率

自动化测试提高测试效率是有前提的，如项目周期长，迭代次数多，已完成的功能模块较稳定。否则，投入大量的人力在维护自动化脚本上，得不偿失！

4、搭建测试环境不是测试员必须会的技能

搭建测试环境还真就是测试员必须会的技能，也许有docker这样的技术让测试员忘记了这一点，但不要去否认。搭建测试环境，不仅仅是考验我们的linux、SQL等指令，更让我们清楚里面的配置参数，日志路径等，不管后续做性能测试，还是定位bug，都非常有帮助，且“部署测试”本就是测试的内容之一。

5、体验性问题不是bug，不用记录bug

体验性问题也是bug，一定要记录。不要忘记测试的初衷，从"用户的角度"去发掘软件中的问题，这里的问题，可以是代码问题、也可以是体验问题。

6、产品经理（或者项目经理）说XXX问题不用管，就不用记录bug

除非我们理解有问题，否则只要不能否认它是问题，没有人能阻止测试记录bug。至于是否被修复，那才是产品经理（或项目经理）可以决定的。

7、bug填写规范？只要开发能看懂就行了，其他无所谓

bug描述应该简洁、明了。这里的简洁是文字上的精炼，明了是通过文字、截图信息让开发能快速复现bug。你认为开发能看懂，说不定开发每次看懂你的bug都得多花几分钟，从而拉低了大家整体的工作效率。

8、测试用例就是我写的，所以测试时没必要看着执行

虽然用例是你写的，但人都是健忘的，执行没执行，可能自己有时都搞不清楚了。所以，不管采用边看边执行，还是执行完后做标记的方式，都得保证用例真的被执行完了。

9、测试结束，让写测试报告，那结论只有：测试通过

测试结论是项目决策人决定软件是否发布上线的重要参考依据。测试结论应该客观、真实，否则失真的信息会让项目决策人做出错误的决定，无法及时规避风险，那这锅，测试得背。所以，测试结论可以是通过，也可以是不通过！

总之，在工作中，我们时常被各种错误的风向带偏，陷入各种各样的误区，不妨定期抽出时间做个梳理——哪些是我们随波逐流而应该坚持的。

最后感谢每一个认真阅读我文章的人，下面这个网盘链接也是我费了几天时间整理的非常全面的，希望也能帮助到有需要的你！

这些资料，对于想转行做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助……

如果你不想一个人野蛮生长，找不到系统的资料，问题得不到帮助，坚持几天便放弃的感受的话，可以点击下方小卡片加入我们群，大家可以一起讨论交流，里面会有各种软件测试资料和技术交流。

敲字不易，如果此文章对你有帮助的话，点个赞收个藏来个关注，给作者一个鼓励。也方便你下次能够快速查找。

自学推荐B站视频：

零基础转行软件测试：自学完软件测试，拿到了字节的测试岗offer，堪称B站最好的视频！

自动化测试进阶：已上岸华为，涨薪20K，2022最适合自学的python自动化测试教程，自己花16800买的,无偿分享