目录
1. 基础知识
1.1 区别性能测试自动化和自动化性能测试
（1）性能测试自动化
（2）自动化性能测试
1.2 自动化性能测试的作用
（1）持续测试
（2）回归验证
（3）准入关卡
1.3 几个常见问题
（1）自动化性能测试是否不需要写脚本？
（2）自动化性能测试是否可以自动完成监控并发现问题？
（3）自动化性能测试能否自己定位问题？
（4）自动化性能测试是不是就是全链路压测？两者有什么区别
2. 常用工具
2.1 Jenkins持续构建平台
（1）流水线和CICD
（2）Jenkins的本质
（3）Jenkins的搭建和启动
（4）基础操作
（5）插件管理
（6）JMeter和Jenkins的集成
2.2 思考几个待解决的问题
（1）JMeter的环境如何管理（如何管理负载机）？
（2）性能测试环境如何维护？
（3）测试数据如何维护？
2.3 结果可视化（报表展示平台）
2.4 实现时的一些实际难点
（1）性能环境如何维护？
（2）脚本及基础数据如何维护？
（3）如何有效的整理报告，诊断问题？
3. 业务架构演进和不同业务架构下性能测试的重点
3.1 业务架构一
3.2 业务架构二
3.3 业务架构三
3.4 业务架构四
3.5 业务架构五
3.6 示例：业务的技术架构图（包含常用的技术）
4. 全链路压测
4.1 什么场景需要做全链路压测？
4.2 什么阶段的公司适合做全链路压测？
4.3 全链路压测的技术栈
（1）流量怎么来？（解决流量来源问题）
（2）流量如何生成？（解决压力生成问题）
（3）业务链路跟踪（解决问题定位的痛点）！！！！！！
（4）全局监控（解决节点监控）
（5）数据污染如何解决（在生产商进行的前置前条件）
5. 性能测试的发展
【写在前面】
读书笔记，做记录，供自学，如侵，请告知，会删。
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）性能测试的前景
有助于系统了解产品技术架构，拓宽技术视野。
有助于全局提升技术能力，深度参与系统研发工作。
有助于形成完整的业务逻辑思维，更好的解决业务痛点。