大话性能测试系列（1）- 性能测试概念与主要指标

若是你对性能测试感兴趣，可是又不熟悉理论知识，能够看下面的系列文章

https://www.cnblogs.com/poloyy/category/1620792.html

 

学习前的认知

咱们在学习性能测试以前，须要有个新的认识：性能测试，再也不是像功能测试同样单纯的找 Bug，而是去找性能指标

 

转变思惟

• 在作功能测试、自动化测试的时候，咱们基本都是依托界面进行测试，也称 GUI 测试，咱们的目的就是为了跑通功能、程序，并成功找到 Bug
• 但在作性能测试的时候，咱们大部分是 headless 模式（所谓的：无头，无界面模式），目的再也不是单纯的为了找到 Bug，而是要分析性能指标等等（后续讲到）

 

性能测试的时间通常会比自动化、功能测试长，为啥？

• 由于性能测试的步骤跟自动化、功能测试的步骤不同，好比说前期的准备（了解系统，环境搭建），后期的压力测试（7*24h）等等
• 在后面，咱们经过讲述性能测试步骤来仔细了解

 

性能测试必定要工具，手工不行吗？

• 性能测试是模拟系统在被不少不少用户同时使用时，系统能不能正常使用和提供服务
• 重点：不少不少用户
• 功能测试：一我的点点点就知道功能通不通，有没有 Bug 了
• 性能测试：用手工的话，能够模拟几个、十几个用户，可是当须要模拟上千万个用户时，手工又怎么模拟数据量多的场景呢？
• 类比，吃饭场景：一我的能够吃好几碗，可是叫你吃几百碗是不可能的
• 结论：工具就能够模拟大数据量的场景，能够作到人作不到的事情

 

大数据量测试是性能测试吗？

大数据量测试

简单理解：一个接口返回的数据比较多（假设：不使用分页，把全部数据同时返回）

 

结论

• 返回大数据量的接口的响应时间会变长
• 这么大的数据量，咱们须要考虑：网络传输数据、服务器查询这些数据、服务器处理这些数据等等分别须要多少时间
• 这已经跟响应时间挂钩，因此已经属于性能测试的范围，但不概括于性能分析范围

 

大数据测试是性能测试吗？

大数据测试的功能属于功能测试哦

 

性能测试过程发现问题须要当即提交吗？

在性能测试过程当中发现一些问题，假设定位到某一段代码有问题，能够截图提交 Bug 给开发，但这并非咱们性能测试的最终目的，最终目的是找出性能指标

 

有哪些性能指标？

• 好比说响应时间：10我的、100我的 、1000我的 、10000我的向服务器发起请求，服务器响应请求的平均响应时间是多少，这就是一个指标
• 又比如TPS：服务器在当前的配置下，不一样用户数发起请求，服务器的 TPS 处理能力是多少，这也是一个指标
• 后续详细介绍

 

性能测试中发现的 Bug 

• 性能测试过程当中发现的 Bug 属于一个衍生品，并非最终获得的结果
• 但像功能测试，最终目的就是为了找出 Bug

 

关于这个问题的总结

• 作性能测试，当数据量变大后，会出现链接超时、链接拒绝、500、502等异常问题；在性能测试中，这些异常问题基本都会出现的，但不会去当即提 Bug
• 对于性能测试工程师，咱们要作的是分析为何在当前数据量下会出现链接超时、链接拒绝，响应时间超时、服务器异常等异常问题
• 这就须要咱们去分析性能瓶颈，并不会单独去看某个异常问题出如今哪里，而是分析为何会出现这个异常问题，分析的是服务器或者是代码，而不是让开发人员立刻来修复这些异常问题

 

咱们常说的压测是指压力测试吗？

• 并非，而是指负载测试，通常都是为了找出系统的最大负载量
• 就好像你老板说：你去压测下，看看系统能支撑多少用户同时访问咱们的系统

 

什么是性能测试？

狭义理解

• 经过工具，找出或得到系统在不一样工况下的性能指标值
• 性能测试过程当中，重点是找出性能指标，而再也不是找出 Bug，
• 性能测试的产出绝对不仅是 Bug

 

场景类比

跑步100米，用时多少？运动员的心跳、步伐频率是多少？

1. 跑步100米：业务场景
2. 用时多少：响应时间
3. 运动员的心跳、步伐：性能指标值

性能指标值和响应时间是否知足当前业务场景的最低要求（合格线）

 

何时能找出性能指标值

假设当前有一个业务

电商系统，下单业务，目前还不知道系统支持多少人同时下单，那么咱们须要找到服务器能正常支持多少人同时下单

 

性能测试初始阶段（第一次作）

• 先把基础的性能指标值找出来（第一次性能测试也叫作基准测试）
• 好比：100我的同时下单系统正常，但120我的同时下单就会出现部分请求的响应时间超长，链接异常
• 那么100-120范围内的某个值就是当前服务器能达到的性能指标值（基准值）

 

版本迭代，进行第二次作性能测试，从新跑一遍以前的性能脚本

• 又会获得一些性能指标值，对比上个版本的性能指标值，看是否有优化（性能变化）
• 假设这个时候120我的同时下单是正常的，150我的才有异常，那么接口已经有优化了

 

假设公司是从0开始作性能测试

• 第一阶段：作好性能测试，获得性能指标值
• 第二阶段：假设性能比以前差，哪些性能指标值不知足预期值，就须要分析是哪里有问题

 

广义理解

• 只要与服务器性能指标相关的测试都属于性能测试
• 好比：响应时间、并发用户数、服务器处理能力、吞吐量等性能指标
• 负载测试、压力测试、容量测试、可靠性测试都属于性能测试
• 一般嘴巴上说的作性能测试就是广义的性能测试，它包括了不少内容，并不仅是针对某一个测试类型

 

 什么是负载测试？

概念

• 逐步增长系统负载，测试系统性能变化，并最终肯定系统所能承受的最大负载量
• 通俗理解：看看你几斤几两

 

如何增长负载

经过增长“用户数”，就是常说的并发数

 

场景类比

天平秤，称东西的时候，须要逐步加砝码，最终达到砝码和物品重量的平衡点，由于它不可能一会儿就达到平衡点【比如不可能一会儿找到系统能承受的最大负载量】

• 称东西：业务场景
• 加砝码：逐步加压
• 达到平衡点：找到最大负载量

 

实际场景

• 有一个业务，增长到40我的的时候，服务器还能正常使用，没有异常
• 当你增长到50我的的时候，服务器已经开始有异常了，那么就能肯定40-50之间某个值就是系统所能承受的最大负载量【出现性能拐点，找到了服务器性能瓶颈的范围值】
• 最后减少加压梯度（好比：从40我的开始每次增长1我的、2我的），确认最大负载量【确认性能拐点】

 

服务器又有哪些可能会出现的异常呢

• 响应时间超长：正常服务器处理请求时间是 1s，但如今变成3s - 5s
• 服务报错：没法同时正常响应多个请求
• 服务器宕机：系统彻底用不了

 

什么是压力测试？

概念

• 在较大的性能压力下，持续运行一个比较长的时间，看看系统服务是否正常及系统资源的利用率状况
• 通俗理解：鸭梨山大！
• 关键字：较大压力 + 较长时间
• 注意：不是满负荷压力哦

 

场景类比

问：你们何时会以为工做压力大？

答：99六、007；由于你不会以为955压力山大吧

结论：因此在咱们平常工做中，长时间工做强度高，才会以为压力大；若是你一周就加班一天也说压力大...（那就别干这一行了）

 

压力测试用来干吗的

测试系统的稳定性

 

类比

工做压力大，你还能坚持下去（那稳定性确定好吧），那若是你很快就离职了（那稳定性确定差，都宕机罢工了）

 

何时会作压力测试

• 生产环境下，系统隔三差五的出现不稳定的状况
• 这个时候，就须要经过压力测试去测试系统的稳定性状况

 

啥状况算不稳定？稳定性差？

隔三差五的出现下面的状况

• 服务异常：响应错误、响应时间超时等
• 服务器出现异常：宕机

 

怎么分析是服务异常仍是服务器异常 

• 若是全部请求都是一片红，应用程序发送的全部请求都报红，就是服务器出现了异常
• 若是有些请求偶尔成功响应，偶尔又失败，则是服务异常，出现不稳定的状况

 

如何取压力值

• 在负载测试中，咱们确认了系统所能承受的最大负载量
• 压力值 < 最大负载量，通常取80%左右

 

灵魂拷问

负载测试通常时间比较短，压力测试时间比较长，持续运行时间短就能正常使用，但持续运行时间长就可能崩掉了，这是什么缘由呢？

 

场景类比

• 栗子一：电脑保持开机状态很长时间，会逐渐变卡，由于内存的东西会愈来愈多，得不到有效的回收， 就会愈来愈卡
• 栗子二：当你常常工做压力很大，且你的心理所能承受的压力逐渐达到最大值时，你就可能会选择离职

 

总结

压力测试长时间运行，可能会逐渐增长系统的内存占用空间，若得不到有效的内存回收，当达到内存最大值时，系统就会崩掉

 

压力测试持续运行时间要多久？

• 标准性能测试里面，通常是7*24小时，或者是它的倍数
• 可是实际工做中，并不会这么久，不然成本过高
• 因此会以小时为单位，好比：4个小时、8个小时...晚上下班以后作，次日早上上班看结果

 

先负载测试仍是压力测试？

• 先负载测试
• 负载测试能够找到服务器性能瓶颈的范围值，若生产环境中系统稳定性较差，再作压力测试
• 因此压力测试是可作可不作的

 

什么是可靠性测试？

概念

• 在给定的必定的业务压力下，持续运行一段时间，查看系统是否稳定
• 关键字：是否稳定，必定业务压力
• 注意：不是较大压力哦

 

业务场景栗子

电商秒杀场景，几十个商品几十万我的同时秒杀抢购

 

如何理解可靠性测试

1. 编写性能脚本：假设一秒内有一万我的同时发起请求
2. 有压力吗？有，一万我的同时发起请求
3. 可是持续时间短，不像压力测试同样须要持续一段时间
4. 目的是为了验证当这么多人同时发起请求时，成功秒杀的用户可否继续完成后续下单付款等操做【必定业务压力下，系统是否稳定运行】

 

什么是容量测试？

概念

• 在必定的软、硬件条件下，在数据库不一样数据量级数据量的状况下，对系统中读/写比较多的业务进行测试，从而得到不一样数据量级下的性能指标值
• 关键字：不一样数据量级

 

数据库数据量对性能测试结果有没有影响？

确定有

• 好比数据库已经有几百条数据和几百万条数据，查询的速度确定不同，因此确定会影响性能测试结果
• 数据量级的差别，会影响TPS、响应时间、网络等

 

场景类比

从一袋米中找一个绿豆，和一碗米中找一个绿豆，找的时间确定是千差万别的

 

性能测试的前提

必要性，是否有作性能测试的必要（关键项评估）

• 主管部门、监管部门审查
• 涉及生命财产安全
• 大型新系统
• 核心系统
• 架构调整
• 业务剧增
• 重大缺陷修复

 

可测性，可量化为性能指标值

通常有需求文档，根据老板或者产品提出的需求，咱们须要将里面的内容量化为性能指标值，这是咱们的预期结果，若是没法量化的话，咱们就没有预期性能指标值，在性能测试完成得出性能指标值后，没有可对比的值，那就不知道是否知足需求的须要

 

开展性能测试必备条件

网络要求

内网（zoom域） 外网独立分开，千万不要用跨内网外网

 

独立环境

功能测试不能和性能测试共用环境（测试环境）

• 在作负载测试的时候，会短期内占用大量的系统资源，若是此时有功能测试正在进行中，极可能会致使功能的不稳定或异常
• 在作压力测试的时候，会长期占用系统的资源，致使一段时间内没法稳定进行功能测试

 

不能使用测试环境、生产环境

• 生产环境有真实用户的各类数据，数据量确定很是庞大【用户数据】
• 性能测试模拟大数据量测试，最终可能也会产生很是多的数据【产生数据】
• 这样一来，真实用户的数据+性能测试产生的数据混在一块儿，生产环境的数据量翻倍变多，会影响服务器对真实用户请求的响应时间【数据量变大，影响响应时间】
• 性能测试产生的数据属于脏数据，不该该出如今生产环境中，因此性能测试不能在生产环境中进行，但硬件环境要尽量一致【脏数据】

 

结论

• 因此，作性能测试须要有单独的一套环境，且硬件环境最好和生产环境一致
• 这样性能测试最终获得系统所能承受的最大负载量会更接近在生产环境中，系统所能承受的最大负载量

 

性能测试步骤

性能测试准备

• 需求分析，熟悉业务：肯定须要重点关注的点，如TPS、响应时间
• 明确性能测试目标（预期性能指标值）
• 了解软件功能、架构
• 指定测试计划，作好工做量评估
• 制定测试模型（编辑测试用例）：好比负载测试，场景如何设计

 

搭建性能测试环境

• 工具选型与准备
• 被测系统环境搭建（服务器、服务版本更新、数据库数据准备）
• 网络配置

 

性能测试脚本开发

• 选取协议
• 制做脚本
• 调试脚本
• 验证脚本

 

性能测试执行

真正开始对服务器进行性能测试

• 试运行
• 场景执行

 

性能测试结果分析与调优

• 分析依据：结果图表
• 分析思路：服务器硬件瓶颈>网络瓶颈>服务器os瓶颈（参数配置、数据库、web服务器）>应用瓶颈（sql语句、数据库设计、业务逻辑、算法）
• 调优
• 修改脚本或场景

 

服务器硬件瓶颈

若是性能测试环境和生产环境的硬件相差甚远，那么很明显就是硬件的问题，也不用去分析后面可能会致使瓶颈的缘由了

 

性能测试报告与结果跟踪

• 性能测试报告
• 性能测试问题跟踪