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、测试结束，让写测试报告，那结论只有：测试通过
测试结论是项目决策人决定软件是否发布上线的重要参考依据。测试结论应该客观、真实，否则失真的信息会让项目决策人做出错误的决定，无法及时规避风险，那这锅，测试得背。所以，测试结论可以是通过，也可以是不通过！
总之，在工作中，我们时常被各种错误的风向带偏，陷入各种各样的误区，不妨定期抽出时间做个梳理——哪些是我们随波逐流而应该坚持的。
-- End --
文末寄语：驾驭命运的舵是奋斗。不抱有一丝幻想，不放弃一点机会，不停止一日努力。