微软DevOps之Jmeter集成探讨

近几年很多企业都在推行DevOps,而DevOps所带来的一系列转变又给测试人员带来了巨大的挑战,如何提高测试的效率和质量成为急需解决的当务之急。

0
183

背景

本文探讨的是微软Azure DevOps Server(TFS)与自动化测试工具Jmeter的集成。近几年很多企业都在推行DevOps,而DevOps所带来的一系列转变又给测试人员带来了巨大的挑战。DevOps提倡开发,测试,运维之间的沟通合作,在采用了自动化CI/CD流水线进行部署之后,部署频率的加快给测试团队的工作效率带来了前所未有的挑战,以往依赖手工的测试方式变成系统的瓶颈。测试作为DevOps中的重要一环,势必需要实现自动化,不仅在开发阶段就要进行一系列的测试,在产品上线后也需要验证其可靠性,如何提高测试的效率和质量成为急需解决的当务之急。

Jmeter介绍

Apache JMeter是Apache组织维护的基于Java的开源压力测试工具。用于对软件做压力测试,它最初被设计用于针对Web应用的测试,后来扩展到其他测试领域。它可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本,Java对象、数据库,FTP 服务器,等等。

JMeter 可以用于对服务器、网络或应用模拟巨大的负载,在不同压力类别下测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序是否返回你期望的结果。

使用Jmeter进行自动化测试的优点:

  • 测试脚本维护方便

  • 支持功能测试和性能测试

  • 开源免费,100%基于Java编写,可集成到其他系统,可拓展各个功能插件

  • 多平台支持,可在Linux,Windows,Mac等支持java的系统上运行

  • 支持自带proxy或badboy录制测试脚本,可以快速的形成测试脚本

Demo项目介绍

为了能够更好的说明Jmeter的使用场景,我们使用了以下示例程序作为被测目标程序,并通过Azure DevOps Server集成Jmeter的方式将测试流程与企业日常开发模式的匹配方式进行说明。

使用Azure DevOps Server (TFS)的来针对Jmeter测试用例脚本进行版本管理,CI/CD调用测试用例脚本针对部署于Azure App Service的被测应用,完成接口测试,回归测试,性能测试。

项目介绍

微软提供的一套以《凤凰项目》小说中的PartsUnlimited公司为背景的样例程序,提供了完整的应用场景,此系统由三部分构成:

•       使用ASP.NET Core电子商务网站

•       使用开源的Java和MongoDB的生产管理系统

•       中间件系统

PartsUnlimited 样例项目接口代码

以下代码是标准的rest api实现,具备一定的普遍性

源码地址:https://github.com/Microsoft/PartsUnlimited

流水线设计图

为了能够和企业日常研发流程进行匹配,我们设计了以下CI/CD流水线。

  1. 在很多偏传统开发模式的企业中,开发和测试是不同的团队,因此使用不同的流水线更加匹配这个场景。
  2. 开发根据需求编写完相关代码后提交git版本库,自动触发CI流水线,执行单元测试。
  3. 测试人员手动触发CD流水线将对应版本部署到测试(Dev)环境,CD流程自动执行接口测试。
  4. 测试人员手动触发CD流水线将对应版本部署到QA环境,部署流程自动调用回归测试脚本。
  5. 针对性能测试,测试人员手动触发CI流水线。
  6. 以上CD流程都可调整为自动化执行,按实际情况调整。

下面让我们来看看如何使用Azure DevOps Server(TFS)集成Jmeter测试工具。

流水线搭建

首先,我们需要搭建Jmeter的环境,Jmeter本身支持单机部署和集群部署,小编这里为了简化环境使用了单机部署。

搭建Jmeter环境

在TFS agent上部署Jmeter4.0,下载链接如下,直接解压即可,需要java8以上。

详情地址:http://jmeter.apache.org/download_jmeter.cgi

对于集群环境部署不做过多描述。

Jmeter测试用例脚本编写

接口测试脚本,通过productId,查询商品详细信息并编写相应的断言,验证返回结果是否正确,保存为product-detail-I.jmx并提交到脚本库。

项目结构

考虑到测试人员和开发人员所属不同部门,我们将项目源码和测试脚本分别存放在两个不同的git库。

TFS调用Jmeter脚本参考如下

@echooff
FOR /f %%i IN ('dir /B %1\*.jmx') DO (md%2\dashboard\%%i
C:\apache-jmeter-4.0\bin\jmeter-n -t %1\%%i  -l %2\report\%%ireport.csv-j %2\log\%%i.log  -e -o%2\dashboard\%%i\)

%1为脚本路径  %2为日志报告路径

参数释义如下

持续集成

配置截图如下

发布结果

持续部署

此Demo项目设计三个环境用作演示,dev环境主要用于接口测试,QA环境主要用于回归测试和性能测试,其他测试类型这边不做考虑。

自动化编译完成后测试人员获取编译版本号触发部署到Dev环境,并自动执行接口测试,接口测试脚本提前提交到测试脚本库(测试脚本与环境相关的变量后续可以通过TFS部署任务统一替换,目前固定为dev环境)。

部署到Azure APP Service

调用测试脚本

注意:

部署完成后测试执行前如何保证应用已经就绪,需要添加一个验证环节。

在接口测试任务项上添加 预先部署条件/入口,配置一个api请求的验证功能,只有当验证通过才能执行后续的任务。

相关文档:

https://docs.microsoft.com/zh-cn/azure/devops/pipelines/release/approvals/index?view=vsts

配置截图

部署过程

部署结果

回归测试与此方式相同,这里不做阐述。

性能测试

假设已有性能测试环境,测试场景和测试脚本,性能测试通过独立的CI流水线由测试人员手动触发。

方式如下:

1. 通过Jmeter命令行调用测试

报表获取

2. 通过利用 Azure DevOps 的功能,使用基于云的负载测试提供更大规模的集群压力测试能力,避免本地部署大量测试资源的麻烦。

这里有两种方式:

第一种,通过Azure DevOps 自动配置负载生成服务器快速生成负载,测试完成后自动销毁,使用这些服务器将收取VUM(virtual user minutes)费用。

第二种,可以使用自己的服务器生成负载,这些服务器可以是本地服务器也可以是自己订阅中创建的服务器。

详情地址:

https://blogs.msdn.microsoft.com/devops/2016/05/20/feature-preview-creating-load-tests-using-http-archive/

https://blogs.msdn.microsoft.com/devops/2016/09/27/run-cloud-based-load-tests-using-your-own-machines-a-k-a-bring-your-own-subscription/

小编这里使用第一种方式配置如下

登陆Azure DevOps地址,查看测试详情

总结

如何验证产品是否达到上线标准,测试至关重要。作为推行DevOps的重要一环,提高自动化测试的效率和质量势在必行。本示例中将开源的Jmeter工具与微软Azure DevOps Server进行了集成,可以匹配不同模式开发团队对于自动化测试的诉求。

end.

- leansoftx.com -