测试自动化允许开发人员获得持续的反馈并及早发现问题。这些原则可以作为编写快速和简洁的自动化测试套件的指南
“test”这个词最初是指“用于测定贵金属的小容器”这意味着测试是一种确定金或银质量的方法。它也用于精炼有价值的合金，如锡。
后来，这个术语在其他领域也被采用，现在在诸如教育、医学或软件开发等领域很常见。然而，它的本质并没有改变: 测试是用来精炼最终价值的。
我们在软件开发中使用测试来确保代码按预期工作。测试可以是手动的或自动的。手动测试类似于汽车制造商撞毁汽车，以验证它们在道路上是否安全。它是可行的，但是频繁地执行的代价太高，因此通常在生产周期结束时执行。这种方法的问题在于，在这个阶段发现的问题可能会将产品的发布推迟数月。
自动化软件测试有一个完全不同的成本结构。初始的反转加上定期的维护，但是一旦测试自动化到位，我们就可以按照需要频繁地运行我们的测试，而且只需要很少的钱。
通过测试自动化，开发人员可以获得持续的反馈，从而使他们能够在生产周期的早期发现问题。快速迭代的结果是改进的设计，更好的质量和更安全的发布。
自动化测试原理
整本书都是关于测试自动化的。这是每个开发人员在某个时候都需要掌握的技能，最好尽快完成。
这里有六个原则来缓解学习曲线:
- 测试应该提高质量.
- 测试应该降低引入故障的风险
- 测试有助于理解代码.
- 测试必须是容易被编写.
- 测试套件必须是很容易运行.
- 一个测试套件应该只需要最低限度的维护.
原则1: 测试自动化提高质量
质量是一个难以捉摸的概念。不管我们怎么努力，都不可能用数字来定义它。然而，当我们看到它的时候，我们知道它。软件产业已经提出了许多衡量质量的指标: 缺陷数量、代码覆盖率、 CI 错误率、测试失败率等等。每一个人都抓住了质量概念的某些方面。
自动化测试通过不断地运行成百上千的测试来提高质量度量; 在缺陷到达生产环境之前发现它们，通知开发人员潜在的问题，并检查系统是否偏离了用户的期望。
Test reports 测试报告 在 Semaphore 中显示项目状态的高级视图
撇开度量不谈，我们知道一个可靠的设计是质量的先决条件。当测试驱动开发时，开发人员可以很容易地尝试不同的想法并确定哪一个最好。这个特性已经被类似于测试驱动开发分析(TDD)和行为驱动开发分析(BDD)这样的实践成功地利用了。
原则2: 自动化测试降低风险
代码审查和同行编程，尽管是必要的和有效的，但不能依靠它们来发现 bug。经验表明，更多的眼球不会转化为更少的错误。
可靠地发现错误的唯一方法是构建一个全面的自动化测试套件。测试可以从上到下检查整个应用程序。他们在可能造成任何危害之前捕捉错误，发现回归，并在各种设备和环境上运行应用程序，否则手动尝试代价高得令人望而却步。
即使团队中的每个人都是非常聪明的开发人员，不知何故从未犯过错误，第三方依赖仍然可能引入错误并构成风险。自动化测试可以扫描项目中的每一行代码，查找错误和安全问题。
Trivy 三维 扫描一个项目的安全问题
原则3: 测试帮助你理解系统
过于频繁的情况是，开发人员返回到仅仅几天前编写的代码，却意识到他们已经完全忘记了它是如何工作的。当开发人员不得不处理其他人编写的代码时，这种情况更加糟糕。
通常，阅读测试是理解系统的最佳场所，因为它们通过例子展示事物是如何工作的。因此，当有疑问时，开发人员可以引用测试套件。
例如，测试可以向其他开发人员展示 API 应该如何响应，从而允许他们跳过查看文档。
ctx := context.Background()result, _, err := env.Client.Server.Create(ctx, ServerCreateOpts{ Name: "test", ServerType: &ServerType{ID: 1}, Image: &Image{ID: 2}, SSHKeys: []*SSHKey{ {ID: 1}, {ID: 2}, },})if err != nil { t.Fatalf("Server.Create failed: %s", err)}if result.Server == nil { t.Fatal("no server")}if result.Server.ID != 1 { t.Errorf("unexpected server ID: %v", result.Server.ID)}if result.RootPassword != "" { t.Errorf("expected no root password, got: %v", result.RootPassword)}if len(result.NextActions) != 1 || result.NextActions[0].ID != 2 { t.Errorf("unexpected next actions: %v", result.NextActions)}
不确定是否需要一行代码？将其注释出来，看看哪个测试失败。有改进功能的想法吗？需要重构一段代码吗？尝试一下并运行自动化测试。您会惊讶地发现，您可以从一个系统的测试中了解到很多东西。
原则4: 自动化测试应该易于编写
有些测试从手工测试开始，然后逐渐自动化。但是，这往往会导致过于复杂、缓慢和尴尬的测试。当测试和代码具有某种协同作用时，最好的结果就会出现。编写测试促使开发人员生成更多的模块化代码，这反过来又使测试更简单、更细粒度。
测试的简单性很重要，因为为测试编写测试是不现实的。代码也应该易于读写。否则，我们将冒着引入测试失败的风险，从而导致错误的阳性和偏差。
许多测试框架使用领域特定语言(dsl)来进行简单的英语定义测试。也许最著名的例子是小黄瓜，小黄瓜测试框架使用的语言:
Feature: Is it Friday yet?Everybody wants to know when it's FridayScenario: Sunday isn't Friday Given today is Sunday When I ask whether it's Friday yet Then I should be told "Nope"
总而言之，在编写测试时坚持一些基本原则是个好主意:
- 每个测试只写一个断言
- 将代码与测试分开，也就是说，生产代码不应该包含测试
- 保持测试彼此独立，因为依赖关系可能会迅速地越滚越大，变成令人头疼的混乱
- 将测试重叠保持在最低限度，也就是说，不要对相同的代码进行两次测试
- 不要破坏已测试代码的封装，只测试外部接口
原则5: 测试应该易于运行
如果开发人员需要打开一个检查表来开始测试运行，那么您的测试将不会像应该的那样经常运行。
理想情况下，测试将在每次代码更改时运行，而不需要任何干预。我们很幸运，因为开发工具相当复杂。大多数现代 ide 都可以检测文件中的更改并自动启动测试套件，而且可以通过命令行程序(如 nodemon、 live reload、 fswatch 或 testmon)实现这一点。
VS 代码在后台运行测试
为了使测试易于运行，必须满足一些条件:
- Idempotency 幂等性: 测试不应该有副作用。副作用包括写入文件、保存到数据库或通常更改数据。开发人员应该能够安全地多次运行相同的测试
- Deterministic 确定性: 在输入相同的情况下，测试应该总是给出相同的结果。当测试需要开发人员无法控制的外部数据(如日期/时间或来自 API 的响应)时，应该使用模拟或存根来伪造这些数据
- Independent 独立: 测试应该相互独立，开发人员必须能够以任何顺序运行它们
- Lightweight 轻量级: 测试必须足够轻量，以便在开发人员的计算机上运行合理时间.
- Granular 颗粒状: 开发人员必须能够逐个运行测试套件
在开发人员的机器上运行测试只是等式的一部分。测试还必须在持续集成管道中进行。您的 CI/CD 管道充当质量检验关; 它在每次提交时运行测试套件，提供即时反馈，并允许开发人员检测何时引入了故障。
原则6: 自动化测试套件需要低维护
最后一个原则是前五个原则的必然结果。也就是说，如果你能很好地满足其他人的要求，你就可以免费得到它。尽管如此，它仍然很重要，所以把它当作一个重点是很好的。
开发人员希望做有创造性和回报的工作。自动化让机器承担起测试的繁重工作。当测试易于编写并且经常执行时，就会产生一个正反馈循环。开发人员倾向于认识到自动化是如何让他们的工作变得更加容易，从而激励他们编写和维护测试。
当然，需要定期进行一些维护，以保持您的测试处于良好状态。这里有四条关于编写和维护测试套件的建议:
- 编写足够多的测试来提高效率(但不要更多)。如果错误正在悄悄溜走，您需要更多的测试。相反，如果您发现测试会因为一些小的变化而中断，那么您需要删除一些测试
- 选择最佳类型的测试。单元测试是快速的、专注于激光的，而端到端测试覆盖了 UI，并且是繁重的、更加全面的。遵循测试金字塔的测试套件具有各种健康的测试
- 保持测试的可靠性。当代码正确时测试失败称为假阳性。有时无明显原因而失败的测试被称为flaky tests . 它们都会在测试套件中引起问题，因为它们是巨大的时间浪费和挫折的来源
- 保持快速测试
总结
那些认为检测昂贵的人并没有完全意识到低质量的代价。单独来看，缺陷和缺陷对产品价值的影响可能难以衡量，但如果不加以解决，它们可能会迅速失控。幸运的是，您可以通过构建和改进您的自动化测试套件来防止这种情况的发生，从而为优秀的开发人员经验和优秀的高质量软件奠定基础。
测试自动化原理过程