性能测试

·什么时候需要做关联？ 一般来说，在脚本运行出错的时候，我们就可能需要进行关联处理。 ·脚本出错分为两种情况： ·直接回放出错（失败）。通常来说，如果录制成功，回放失败，排除数据的唯一性约束之后，那就必然是需要做关联的。 ·参数化之后出错。这种时候排除数据本身的功能错误以外，通常也是要做关联处理的。 ·什么是关联？ 一般来说，关联是用来解决请求之间的依赖关系的。 什么叫请求之间的依赖关系呢？ 所谓依赖，是指两个请求之间有数据的交互。如果请求B中所发送的数据，是来源于请求A所响应的数据。 脚本和真实的客户端有什么差异呢? 客户端是可以运行客户端脚本，是可以去实现一些业务逻辑的。可以去接收和处理服务器响应的数据并且封装到请求中。 性能脚本在没有做更多的处理之前（录制or抓包手写），是没有任何逻辑处理能力。 所谓的关联其实就是要去模拟客户端脚本的某些数据处理能力。 ·关联的数据的特征。 一般来说，需要做关联处理的数据的特征有三个： ·数据一定是来源于服务器的响应。 ·数据一定要在后续的请求中被用到。 ·数据一定是动态变化。 ·关联的方式： 在LR中，关联的方式有两大类三小类 ·自动关联： ·录制关联：功能正确，但是无用。 ·回放关联：采取的是对比法。即自动对比录制和回放的数据。 前提：最后一次回放必须是错误的。 建议：最好只是用来辅助定位数据，最终要解决关联问题还是要了解业务。

性能测试脚本的增强： ·参数化 ·关联 ·事务 ·检查点 ·思考时间 ·集合点 ·参数化：模拟不同用户的不同请求。 ·为什么要做参数化？ ·功能：通常来说，系统的某些业务数据具有唯一性的要求。 ·性能：一般来说，如果系统的后端（服务器端）对于业务提供了缓存机制，则要考虑参数化。 PS：一般来说，查询类的业务都会通过缓存机制来提升服务器端的性能的。 从模拟的真实度来说，缓存和非缓存数据的比例越接近真实线上数据越好。 ·参数化的实现操作。 在LR中，参数化的实现方式很多，但是从本质上来说，只需要保证两点： ·参数存在并且有值。 ·脚本中对参数进行了调用。 在LR中，参数调用的格式一般为：“{参数名}”。 ·参数化的实现方式： 在LR中，参数的类型有很多种，所以实现方式也有很多。但是从本质上来说，参数的实现方式就是两种： ·函数方式：通过LR内置的函数去实现参数值的生成。 ·文件方式：通过读取数据文件（source）的方式来实现。 ·参数和参数文件是多对一的关系。 ·一个参数文件中可以存放多列值。 ·一个参数只能读取一个参数文件中的某一列值。 ·参数化的注意事项： ·如果用记事本编辑参数文件，则要保证最后的有效数据之后有且只有一个回车。 ·一般来说，只有用户输入或者选择的数据我们才会做参数化处理。 ·参数化一般只是针对用户输入或者所选择的值。 ·参数值本身要符合业务功能的要求。 主要是

Redis是一个开源，先进的key-value存储，并用于构建高性能，可扩展的Web应用程序的完美解决方案。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型），为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。 Redis从它的许多竞争继承来的三个主要特点： 1.Redis数据库完全在内存中，使用磁盘仅用于持久性。 2.相比许多键值数据存储，Redis拥有一套较为丰富的数据类型。 3.Redis可以将数据复制到任意数量的从服务器。 一、安装redis 1.安装redis：直接下载安装包 2.设置密码：默认安装后的redis是没有密码的，可修改配置文件redis.conf（找到SECURITY文字，在此加入一行文字requirepass 你的密码） 二、安装redis扩展 1.在phpinfo()中查看所用php编译版本V6/V9 ，下载对应版本的php_reids.dll 2.将下载的php_redis.dll放在php扩展目录中（ext），并修改配置文件php.ini extension=php_igbinary

什么是自动化测试 一般是指软件测试的自动化，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件 自动化测试： - 接口自动化 - 界面自动化 什么是性能测试 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。 负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能， 目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能 接受的性能点，来获得系统能提供的最大服务级别的测试。 自动化测试和性能测试对应了软件测试技术发展的两个不同的路线 虽然是两个不同方向，但是关联度还是挺高的。 下面对性能测试做个详细的介绍吧。 一般来讲，大多数的性能测试都是基于工具来实现的。 比如经典的 jmeter\loadrunner\locustio 这些。 其中 jmeter 和 loadrunner 都是支持使用工具来录制的。 但是录制的脚本可用性不敢恭维，在实际的工作里，大多数的性能测试脚本其实都是自己写的。 【脚本是要自己写的】 不管是自动化测试还是性能测试，都要掌握写脚本的技能 性能测试不止是工具和脚本 脚本的功能是可以模拟用户操作 工具提供了多线程用来施压并发等 学习性能测试应该如何入手： 掌握接口测试 选择测试工具 学会分析

一、性能测试中的常见指标及其含义 1、并发用户数 并发用户的含义分为狭义和广义两种。 狭义上的，或者说严格意义上的并发用户，指的是同一时刻做同一件事件的用户，如操作同一记录或不同记录。 广义上的，则是指在同一时间内，对系统发出请求或操作，可以是相同的请求或操作，也可以是不同的。 狭义的并发用户，主要用于针对核心模块或核心算法的测试中，与功能相关，是健壮性和稳定性测试的一部分，需要在广义的并发测试前进行。 而并发用户数，就是同一时刻与服务器进行交互的在线用户数量。 2、请求响应时间 请求响应时间，是指客户端发出请求到得到响应的整个过程的时间，包括了网络响应时间、应用与系统的响应时间。 4、事务响应时间 事务，是有一系列请求组成的，其响应时间针对用户而言，属于宏观的业务上的概念。顾名思义，事务响应时间，则是用户完成一个对于用户来说具有原子性价值的业务操作的时间，包含了一个或多个请求。 5、吞吐量 一次性能测试过程中，网络上传输的数据流量的总和。 6、吞吐率 单位时间内的吞吐量，常用单位有字节数/秒、请求数/秒、页面数/秒。 7、TPS 每秒能够处理的交易或事物的数量。 8、点击率 点击率，指的是每秒用户向服务器提交的http请求的数量，是web应用特有的。注意，鼠标在页面的单击数不一定等于点击数！一次单击，可能会发起多个请求，引起多个点击。 9、资源利用率 不同资源的使用程度

1. 性能测试准备 1.1 性能测试环境申请 当做完性能需求分析之后，就要申请性能测试环境。因为性能测试需要在物理机上运行，而物理机又是稀缺资源，所以我们每次做性能测试都需要提前申请。 1.2 环境清理 在部署系统之前必须要做的一件事就是环境清理，最简单的就是统统删除然后重新搭建一个干净无污染的系统。如果是在旧系统上做更新，那至少也得把Log日志清理一下、其他可能的干扰进程该杀就杀掉、定时跑的任务、临时文件、初始化文件等等该清理的都清理。 1.3 环境搭建及数据准备 环境搭建理想的情况是使用我们的环境搭建平台，或者一键式环境搭建脚本。当然，如果都没有的话，我们就得按照我们的上线步骤流程来一步步搭建了。 1.4 压力工具选择 当我们做了性能需求分析、制定了测试方案，这时候需要选取一款合适的性能测试工具，并通过这个工具快速高效的完成测试任务。通常我们用的压力工具，如：ab、JMeter、LoadRunner等工具，这些在网上都有各种的使用方法，这里就不再一一介绍了。 我们需要了解不同的压力工具的特点。 比如apache的 ab ，它是采用了Linux 2.6内核之后引入的epoll模型，能够制造非常高的压力，尤其是在高并发的环境下最能体现出它的优势。如果我们要压某个耗时稍长的请求，比如某个css静态文件，ab是非常合适的。Ab的缺点是不够灵活。 JMeter 采用的是多线程模型

性能测试通用原则【3-1；2-5-10；80/20】 如果设计说明书中没有给出明确的标准，那么可以参考国外的业内公认的一些标准： 3+1原则(指量、全、深+快) 主要对 性能测试 设计、测试执行以及数据分析。 量：包括业务量（业务类型），负荷量（系统处理的流量），配置量（软件配置和硬件配置），用户量（静态用户和动态用户），时间量（测试的时间）。 全：主要是针对 测试用例 而言。测试用例理你包括预置条件，测试步骤和预期结果三部分，这个“全”重点针对预置条件和测试步骤的测试结果观察和数据而言。 深：一是对系统的了解要深，二是对缺陷的分析要深。 快：一是测试经验的固化，避免测试设计，观察等遗漏。将经验固化成模板或工具便于经验的传承，减少测试的重复和遗漏；二是性能测试的自动化，包括性能测试环境构建和测试执行以及测试分析的自动化，自动化对性能测试效率的提升价值更大。 2-5-10原则 主要针对响应时间。简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。 80/20原则 用于减少风险，抓住重点进行更多的测试：80

Apache JMeter是一款纯java编写负载功能测试和性能测试开源工具软件。相比Loadrunner而言，JMeter小巧轻便且免费，逐渐成为了主流的性能测试工具，是每个测试人员都必须要掌握的工具之一。 本文为JMeter性能测试完整入门篇，从Jmeter下载安装到编写一个完整性能测试脚本、最终执行性能测试并分析性能测试结果。 运行环境为Windows 10系统，JDK版本为1.8，JMeter版本为3.3。 Jmeter安装 2.1 JDK安装 由于Jmeter是基于java开发，首先需要下载安装JDK （目前JMeter只支持到Java 8，尚不支持 Java 9） 官网下载地址： http://www.oracle.com/technetwork/java/javase/downloads/index.html 选择Java SE 8u151/ 8u152，点击JDK下载 这里写图片描述 安装下载的JDK 配置系统环境变量 2.2 JMeter安装 官网下载地址： http://jmeter.apache.org/download_jmeter.cgi 下载最新JMeter 3.3版本：apache-jmeter-3.3.zip 这里写图片描述 下载完成后解压zip包 启动JMeter 双击JMeter解压路径（apache-jmeter-3.3\bin

学习了《软件开发沉思录》中的实用主义性能测试，对重点内容做下记录： 性能测试应该囊括确保产品性能符合要求所需的一切行动。这里有四个关键点:需求、产品性能数据、沟通和流程。 1.需求采集 需求采集中的几个重要问题:要度量什么?如何知道我们需要什么?以及如何得到确实有用(而非帮倒忙)的数据? @要度量什么 最重要的性能度量点有两个,最大吞吐量以及给定吞吐量下的响应时间。一个好的做法是:分别度量几种不同吞吐量下的响应时间,从中分析负载对响应时间的影响。 需要通过度量找出两项数据:当响应时间恰好可以接受时的吞吐量,以及达到预期吞吐量时的响应时间。伸缩性度量的关键则在于:随着数据规模、用户数量或者运行系统的硬件变化,起初得到的性能度量数据会发生怎样的变化。 可靠性的关键度量点是:当负载量高得超乎寻常,或者连续运行了很长时间以后,系统是否仍然正常工作。 @如何设定目标 要想知道系统需要达到怎样的吞吐量,你首先需要知道有多少用户会使用这个系统,以及他们的使用模式。用户会多频繁地使用某个功能?这个功能需要多快完成? 需要有一个可靠的沟通流程与机制来获得所需的信息,及时获知支撑业务需求所需的性能指标。 总之： 需求采集是为了让所有人都清楚最终交付的产品需要有怎样的性能才能支撑业务目标。之所以要让客户参与,是因为他们最了解自己的业务,这样才能确保采集到的需求足够准确

前言 使用Locust进行性能测试时，当一台单机不足以模拟所需的用户数量的时候，可以在多台机器上分布式的执行性能测试。 locust分布式启动场景有2种，一种是单机设置master和slave模式，另外一种是有多个机器，其中一个机器设置master，其它机器设置slave节点。 单机主从模式 Locust 中如需使用 master-slave 模式启动多个进程（使用多核处理器的能力），先启动 master，然后再逐一启动若干个 slave。 其中 slave 的节点数要小于等于本机的处理器数，那么问题来了，如何看自己的电脑是及核的，以win10为例。 打开设备管理器-处理器，数下有几个，比如我下面有四个，那就是四核的 先启动一个master节点，mater节点不执行任务 locust -f locustfile.py --master 开多个窗口，启动多个slave节点，比如我开四个窗口，依次执行以下命令 locust -f locustfile.py --slave 此时在浏览器输入： http://localhost:8089/ slave节点数为4 多机主从模式 当一台机器的并发数无法满足你的业务需求时，可以在多台机器上分布式的执行性能测试。 选择其中一台电脑，启动master节点，因为主节点无法操作别的节点，所以必须在其它机器上启动从属Locust节点，后面跟上-