为您的组织带来持续的测试
摘要：连续测试意味着您的所有测试一直在执行，从而提供有关应用程序质量和运行状况的连续反馈。为了实现连续测试，您必须首先采用正确的测试自动化策略。了解如何尽可能有效地引入所有不同类型的测试自动化实践，可以使您开始进行连续测试。
作为进入市场战略的一部分，企业越来越关注客户体验，而客户体验的关键部分是他们以快速、无缝的方式遍历软件的能力。消费者比以往任何时候都更精通技术，对缺陷的容忍度也较低，因此遭受不良行为影响的应用程序可能会对您的品牌产生极大的负面影响。
为了降低这些风险，组织将质量计划加倍，软件开发行业也将持续测试作为主流活动。
什么是连续测试？
持续测试是软件测试的一项原则，在该原则中，您的所有测试始终在执行，从而不断提供有关应用程序质量和运行状况的反馈。
为了实现连续测试，组织必须首先采用测试自动化。测试自动化的类型很多，从UI层到中间件系统，甚至到后端系统，都涵盖了应用程序的整个范围。了解如何尽可能有效地引入这些不同类型的测试自动化实践，可以使您迈向连续测试的道路。
这一切都始于制定测试自动化策略
由迈克尔·科恩（Michael Cohn）和马丁·福勒（Martin Fowler）推广的测试金字塔确定了我们应该进行不同数量的不同类型的测试活动。在基础上，我们希望建立广泛的单元测试和API测试。这些类型的测试更容易在自动化中运行，但通常需要技术技能来构建。测试金字塔的顶部具有自动UI测试和手动测试。我们希望这种类型的测试活动在顶部，因为这是确保客户体验的唯一方法。
大多数人专注于UI测试的“自动上手”方法，而单元开发则采用“开发人员应测试”的心态来关注测试金字塔的底部和顶部。尽管这些做法很重要，但专注于顶部和底部会在UI和代码之间的API层中间产生间隙。
这种差距只会继续变得更加棘手，ProgrammableWeb最近的一份报告显示，目录中有超过22000种公开可用的API，并且这个数字还在稳步攀升。API测试比以往任何时候都更为关键，它需要成为您正在构建的持续测试策略的一个组成部分。
选择正确的API测试解决方案
这一切都始于选择一个API测试解决方案，该解决方案可以随着您API测试成熟度的增长而发展。您可能需要的关键功能取决于您的行业，应用程序和组织的独特要求。但是，一旦选择了工具，该如何开始？
可以通过三个关键步骤来更快地实现功能测试自动化。
步骤1：建立您现有的自动化API的广泛测试范围
通过从Web记录和API合同构建无脚本测试，然后使用这些测试来连续验证API的运行状况，可以确保API能够按照设计的方式运行。可以将其视为对API的单元测试，但无需花费大量精力。
这不仅是一种有价值的测试技术，而且还是您可以进行的最早的功能测试验证类型之一，因为API的服务合同通常是在创建新功能或新功能时首先编写的内容之一。
举例来说，假设团队已经为我们的应用程序添加了一些新功能。第一步，开发团队发布了新的服务定义。在这种情况下，将生成Swagger文档。所添加的新服务是RequestLoan服务，该服务接受一系列输入并与贷款提供者响应以获取新贷款。
为了测试该服务，我可以使用Swagger YAML并为每个单独的操作创建一系列客户端。
这些客户之一就是请求贷款服务。我可以创建一系列输入（包括正数和负数），以验证服务的行为是否正确。然后，可以将这些测试重新用于回归目的。
当然，尽管这种测试非常有价值，但这只是API测试难题的一半，因为它无法验证API的实际使用方式。下面输入步骤2。
步骤2：弥合UI和API之间的鸿沟
API测试策略的第二部分是能够将您对应用程序的人工使用建模为完整的API测试方案。
您可以通过利用人工智能来增强您的能力，从而在用户浏览您的应用程序时了解幕后实际发生的事情，并将这些幕后事务解释为API调用，从而开始弥合测试金字塔中的空白。这种类型的测试可让您将用户体验与关键的API测试保持一致。
人工智能是该策略的关键组成部分，因为我们可以可靠地使用人工智能来帮助我们将这些通信分解为各种关系和模式，因此我们可以了解如何测试应用程序的业务规则。我们可以将其与我们的单元级API测试结合起来，以广泛涵盖我们的API范围。
继续我的示例，您将注意到请求贷款服务需要来自应用程序其他区域的输入：
虽然我可以从帐户中任意提供客户ID，但实际上我需要它们存在于我的应用程序中，因此，我将需要创建一个动态方案，在该方案中，我首先查询单个用户以获得客户ID和帐户ID，以便可以处理该问题。信息提供给请求贷款服务，并确保动态方案按所述方式工作。确保我正在使用真实的动态数据，以确保可以充实因API相互交互而存在的行为。
尽管这些类型的技术将使我们能够将API测试实践向左转移，并在可能的最早阶段为我们的应用程序创建广泛的覆盖范围，但这种实践的第三个关键组成部分是：我们了解并适应变化的能力。
步骤3：通过可维护的变更管理过程确保信心
我已经与很多人谈论过他们的功能测试计划，一旦他们的应用程序更改了，他们的计划就停滞了。这是常见的情况，因为测试人员将大部分时间都花在构建丰富而出色的API测试上，而只是在应用程序的API发生更改时才让它们中断。这可能会产生累积效应，从而降低对API测试策略的信心，因为测试人员将大量时间用于维护API测试，而不是建立新的价值。
变更管理是任何功能测试策略的关键部分，而AI在这里也可以成为关键的推动者。通过自动扫描服务定义（是的，与最初创建测试用例的服务定义相同）来确定您的API何时更改，您可以了解何时会受到影响，然后构建用于将现有服务迁移到新服务的模板版。
在本示例的第一部分中，我声明了将新服务添加到我的应用程序中。这实际上代表API的更改。自从我使用服务定义创建了第一轮基准测试以来，我可以相互比较服务定义的不同版本，以识别发生了什么变化并构建映射以更新现有的测试用例。
在查看更改模板后，很明显不仅添加了新服务，而且还重构了我的许多现有服务。在上图中，您会注意到“ GET客户”已添加了一系列新字段。使用变更管理工作流将使您能够主动识别服务变更，同时管理现有测试用例的更新，因此您可以尽快从变更中恢复。
可以说，这是在构建功能测试策略时必须建立的最重要的实践。从一开始就了解这一点并对质量做出承诺，将有助于您和您的组织采用这种做法。
片状测试环境如何？
凭借出色的测试自动化功能，可以轻松地在此处停止测试。但是，请说您花了很多时间来构建这种丰富而强大的功能测试策略，作为自动化的夜间连续测试过程的一部分，在您的环境中运行测试，并且在查看结果时，您会发现很大一部分您的测试因系统无法控制而失败。
这是否意味着您的测试不合格？您现在是否要对技术超出测试范围的系统负责？
这不是一个罕见的故事。我们知道功能测试只能与执行它们的测试环境一样有效。不稳定，不可用或只是普通的不稳定测试环境会降低我们从功能测试工具中获得的投资回报。因此，我必须至少简短地提到稳定测试环境的最佳方法之一：服务虚拟化。
不要与虚拟机（即硬件虚拟化）相混淆，服务虚拟化使您可以模拟在不同硬件之间进行通信的服务。例如，考虑一个调用数据库的应用程序。您在测试环境中实际上是否需要该数据库？如果没有所需的数据怎么办？通过服务虚拟化，您可以记录与数据库的事务，然后使用该记录创建该数据库的模拟版本，以及针对测试环境所需的所有行为。但是，当然，它不仅限于数据库；还包括数据库。它可以是任何类型的服务，例如SOAP或REST API，甚至是TCP和微服务。
作为制定可持续的API测试策略的一部分，您需要制定可持续的服务虚拟化策略，首先要回答以下问题：
哪些服务适合虚拟化？
如何创建虚拟服务？
如何维护虚拟环境？
如何在我的连续测试策略中部署虚拟环境？
服务虚拟化是可持续的连续测试策略的关键推动力，但是了解在何处，何时引入它以及如何使其尽可能有效是成功的关键。
持续测试入门
现在，您已经更好地了解了如何将API测试集成为持续测试策略的一部分，下一步就是开始！与API测试工具供应商合作，并从第一步开始。在开始时了解最终目标将有助于您一路做出明智的选择。
页:
[1]
