自动化测试原则｜首先确保能够自动执行-优快云博客

📝 面试求职： 「面试试题小程序」，内容涵盖测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

“嗯，在我的机器上可以运行”

我相信在我们的职业生涯中，我们都曾听过开发人员对我们这样说过，我们也都会对此翻白眼。显然，这并不只是你机器上的问题……

我们最好将同样的“它不应该只在我的机器上运行”理念应用到我们的测试中：团队中的每个人都应该能够运行它们。测试自动化的核心在于快速反馈，只有当运行测试快速、顺畅且无缝时，你才能获得这种反馈。

此外，测试应该能够按需运行，无需等待有人设置机器、准备必要的测试数据，等等。无论“按需”在你的情况下意味着每个迭代一次还是每天十次，你的测试都应该随时准备就绪。

因此，在他人的机器上按需运行测试，是我在与个人和团队学习测试自动化，或在改进他们已有的知识时首先涵盖的内容之一。

这样，我们以后在编写了几十甚至上百个测试后，就不必做大量的工作来自动化运行测试，并使其成为我们所期望的快速、顺畅和无缝的体验。

以下是我在每次教授个人或小团队测试自动化（例如在我的公司指导中）时几乎一丝不苟地遵循的逐步指南。

编写几个小而有意义的测试

它们不必是你最重要的测试。完全不需要。但既然没有编写无用测试的意义，就选择一些“应该正常工作”的内容。对于UI测试，可以是应用程序的登录流程。对于API测试，选择一个从后端系统检索一些数据的调用，最好是你知道应该始终存在的内容。如果API调用需要身份验证，更是加分项。对于单元测试，编写一个针对代码行为中有意义部分的测试。不需要测试getter/setter。

通过使用命令行多次运行这些测试，确保它们在本地机器上可靠运行。为什么是命令行？因为在后续步骤中，你的测试将在CI中运行，因此最好从一开始就确保你知道如何通过命令行运行它们。

你的测试每次都应该以相同的方式表现，并报告相同的结果。代码本身不必一开始就漂亮，我们稍后会讨论这个问题。

这教会你的： 编写测试，使用测试库

将测试纳入版本控制

大多数代码（包括测试）都需要协作，协作代码的唯一可靠且可扩展的方式是通过版本控制。因此，逻辑的下一步是将测试纳入版本控制。确保排除/忽略不应纳入版本控制的代码库部分，包括：

• 编译后的代码和其他生成的产物
• 测试报告
• 凭证和其他秘密

对于凭证和其他秘密，按照你的开发团队已经在做的方式处理。通常，这涉及某种类型的密钥库或秘密保管库和/或使用（环境）变量。

这教会你的： 使用版本控制系统，处理代码中的秘密

将测试执行添加到CI管道

也许有一个现有的构建和部署管道，你可以将测试添加进去，也许你现在需要为此构建一个单独的管道。这两种方式都可以，尽管理想情况下，你希望你的测试最终成为应用程序“主”管道中的一个阶段。

无论哪种方式，确保每次触发CI构建时运行你的测试。这可以是基于时间的触发器（“每晚11点运行测试”）、基于事件的触发器（“每次有人提交到分支/每次有人创建拉取请求时运行这些测试”）或两者兼有。只要你的测试每天至少运行一次，就没问题。你希望这些测试经常运行，以便快速反馈两件事：

1. 你正在验证的应用程序的状态，以及
2. 你自己的测试的可靠性

第二点非常重要——我们希望从一开始就建立对测试的信任，唯一的办法是通过CI在他人的机器上经常运行它们。

这教会你的： 构建/编辑CI管道，配置和使用CI代理

并行测试执行

我们还处于非常早期的阶段，但在某个时候，我们的测试套件会增长，测试执行时间会越来越长。然而，理想情况下，我们希望测试运行的反馈尽快回来。我通常在这里使用“泡一杯咖啡的时间”作为经验法则。

尤其是当你的测试套件大量依赖E2E测试时，你会很快发现测试执行时间急剧增加。并行运行测试是解决这一问题的一个好方法，而且当你的测试套件还处于起步阶段时，这是最容易实现的。一些框架支持开箱即用的并行测试执行，对于其他框架，可能需要更多的工作，但尽早实现并行化会在以后为你节省很多麻烦，所以现在是做这件事的好时机。

这教会你的： 并行运行测试，处理并发冲突