LEAP

LEAPWORK的自动化见解和生产力提示。

所有帖子

为什么良好的环境对成功进行测试自动化至关重要

一旦批准了自动化测试策略并启动了实施计划,测试人员将不可避免地要问自己一个问题:“我们可以相信自动化测试产生的结果吗?”

我们之前已经概述了 分析测试自动化结果的最佳实践,并且这篇文章介绍了如何确保产生可靠测试结果的环境。测试中的一条黄金法则是,测试的质量并不比测试环境的质量好。

当涉及到自动化测试时,情况更是如此。在 测试自动化,测试人员的主观,认知分析仅在测试用例的设计和评估过程中进行,而不是在实际执行过程中进行。即使存在明显问题,机器人也只会按照指示执行。

因此,为了给机器人或测试执行代理提供最佳的工作条件,您需要设置健壮且可预测的测试环境。但是,这不是一个简单的任务:

  • 您如何确定被测系统是否真正可测-尤其是测试环境是否可依赖外部系统?
  • 如果存在系统故障,您如何重新配置​​测试环境,即使其准备好再次进行测试?
  • 如何管理测试数据,包括清理和基准测试?

当涉及到测试环境时,需要考虑三个主要方面,每个方面都将在本文中介绍。

  • 哪种架构可使应用程序可测试?
  • 测试环境如何适合DevOps管道?
  • 如何处理测试数据?

使用正确的架构使系统可测试

几乎所有应用程序都具有与第三方系统的连接和关系,这使其成为测试的挑战。如果第三方服务存在问题,则该应用程序可能会失败,从而带来问题:该应用程序是否可测试?如果没有,请不要浪费时间进行测试。

有两种方法可以解决第三方服务依赖性问题:

  • 您可以使应用程序的测试独立于第三方服务,或者;
  • 您可以在执行测试用例之前确保第三方服务能够响应。

1.封装应用程序以进行测试

您可以使用测试工具从测试角度封装应用程序 面向服务的架构(SOA)。 SOA基于各个系统之间的松散耦合,通常基于REST API或类似的东西。这使得可以出于测试目的而介入各方之间的通信。

SOA方法为您提供了至少两种使测试独立于第三方的方法。

在应用程序内部模拟数据

依赖于被测应用程序内部的模拟数据意味着应用程序本身会干预从应用程序到第三方服务的任何调用。该应用程序不会将数据传输到第三方服务,而是“将数据返回给自己”,从而对其进行测试。

通过使用模拟数据封装应用程序以进行测试。

图1: 通过使用模拟数据封装应用程序以进行测试。

使用代理服务

或者,您可以设置代理服务,该代理服务将充当被测应用程序和第三方服务之间的中介。代理的接口将类似于第三方服务的接口,因此从应用程序的角度来看,与代理的交互与与第三方服务的交互没有区别。代理服务可以存储和返回数据,也可以充当“真实”代理,并在应用程序和第三方服务之间传输数据。最重要的是,代理可以处理第三方服务不可用的情况。

图2:使用代理服务封装应用程序以进行测试。

图2: 使用代理服务封装应用程序以进行测试。

2.确保第三方服务可用

在这种情况下,问题“系统是否可测试?”只需使用系统即可得到答案。例如,假设一个网站与多个Web服务集成以生成特定的网页和/或功能。

要确定网站是否能够按预期运行,请对所涉及的服务进行在线检查。一种简单的方法是建立一个网页,其唯一目的是调用所有相关的外部引用,并确保它们能够按预期进行响应。这将很好地表明该网站是否可测试。

Web服务状态

图3: Microsoft Azure的一个示例,其中报告有关相关Web服务状态的网页。要测试服务是否响应,您可以为此特定页面构建一个自动化测试用例,测试所有系统是否报告绿灯,在这种情况下用复选标记直观表示。

使测试环境适合DevOps管道

开发运维-在发布产品之前降低风险的实践—严重依赖于测试自​​动化。为了从自动化测试用例中获得最相关的反馈,从而降低风险,至关重要的是,测试环境必须尽可能类似于生产环境。例如,如果生产环境利用负载平衡器上的SSL卸载,则测试环境应具有相同的设置。

下表列出了设计测试环境时要考虑的一些组件。

零件

描述

负载均衡器:会话状态

大多数系统使用负载平衡器在前端服务器之间分配负载。这意味着用户会话的状态存储在全局存储库中,如果未经测试,则可能是错误的潜在来源。

负载均衡器:部署方案

部署到负载均衡器后面的多台服务器将为您提供部署/释放机会,而不会造成任何中断。必须在测试环境中反复进行此操作以降低风险。

负载均衡器:SSL卸载

为了减轻解密前端服务器上所有传入流量的负担,可以由负载平衡器来代替。这意味着从负载平衡器到应用程序服务器的所有流量均未加密,但是从客户端到负载平衡器的所有流量均已加密。这也应包括在测试环境中以降低风险。

部署:安装脚本

在测试环境中重用生产中的确切部署机制。例如,这意味着要重复使用相同的脚本(PowerShell,Bash等),并且仅在部署到不同环境之间更改环境配置。

部署:构建和配置

将配置保留在内部。部署到测试环境的构建应该与部署到生产的构建相同。仅配置应更改。

设置:服务帐户

使用相同的结构在生产和测试环境中提供对系统的访问。尽可能分配服务帐户,以最大程度地减少人为干预,并在整个环境中进行类似设置。

设置:测试环境安装

如果可能,请使用相同的脚本从头开始设置测试计算机和生产计算机。如果应用程序在虚拟机上运行,​​则这些脚本在“原始”(默认)安装上运行,旨在使计算机准备好安装实际的应用程序。因此,这是独立于实际应用的机器的基本配置。

 

在讨论与DevOps相关的测试环境时,一个常见的问题是是动态生成测试环境还是依赖跨多个发行版的更永久的测试环境。

在需要时创建临时自定义环境(“雪花服务器”)的优点是不必在不使用时保持测试环境运行。但是,由于 马丁·福勒争论,雪花服务器很难复制,也无法轻松反映您的生产环境以进行测试。此外,随着测试自动化的引入,应该大大减少测试环境中的闲置时间。因此,我们建议在雪花服务器上使用永久性环境,除非这会给您的组织带来严重的不利影响。

管理测试数据

软件测试的价值在很大程度上取决于测试数据的质量。特别是在测试自动化中,所使用的数据需要具有一定程度的可预测性,以便能够成功运行确定性测试用例。

有几种方法可以确保测试数据符合所需的标准:

1.以生产数据为基准

如果被测系统允许,则将生产环境中的数据基线化到测试环境中,以确保数据是最新的,相关的并反映实际的使用模式。此外,它允许测试人员将生产中的错误重现到测试环境中。

并非所有系统都允许以此方式为基准设定基线,尤其是在应用程序是更大的互连设置的一部分的情况下。在这些情况下,基准测试通常以固定的间隔(即每月进行一次)完成,并且测试工作通常会在基准测试期间受到影响。

如果应用程序确实允许直接从生产中进行基准测试,则这应该是DevOps设置的一部分。这是通过从生产创建数据备份并将其导入测试环境(最好是每天)来完成的。确保您已制定计划,以掩盖生产数据,以不违反任何与个人数据有关的隐私法规。还考虑应如何处理数据以包括例如某些更适合测试的数据变体。换句话说,请确定是否有必要在导入过程中创建或更改任何数据记录以优化测试应用程序。

2.引导数据库

确保数据可预测的另一种方法是引导数据存储库。这可以通过几种方式来完成,例如运行的脚本将覆盖整个数据存储库或按计划注入数据。另一种方法是还原相同的数据库备份,例如每天确保系统可测试。

3.创建独立的测试用例

确保始终存在正确数据的一种简单且流行的方法是将数据创建作为测试用例的一部分。这样,可以在单个测试用例中控制数据的整个生命周期。数据的删除和清理也可以是测试用例的一部分,也可以作为计划任务的一部分。

下图总结了测试数据管理的所有三种情况。

生产-测试自动化03图4:测试自动化环境中的数据管理。

概要 

本文介绍了一些步骤,您可以采取这些步骤来为成功进行测试自动化最佳地准备测试环境。主要要求是:

  • 通过处理第三方系统依赖性,使有问题的应用程序可测试。可以通过以下两种方式之一来完成此操作:
    • 通过依赖应用程序内部的模拟数据或使用代理服务来封装应用程序以进行测试。 
    • 只需设置自动监控功能,例如调用所有相关第三方服务的网页。
  • 使测试环境适合您的DevOps管道。这包括与负载平衡器,部署,服务帐户,环境安装等有关的注意事项。
  • 确定如何管理测试数据。有几种方法可以确保测试数据具有一定的质量,包括:
    • 从生产数据基线
    • 引导数据库
    • 创建包含数据生成本身的测试用例

要了解更多有关自动化测试的最佳做法, 查阅LEAPWORK指南,以通过测试自动化降低风险,降低成本并提高价值。

CTA-StartTrial-8

卡斯珀·费伦德(Kasper Fehrend)
卡斯珀·费伦德(Kasper Fehrend)
LEAPWORK的高级产品布道者。

相关文章

如何使用无代码硒自动化移动Web测试

在持续的大流行中,随着实体店的关闭,网站,尤其是电子商务网站,比以往任何时候都必须更加专注于在线创建优质的客户体验。这就需要更快的测试和新的网站功能。

什么是移动Web测试,为什么要自动化?

网站和Web应用程序是企业获取客户的重要组成部分。只有一个糟糕的客户体验会影响他们的购买决定,尤其是在电子商务中。 在移动网站上拥有负面体验的用户将来向该业务购买的可能性降低了62%。 - Think with Google. 

通过自动测试简化ServiceNow中的系统升级

对于许多企业而言,ServiceNow是运营骨干。但是一年两次,恐慌不断发展。 现在的服务发布了两个主要的强制升级,需要进行大量测试。而且,功能测试和回归测试通常会被推迟或抛在后面。 如果推迟或跳过这些测试,则企业将承担风险。在这些关键时刻,系统管理员和开发人员面临着快速完成功能和回归测试的压力。