性能测试

一、分布式压测 在单机上通过JMeter做性能测试，由于受到内存、CPU、网络IO的限制，会出现服务器压力还没有上去，但压测服务器已经由于模拟的压力太大（例如并发数太大）导致死机的情况；因此这种情况下，可以通过多台机器模拟负载实现分布式压测。 分布式压测需要server（控制机）和agent（压力机），server只负责进行调度，压力测试瓶颈大都在带宽上面，需要保证压力机的带宽要比服务器的带宽高，不然压力上不去。 需要保证agent和server都在一个网络中，且在多网卡环境需要保证启动的网卡都在一个网段。 需要保证server和agent之间的时间同步 关闭防火墙 二、性能测试类型 基准测试：给系统施加较低压力，记录系统运行时的各项相关参数，以此作为该系统的基础指标； 负载测试：通过对系统不断增加压力，或增加一定压力下的运行时间，直到系统的某项指标达到临界值； 压力测试：系统处于超过预期负载的环境下运行，通过各项指标参数分析系统的处理能力； 稳定性：给系统加载一定业务压力的情况下（不一定超出预期负载指标），让系统运行一段时间，通过查看系统各项指标判断是否稳定； 实际项目测试中，根据业务需求，采取不同的性能测试方案； 三、性能测试指标 1.RT响应时间：用户发送一个请求到用户接收到服务器返回的响应数据这段时间称之为响应时间，包含网络中传输的时间及服务器处理的时间； 来源：

并发数，线程数，吞吐量，每秒事务数（TPS）都是性能测试领域非常关键的数据和指标。 那么他们之间究竟是怎样的一个对应关系和内在联系？ 测试时，我们经常容易将线程数等同于表述为并发数，这一表述正确吗？ 本文就将对性能领域的这些关键概念做一次探讨。 文章可能会比较长，希望您保持耐心看完。 1. 走进开封菜，了解性能 ①老王开了家餐厅 我们的主角老王 ，在M市投资新开业了一家 ，前来用餐的顾客络绎不绝： 餐厅里有4种不同身份的人员： 用户一次完整的用餐流程如下： 顾客到店小二处付款点餐 => 小二将订单转发给后厨 => 后厨与备菜工配合，取材完成烹饪后交给小二 => 小二上菜，顾客用餐。 假设所有顾客都不堂食而是打包带走，也就是不考虑用户用餐时间。餐厅完成一次订单的时间是多久？ 订单时间 = 顾客点单时间 + 前台接收转发时间 + 后厨取材烹饪时间 + 后厨交给服务员，服务员上菜时间。 说白了就是每个流程的耗时相加。 假设以上时间分别为1，1，5，1（分钟），那么一次订单的完成时间就是8分钟。 ②问题来了 餐厅当然不可能只有一个人就餐，否则老王不要带着小姨子跑路。 所以我们接下来看多人就餐的情况。 假设同一时间点上有两人 就餐，会发生什么情况？ 第一位用户与第一个场景一样，仍然是点单-下单-烹饪-上菜，8分钟后第一位顾客拿着打包的食物离开。 第二位用户则有所不同了。假设小二，厨师

性能测试的目的，是通过模拟真实的业务场景和海量的用户请求及数据对业务系统进行多种场景的测试， 来验证各个服务的性能表现是否满足实际的业务需要。 长期来看，性能测试最终的目标是为生产环境容量规划提供可靠地参考数据，使生产服务的可用性、扩展性和稳定性更高， 让技术更好的服务业务，创造更多的价值 。 从整个性能测试的生命周期来说，测试报告的产出就意味着一次完整性能测试项目的结束。那么，怎样的测试报告，才是真正具有价值的呢？ 这篇博客，聊聊一份完善且具有价值的性能测试报告，都包含哪些内容。。。 关键词：信息完善，简洁明了，有图有数据有结论！！！即 让每一个业务服务能够清晰地知道： 单机水位是多少、满足业务需求要上多少机器、什么时候该加机器、什么时候应该减机器。双11等大促场景需要准备多少机器，既能保障系统扩展性和稳定性，又能节约成本。 一份完善且具有价值的性能测试报告，主要包含如下几个方面： 一、测试背景 首先要阐述本次性能测试的背景，即被测系统类型，面向哪些用户，具备什么特点，为什么要进行性能测试，预期的一些指标等等。 比如：为了保证“双十一”大促期间，系统能稳定运行且保障业务的高可用，进行性能测试。 核心：评估系统性能、分析性能变化趋势、定位系统瓶颈风险、协助规划系统容量。 二、测试目的 测试的目的要根据测试背景来分析设定，比如： 1、线上服务由于流量过高某部分应用挂了，那测试目的就是

移动端测试的八大过程 一、安装/卸载； 真机上安装、卸载、高版本覆盖安装、低版本覆盖安装、卸载后安装高版本； 安装关注点：版本号、渠道号、数字签名（用抓包工具辅助查看）、安装成功后启动向导、安装过程中对意外情况的处理（取消、死机、重启、断电、内存不足、断网）、安装进度条、主要功能流程； 卸载关注点：卸载过程中的意外情况处理（取消、死机、重启、断电、内存不足、断网）、卸载进度条； 第三方软件协助安装、卸载、高版本覆盖安装、低版本覆盖安装、卸载后安装高版本； 在线升级： 升级注意点：升级提示、取消更新/强制更新、后台更新（ios的自动更新）、跨版本升级、升级过程中异常情况的处理（取消、死机、重启、断电、内存不足、断网）、升级进度、不同网络下升级； 第三方软件支持：itools、豌豆荚、91助手、华为助手、360、应用宝等； 二、业务功能测试； 根据需求文档、原型图和设计稿验证app各个功能的实现；　　　 共性功能： 注册：用户名密码的输入（同文本框编辑“2-1）”）、用户名密码长度限制、注册后的页面提示（手机短信提示）、前台和后台数据一致、； 登录：用户名密码的输入（同登录“1-1）”）、非法登录次数限制、多设备登录（MTOP现有原则，一个应用同时只允许一台设备登录）、禁用账号登录、登录成功信息、登录后有注销按钮、登录超时处理、登录过程断网处理、登录过程切换网络； 注销

1.性能测试必要性评估 常见关键评估项 监管单位要求性能报告 涉及财产、生命安全的系统 首次投产的大型系统 核心数据库、软硬件升级 用户量、业务量增长30%以上 单版本单业务评估权重 是否平台核心位置 是否存在部署方式调整或优化 是否增加了性能风险较高的调整 是否存在客户要求必须测试的业务流程 是否涉及多个功能缺陷的修复且流程发生较大变化 2. 性能测试需求分析 业务层面 用户大量使用的功能 日常占比80%以上的业务 特殊交易日或峰值80%的业务 核心业务发生流程重大调整的业务 项目层面 曾经测试过性能调整了架构的业务 逻辑复杂、关键的业务 可能消耗大量资源的业务 与外部系统存在接口调用、大量交互的业务 调用第三方业务组件且逻辑复杂的业务 性能测试需求评审 可测性 可搭建相对真实的环境 一致性 用户需求、生产需求（真实性）、运营需求（规划未来发展要求） 正确性 3.性能测试用例设计 测试模型建模 举例 ：登陆业务操作流程（思维导图） 打开首页 输入用户名、密码登陆 退出系统 场景用例设计 分类 单业务基准测试：是否满足系统设计和用户期望的性能指标 单业务压力测试：最大负载下，持续服务的时长 单业务负载测试：系统能够承受的最大负载 综合业务压力测试 综合业务负载测试 综合业务稳定性：核心业务基准负载下长时间运行系统稳定服务的能力 线程数计算 场景用例 脚本用例设计 4.测试数据构造

·Jmeter的二次开发，常见的有以下几种类型： ·扩展、修改Jmeter已有的组件（源代码） ·扩展、修改Jmeter已有的函数。 ·完全自主开发一个新的组件（依赖于Jmeter提供的框架）。 ·扩展请求。 通常来说，我们都建议直接通过jmeter所提供的java测试接口来进行请求的扩展。 ·准备工作： ·需要用到的jar包。 ·ApacheJMeter_core.jar ·ApacheJMeter_java.jar ·需要用到的类： AbstractJavaSamplerClient //Jmeter提供的java请求的抽象类。需要继承该类。 Arguments 用来定义GUI界面参数的。 JavaSamplerContext 用来接收GUI界面所传递的参数值。 SampleResult 请求类，用来实现请求的开始计时、结束计时、请求数据的展示、响应数据的展示、请求结果的状态等。 ·导出： 将写好的类（多个类的话就直接导出package），右键导出为jar file即可。 导出的jar包最后放在jmeter的lib\ext目录下。 ·注意事项： ·一般来说，对于要扩展的请求方法，我们建议先独立打包（jar包），然后再在扩展jmeter的java请求时添加到classpath，使得可以import调用。这样最终的产出物就是分离的。 ·一个是我们自己写的扩展的jmeter的jar包

Jmeter函数的二次开发。 ·什么时候需要进行jmeter的自定义函数扩展呢? 一般来说，如果我们要对数据进行处理，而jmeter没有提供相应的功能（函数），此时我们可以自己进行自定义函数的扩展。 常见的: ·数据的加密处理。 真实环境下，数据的加密处理是由前端来实现的。那么我们在jmeter中要进行接口or性能测试的时候，通常就要去实现数据的加密然后发送。 ·额外的功能or数据处理的需求。 ·Jmeter中自定义函数的相关知识点。 ·package的最后一个节点的名称必须是functions。 ·继承的类是abstractFunction类。 方法有： getArgumentDesc() execute() getReferenceKey() setParameters() 值的传递有关的类是： CompoundVariable 该类提供了一个execute()方法，用来将获取的值转为string类型。 来源： https://www.cnblogs.com/wendy-0901/p/11898642.html

JMH是有OpenJDK开发的基准测试（Benchmark）工具。JMH可以为写基准测试和运行测试提供很好的支持。JMH在C oncurrent Benchmarks也提供很好的支持，可以说是多功能测试工具。JMH在2013被公布出来，现在最新版本到1.9。 JMH基本用法: JMH环境构建 1 使用maven工程，直接在项目中引入相应的jar包 <dependency> <groupId>org.openjdk.jmh</groupId> <artifactId>jmh-core</artifactId> <version>${jmh.version}</version> </dependency> <dependency> <groupId>org.openjdk.jmh</groupId> <artifactId>jmh-generator-annprocess</artifactId> <version>${jmh.version}</version> <scope>provided</scope> </dependency> 2 或者直接用JMH的 archetype创建： mvn archetype:generate \ -DinteractiveMode=false \ -DarchetypeGroupId=org.openjdk.jmh \

性能测试造数据的过程找中发现造下面格式的数据文件比较麻烦 解决： 可以多添加几个CSV数据文件设置，每个中加一个参数 还可以把姓名，卡号，存到数据中，从个数据库中读取 之前一直想着，写到代码，写到文件中等 来源： https://www.cnblogs.com/jpr-ok/p/11884366.html

新版本和旧版本的性能测试数据差在10%以上 来源： https://www.cnblogs.com/tarzen213/p/11880479.html