性能测试之自动化性能测试（全链路）
Posted 出处不详，经久不息
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了性能测试之自动化性能测试（全链路）相关的知识，希望对你有一定的参考价值。
目录
【写在前面】
读书笔记，做记录，供自学，如侵，请告知，会删。
1. 基础知识
1.1 区别性能测试自动化和自动化性能测试
（1）性能测试自动化
以自动化的形式开展性能测试工作。
通常用JMeter， LoaderRunner等工具，模拟大规模的用户来使用产品的场景，来进行性能测试。
早期是手工执行。
（2）自动化性能测试
指的是让性能测试可持续的进行。能够进行可持续的性能测试。
当需要执行性能测试时，直接运行我们的脚本。脚本，环境，数据是可以复用的。
在任何节点上发起测试，不需要做很多前置规划。
1.2 自动化性能测试的作用
（1）持续测试
让性能测试可持续的进行。
大版本准备发行时，直接用脚本和环境去执行，不需要从头开始规划。
（2）回归验证
每个版本进行一次简单的回归验证，确保性能不出问题。
这里不强调调优，只需要该版本跟之前版本跟之前的性能没有太大的差别，即可。
（3）准入关卡
与主流的CICD工具集成，自动触发并组我诶版本质量中的一环。
接口自动化测试，也差不多是这几项。
1.3 几个常见问题
（1）自动化性能测试是否不需要写脚本？
需要写。
对脚本的复用性和健壮性要求更高。
单脚本的很多信息可以写死，但是这里的脚本（流水线上），对脚本的兼容性和可控性要求更高，很多数据不能写死，要去获取不同环境下的，或者最新的数据。
（2）自动化性能测试是否可以自动完成监控并发现问题？
是的，这是整体的目标。
单个性能测试时，可以手动监控和分析。
但是这里需要给指标设定响应的阈值，SLA，服务的可用性测试（达到什么情况才算通过）。
来自动完成监控和发现问题。
（3）自动化性能测试能否自己定位问题？
现在还不可能。
未来在AI更智能的时候，有可能做到。
现在还是需要拿到数据之后自己去分析定位。
（4）自动化性能测试是不是就是全链路压测？两者有什么区别
不一样。
2. 常用工具
2.1 Jenkins持续构建平台
（1）流水线和CICD
1）什么是流水线？用来做什么事？
流水线指的是多应用串联发布。
最终交付的是完整的功能项（功能清单）。
流水线指的是把多个CICD的步骤串连到一起，加上特定的开关，对有序或无序的构建进行部署。
2）什么是CICD？跟测试有什么关系？
CI：持续构建。最终产物是可发布的包（比如Jar, War包），替代了手动拉代码打包。集成单元测试，接口测试（少量的核心用例）。
CD：自动部署。打完包后，发布到指定（测试）环境。端到端的测试用例集（覆盖主流程）。
CICD指的是摸单个服务。
（2）Jenkins的本质
可以做CICD，可以做流水线。
基于插拔式的组件管理方式。有大量的插件。
原来用Shell脚本，后来多用Jenkins。
（3）Jenkins的搭建和启动
此处略，已在其他文章中做了描述。
也可以通过命令来启动： java -jar .\\jenkins.war
或者放到tomcat中启动。
（4）基础操作
如何构建一个job？
（5）插件管理
1）Jenkins常用的一些插件：Jenkins常用插件
Jenkins自带的可选插件库不够齐全，因此，可以从该镜像连接下载自己需要的插件，这个地址是国内的镜像：http://updates.jenkins-ci.org/download/plugins/
如果是手动下载的，那下载后，登录Jenkins, 在插件管理的“高级”中，通过“上传插件”来实现手动安装。
2）Jenkins API：https://jenkinsapi.readthedocs.io/en/latest/index.html
很多时候，需要用Jenkins的API，来做二次开发。
Jenkins的进阶使用。
（6） JMeter和Jenkins的集成
所有想要跟Jenkins集成的应用，必须支持命令行的启动模式。
1）JMeter支持非GUI形式下的运行：
jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]
2）JMeter运行结果可视化的插件：
Publish html reports 插件
3）简单的Jenkins Job的构建
实现了持续测试，多次使用脚本。
命令：
D:
cd \\Work\\apache-jmeter-4.0\\bin
.\\jmeter -Jthread=%thread% -Jnumber=%number% -n -t .\\$jmx.jmx -l ../report/$report_name.jtl
构建后操作：
Publish Performance test result report中，手动获取报告： D:\\Work\\apache-jmeter-4.0\\report\\$report_name.jtl
（注意，这个插件在使用时，无法获取report_name的参数值，构建结果会报错。所以这里需要写死这个report_name）
其中，参数化jmx, report_name, thread, number等
补充：
如何从JMeter脚本中提取出线程数和迭代次数，使之变成参数变量，传给Jenkins？
答：JMeter中所有的参数，都可以通过函数助手中的__P函数来提取。
4）jtl报告文件如何解析？
一. 用插件：Publish Performance test result report
使用文本形式,notepad。得到原始的数据。
用excel打开。
二. 用-e -o web命令，用html报告去打开。（此时就不需要用Publish Performance test result report插件）
2.2 思考几个待解决的问题
（1）JMeter的环境如何管理（如何管理负载机）？
容器化基础环境，让JMeter的执行机可动态扩容。比如用docker。
（2）性能测试环境如何维护？
系统资源监控可视化。
（3）测试数据如何维护？
自动化性能测试平台。
2.3 结果可视化（报表展示平台）
Grafana
普罗米修斯
附图：自动化生成测试平台技术架构参考（重要）
2.4 实现时的一些实际难点
（1）性能环境如何维护？
定期全量升级环境（至少两个月更新一次） 。
如果有版本频繁更新，那根据实际情况来。
（2）脚本及基础数据如何维护？
数据代码化，跟着版本走。
把脚本当代码来管理。
数据来源：接口，SQL，导入导出数据。
测试资源服务化。
（3）如何有效的整理报告，诊断问题？
需要靠个人经验。
3. 业务架构演进和不同业务架构下性能测试的重点
3.1 业务架构一
第一阶段：访问人数有限，数据量不大，只需要一台服务器就足够了。这时所有的应用程序，文件，数据库等所有资源，全部集中在这台服务器上，也称为集中式部署。
此时，无所谓性能测试，业务优先，硬件足够好就行。
3.2 业务架构二
第二阶段：随着用户量的上升，业务的发展，一台服务器不能满足要求。用户访问量越来越大，数据量也越来越大，此时，分层治理的思路出现了。
无所谓性能测试，业务优先，但性能问题已经有所体现，硬件足够好就行。
（性能测试主要还是针对服务器）
3.3 业务架构三
第三阶段：业务越来越复杂，服务端不堪重负，需要解耦。
逐步引入性能测试并关注用户性能反馈，关注单点性能，不行就上负载。
补充：什么是RPC协议通信？
基于应用层的。
待补充..........
3.4 业务架构四
第四阶段：当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
（各种服务？）这里还不能算微服务。因为微服务最重要的特征是：服务的自主注册发现。
关注局部性能问题，解决单点性能故障，上负载。
3.5 业务架构五
第五阶段：当服务越来越多，容量的评估，小服务器资源的浪费等问题逐渐显现，此时需要增加一个调度中心，基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心（SOA）是关键。（只有出现了资源调度和治理中心，才能说这个架构是微服务，不然只能算业务的拆分。）
关注全局性能问题，提倡全链路压测，不行就换框架。
这里性能测试最核心的是：注册中心，调度中心，熔断，降级（业务变得不太重要了）
3.6 示例：业务的技术架构图（包含常用的技术）
知识储备要足够！不一定要每一个都精通，但要求最好什么都了解一些。扩大知识面！
4. 全链路压测
4.1 什么场景需要做全链路压测？
有追求有余力的公司，支付场景比较高并发的公司。
支付场景，也就是支付相关的各个服务（订单，派送，入库出库等），相连密切等等，这样的场景比较复杂，而且是高并发，对性能测试有比较高的要求。
最开始是淘宝为了应付双十一，开始引入了全链路压测。后来是滴滴，美团等。
全链路压测，需要很大的技术成本和硬件成本。
4.2 什么阶段的公司适合做全链路压测？
（1）微服务的架构。
为什么要强调微服务架构呢？因为如果不是微服务架构，那它天然就是全链路的了。
（2）需要架构组，得有Mtrace的这种微服务RPC消息跟踪体系架构，能改中间件。
（3）各部门能配合全链路压测调试和部署，运维的机器资源部署。
（4）简单性能测试要通过，即单点的性能测试要没问题。
（5）有更高的技术追求。
4.3 全链路压测的技术栈
（1）流量怎么来？（解决流量来源问题）
这里就不能造数据了，因为数据量太大了。
通过HTTP录制回放，中间件修改。
跟Loadrunner的录制回放不一样，Loadrunner是单用户的操作问题。
全链路压测来说，是要录制所有人全天候的要求。
这里的录制回放是放在服务端的，对服务端所有人的所有请求做录制回放。常用的做法是该中间件，所有的请求都通过中间件。在tomcat或nginx层做修改，做代理。
（2）流量如何生成？（解决压力生成问题）
线上流量回放，NIO的并发设置，基于Netty框架的自研。（解决高并发的问题）
（3）业务链路跟踪（解决问题定位的痛点）！！！！！！
TranceID跟踪，ELK链路跟踪。 （可以尝试去推动的，很有技术价值和业务价值）
共同特点是生成统一的ID，记录到统一的日志中，拿到ID就可以查到这个ID在本系统或跨系统的路径和操作日志等。
（4）全局监控（解决节点监控）
全链路监控工具Zipkin，PinPoint，全链路监控工具。
（5）数据污染如何解决（在生产商进行的前置前条件）
数据标识（在HTTP请求头上加），影子库。
补充：
现在很多解决问题的技术都比较成熟了，难点是如何说服业务方和其他部门等来配合做这个全链路的改造。
推荐参考文章：
思考：有能力搞定上述（包括推荐文章中）技术栈吗？
答：比较难，也没有速成的方法。
全链路压测，是需要全IT部门的共同投入，不是测试人员可以推动的。
公司的高端技术能力是否支持，能搞得定自定义中间件吗？是否有自研的消息队列？如何处理海量的数据分隔？是否有能力做技术NIO的改造？（阿里，有赞）
运维体系是否支持灰度发布？是否有熔断，降级机制？
业务系统为什么要支持你做相应的改造？他们自己的KPI都还不一定能完成。
平台比个人能力更重要！平台要大于个人能力。好的平台，才能充分发挥个人能力。
5. 性能测试的发展
（1）如何对待一线的新技术？
答：
（1）了解行业最新动态，保持技术敏感度。
（2）结合公司实际情况，推动部分技术的尝试和落地。
（3）积累技术能力，不断保持学习的能力和动力。
思考：代码染色？敏捷测试？DevOps？质量门禁？
（2）性能测试的前景
有助于系统了解产品技术架构，拓宽技术视野。
有助于全局提升技术能力，深度参与系统研发工作。
有助于形成完整的业务逻辑思维，更好的解决业务痛点。
以上是关于性能测试之自动化性能测试（全链路）的主要内容，如果未能解决你的问题，请参考以下文章