当您开始作为自动化测试员的旅程时，肯定会发生错误。 如果您不参加Selenium自动化测试脚本的深入研究而参加自动化网站测试，也可能会发生这种情况。 虽然可以从错误中学习，但最好还是从他人那里学习，以防患于未然。
在处理自动化测试项目时，您承担着巨大的责任。 您不正确的签收可能会导致生产中断，并最终导致客户和声誉损失。 我去过接收端几次，这不是一个愉快的经历。 因此，作为一个自动化测试人员，我现在要确保避免这14个错误，我将与您分享这些错误。 请确保对它们进行记录，以免出现红脸。
必要时自动化
当我承担了为我的Web应用程序自动化Selenium测试脚本的责任时，我感到非常高兴，因为这是我对团队的第一份工作。 第一印象总是至关重要的，我希望我的完美。 我被要求自动化Web应用程序的一个模块，我对此感到很自在。 但是，我想做更多的自动化工作，因此我从自己的理解中选出了另一个模块。 我碰到了死胡同，却没有自动化。 现在，尝试自动化新模块没有错。 我在没有咨询我的前辈的情况下试图自动化该模块是错误的。 原来，该模块并非旨在实现自动化，因为集成系统可能会导致多个误报和误报。 我花了我的时间在那个永远不会自动化的模块上。 我什至最终忽略了我的其余职责。 这么多给人很好的印象吧？
我已经看到许多新的自动化测试仪会发生这种情况。 毕竟，好奇心可以带您到位。 学习自动化测试时，您可以尝试在每个项目中引入自动化。 这不是必需的。 您也许可以使某件事自动化，但这是否足够可行？ 众所周知，自动化可以节省时间和精力，但回答以下问题绝对重要：为什么需要使该项目自动化？ 如果您得到务实的答案，则只有向自动化显示绿灯。 避免作为自动化测试人员的这一错误至关重要。
定义范围
定义要执行的测试范围是非常必要的。 当我是一名新的自动化测试人员时，我尝试测试所有内容并使每个测试自动化。 问题是，尽管您可以成功地自动化所有测试，但它既不实用也不可行。 首先，代码的很多部分不需要经常测试，我们可能需要花费大量时间来开发仅用于这些代码的框架或脚本。
例如，在使用Selenium测试网站时，自动化网站的每个元素并在其上运行脚本是没有用的。 这不值得花费时间和金钱。 其次，使一切自动化将增加测试自动化百分比，这会让您感到自己做得非常出色，这是不对的。 在纸上看起来可能不错，但这不是必需的。 定义测试范围，并仅考虑可行的代码，以提供及时的实际价值。
明智地选择自动化测试工具
作为自动化测试人员，另一个最常见的错误是没有选择正确的自动化测试工具。 一个项目包含着重于不同测试目标的许多组件。 这些目标应分为不同的工具，可以帮助更有效地实现该目标。 例如，如果要测试网站的API，则最好选择Postman，但如果要确保在不同浏览器中完美呈现Web应用程序，则在线Selenium Grid是进行自动跨浏览器测试的最佳选择。
这种情况的直接方法是不要跳到软件上，然后尝试通过该软件解决问题。 首先，找到问题，然后找到合适的工具。
与研究员测试人员协调良好
测试团队中有很多人。 所有这些人都具备不同的技能。 例如，某人擅长业务测试，而某人擅长功能测试。 但是，这没有理由不与他们讨论任务的进度。 协调是加快产品交付的关键。 确认谁在从事什么工作，他们在使用哪些工具，他们对哪种用于自动化测试的编程语言感到满意。 为什么？
这绝对可以帮助您对Selenium自动化测试脚本进行故障排除。 因此，万一事情往南走，您将知道在哪里敲门，或者更确切地说是谁在敲门！
了解您的团队还可以帮助您在需要时进行管理。 正如最后一点所讨论的，一个项目可能需要使用不同的工具来实现合并的目标，最好让测试人员使用他愿意使用的工具。
重要的是不要强迫任何人随意使用任何任务和工具。 为此，您始终可以在开始测试过程之前进行空运行。 如果没有适合的西装，则需要进行相应的培训。
检查投资回报率
仅将测试人员的薪水作为与整个测试过程相关的成本，这是一个非常菜鸟的错误。 在最初的日子里，我做过同样的事情。 显然，事实并非如此。 例如，让我们考虑您要对网站执行跨浏览器测试 。 测试人员的薪水显然是成本的一部分。 如果您的团队不知道这种类型的测试或与之相关的任何工具，那么您需要通过培训他们来提高他们的技能。 这产生了额外的费用。 此外，您需要具有正确的自动化工具或框架来执行自动化浏览器测试 。
现在，您可能正在考虑选择像Selenium这样的开源框架。 这样，您可能不必支付更多，对吗？ 嗯，就像其他所有东西一样，硒不是完美的。 Selenium自动化测试面临一些挑战。 主要问题在于可伸缩性。 您可能知道，Selenium Grid将帮助您执行并行测试，这很棒。 但是，您只能通过提供Selenium Grid的计算机中安装的浏览器来测试您的网站。 现在，您可能必须跨移动和台式设备的不同操作系统测试数百种浏览器和浏览器版本。 自行执行此操作将非常耗时且昂贵。 选择设备实验室将伤您的口袋。 所以，你可以做什么？
您可以寻找在线Selenium Grid，例如LambdaTest。 我们的Selenium Grid可帮助您跨2000多种真实的浏览器和真实的操作系统测试您的网站。 最好的部分？ 一切都在云上，这意味着您可以摆脱维护内部基础结构的麻烦，而选择使用托管在云上的分布式计算机。 您不仅会节省时间，而且会节省金钱。
这只是一个例子。 同样，在执行Web应用程序自动化测试的过程中还会遇到其他投资。 但是，它们一定会出现。 因此，应仔细考虑测试成本，同时牢记您将获得的这些投资的回报。 如果回报较少，则需要更改策略并重新计算。 但最后，您需要在整个测试过程中获得良好的投资回报率。
并非每个开源都将成为黄金
开源工具每天都在流行。 他们在用户，支持和社区方面确实很棒。 开源软件的最好之处在于，全球有大量的开发人员参与其中，从而可以更快地进行改进。 但是，这并不意味着您仅选择或搜索开源工具。 开源工具的开发者也需要像其他人一样的钱。 因此，更多时候您可能找不到带有功能的开源软件，即使很少有开源提供大量功能，也无法告知需要多长时间！ 软件错误可能会弹出，而社区支持程度较低的开放源代码工具将很难找到这些错误的修复程序。 您可能最终意识到，这是您作为自动化测试员的大错误。
因此，始终建议将具有大型社区支持的开源框架（例如Selenium）用于Web应用程序自动化测试。 因此，在开始之前，不要只将目光投向开源类别。 如果开源可以满足您的要求，那很好，但如果不满足，那么您就需要拥有合适的软件。
将无代码自动化视为垫脚石
尽管无代码自动化测试工具的学习范围狭窄且易于上手，但它们无法帮助您建立自动化测试人员档案所需的相关技能。 作为一个初学者，他们很好地帮助您入门，但是随着您在测试自动化事业中的发展，您会意识到它们并没有您期望的那样有帮助。 而且，如果您决定以无代码自动化工具的智慧参加一次自动化测试人员资料的采访，或者如果您认为仅凭无代码自动化就可以使复杂的Web应用程序自动化，那么您将需要花费大量时间来破解它。
在这些类型的工具中，可靠性是另一个大问题。 最终，您需要学习代码以调试自动化测试套件执行出错的地方。 另外，如果您要处理一个复杂的网站，那么您将找不到无代码的自动化测试工具，它没有您想要的那么灵活。 建议不要逃避代码，而是要熟练地学习它。 最重要的是，这将是您简历的魅力。 因此，请确保避免作为自动化测试人员的常见错误。
维护测试设计
测试设计是将一般测试目标转换为实际测试用例和条件的过程。 作为开发人员，我们倾向于认为既然测试需要编码，为什么开发人员不能完成这项工作？ 好吧，如果真是那样，那么测试人员将不存在。
作为一个初学者，我不了解测试设计的重要性，这可能是我作为自动化测试员的最大错误。 随时进行任何测试都是荒谬的想法。 为了有效地进行测试，测试人员需要设计测试，然后对它们进行编码。 设计测试有助于创建有意义的测试，并使整个测试过程非常有效。
避免出现假阳性和假阴性结果
当测试结果错误地指示测试通过但实际上没有通过时，则为假阳性。 反之亦然。 在测试人员中盲目相信测试报告是一个非常普遍的错误。 这也可以称为您正在测试的元素的非验证。 例如，假设您正在使用使用不同测试用例编写的测试脚本来测试登录页面。 测试报告表明登录已通过。 在这种情况下，您需要验证登录是否成功。 作为自动化测试人员，请不要因总是误认和误判自己而犯错。
专注于代码可重用性
一个测试用例并不是它所应用的代码所独有的。 在项目中，会出现许多类似的组件，并且它们需要类似的测试设计和测试套件。 例如，在使用Selenium进行跨浏览器测试时，我们发现网页的四个元素都是输入字段，并且需要类似的测试用例。 在这里，您可以通过仅针对第一个元素编写测试来复制粘贴代码。 尽管这将提供预期的结果，但问题在于，将来开发人员可能会以某种方式更改元素。 现在，要更改测试用例，您需要更改编写的每个测试套件中的代码。 全部时间都浪费在查找和修改这些测试代码上。 我犯了这个错误，我可以看出，测试时这变得非常难看。
为避免这种情况，您应始终专注于代码的可重用性。 而不是一次又一次地粘贴代码，您应该构造一个带有适当参数的函数，并在每个元素上调用此函数。 这样，如果将来有任何更改，您只需要修改功能就可以了。
100％自动化是神话
不要迷恋这个神话，因为这将是一个自动化测试员的严重错误。 作为测试自动化领域的新手，我很高兴为项目带来自动化。 这导致我犯了一个错误，认为自动化测试可以完全替代手动测试过程。 随着时间的推移，我知道这是不可能的。 完全用自动化测试（100％）代替手动测试是一个神话。 它永远不可能实现。 作为该领域的初学者，请勿尝试实现此目标。 仅在必要时自动化，并且仅在那些需要自动化的事物上自动化。
遵循地面向上的方法
在测试时，您会遇到不同类型的问题。 您将需要设定目标并对这些问题进行分类。 全面的方法意味着使用较小的模块而不是较大的模块开始自动化测试。
作为自动化测试仪，最大的错误之一就是要使用更大，更复杂的模块开始自动化。 不要那样做！ 您缺乏对每个用户交互中涉及的入站和出站流程的了解。 您甚至可能不具备处理棘手的测试用例的能力，并且最终可能会浪费大量时间而无所适从。 因此，从小处着手，并从根本上增加自动化测试的覆盖范围。
参与探索性测试
作为自动化测试人员，常见的错误之一就是不将探索性测试纳入您的每周例行程序。 探索性测试是一次伟大的冒险，它有助于寻找新的测试用例。 当我们进入自动化阶段时，探索性测试至关重要。 仅使用测试脚本可能会忽略自动化测试中一些意外的重要测试用例。 作为一个初学者，我们只想依靠脚本和预先编写的测试，应该避免这种情况。
花一些时间进行探索性测试。 您可能永远都不知道在野外测试时可能会捕获哪些错误。
UI不可渗透的设计测试
在较早的版本中，软件的用户界面发生了很大变化。 自动化测试可以帮助我们重复执行测试，如果没有实现，那就没有意义了。 在早期阶段，测试人员会像自动化测试人员一样忽略这些类型的错误，我也这样做。 现在，我知道我不应该拥有！！
用户界面的更改迫使我们更改测试脚本。 有时，某个元素在将来的版本中会更改其位置，而脚本会利用该位置进行进一步测试。 由于位置更改是测试所依赖的，因此完整的测试执行失败。 例如，在自动浏览器测试中，如果某个图像的位置发生更改，则Selenium自动化测试脚本将无法找到该位置。 这将使整个测试失败。 这些依赖于用户界面的测试应尽可能少地编写。
包起来
自动化是一个蓬勃发展的行业。 从小型JUnit测试到大型Selenium脚本，每个人都朝着自动化迈进。 您可能会在添加了小的补丁的情况下遇到相同的代码，并且不得不再次运行相同的测试。 借助自动化，重复性任务中的错误率已降低至零。 但是，只有在自动化方面有一些实践和经验之后，才能达到此阶段。 当人们第一次进入自动化领域时，他们注定会犯一些错误。 尽管犯错并不是犯罪，但是如果您在公司或团队中工作，这些错误会浪费您的金钱，时间和其他关键资源。 这就是为什么事前安全要好一些的原因。 我希望您不会因为自动化测试人员而屈服于这14个错误。 测试愉快！
翻译自: https://www.javacodegeeks.com/2020/02/14-mistakes-i-did-that-you-should-avoid-as-a-newbie-automation-tester.html