微软DevOps之Jmeter集成探讨

背景

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

作者：过佳昱

DevOps实施工程师，认证 ScrumMaster，曾为多家客户提供微软 Azure DevOps Server (TFS) 实施咨询、二次开发、报表定制等服务，包括：上海汇众汽车，上海通用汽车，农业银行，中关村银行等等。

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进行了集成，可以匹配不同模式开发团队对于自动化测试的诉求。