背景
本文探讨的是微软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编写，可集成到其他系统，可拓展各个功能插件
支持自带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流水线。
在很多偏传统开发模式的企业中，开发和测试是不同的团队，因此使用不同的流水线更加匹配这个场景。
开发根据需求编写完相关代码后提交git版本库，自动触发CI流水线，执行单元测试。
测试人员手动触发CD流水线将对应版本部署到测试（Dev）环境,CD流程自动执行接口测试。
测试人员手动触发CD流水线将对应版本部署到QA环境，部署流程自动调用回归测试脚本。
针对性能测试，测试人员手动触发CI流水线。
以上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脚本参考如下
@echooffFOR /f %%i IN ('dir /B %1\*.jmx') DO (md%2\dashboard\%%iC:\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进行了集成，可以匹配不同模式开发团队对于自动化测试的诉求。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
