性能测试

目的 ：寻找或证明系统的某些关键性性能指标 　　1、全新系统，从未做过性能测试 　　　　寻找关键性的性能指标值 　　2、基于已有的性能测试基础上，再次做性能测试 　　　　验证预定的性能指标值 来源： https://www.cnblogs.com/eee222/p/11743651.html

拼店压测全过程 来源： https://www.cnblogs.com/Slowfish/p/11728597.html

性能测试分类 性能测试是一个非常广泛的概念，包括很多方面的测试，也可称之为非功能测试。 移动端性能测试（耗电量、稳定性、弱信号、空数据） 自动化测试属于功能测试的范围，由于其测试方法要求测试人员拥有一定的代码能力，所以被单独分成一个测试模块 具体分类（测试范围） 　　1、负载测试：通过逐步加压的方法，达到既定的性能阈值的目标，阈值的设定应是小于等于某个值，如cpu使用率小于等于80% 　　2、压力测试：通过逐步加压的方法，使得系统的某些资源达到饱和，甚至失效的状态，简单粗暴的解释就是什么条件能把系统压崩溃。 　　3、并发测试：在同一时间内，多个虚拟用户同时访问同一模块、同一功能，通常的测试方法是设置集合点。 　　4、容量测试：通常是指数据库层面的，目标是获取数据库的最佳容量的能力。又称之为容量预估。具体测试方法为在一定的并发用户，不同的基数数据量下，观察数据库的处理能力，即获取数据库的各项性能指标。（如压测100个用户，数据库一个表有500、1000条数据，同样的并发用户，结果是不一样的） 　　5、可靠性测试：又称之为稳定性测试或疲劳测试。是指系统在高压情况下，长时间的运行系统是否稳定。如cpu使用率在80%以上，7*24小时运行，系统是否稳定。（最能发现内存溢出） 　　6、异常测试：又称之为失败测试。是指系统架构方面的测试。如在负载均衡架构中，要测试宕机、节点挂掉等情况系统的反映

行业需求 - 技能 　　能力需求： 　　1、熟悉Linux（环境部署、达到监控、定位）、windows等操作系统，熟悉shell脚本； 　　2、熟悉jvm调优，tomcat调优等基础策略； 　　3、熟悉mysql数据库（能对数据库进行监控、明白原理） 　　4、熟悉掌握Java、python、groovy等至少一门编程语言； 　　5、熟悉常见的压测工具，如jmeter、loadrunner、fiddler，熟悉常见的分析调优工具，如visualvm、yourkit、jps、jstar（均跟Java相关）等； 　　6、熟悉性能测试的整体流程，能够通过产品需求，梳理出性能测试点，并给出计划方案，对系统性能瓶颈进行定位（监控能力-利用工具进行监控才能定位瓶颈）及优化分析； 　　7、常用网络协议http（所谓的接口测试90%以上应用的都是http协议） 来源： https://www.cnblogs.com/xly22/p/11726475.html

·Jmeter入门 ·Jmeter的简介： ·Jmeter是一款基于纯JAVA语言开发的开源的性能测试工具。 ·Jmeter的下载： ·最新版：http://jmeter.apache.org/download_jmeter.cgi ·历史版本：https://archive.apache.org/dist/jmeter/binaries/ PS：如果是windows下使用，则下载zip压缩包，如果linux平台使用，则下载tgz。 ·安装和使用： Jmeter是基于java的应用，所以需要有java环境。 ·JDK的安装和配置： ·Java的版本，一般来说下载se的版本，然后版本号只需要和Jmeter的要求匹配。 ·环境变量的配置 需要配置的环境变量有两个： ·JAVA_HOME：值就是java的安装路径，不包含bin目录。 ·PATH变量：是修改而不是新建，将“%JAVA_HOME%\bin;”加入到path变量的最前面。 PS：通过java -version和javac -version进行检测即可。 要保证java和javac的版本的一致性。 ·Jmeter的目录介绍 ·bin目录：该目录存放了jmeter的主jar包，启动脚本，配置文件。并且该目录是jmeter默认的日志存放目录。 ·ApacheJmeter.jar：这是jmeter的主jar包（主类所在的包）

·场景设置。 性能测试场景依托于性能测试脚本，但是又独立于脚本。 所谓场景(scenario)，就是用来模拟多用户运行性能测试脚本的情形，是来源于我们对于业务场景的分析的。 性能测试对于业务场景的分析，一般来说我们采取的策略是悲观的策略，多考虑一些相对极端的情况。 然后对于业务场景的模拟，一般我们都会采用等价、幂等的思想。 一般来说，性能测试场景分为两类：单一场景和混合场景。 ·单一场景：在一个场景中，只跑一个脚本（一类业务）。 多用于负载测试、压力测试、容量测试、并发测试、基准测试等。 ·混合场景：在一个场景中，运行多个脚本（多类业务）。 多用于负载测试、压力测试（主要）、容量测试、配置测试、并发测试（主要）等。 ·在LR中，是通过Controller组件来实现场景的设计、运行等功能的。 LR的Controller组件提供了两种类型的场景创建方式： ·目标场景：goal scenario：以特定的性能测试目标为驱动来实现的场景，该类场景中，我们只能设置性能目标，不能控制每一个虚拟用户的具体的行为（启动、持续和结束）。 该类场景中，只提供了以下五种性能测试目标的驱动： ·Vusers：虚拟用户数。 ·Transactions per second：简称TPS，每秒事务数。 ·Hits per second：简称HPS，每秒点击数，在很多互联网公司，有一个指标叫QPS

·函数中的参数的分隔符是逗号，因此LR在解析的时候，会将变量的值解析为多个参数，从而导致报错。如果在函数中使用自定义的变量，变量的值是不能包含逗号的。 ·性能监控： ·监控是性能测试中非常重要的一个环节，只有通过监控我们才能知道被测系统的性能的好坏，通过分析性能测试和监控的一些数据，我们可以分析定位到性能瓶颈，从而进行性能调优。 ·对于监控来说，大家需要掌握的原则如下： ·监控是会对被测系统的性能造成影响的。所以一般来说我们都建议直接在被测服务器上进行监控，而不是通过远程的集成监控方式。 ·监控并不是越多越好，而是根据实际情况，逐步加大监控力度。 ·监控是分层的，通常我们监控的层面有： ·系统级别的：CPU、内存、网络、磁盘IO等。 ·服务器级别的。 ·中间件。 ·数据库级别。 ·监控的工具的选择。 一般来说，建议使用系统、服务器、数据库自带的监控工具来做，其次建议使用专业的第三方检测工具，最后才建议使用性能测试工具or平台提供的集成监控方式。 ·系统级别的监控： 常见的操作系统有两种：windows、linux。 两种系统虽然底层的工作机制有所差异，但是对于常见的性能指标来说，差异并不是很大。 ·windows平台：对于windows来说，建议使用windows自带的性能监控工具perfmon进行监控。 PS：LR的集成监控，就是通过RPC来调用perfmon的接口来实现的。

·性能分析： ·对于性能分析，大家需要了解以下信息： ·分析是建立在正确的数据的基础之上的。 ·分析是建立在对于被测系统的足够了解的基础之上的。 ·分析是有方法、有技巧的。 ·分析模型 ·分析的原则。 ·分析的技巧（原则）： ·一般来说，分析、监控、定位这三个操作往往是迭代进行的。 通常来说，分析、监控、定位的层级迭代遵循下列原则： ·从简单到复杂（技术） ·从高效到低效（成本） 按照以上原则，我们一般的做法是： ·从硬件到软件： ·从配置到应用： ·从SQL到代码： ·分析模型： 在业界，性能分析常用的有两个： ·理发师模型：该模型是从队列论的角度来阐述系统性能问题产生的根本原因--等待。 理发师模型设定： ·理发店有10名理发师，理发师和客人是一一对应，理发时间固定为10分钟。 ·理发店有空闲位置30个。 ·客人的忍耐上限：20分钟。 要求大家计算以下数据： A、在理发店的客人的最大数量。 B、工作中的理发师的数量。 C、每一名客人的实际理发时间==理发时间+等待时间。 ·场景1：每隔2分钟来一名客人。 A、5 B、5 C、10 ·场景2：每隔1分钟来一名客人。 A、10 B、10 C、10 ·场景3：每隔30s来一名客人。 A、40 B、10 C、 进店时间 客人编号 理发时间 0 1-10 10+0 5 11-20 10+5 10 21-30 10+10 15 31-40

·性能测试技术 一般来说，性能测试技术可以分为三类： ·用户行为模拟：通过性能测试工具，在协议级别模拟用户行为（用户行为所对应的请求包）。对于用户行为模拟，我们又得注意几件事情： ·不同用户的不同请求。 我们要做到的是：逻辑相同，数据不同。 实现的技术手段--参数化。 ·处理请求之间的依赖。 实现的技术手段--关联。 ·模拟用户的延迟和并发。 实现的技术手段--思考时间、集合点。 ·指标监控： ·响应时间： ·吞吐量： 一般来说，响应时间和吞吐量指标的监控都是应该由性能测试工具自身来完成。 通常就会用到以下技术手段--事务、检查点。 ·资源利用率： 一般是借助第三方工具完成，尽量不用集成到性能测试工具中。 ·性能调优： 调优是一个团队的事情，而不是某一个人的事情，调优是建立在正确的测试、足够的数据和分析的基础上。 ·性能测试工具：目前主流的是Loadrunner（简称LR）和JMeter。 工具的对比： Loadrunner jmeter 功能 优 优- 成本 商业收费（几十万RMB/年）开源 可用性 良好 良 性能 优 良 扩展性 可以二次开发 基于java，可以任意修改。 但是受限于C库。 ·Loadrunner的构成：通常来说，Loadrunner的核心组件有四个： ·Vugen：virtual Users Generator、虚拟用户生成器，是LR中用来录制、生成、编辑

·LR的运行时设置（Runtime settings）： ·Run Logic：该选项是用来控制脚本的真正的运行逻辑。 ·该选项会把脚本中的函数分别放入三个运行模块中：Init、Run、End ·默认情况下，vuer_init函数会放在Init部分、vuser_end会放在End部分。其他acthon函数会按原始顺序放入Run部分。 ·执行逻辑：LR会按顺序依次执行Init、Run和End这三个模块。 ·其中Init和End模块在每一个虚拟用户（线程或者进程）的生命周期中只会执行一次；Run模块是可以执行多次，次数由迭代次数（Number of iterations）或者持续时间（Duration）决定。 ·迭代：iteration，在LR中，迭代是指Run部分的脚本完整的执行一次。即Run一次就是迭代一次。 ·Pacing：该选项是用来设置两次迭代之间的间隔时间的。 一般来说，用得很少。它的作用和思考时间的作用极其接近。都是用来控制负载的。 ·Log：日志选项。 ·日志的作用：记录信息、帮助调试。 ·日志的需求级别：调试比最终运行所需要的日志信息更多。 ·日志的开启，本身会影响到最终的性能测试的结果。 ·Think Time：思考时间选项。 在LR中，思考时间的实现是由：函数（Vugen中添加）和设置（Vugen或者Controller中设置）组合来实现。 在LR中