什么是持续测试以及如何将其引入到你的组织中？-控件新闻-慧都网

什么是持续测试以及如何将其引入到你的组织中？

原创|行业资讯|编辑：况鱼杰|2020-11-30 11:36:50.327|阅读 191 次

概述：企业越来越注重客户体验，将其作为进入市场战略的一部分，而客户体验的关键一环是他们能够以快速和无缝的方式穿越你的软件。

什么是持续测试？

持续测试是软件测试的一个原则，在这个原则下，你的所有测试都在一直执行，对你的应用程序的质量和健康状况进行持续反馈。但为了实现持续测试，企业必须首先采用测试自动化。测试自动化有很多类型，从UI层开始，到中间件系统，甚至是后端系统，跨越了应用程序的宽度。了解如何尽可能高效地引入这些不同类型的测试自动化实践，可以让你走向持续测试的道路。

构建正确的测试自动化策略

现在被广泛接受的测试金字塔（由Michael Cohen和Martin Fowler推广）确定了不同类型测试活动的最佳策略。在基层，代表着最大数量的测试，希望建立广泛覆盖的单元和API测试，这些测试在自动化中最容易运行，但通常需要技术技能来构建。到了测试金字塔的顶端，你会发现自动化UI测试和手动测试。我们希望这种类型的测试活动在顶部，因为这是确保客户体验的唯一方法。

大多数人把注意力集中在测试金字塔的底部和顶部，对UI测试采取 "把人工的东西自动化 "的做法，对单元测试采取 "开发人员应该测试 "的心态。虽然这些做法很重要，但专注于顶部和底部，在中间的API层，在UI和代码之间造成了差距。但这种差距只会继续变得越来越麻烦，Programmable Web最近的一项调查预测，到2021年将有超过22000个公开的API。API测试比以往任何时候都更加关键，需要成为你正在构建的持续测试策略的一个集成部分。

利用测试自动化实现持续测试的3个步骤

之前曾讨论过如何为您的组织的独特需求选择最佳的API测试解决方案，并根据您的行业和应用程序，指出了您可能需要的关键功能。从一个API测试解决方案开始是很有帮助的，它可以随着您的API测试成熟度的增长而增长。一旦你选择了一个工具，您该如何开始？以下是三个关键步骤，以更快地实现功能测试自动化，并实现您的持续测试。

第1步：为您现有的API建立广泛的自动化测试覆盖范围。

为了创建一套广泛的自动化测试，您可以从网络录音和API合同中构建无脚本测试，然后使用这些测试来持续验证您的API的健康状况，确保API按照设计工作。把它想象成API的单元测试，但不需要进行磨合--这不仅是一种有价值的测试技术，而且也是您可以做的最早的功能测试验证类型之一，因为API的服务合同通常是在创建新特性或功能时最先编写的东西之一。

举个例子，假设团队在银行应用中增加了一些新功能。作为第一步，开发团队发布了一个新的服务定义。在这种情况下，生成了一个swagger文档。正在添加的新服务是RequestLoan服务。这个服务需要一系列的输入，并响应新贷款的贷款提供者。为了测试这个服务，可以消耗Swagger YAML，并为每个单独的操作创建一系列客户端。

其中一个客户将是请求贷款服务，可以创建一系列的输入，包括正向和负向输入，以验证该服务的行为是否恰当。然后将这些测试重新用于回归目的。当然，虽然这种类型的测试非常有价值，但它只是API测试难题的一半，因为它不能验证API的实际使用情况。进入第二步。

第二步：弥补UI和API之间的差距

API测试策略的第二部分是能够将人类对应用的使用建模为完整的API测试场景。您可以开始通过利用人工智能来弥补测试金字塔中的这一差距，以增强您的能力，了解用户在浏览您的应用程序时在幕后实际发生了什么，并将这些幕后事务解释为API调用。这种类型的测试允许您将用户体验与您的关键API测试相一致。

AI是战略的关键组成部分，因为可以可靠地使用AI来帮助我们将这些通信分解为关系和模式，了解应用程序如何被测试的业务规则。可以将其与单元级API测试结合起来，以获得广泛的API频谱覆盖。

继续前面的例子，你会注意到，申请贷款服务需要申请的其他方面的输入。具体来说：

现在，虽然可以任意提供customerID和from accountAccountID，但是需要创建一个动态场景，在这个场景中，首先查询个人用户以获得客户ID和账户ID，这样就可以将这些信息交给请求贷款服务，并确保动态场景如所述工作。确保使用的是真实的动态数据，可以确保那些由于API相互交互而存在的行为能够得到充实。

这些类型的技术将使我们能够转变左API测试实践，并在尽可能早的阶段为应用创造广泛的覆盖面。一旦实现了这一目标，这一实践还有第三个关键的组成部分，那就是我们理解和适应变化的能力。

第3步：通过可维护的变革管理程序确保信心。

很多人的功能测试计划，一旦他们的应用发生变化，就会落空。这是一种常见的情况，因为测试人员把大部分时间都花在了构建丰富而伟大的API测试上，却在应用的API发生变化时中断了。这可能会产生累积效应，降低对API测试策略的信心，因为测试人员将大部分时间用于维护他们的API测试，而不是建立新的价值。

变更管理是任何功能测试策略的关键一环，而AI在这里也可以成为一个关键的推动者。通过自动扫描服务定义（是的，与最初创建测试用例所用的服务定义相同）来识别您的API何时发生了变化，您可以了解您何时会受到影响，然后建立一个模板，将现有服务迁移到新版本。

回到银行应用例子的第一部分，这里在我的应用中添加一个新的服务，这实际上代表了API的变化。由于这里使用服务定义创建了第一轮基线测试，现在可以将服务定义的不同版本相互比较，不仅可以识别出有什么变化，而且可以建立一个地图来更新我现有的测试用例。

查看变更模板后，很容易看到不仅增加了一个新的服务，而且许多现有服务也被重新构建。在上图中，你会注意到get customers有一系列新的字段被添加。使用变更管理工作流，你可以主动识别服务变更，同时管理现有测试用例的更新，这样你就可以尽快从变更中恢复。<

这可以说是一个人在建立功能测试策略时必须建立的最重要的实践，从一开始就对质量有一个理解和承诺将帮助你和你的组织采用这种实践。

片状的测试环境怎么办？

如果你的优秀测试自动化实现了持续测试，很容易就此打住。但是，假如你花了大量的时间来构建这个丰富而强大的功能测试策略，你在你的环境中运行你的测试，作为你的自动化夜间持续测试过程的一部分，当你审查结果时，你看到你的测试有很大一部分失败了，原因是你无法控制的系统。这是否意味着你的测试很糟糕？你现在是否要为那些在技术上超出你测试范围的系统负责？

这不是一个罕见的情况。我们知道，功能测试只有在其执行的测试环境中才会有效。不稳定的、不可用的、或者仅仅是片面的测试环境会降低我们从功能测试工具中获得的投资回报。因此，必须至少简单地提到稳定测试环境的最佳方法之一，那就是：服务虚拟化。

不要与虚拟机（那是硬件虚拟化）混淆，服务虚拟化可以让你实际模拟不同硬件之间通信的服务。例如，想想一个应用程序调用一个数据库。在你的测试环境中，你真的需要那个数据库吗？如果它没有你需要的数据怎么办？通过服务虚拟化，你可以记录与数据库的事务，然后使用该记录来创建该数据库的模拟版本，并为你的测试环境提供你想要的所有行为。但当然，它并不仅仅停留在数据库上，它可以是任何类型的服务，比如SOAP或REST API，甚至是TCP和微服务。

作为构建可持续的API测试策略的一部分，你需要建立一个可持续的服务虚拟化策略，而这首先要回答以下问题。