使用SOAtest进行功能回归测试,作为持续集成过程的一部分

实现速度,同时保护您的应用程序不受退步影响

持续集成“CI”是一种广为人知且(在这一点上)被广泛采用的实践。它是显著提高应用交付速度的必要第一步。

持续集成允许开发人员将他们的变更推送到源代码的“主”分支中,一个开发人员可能在一天内向主分支推送许多变更。为了确保主分支是原始的、可构建的和高质量的,在每次变更后进行测试是至关重要的,因为它是应用程序源代码的黄金副本。

如果你对持续集成感兴趣,我推荐Martin Fowler的一篇较早但仍然有趣的文章(https://www.martinfowler.com/articles/originalContinuousIntegration.html),介绍软件开发中集成的历史和CI的好处/最佳实践。

今天我们将关注如何配置Parasoft SOAtest来执行功能回归测试,作为持续集成过程的一部分。在这篇文章中,我将描述使用Jenkins(一个流行的自动化平台)配置SOAtest的步骤。我们将使用开源的Parabank应用程序,并使用Docker部署它,以保持简单。

这将如何工作?

下图解释了我们将在本文中进行的设置。最好从左到右阅读。

简而言之,Jenkins会从Github中检查出一个repo,其中包含名为“Parabank”的SOAtest项目,其中包含REST测试。Jenkins还将从Docker Hub中提取一个名为parasoft/parabank的Docker镜像。这个镜像不仅包含Parabank,还包含Tomcat和正确的Java运行时环境。

然后,Jenkins将运行这个Parabank镜像的一个实例(称为“容器”)。之后,Jenkins会告诉SOAtest运行我们从Github拉来的测试,这样我们就可以验证我们的Parabank实例。

现在,这并不符合真正的持续集成的精神(因为我给你提供的是一个预构建的应用程序),但我想使用Docker来为你省去用Maven构建Parabank的麻烦,并且必须安装和配置Tomcat/Java。

下面提供了一个更真实/现实世界的CI图。开发者将源代码检查到Github中。现在我们要测试的是,即使在Developer修改后,应用程序仍然处于良好状态。

Github中的源代码修改会触发Jenkins中的构建,Jenkins会启动Maven自动构建(执行JUnit测试)。如果所有的单元测试都通过了,那么打包后的应用程序(parabank.war)就会部署到Tomcat上。然后SOAtest开始执行功能“黑盒”测试。

只有在单元测试通过(在Maven构建过程中)和功能“黑盒”测试通过(在SOAtest执行过程中)之后,开发者的原始修改才会被认为是好的。

让我们来看看第一张图中配置流程的必要步骤吧!

配置SOAtest和Jenkins

前提条件:

  • 一台能够运行Docker的Windows 10机器(其他操作系统也可以,但我在本文中提供的一些命令可能有不同的语法)。这台机器必须有互联网连接。
  • 在机器上某个地方创建一个localsettings.properties文件。将我的示例文件(https://github.com/sdebrosse/soatest-automation-example/blob/master/localsettings.properties)的内容复制到其中。如果你有一个节点锁定的许可证,把它添加到第5行。如果你使用许可证服务器,将第6行设置为true,并在第3行添加你的许可证服务器主机名。我们稍后将需要这个文件的路径。
  • Jenkins 1.651或更新版本安装在同一台机器上
  • SOAtest 9.10或更新的版本,并安装在同一台机器的PATH上(这样你就可以从任何目录调用soatestcli)。
  • 安装Docker,并在同一台机器的PATH上。

步骤:

1. 在你的浏览器中登录Jenkins。

在Web浏览器中登录Jenkins(Jenkins通常部署在一个URL,如http://<JENKINS_HOST_IP>:8080/jenkins)。

2. 我们要从安装一些Jenkins插件开始。选择左侧的“Manage Jenkins”,然后在出现的新菜单中选择“Manage Plugins”。

3. 在“可用”标签下,选择并安装这些插件:

a. “Parasoft Findings”

b. “Git插件”(3.30版本)选择“安装不重启”,然后在安装页面,勾选“安装完成且无作业运行时重启Jenkins”的选项。

4. 回到Jenkins主菜单形式步骤1。在左侧,选择“新项目”

5. 提供名称“Parabank Deploy and Test”,并选择“Freestyle”项目,然后确定。

6. 在出现的配置菜单中,向下滚动到源代码管理并选择 Git。在 Repo URL 栏中添加以下 URL:https://github.com/sdebrosse/soatest-automation-example.git 。其他所有字段都可以保持默认值。

7. 滚动到页面底部,在“构建”下添加“执行 Windows 批量命令”的构建步骤(如果使用 Linux,则选择“执行 shell”)。

8. 复制这里的脚本(https://github.com/sdebrosse/soatest-automation-example/blob/master/DeployParabankContainerAndTest.bat)内容,并将其粘贴到新的构建步骤字段中。你需要更改脚本顶部的两个变量的值,以反映你自己的 localsettings.properties 文件的路径和你想要创建临时工作空间的位置(SOAtest 将在测试过程中创建这个工作空间)。脚本中的注释解释了每一行发生了什么。

9. 就是这样。我们现在已经准备好执行我们的Jenkins作业了!确保你首先关闭所有打开的SOAtest实例。然后选择配置菜单底部的保存,然后点击左侧的“Build Now”。

10. 你可以点击左边正在运行的作业,然后查看实时控制台输出。

 

如果一切正常的话,日志最后会显示“SUCCESS”。这意味着你已经成功地从Github上调出了一个SOAtest测试项目,部署了一个带有Parabank的Docker容器,并针对这个Parabank实例执行了测试。在这个过程结束时,我们自动停止了Parabank容器,并删除了我们的temp_workspace来清理我们的环境.但是等一下,你可能已经注意到了,从查看日志中,我们有一些测试失败......

是的,我们对Parabank的一些测试失败了。如果我们希望我们的Jenkins构建因为SOAtest测试失败而失败,我们在调用soatestcli时添加-fail标志。像这样:

soatestcli.exe -fail -data %TEMP_WORKSPACE_PATH% -resource /Parabank -config “builtin://Demo Configuration” -localsettings %LOCALSETTINGS_PATH%

如果你在SOAtest桌面UI中打开测试,你会发现这个故障主要是测试数据/测试环境配置问题。我们的贷款处理器拒绝了一笔本应批准的贷款。

我们该如何处理?

测试环境配置和测试数据是可靠的自动化测试的最大障碍。在未来的文章中,我将探讨一种名为服务虚拟化的技术如何帮助确保我们始终拥有所需的准确环境配置,以便随时可靠地运行我们的测试——这将使我们从持续集成转入持续测试的世界。

猜你喜欢

转载自blog.csdn.net/Pokemogo/article/details/115164974