一.前言：
“最占时间的是测试阶段。”你曾经听到过这样的说法吗?这是大多数非测试人员在从事项目工作时的表现，他们不了解软件测试有多强大。
软件测试是一门艺术，不是每个软件专家都能精通，然而很多人都低估了它。本文就将澄清技术界盛行的关于软件测试的误解。今天我们来盘点软件测试的误解，至今为止，可能很多人都软件测试的认识都停留在表面，今天基于我的经验，一菲给大家总结了软件测试的几个常见误解，解开这些误解，你会发现新的世界！
二.正文：
1.做测试简单、轻松，点点点就行了，是个人都能做？
作为一名软件测试工程师，我在和很多开发的同事聊天的时候，他们很多人都持有这样的想法。虽然我不知道为什么会产生这样的想法，但是我想说的是，测试并不是像他们说的那样简单轻松，只是点点点。
当然不排除有些公司对测试不够重视，所以就可能会只要求测试在UI层上，只要验证UI层没有问题就行了。但这样的测试流程，根本就不可能控制好软件的质量。
所以这才导致了在国内的测试行业里，开发对测试产生的误解。
2.测试人员不需要代码能力？
这个问题不是绝对的，具体还要看测试的工作。有些工作可能只是看看视频的画质和流畅度，看上去确实不需要什么代码能力。
但是考虑到自动化测试，测试工具都是需要用代码堆起来的。即便是有现成的测试工具，积累测试用例也是需要一定的代码能力。当然，如果测试人员本身对硬件代码有更深的理解，绝对会体现在测试质量上，对你未来的成长也有很大帮助。
3.产品出现问题，说明没有很好地进行测试？
其实有很多不太懂测试的人就会产生一种误解，认为要测试的干嘛呢？既然我们花了钱用你，就应该保证我们的产品没有缺陷啊！
对于这种想法，我只能说不太理智，测试并没有直接编写产生bug的代码。所以产品出现bug，是整个研发过程中整体流程的作用后果，而不应该据此作为评判测试工作好坏的标准。测试只是提高产品质量，而并非保证产品质量。
在这里插入图片描述
4.测试应该在开发环境后期进行？
在传统研发模式中，研发后期会有专门的测试阶段，包括集成测试、系统测试、验收测试等。
所以大家可能会形成一个误解，认为测试是在开发阶段后期进行的。但其实不然，在现代研发模式下，更加强调测试工作的迁移。
实则测试是贯穿在研发生命周期全流程的一项活动，并不是某一个独立阶段。测试越早介入对产品最终质量就更能产生好的效果。
5.测试是枯燥乏味，缺乏创造力的工作？
一个好的测试是需要经过计划，设计到执行。为了设计好的测试用例，你需要充分发挥你的想象力。对于一个缺乏想象力的测试人员来说，你可以胜任测试执行的工作，但是却无法设计出高质量的测试用例。其实无论是从事开发还是测试，都应当从工作中去寻找乐趣，不断地改进和完善自己。
6.测试即QA(质量保证)
在很多企业，往往会混淆QA和Testing两种角色，认为Testing就是QA（Quality Assurence）。应该说两者有相关性，或者说QA > testing。 前面说过，质量不会由测试来决定，质量更多是从需求、设计、开发环节就确定的。所以QA工作除了包含测试外，更主要的是流程改进，通过流程关键节点的管控来保证质量水准。
QA涵盖的范围比测试更大，二者侧重点也不同。QA更关注软件研发全流程的质量管控，测试则更关注将当前软件中的缺陷暴露出来。二者的关注点不同，所需要的技能也不相同。不能简单地把测试和QA工作划等号。
7.测试人员不会成为项目经理。
许多人认为，测试人员缺乏管理方面的专业培养。但这两者本就是互不干涉的。经理需要掌握人员管理、成本管理、时间管理等技能。无论是测试人员、开发人员，还是其他任何技术人员，这些技能都与他们的工作无关。
项目管理技能需要单独培养，并且世界上无论从事哪种技术，属于哪个流派的人员都可以进行培养。因此，作为一名测试人员，对项目管理的追求并不会受到鼓励或阻止。大家还记得那句话吗，只要你想努力，全世界都会为你让路，不怕！在这里插入图片描述
8.向开发主管进行工作汇报是测试人员职业生涯的阻碍。”
理想情况下应有独立的垂直部门，开发主管和QA主管都应向项目经理进行工作汇报。然而有时候可能会出现测试团队和开发团队有同一个开发主管的情况，这时候就必须向一个并不懂得如何进行深入测试的人汇报工作。
但其实，只要把工作做好，并耐心地帮助领导完成评估实践，就不会有什么差错，也不会对职业生涯产生长期的负面影响。
9.编码技能差的人才会从事软件测试。
大多数情况下，测试还包括编码。测试人员需编写复杂的结构化查询语言(SDL)来验证数据，或者在进行提取转换加载(ETL)测试/数据验证时创建测试数据。进行迁移测试时，测试人员需将编写的代码从一个数据库转换到另一个数据库。进行自动化测试时，测试人员需用Java、Perl或其他编程语言编写脚本。
因此，这个观点根本站不住脚。
10.软件测试就是随意点击。
人们通常认为，测试就是在用户界面(UI)随意点击，然后在Excel或其他文档中记录细节。事实上，测试人员会执行非常明确的测试步骤，以确保UI/应用在极特殊情况下也能够正常工作。因此，视域才是最重要的。
用户对操作限制没有概念，测试人员也一样。因此探索用户界面很重要，这种探索可能看起来像很多随意的点击。只有测试人员知道这种疯狂的操作是有方法步骤的。
11.测试就是文件记录，或者说填充Excel表格。
首先，需要强调一下：每个参与项目的人都必须进行文件记录。一份准确和完整的文件可以为项目提供基本证明和历史证明。
然而，对于测试人员来说，文件记录尤为重要，因为我们创造的产物不是一个程序或模块，而是通过人工呈现的一种质量保证。Microsoft Office套件是大多数团队的首选，但如果要做得更好，就请使用测试管理软件。
12.做测试员赚不了多少钱。
如果这种说法用在测试人员身上，那就大错特错了。这种思想可能需要转变一下。即便如此，薪酬取决于很多因素，把测试员这一身份作为薪酬较低的唯一原因是错误的。
在这里插入图片描述
在这里推荐一个软件测试及交流群，qq:642830685,群中inghui不定期的分享软件测试资源，测试面试题以及行业资讯。
13.测试员得不到赏识。
软件测试有时像是一种“吃力不讨好”的工作，这取决于公司文化对团队的重视程度。试着保持积极的心态，并用工作证明一切。我认同以下说法：如果公司和客户欣赏QA团队，事情会好办很多。但如果他们不欣赏QA团队，我们也不必低估自己。
欢迎关注微信公众号：程序媛一菲
1.免费领取一份216页软件测试工程师面试宝典文档资料。
2.软件测试学习路线以及相对应的视频学习教程免费分享！
14.测试员拖慢项目交付进度。
不管是否与开发团队同时开始工作，测试人员都必须等到开发彻底完成后才能开始测试。这就给人一种粗略的印象，即测试一次又一次地拖慢项目进度。
如果在计算机上对测试周期进行预先计划，就不会出现这个问题。因此，测试不是使项目延迟的原因，不正确的计划和不合理的预期才是罪魁祸首。
15.自动化测试人员不必担心手工测试。
没有什么比这种说法更令人难以置信了。
自动化测试也是测试，不同之处在于测试的方式。不要忘了，自动化测试一直延续或遵循着手工测试的流程。不是所有的项目都是自动化项目，同样地，同时掌握手工测试和自动化测试的测试人员也是很罕见的。
手工测试是测试员需要培养的一项基本技能，它是基础。自动化测试很厉害，它是质量控制领域最像魔法的东西。但在软件测试领域中，我们并不愿意去评价它们孰优孰劣。
自动化测试人员可以在一些项目中进行手工测试，而手工测试人员也可以在某些情况下进行自动化测试。
16.测试主管不参与测试。
事实上，在行业标准里，测试主管在协调方面的工作仅为10%，他们也是QA团队的一员，需负责协助测试活动。当然，还有其他任务。
因此，QA主管必须把一小部分精力花在测试活动上。要想成为一名测试员，就必须准备好在以后的职业生涯中完成作为一名普通QA团队成员应执行的所有任务，否则是时候考虑换个领域了。
17.测试员质疑一切，在IT行业以‘吹毛求疵’闻名。”
怀疑一切的人的生活是最难的。如果我们真的怀疑一切，我们甚至会质疑软件的存在、运用和效率，这意味着在相信产品毫无用处的情况下，我们依然在为它工作。
你觉得这种看法正确吗?我们真的可以在一个软件系统上花费大量的时间，而又认为它毫无用处吗?与普遍的观点相反，测试人员相信软件的性能、效率、生产力和用途，并且帮助它在实际运用中取得成功。
但是，测试人员要确保软件处于最佳状态。在测试时要记住，产品是优秀的，我们必须识别并消除任何可能对这个优秀产品产生负面影响的因素。我们真的认可它，是它的忠实粉丝。
18.测试工程师的工作是破坏软件
“测试工程师的工作就是破坏软件”是一个常见的误解。作为程序员十大金句之首的“在我机器上是好的”往往来源于这一误解。测试人员好像有什么魔力，能够把正确运行的程序在测试环境上搞得不能工作。 但是这不是测试工程师破坏了软件，测试工程师并不能在软件中创造某些bug。他们只是做了些程序员没有考虑到的某些操作，比如在测试环境上，没有执行相关的依赖操作。程序员在自测时很多情况下会默认某些场景，或者是开发的新功能而没有考虑到对原有功能的影响。这也是为什么我们不推荐完全由开发者本人完成功能的测试。
而软件bug只会来源于产生它们的代码，测试工程师不实现代码，所以他们并不能破坏软件，他们只是发现了软件不工作的触发条件并且报告了出来。 “测试工程师对软件进行破坏”往往会导致团队开发和测试的对立情绪，甚至将软件没有满足客户要求和大量因解决问题的额外工作量归咎于测试工程师的劳动。这是非常不利于团队和产品成功的。
19自动化测试可以代替测试
这个误解在现如今几乎已经成为信条了。确实，理论上，所有的测试用例都可以通过技术手段来实现并自动执行，但是正如我们在前面提过的，测试并不是测试用例+测试执行的叠加。测试还包括大量的创造性的活动。所以自动化测试代替测试是个伪命题（除非有朝一日，人工智能发展到能够打败人类的创造性。那时可能整个IT行业都不需要人力劳动了） 除此之外，即使自动化测试能把所有的测试用例都实现通过机器执行，也不意味着应该这么做。因为自动化测试本身也是一项投资，有大量的投入在其中。很多测试场景通过自动化测试可以产生很大的价值，比如大量重复性地验证。但是也有很多场景，不需要通过自动化的投入来实现，比如很多一次性的功能验证，还有依赖人进行主观判断的功能等。
测试中的检查工作，很大一部分可以通过自动化测试代替，但是测试工作不会被自动化测试代替。即使可以实现自动化测试的场景，我们也要通过ROI的衡量（如测试金字塔）来确定实施自动化测试的必要性
20.测试就是写测试用例，然后执行
测试就是把需求转换成测试用例，然后在软件中执行这些用例。这是一个在瀑布研发模式时代非常广泛的一个错误看法，然而在如今敏捷研发模式时代，也换了个模样，但是依然存在类似的认知。 在瀑布研发模式下，很多测试工作被严格地要求有非常完备地测试设计文档，然后依照这些文档进行覆盖式地执行验证。可能高级测试工程师负责编写，然后初级工程师来执行。这更多是工厂式的质量管理经验在软件行业的错误应用。 即使在敏捷研发模式得到大量应用的今天，我们还是可以看到类似认知的变种，比如测试由开发人员做好单元测试的充分覆盖就可以了。这其实依然是把测试工作文档化，只是这个文档变成了单元测试代码，执行变成了计算机。本质依然是测试=测试设计+执行
输出测试设计文档，并不是真的那么重要。测试中，更重要的永远是那些创造性的东西。提问、研究、建模、观察、推理、试验等。文档是这些活动的一个输出形式，我们不应该把测试简单看作是这些文档的机械生成和执行
好了，以上就是一菲总结说的关于软件测试的20个误解，希望能够给需要的小伙伴们带来帮助喔，如果大家有补充的内容欢迎私信我，我们可以做出史上最全软件测试破谣葵花宝典。