【性能测试】性能测试基础

一、性能测试分类

• 负载测试：通过逐步加压的方法，达到既定的性能阈值的目标。阈值的设定应是小于等于某个值，如cpu使用率小于等于80%。
• 压力测试：通过逐步加压的方法，使得系统的某些资源达到饱和，甚至失效的状态，简单粗暴的解释就是什么条件能把系统压崩溃。
• 并发测试：在同一时间内，多个虚拟用户同时访问同一模块、同一功能，通常的测试方法是设置集合点。(同一时间触发同一个动作)
• 容量测试：通常是指数据库层面的，目标是获取数据库的最佳容量的能力。又称之为容量预估。具体测试方法为在一定的并发用户，并发的基础数据量下，观察数据库的处理能力，即获取数据库的各项性能指标。
• 可靠性测试：又称之为稳定性测试或疲劳测试。是指系统在高压情况下，长时间的运行系统是否稳定。如cpu使用率在80%以上，7*24小时运行，系统是否稳定。内存泄漏、内存溢出的问题多在这部分测试发现的。（性能监控性能指标）
• 异常测试：又称之为失败测试。是指系统架构方面的测试。如在负载均衡架构中，要测试宕机、节点挂掉等情况系统的反映。

二、性能测试的工作流程

需求分析->性能指标制定->脚本开发->场景设置->监控部署->测试执行->性能分析->性能调优->测试执行… ->测试报告（不再进行调优）

• 需求分析：熟悉项目业务，知道哪些是重点，哪些是主要业务流程

• 性能指标制定：性能测试的目标，定义吞吐量，并发量等，什么样的标准满足现阶段业务需求

• 脚本开发：可以自己写，也可以使用工具

• 场景设置：对脚本进行调试，设置场景，与需求分析产生关联，符合用户在应用程序上的使用流程

• 监控部署：监控目标：应用程序，运行的服务器，数据库。看得到整个环境的运行状态。

• 测试执行：
  第一阶段：基本测试，使用少量用户先跑一下，可以发现多并发逻辑问题
  第二阶段：长时间运行，稳定性测试

• 性能分析：基于监控部署进行关联，使性能分析有理有据。

• 性能调优：主要解决性能测试过程中发现的性能瓶颈问题。通常会涉及多个层面的调整，包括硬件设备选型、操作系统配置、应用系统配置、数据库配置和应用代码实现的优化等。

  测试执行，性能分析，性能调优是一个循环的过程。
  最常见的问题，开发在开发程序的时候对应用变量、类的声明，生命周期控制不严格，出现内存泄漏，或内存溢出。或资源竞争、不合理的线程锁和死锁等问题。

三、常见系统应用分层架构

• 显示层(view)：web android ios H5

• 逻辑控制层(controller)：控制包含大部分业务逻辑处理，即Api层

• 数据存储层(model)：存储数据层
  

  mysql、oracle：关系型数据库，支持事务 mongodb：文档存储，单表存储数据量比mysql大 redis：内存存储、持久化技术…

  ---

• 分层测试的好处：方便定位问题，排除其他因素的问题干扰。

• 分层测试一般是自底向上测试。

• 数据库测试：把开发代码拿过来，把跟数据库产生交互的sql语句抽离出来，开发成性能测试脚本。sql语句调优，mysql配置，服务器硬件升级。

• 接口层面(Api)：代码逻辑问题，并发逻辑，具体问题具体分析。

• 显示层：监控图片大小如何进行格式压缩，如何压缩不会失真。js控制业务逻辑，css控制样式。一般先加载样式，后加载脚本会比较快。

四、性能测试指标定义

• 事务：从客户端发起的一个或多个请求（这些请求组成一个完整的操作），到客户端接收的从服务器返回的响应。

  注意：事务只能是一个完整的操作，但是是允许失败的。 其中的一个步骤操作失败了，那么这个事务就失败了，虽然失败了，但是也是一个事务。

• TPS(Transaction Per Second)：每秒钟系统能够处理的事务数。

• QPS(Query Per Second)：每秒钟系统能够处理的请求数。

---

• 请求响应时间：从客户端发起的一个请求开始，到客户端接收到从服务器返回的响应，整个过程所耗费的时间。

  请求响应时间分为前端展现时间和系统响应时间两部分：

  • 前端展现时间的长短取决于客户端收到服务器返回的数据后渲染页面所消耗的时间；
  • 系统响应时间又可以进一步划分为Web服务器处理时间、数据库渲染服务器处理时间，以及数据网络传输时间。

• 事务响应时间：主要是针对于用户的角度而言，并不仅仅是一个请求。

---

• 并发：没有严格意义上的并发。并发总有先后，无论差距是1毫秒或者是1微秒，总有一个时间差。所有并发讲的是一个时间范围内，比如1秒内。

  • 多用户在系统上进行同一操作，比如双十一时，大家都针对同一种商品进行秒杀；
  • 多用户在系统上进行不同操作，比如双十一时，大家针对不同商品进行秒杀，或者是大家有进行其他不同的操作，比如商品浏览。

• 并发用户数：同一单位时间内对系统发起请求的用户数量。

  并发用户数包含了业务层面和服务器层面的含义。

  • 业务层面的并发用户数，指的是实际使用系统的用户总数。但是，单靠这个指标并不能反映系统的实际承载的压力，还要结合用户行为模型才能得到系统实际承载的压力。

  • 服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”， 直接反映了系统实际承载的压力。

    有一个已经投入使用的ERP系统，使用该系统的企业有5000名员工，并都拥有登录账号。也就是说，该系统有5000个潜在用户。 根据系统日志分析，该系统最大在线用户数是2500人。从宏观角度来看，2500就是这个系统的最大并发用户数。但是，这个数据仅仅是指在系统峰值时段有2500个用户登录了系统，而服务器所承受的压力取决于登录用户的行为，所有它并不能准确表现服务器此时此刻正在承受的压力。 假设在某一个时间点这2500个用户中30%处于页面浏览状态(对服务器没有发起请求)，20%的用户在填写订单(也没有对服务器发起请求)，5%的用户在递交订单，15%的用户在查询订单，而剩下的30%的用户没有进行任何操作。那么这2500个“并发用户”中真正对服务器产生压力的只有500个用户((5%+15%)*2500=500)。 在这个例子中，5000是最大的“系统潜在用户数” ，2500是最大的“业务并发用户数”，500则是某个时间点上的“实际并发用户数”。而这500个用户同时执行业务操作所实际触发的服务器端的所有调用，叫做“服务器并发请求数”。

---

• 吞吐量：一次性能测试过程中网络上传输的数据量的总和。

• 吞吐率：单位时间内网络上传输的数据量。

  吞吐率=吞吐量/单位时间

---

• 点击率：每秒钟用户向服务器提交的请求数。这个指标是web应用程序特有的一个指标，可以想象为每秒钟用户总共在页面上进行多少次点击动作，但是需要注意的是一次鼠标点击的操作后，客户端有可能向服务器发送了多次请求。
• 资源使用率：对不同的系统资源的使用情况，如cpu、内存、io
• 集合点：Thread Group–>Add–>Timer–>Synchronizing Timer（同步定时器）

五、性能测试需求分析

• 需求分析的目的

  明确测试指标，确认我们重点关注的指标是哪些。

  明确测试场景，明确功能点的侧重点，如登录用户在每一个不同的功能点的百分比，推断每一个不同的功能用户并发量，即分析用户行为模式。

• 分析得到准确的用户行为模式，是性能测试中关键的一环

  对于已经上线的系统来说，首先可以采用系统日志分析法获取用户行为，以及峰值并发量等信息；然后对比以往的用户行为以及用户量，看系统用户增长是属于上升期还是平稳期，从而却定测试目标。

  对于未上线的新系统来说，一方面可以参考行业中类似系统的统计信息，对并发量进行收集，来建立用户行为模型，并分析；另一方面跟需求人员和市场调研人员沟通，询问业务预期，市场规划相关的问题，比如三个月用户增长预期是什么，预期日活是多少的之类的。

六、性能测试工具

• Loadrunner：量级比较重，语言支持C/java1.5，收费，需要的依赖比较多，只能在Windows环境中运行
• Jmeter：免费开源，开发语言为java，量级比较轻，基于JVM开发，可移植性强，可以在多种环境下使用，可以做二次开发，可以通过拓展支持海量并发