定义好要执行的测试范围是非常必要的。当我还是一个自动化测试新手时，我曾试图测试所有的东西并使每个测试自动化。问题是，尽管你可以成功地自动化所有测试，但实际上既不实用也不可行。代码中有很多部分不需要频繁的测试，但我们却可能需要投入大量的时间来开发一个框架或脚本来编写这些代码。

作为一名自动化测试人员，另一个需要格外注意的事情就是要选择正确的自动化测试工具。一个测试项目包含许多专注于不同测试目标的组件。这些目标应该被分成不同的工具，以帮助更有效地实现目标。例如，如果你想为你的网站测试一个API，那么Postman无疑是你最好的选择，但是如果你想确保你的web应用程序在不同浏览器之间能够完美呈现，那么online Selenium Grid 就是你进行自动跨浏览器测试的最佳选择。

一个测试团队中会有很多人，每个人都具备自己的优势。例如，有人擅长业务测试，有人擅长功能测试。然而，这并不是你不与他们讨论任务进展的理由。协调是加速产品交付的关键，确认谁在从事什么工作，他们使用什么工具，他们在进行测试自动化时使用哪种编程语言最顺畅。

虽然无代码的自动化测试工具有一个统一的学习方法，并且很容易上手，但是它们不能帮助你构建自动化测试人员概要文件所需的相关技能。作为一个初学者，虽然它们对你的入门很有帮助，但是随着你的测试自动化事业的发展，你会意识到它们并没有你预期的那么有帮助。

当测试结果错误地表明测试通过，而实际上测试没有通过时，就会出现假阳性结果。假阴性则相反。盲目地相信测试报告是测试人员中非常常见的错误，这也可以称为测试元素的非验证。例如，假设你正在用不同测试用例编写的测试脚本测试登录页面，测试报告表明登录通过了，在这种情况下，你需要验证登录是否成功。作为一个自动化测试人员，不要因为警惕错误的出现而去犯这种错误。

测试用例并不是它所应用的代码所独有的。在一个项目中，会出现许多类似的组件，它们需要类似的测试设计和测试套件。例如，在使用Selenium进行跨浏览器测试时，我们发现web页面的四个元素都是输入字段，并且需要类似的测试用例。在这里，你可以通过只编写第一个元素的测试来复制粘贴代码，虽然这将给出预期的结果，但问题是将来开发人员可能会以某种方式更改元素。现在，要更改测试用例，你需要更改所编写的每个测试套件中的代码。所有的时间都将浪费在寻找和修改这些测试代码上。

不要相信这个神话，因为作为一个自动化测试人员，这是一个严重的错误。作为测试自动化领域的新手，对于将自动化引入到项目中，你可能会感到很兴奋，可能会错误地认为自动化测试可以完全取代手工测试过程。随着时间的推移，你会明白这是不可能的。完全(100%)用自动化测试代替手工测试是一个神话，这是不现实的。作为这个领域的初学者，不要试图达到这样的目标，只在必要的时候自动化，只自动化那些需要自动化的事情才是合理的。

在测试时，你会遇到不同类型的问题。你会被要求设定目标并对这些问题进行分类，有一种全新的方法是从较小的模块而不是较大的模块开始自动化测试。

在你的每周例行工作中没有包含探索性测试是自动化测试人员的常见错误之一。探索性测试是一个伟大的冒险，它有助于发现新的测试用例。当我们进入自动化阶段时，探索性测试是非常重要的。只使用测试脚本可能会忽略自动化测试中一些意料之外的重要测试用例。作为一个初学者，我们只想依赖脚本和预先编写的测试，这是应该避免的。

早期的版本跟现在相比，软件的用户界面发生了很大的变化，自动化测试可以帮助我们重复执行测试。在早期阶段，作为自动化测试人员，可能会忽略这些类型的错误。用户界面的变化迫使我们更改测试脚本，有时候一个元素在将来的构建中会改变它的位置，而脚本会利用这个位置进行进一步的测试。由于测试所依赖的位置更改，所以整个测试会执行失败。例如，在自动化浏览器测试时，如果某个图像的位置发生变化，Selenium自动化测试脚本将无法找到该位置，这将导致整个测试无法通过。这类依赖于用户界面的测试脚本应该尽可能少地编写。