很多人选择这个行业是因为觉得测试不需要懂代码，这个要看职业定位，是想止步于月薪过万，还是想突破到2万、3万？如果是，就必须懂接口、懂自动化，这必然会涉及到代码。
如果真的看不懂代码，在后期实际的测试工作中会出现什么样的问题呢？
（1）如果测试人员看不懂开发代码，那么对bug的描述就会很模糊，不准确。开发人员不会明白如何重现这个bug，也不明白你到底想表达什么。即使是一些很表面的bug，也可能被测试人员认为是非常严重的问题。
（2）测试人员缺乏开发知识，向开发人员提交的不是bug的bug，或者提出的建议在开发过程中很难实现而无法提供合理的解决方案（开发人员容易实现的解决方案）。
（3）当发现 Bug 时，无法清楚准确地定位 Bug 来源，导致与开发人员的交涉过于频繁。时间宝贵，缺乏沟通有害，但沟通过多也容易导致问题。
因此，测试人员有必要具备开发知识。
（4）如果测试人员不懂开发知识，很容易被开发人员牵着鼻子走，在PK一些bug的时候，他们经常会哑口无言，因为开发人员只会胡编乱造故事，如果你不懂其中的玄机，那你就说不出话来。
（5）自动化测试和性能测试，包括项目管理，都需要对软件开发有很深的理解，如何设计一个好的自动化框架，好的性能测试用例，如何管理一个开发团队，都需要我们对软件开发有一定的了解。
因此，了解软件开发知识对于测试来说是非常必要的。
从这个问题出发发散性思考，发现对于软件测试确实存在一些误解，无论是行业内还是行业外。通过和身边做测试的朋友深入交流，我也总结整理了一些问题，所以就占用一些篇幅在这里说一下。如果真的想对这个行业有一个清晰的认识，那就要耐心看下去，不管你的技术有多好！
我整理了软件测试人员最容易犯的 28 个常见误区，照例把文章的思维导图放在了文章最后，需要原图可以私信或者留言。文章有 2000 多字，预计阅读需要 4 分钟，希望对大家有帮助。
1. 测试和开发永远是敌人
虽然测试与开发工作的性质相反，但它们的目的都是为了更好地开发项目。
我之前发起过一个倡议：讨论的时候不要用他们（开发人员）和我们（测试人员），而要统一用“我们”，因为开发人员和测试人员本来就是在一起的。如果测试人员能和开发人员成为朋友，你会发现工作会很顺利。在我所在的公司，测试人员和开发人员的关系很融洽，互相尊重，肯定每个人的工作能力和技术。
关键在于测试端的沟通，没有人能接受别人对自己杰作的批评，所以测试要帮助开发，让开发的“孩子”更健康，让开发“养孩子”不那么难；
测试是系统之父，开发是系统之母。妈妈费尽心机生下孩子，爸爸要打她，妈妈能答应吗？她发脾气的时候，爸爸要冷静下来哄哄她。妈妈不是傻子，也知道是非对错。如果妈妈真的糊涂了，那你还犹豫什么，打她吧（哈哈，开玩笑的，还是要以理服人）。
2.测试人员不需要了解软件开发知识
测试人员和开发人员沟通不畅的原因有以下几点：
（1）如果测试人员看不懂开发代码，那么对bug的描述就会很模糊，不准确。开发人员不会明白如何重现这个bug，也不明白你到底想表达什么。即使是一些很表面的bug，也可能被测试人员认为是非常严重的问题。
（2）测试人员缺乏开发知识，向开发人员提交的不是bug的bug，或者提出的建议在开发过程中很难实现而无法提供合理的解决方案（开发人员容易实现的解决方案）。
（3）当发现 Bug 时，无法清楚准确地定位 Bug 来源，导致与开发人员的交涉过于频繁。时间宝贵，缺乏沟通有害，但沟通过多也容易导致问题。
因此，测试人员有必要具备开发知识。
（4）如果测试人员不懂开发知识，很容易被开发人员牵着鼻子走，在PK一些bug的时候，他们经常会哑口无言，因为开发人员只会胡编乱造故事，如果你不懂其中的玄机，那你就说不出话来。
（5）自动化测试和性能测试，包括项目管理，都需要对软件开发有很深的理解，如何设计一个好的自动化框架，好的性能测试用例，如何管理一个开发团队，都需要我们对软件开发有一定的了解。
所以对于测试来说了解软件开发知识是十分必要的。
3.软件测试简单
软件测试的入门比开发容易，因为开发需要从一开始就掌握一门语言，而测试只需要在中后期掌握开发语言技术。测试更注重测试思路、方法，掌握测试工具。但到了中后期，软件测试所需的知识量会比开发人员大很多。测试后期需要掌握功能、性能、自动化、接口、协议、抓包、安全，包括移动端等一系列测试工具，技术难度不亚于开发技术。
4. 测试是为了发现错误
测试人员不仅需要发现bug，还要跟踪bug直到问题修复，确认缺陷并关闭，同时还要分析问题产生的原因，避免影响其他功能。
此外，测试还需要对软件进行性能测试、自动化测试、安全测试等一系列其他的测试手段，以发现系统的漏洞、性能瓶颈、服务器的抗压能力和稳定性等，这已经远远超出了查找Bug的范畴。
5.自动化测试太难
很多初学者觉得自动化测试比性能、功能测试难很多，其实掌握每个测试方向都不容易，自动化只是测试的一部分，功能测试想要做到极致并不容易，掌握性能测试还需要各种技术手段，而自动化只需要懂一些代码就行。难的不在于技术，而在于思路和实现操作。其实只要付出同样的努力，性能和自动化都可以做好。
6. 手动测试并不困难
手工测试是测试的基本技能，也是每个测试的必经步骤。但是真正能做好的人并不多，很多人觉得手工测试就是小菜一碟，我觉得这种说法是对测试的污蔑。手工测试的范围非常大，涉及到的内容非常多，比如数据准确性、表单值范围、逻辑分析、业务梳理、交互可用性、逆向思维、UI兼容性、cookie等等。单说业务逻辑、业务流程测试，有多少人测试的不全面、分析的不到位，导致发布上线之后出现严重问题。
7.软件测试重复且无聊
软件测试的范围很广，测试的手段和方法也各有不同。而且每个人对测试一个项目的想法都不一样。其实，认为重复性工作的人往往是技能较差的人，因为他们永远得不到成长。
真正擅长测试的人，会针对每个项目使用不同的测试方式，接口测试完再做功能测试，功能测试完再做自动化，上线前做性能测试，测试工具也可以随意换。对我来说，每个新项目的开始都是一个新的挑战，工作了8年，从来没有觉得无聊过。
8. 女生更适合做软件测试
很多人以为女生做测试员比较吃香，其实做测试员的女生比男生多，一个原因是女生天生比男生细心，其次很多人以为由于大部分开发人员都是男生，女生跟开发人员沟通起来更顺畅，这些其实都是一些客观现实的因素，但并不代表男生不适合做测试，根据统计，各大公司的男性测试经理比女性测试员多。
9.白盒测试是开发人员所做的：
一个合格的测试人员必须掌握白盒测试，了解其原理。无论什么测试，都要有测试人员的思维才能做好。白盒测试有自己的测试理论和技术，可以由专业的白盒测试人员来做，避免开发人员自己测试自己的程序。
10. 测试是为了清理开发中的烂摊子
大家应该知道，实际工作中，通常采用的是测试驱动开发，也就是由测试来带动项目的进度，开发人员的技术水平直接体现在bug的数量上，开发能力显然是测试出来的，驱动开发人员做修改的也是测试人员。如果测试不能带动开发，而是由开发来主导，那只有一个原因，那就是测试人员能力弱，不能胜任这个角色。
11.我不适合开发，所以我会做测试。
这种观点对于刚毕业的学生尤其适用。以前面试的时候，有人觉得我写代码不行，就转行做测试。也有人对开发也懂一点，但觉得自己做开发没什么优势，就主动把自己定位成测试员。其实测试需要的技能远比开发多，至少范围要广得多。做一个好的测试员比做开发人员要难得多。
12.机器自动化将取代手工测试
现在很多人都在说自动化测试会取代手工测试，首先有这种想法的人肯定没有真正理解自动化测试。自动化是为了回归测试，自动化脚本是手工编写或者录制的，只能覆盖大概的业务流程，无法覆盖软件的细节。详细的测试还是需要手工来做，否则自动化脚本维护的时间成本会大大增加，适得其反。而且新功能必须手工测试，只能用自动化来测试老功能。自动化是为了提高测试效率而存在的测试手段，而不是为了取代手工测试。
13. 使用测试工具意味着进行有效的测试
测试工具的目的是辅助测试工程师更高效的完成测试工作，测试能否有效完成，完全取决于使用工具的人的技术水平，水平强，测试结果就有参考价值，水平弱，测试结果就会一团糟。
建议大家还是以手工测试为主，工具只是为了提高测试效率，更好的完成测试工作，用工具测试并不一定有效果。
14.标准化软件测试增加了项目成本
软件测试流程如果不规范，结果肯定不会理想，规范、严谨的测试流程可以大大提高测试质量，不但不会提高项目成本，还能减少上线后项目的风险甚至损失。
一个不重视测试标准的公司是不会生产出在市场上具有极强竞争力的软件的，而其后果也不应该由测试人员来承担。
15. 期望通过短期内增加软件测试投入来快速达到零错误率
测试人员应该都知道一个道理：完整的测试是不可能做到的，即便是阿里巴巴，也无法做到零bug。软件测试贯穿整个项目生命周期，需要尽早介入测试，如果项目后期才加大测试力度，并不能有效提升测试质量，因为测试人员没有时间去了解软件的业务流程和接口逻辑。
16. 忽视参与需求阶段
软件测试必须从需求阶段开始，没有需求文档就无法衡量测试周期和测试范围，更无法编写测试计划和测试用例，因此忽视需求阶段的参与对于项目质量将带来灾难性的后果。
17. 忽略用户密集型和核心功能的回归测试
很多人以为，用户操作频繁的地方就不会出问题，但一个项目更新之后，很有可能之前的核心功能会受到影响，新的代码会损害旧的业务，所以回归测试一定不能忽视核心功能和用户操作密集的模块，而应该把重点放在回归上！
18. 忽视软件测试文档
软件测试归档是指软件测试记录是否得到有效保存和可检索。如果测试没有归档，测试报告就无法审核，测试结果也就没有依据。因此，测试归档是一个必要的环节，不容忽视。
19.软件开发完成后进行软件测试
软件测试贯穿整个项目生命周期，在需求阶段就必须介入，在单元测试完成后进行集成测试也就是接口测试，可以发现80%的软件缺陷，如果等到开发完成才介入测试，那么项目发布上线的时间就会大大延长，另外修复很多问题的成本也会大大增加。
20. 如果软件发布时发现质量问题，那是测试人员的错。
很多人以为测试通过后，当用户使用产品时才发现 Bug，一定是测试人员没有彻底测试导致的。我在之前的工作中多次遇到过此类问题，但测试人员却坚称该功能没有测试过，不存在此类问题。后来经过我自己的争论，终于找到了问题的原因，原来是开发人员的疏忽，导致封包时没有保存最新的代码。
首先，如果以后再遇到这样的情况，不要着急慌张，首先要确定这个功能是否经过测试，是否通过了测试。如果没有经过测试，那么毫无疑问就是测试惹的祸。如果测试通过了但是还是有问题，那么很有可能是开发人员在关闭版本的时候没有保存最新的代码。或者是开发人员在发布最终版本的时候擅自修改了部分代码。
21. 项目紧张时少做测试，时间充裕时多做测试
当项目测试时间紧张时，很容易出现测试不完整，导致发布后出现问题。正常的处理方式是使用敏捷测试方法。测试范围一定不能缩小。测试用例可以忽略表单值字段的用例，专注于编写过程测试用例。并且开发完一个模块后，一次测试一个模块，这样可以大大加快测试效率。我喜欢使用敏捷测试方法，这样不仅可以减少测试时间，还可以保证质量。记住敏捷测试一定要有明确的人员分工。避免重复测试造成的效率损失。
22.软件测试没有前途。只有程序员才是软件专家。
相信很多人都觉得测试人员不如开发人员，这确实是目前的市场现状，很多测试技术确实不如开发强。但是从未来来看，我觉得测试比开发更有潜力，测试的开发形式多样，涉及面广，薪资不亚于开发人员，真正的全栈测试工程师在技术上绝对不会输给开发人员，甚至有可能超越他们。在工作中，经常会碰到开发人员来找我请教性能技术、自动化技术等问题。
23. 软件测试是为了确保软件运行无任何问题
软件测试不仅要保证软件的无故障运行，还要保证软件的可用性、健壮性、稳定性、安全性、兼容性、用户体验等一系列因素，因此单纯以无故障运行为目标显得有些肤浅。
24. 选择用户的环境作为软件测试环境
软件测试分为“测试环境”、“HA环境”（准线上环境）、“线上环境”三种环境。用户环境指的是第三种“线上环境”，测试的重点应该放在“测试环境”和“HA环境”上。在用户环境中不能随意提交数据进行测试，此环境只会在最终的beta验收阶段用于测试。
25.开发人员更适合软件测试
我们经常听到这样的问题：“软件开发人员为什么不测试自己开发的软件？”其实，软件开发人员测试自己的软件就像学生在完成考试后评估自己的成绩一样，这种做法毫无意义。
（1）开发人员对自己编写的代码具有主观认同感
人们常常对自己的错误视而不见或拒绝承认。同样，在软件开发领域，程序员对待自己开发的应用程序就像对待自己的孩子一样，拒绝承认孩子有什么问题。这就是为什么软件开发人员很难发现和纠正自己的错误。
（2）开发人员对软件过于乐观
开发人员的目标是完美地展现软件所需的功能，当程序的功能正常运行时，他们会自我感觉良好，因为他们的主要目标就是“功能”二字。然而测试人员的想法则不同，测试人员通常会从不同的角度切入软件，打破程序员的习惯性思维方式，通过各种测试用例触发软件中潜在的缺陷。
26. Bug 越多，测试越有效
测试 Bug 的数量并不能反映测试的有效性，而是开发者的技术水平。测试 Bug 越多，需要修改的代码就越多。代码修改得越多，就越有可能出现其他问题，甚至后期会出现更多的 Bug。原本没有问题的模块也会开始出现问题。测试的有效性不能由发现的 Bug 数量来决定，而应该由问题的隐蔽性或严重性来决定。
27. 注重测试执行，忽视测试设计
测试的执行必须按照事先设计好的方法进行，测试方法就是测试用例，如果不设计测试用例，直接进行测试执行阶段，再厉害的测试工程师也无法保证测试的全面性。相信大家都知道编写测试用例的原则就是100%覆盖需求，由此可见测试设计阶段的重要性。
28.测试是为了证明软件的正确性
测试不仅要证明软件的正确性，还要证明软件是错误的。测试人员不能只考虑正确的过程，逆向思维测试和反逻辑测试往往犯的错误最多，违反常规的测试才是最有效的测试。所以，测试不是要证明软件的正确性，相反要证明软件的错误性。
如果觉得有用的话，可以把文章和图片保存下来以后用！
如果上传的图片不清晰，需要原图的话，记得联系我！
最后放上一颗彩蛋。
软件测试视频及教程合集，链接：密码：hlcy
如果你路过，请点赞！
谢谢猫哥！
