“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 its FridayScenario: Sunday isnt Friday Given today is Sunday When I ask whether its 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 . 它们都会在测试套件中引起问题，因为它们是巨大的时间浪费和挫折的来源保持快速测试总结那些认为检测昂贵的人并没有完全意识到低质量的代价。单独来看，缺陷和缺陷对产品价值的影响可能难以衡量，但如果不加以解决，它们可能会迅速失控。幸运的是，您可以通过构建和改进您的自动化测试套件来防止这种情况的发生，从而为优秀的开发人员经验和优秀的高质量软件奠定基础。
