“嗯，在我的机器上可以运行”
我相信在我们的职业生涯中，我们都曾听过开发人员对我们这样说过，我们也都会对此翻白眼。显然，这并不只是你机器上的问题……
我们最好将同样的“它不应该只在我的机器上运行”理念应用到我们的测试中：团队中的每个人都应该能够运行它们。测试自动化的核心在于快速反馈，只有当运行测试快速、顺畅且无缝时，你才能获得这种反馈。
此外，测试应该能够按需运行，无需等待有人设置机器、准备必要的测试数据，等等。无论“按需”在你的情况下意味着每个迭代一次还是每天十次，你的测试都应该随时准备就绪。
因此，在他人的机器上按需运行测试，是我在与个人和团队学习测试自动化，或在改进他们已有的知识时首先涵盖的内容之一。
这样，我们以后在编写了几十甚至上百个测试后，就不必做大量的工作来自动化运行测试，并使其成为我们所期望的快速、顺畅和无缝的体验。
以下是我在每次教授个人或小团队测试自动化（例如在我的公司指导中）时几乎一丝不苟地遵循的逐步指南。
编写几个小而有意义的测试
它们不必是你最重要的测试。完全不需要。但既然没有编写无用测试的意义，就选择一些“应该正常工作”的内容。对于UI测试，可以是应用程序的登录流程。对于API测试，选择一个从后端系统检索一些数据的调用，最好是你知道应该始终存在的内容。如果API调用需要身份验证，更是加分项。对于单元测试，编写一个针对代码行为中有意义部分的测试。不需要测试getter/setter。
通过使用命令行多次运行这些测试，确保它们在本地机器上可靠运行。为什么是命令行？因为在后续步骤中，你的测试将在CI中运行，因此最好从一开始就确保你知道如何通过命令行运行它们。
你的测试每次都应该以相同的方式表现，并报告相同的结果。代码本身不必一开始就漂亮，我们稍后会讨论这个问题。
这教会你的： 编写测试，使用测试库
将测试纳入版本控制
大多数代码（包括测试）都需要协作，协作代码的唯一可靠且可扩展的方式是通过版本控制。因此，逻辑的下一步是将测试纳入版本控制。确保排除/忽略不应纳入版本控制的代码库部分，包括：
- 编译后的代码和其他生成的产物
- 测试报告
- 凭证和其他秘密
对于凭证和其他秘密，按照你的开发团队已经在做的方式处理。通常，这涉及某种类型的密钥库或秘密保管库和/或使用（环境）变量。
这教会你的： 使用版本控制系统，处理代码中的秘密
将测试执行添加到CI管道
也许有一个现有的构建和部署管道，你可以将测试添加进去，也许你现在需要为此构建一个单独的管道。这两种方式都可以，尽管理想情况下，你希望你的测试最终成为应用程序“主”管道中的一个阶段。
无论哪种方式，确保每次触发CI构建时运行你的测试。这可以是基于时间的触发器（“每晚11点运行测试”）、基于事件的触发器（“每次有人提交到分支/每次有人创建拉取请求时运行这些测试”）或两者兼有。只要你的测试每天至少运行一次，就没问题。你希望这些测试经常运行，以便快速反馈两件事：
- 你正在验证的应用程序的状态，以及
- 你自己的测试的可靠性
第二点非常重要——我们希望从一开始就建立对测试的信任，唯一的办法是通过CI在他人的机器上经常运行它们。
这教会你的： 构建/编辑CI管道，配置和使用CI代理
并行测试执行
我们还处于非常早期的阶段，但在某个时候，我们的测试套件会增长，测试执行时间会越来越长。然而，理想情况下，我们希望测试运行的反馈尽快回来。我通常在这里使用“泡一杯咖啡的时间”作为经验法则。
尤其是当你的测试套件大量依赖E2E测试时，你会很快发现测试执行时间急剧增加。并行运行测试是解决这一问题的一个好方法，而且当你的测试套件还处于起步阶段时，这是最容易实现的。一些框架支持开箱即用的并行测试执行，对于其他框架，可能需要更多的工作，但尽早实现并行化会在以后为你节省很多麻烦，所以现在是做这件事的好时机。
这教会你的： 并行运行测试，处理并发冲突
下一步
只有在我们编写了第一个测试，将它们纳入版本控制，使用CI编排器自动化执行测试，并确保我们的测试可以并行运行且没有问题之后，才是开始处理其他任务的时候，包括：
- 提高现有测试代码的可读性和可维护性
- 添加测试结果的报告和通知
- 确保我们的测试可以在多个环境中运行（如果需要）
当然，你还会花很多时间（实际上是大部分时间）向测试套件中添加更多的测试。但请为自己做一个好事，只有在完成前面的步骤后再开始这样做。你会感谢自己（还有我 ;)）因为你这样做并为早期的成功奠定了基础。
