“测试”一词的原意是“用于测定贵金属的小容器”。这意味着测试是确定黄金或白银质量的一种方式。它还用于提炼有价值的合金，例如锡。后来，该术语被其他领域采用，如今它经常出现在教育、医学或软件开发等语境中。但是，它的本质并没有改变：测试是用来提炼最终值的。我们在软件开发中使用测试来确保代码按预期工作。测试可以是手动的或自动的。手动测试类似于汽车制造商碰撞汽车以验证它们在路上是否安全。它有效，但经常这样做太昂贵了，所以它通常在生产周期结束时完成。这种方法的问题在于，在此阶段发现的问题可能会使产品发布延迟数月。自动化软件测试具有完全不同的成本结构。有一个初始的翻转和定期维护，但是一旦测试自动化到位，我们就可以根据需要经常运行测试-只需几分钱。通过测试自动化，开发人员可以获得持续的反馈，使他们能够在生产周期的早期发现问题。快速迭代导致改进的设计、更高的质量和更安全的发布。测试自动化原理整本书都专门讨论测试自动化的主题。这是每个开发人员在某个时候都需要掌握的技能，最好尽早掌握。以下是简化学习曲线的六个原则：测试应该提高质量。测试应该降低引入故障的风险。测试有助于理解代码。测试必须易于编写。测试套件必须易于运行。测试套件应该需要最少的维护。原则1：测试自动化提高质量质量是一个难以捉摸的概念。尽我们所能，用数字来定义它是不可能的。但是，当我们看到它时，我们就知道了。软件行业提出了很多衡量质量的指标：缺陷数、代码覆盖率、CI错误率、测试失败率等，每一个都抓住了质量概念的某个方面。自动化测试通过连续运行数百或数千次测试来提高质量指标；在将其投入生产之前发现缺陷，将潜在问题通知开发人员，并检查系统是否偏离用户期望。除了指标，我们知道可靠的设计是质量的先决条件。当测试驱动开发时，开发人员可以轻松地尝试不同的想法并确定哪一个最有效。测试驱动开发(TDD)和行为驱动开发(BDD)等实践利用此属性取得了巨大成功。原则2：测试自动化降低风险代码审查和同行编程虽然必要且富有成效，但不能依赖它们来发现错误。经验表明，更多的眼球并不能转化为更少的错误。可靠地发现错误的唯一方法是构建一个全面的自动化测试套件。测试可以从上到下检查整个应用程序。他们在错误造成任何危害之前发现错误，发现回归，并在各种设备和环境上运行应用程序，否则手动尝试的成本会高得令人望而却步。即使团队中的每个人都是非常聪明的开发人员，不知何故从不犯错，第三方依赖项仍然会引入错误并带来风险。自动化测试会扫描项目中的每一行代码以查找错误和安全问题。原则3：测试帮助您了解系统很多时候，开发人员回到他们几天前编写的代码，却发现他们已经完全忘记了它是如何工作的。当开发人员不得不处理其他人编写的代码时，情况就更糟了。通常，阅读测试是理解系统的最佳方式，因为它们通过示例展示了事物是如何工作的。因此，当有疑问时，开发人员可以参考测试套件。例如，测试可以向其他开发人员展示API应如何响应，从而使他们无需查看文档。ctx:=context.Background()结果,_,err:=env.Client.Server.Create(ctx,ServerCreateOpts{Name:"test",ServerType:&ServerType{ID:1},Image:&Image{ID:2},SSHKeys:[]*SSHKey{{ID:1},{ID:2},},})iferr!=nil{t.Fatalf("Server.Createfailed:%s",err)}if结果。Server==nil{t.Fatal("noserver")}ifresult.Server.ID!=1{t.Errorf("unexpectedserverID:%v",result.Server.ID)}ifresult.RootPassword!=""{t.Errorf("预期没有root密码，得到：%v"，result.RootPassword)}iflen(result.NextActions)!=1||result.NextActions[0].ID!=2{t.Errorf("unexpectednextactions:%v",result.NextActions)}不确定是否需要一行代码？将其注释掉以查看哪个测试失败。有改进功能的想法吗？需要重构一段代码？试一试并运行自动化测试。您会惊讶于您可以从系统测试中学到多少东西。原则4：自动化测试应该易于编写有些测试从手动测试开始，然后自动完成。然而，这通常会导致过于复杂、缓慢和笨拙的测试。当测试和代码具有一定的协同作用时，就会出现最好的结果。编写测试的行为促使开发人员生成更多模块化代码，这反过来又使测试更简单、更精细。测试的简单性很重要，因为为测试编写测试是不切实际的。代码也应该易于阅读和编写。否则，我们就有可能在测试本身中引入失败，从而导致误报和不稳定。许多测试框架使用领域特定语言(DSL)以简单的英语定义测试。也许最显着的例子是Gherkin，Gherkin测试框架使用的语言：Feature：IsitFridayyet？每个人都想知道什么时候是星期五场景：星期天不是星期五鉴于今天是星期天当我问是否是星期五然后我应该被告知“不是”总而言之，在编写测试时坚持一些基本原则是个好主意：仅每个测试写一个断言。将代码与测试分开，即生产代码不应包含测试。保持测试彼此独立，因为依赖关系会迅速滚雪球，变成令人头疼的混乱局面。将测试重叠保持在最低限度，即不要对同一代码进行两次测试。不要破坏测试代码的封装。没有，只测试了外部接口。原则5：测试应该易于运行如果开发人员需要打开清单来开始测试运行，那么测试将不会像应有的那样频繁地运行。理想情况下，每次代码更改时都会运行测试，而无需任何干预。我们在这里很幸运，因为开发人员工具非常复杂。大多数现代IDE都可以检测文件的变化并自动启动测试套件，同样可以通过nodemon、livereload、fswatch或testmon等命令行程序来实现。说明：VSCode在后台运行测试为了让测试轻松运行，必须满足一些条件：幂等性：测试不应该有副作用。副作用包括写入文件、保存到数据库或通常更改数据。开发人员应该能够安全地多次运行相同的测试。确定性：给定相同的输入，测试应该总是给出相同的结果。当测试需要开发人员无法控制的外部数据（例如日期/时间或来自API的响应）时，应使用模拟或存根来伪造该数据。独立：测试应该相互独立，开发人员必须能够以任何顺序运行它们。轻量级：测试必须足够轻量，以便在合理的时间内在开发人员的计算机上运行。粒度：开发人员必须能够单独运行测试套件。在开发人员的机器上运行测试只是等式的一部分。测试也必须在持续集成管道中进行。您的CI/CD管道充当质量门；它在每次提交时运行测试套件，提供即时反馈，并允许开发人员检测何时引入故障。原则6：自动化测试套件需要维护成本低最后一条原则是前五个原则的必然结果。也就是说，如果你很好地满足了其他人，你就可以免费获得它。不过，这很重要，所以最好说出来。开发人员希望从事创造性和有益的工作。自动化使机器能够处理繁重的测试工作。当测试易于编写和频繁执行时，就会创建一个正反馈循环。开发人员倾向于欣赏自动化如何使他们的生活更轻松，因此有动力编写和维护测试。当然，需要进行一些定期维护以保持测试的良好状态。以下是编写和维护测试套件的四条建议：编写足够有效的测试（但不要更多）。如果错误漏掉了，则需要进行更多测试。相反，如果您发现您的测试由于微小的更改而中断，则需要删除一些测试。根据情况选择最佳测试类型。单元测试快速且专注于激光，而端到端测试覆盖UI，并且更重、更全面。遵循测试金字塔的测试套件具有各种健康的测试。保持测试可靠性。当代码正确时失败的测试称为误报。有时无缘无故失败的测试称为片状测试。两者都可能导致测试套件出现问题，因为它们会浪费大量时间和令人沮丧。保持快速测试。缓慢的测试套件会阻碍开发。结论那些认为测试成本高昂的人并没有完全意识到质量差的代价。单独来看，错误和缺陷对产品价值的影响可能难以衡量，但如果不加以解决，它们很快就会失控。幸运的是，您可以通过构建和完善自动化测试套件来防止这种情况发生，从而为出色的开发人员体验和出色的高质量软件奠定基础。
