目录
1. 什么是性能测试 Performance Testing
7.3 以PV为切入点，通过模型将其转换成性能测试可量化的TPS
7.5 日志等级设置成warn，避免大量打印log对性能测试结果的影响
【写在前面】
读书笔记，做记录，供自学，如侵，请告知，会删。
1. 什么是性能测试 Performance Testing
1.1 性能概念
性能是指器物所具有的性质和效用。
其中，性质是指该器物是什么特性。效用是指该器物能干什么，干得怎么样。
软件的性能，通常是指单位时间能处理的业务，处理一个运算所需要花费的时间，打开软件所需要的时间等。
1.2 性能测试概念
在一定的负载情况下，系统的响应时间等特性是否满足特定的性能需求。性能其实算功能的一种。
对于系统测试，要分析：
（1）功能测试：某个功能点
（2）性能测试：整个系统包括软件和硬件
1.3 软件效率是指什么
在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
其中，资源包括其他软件产品，系统的软件硬件配置，物质材料。
用户操作的系统，功能性，可靠性，易用性和效率的组合，可以由使用质量从外部进行测量。
1.4 软件效率的哪些方面可以用来衡量软件的性能
（1）时间特性：在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。
（2）资源利用率：在规定条件下，软件产品执行其功能时，使用合适数量和类型的资源的能力。（包括人力资源）
（3）效率依从性：软件产品遵循与效率相关的标准或约定的能力。
1.5 要解决性能问题，需要注意以下几个问题
（1）产品/业务需求
（2）系统的健壮性：系统在极端情况下正常运行。
（3）意外的处理能力：将多余的服务器或者不常用的业务服务器腾出来，加入核心服务器的群集中，并且控制流量阈值，确保整个系统能够正常的工作。当网络量过大时，通过队列等技术解决。
1.6 性能测试的好处
（1）评估系统的能力：测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助做出决策。
（2）识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，突破它从而修复体系的瓶颈或薄弱的地方。
（3）系统调优：重复测试，验证调整系统的活动得到了预期的结果，从而改进性能。检测软件中的问题。
（4）验证系统稳定性和可靠性：在一定生产负荷下执行测试一定的时间，是评估系统稳定性和可靠性是否满足要求的唯一方法。
简言之，
要确保软件在一定的资源下达到一定的性能，并且遵守相关的标准或协议。
软件测试的主要工作目标是：确保系统能够在一定的软硬件环境下达到一定的性能指标物数目。
2. 性能测试基础理论
2.1 软件测试分类
（1）测试对象：手机端测试，PC端测试
（2）服务类型：B/S, C/S
（3）程序运行状态：静态测试，动态测试
（4）软件阶段：
单元测试，集成测试，系统测试，验收测试，回归测试，Alpha测试，Beta测试
（5）测试方法：
白盒测试，黑盒测试，探索性测试
（6）测试内容：
功能测试，负载测试，压力测试，性能测试，大数量测试，易用性测试/用户体验测试，安装卸载测试，恢复测试，安全性测试，兼容性测试，内存泄漏测试，竞品测试，可靠性测试，文档测试。（其中，性能测试占了大部分）
2.2 软件性能测试的不同角度
（1）用户视觉角度
Users -> request -> 应用界面 -> APP server -> DB server
Users -> sed -> 应用界面 -> APP server -> DB server
（少部分数据先展现，大部分数据延后传输）
（2）管理员视觉角度
CPU+MEMORY+IO
JVM
DB
扩展性，兼容性，最大容量，Bottleneck
更换哪些硬件能提高性能
系统能否支持7*24小时服务 等
（3）开发视觉角度
架构合理性
数据库设计合理性
代码
系统里内存的使用方式
系统里线程的使用方式
2.3 前端性能
Web前端性能，Page Speed, Yslow, 模块，架构，协议，业务模型
2.4 性能测试需求分析
（1）性能测试要素
用户数量，测试执行的功能，用户分布（每种功能的用户数），硬件环境，软件环境，数据量，系统运行出现的问题时有什么特性或规律，疲劳测试执行时间，性能需求的指标是什么
（2）性能测试策略
性能符合性验证：SEI负载测试，疲劳强度测试
性能能力验证：RBI压力测试，疲劳强度测试，并发测试
性能调优：测试调整测试。负载，压力，疲劳强度
（3）性能测试方案
测试需求，测试策略，测试场景，测试环境，测试准备，人员和时间安排，问题和对策
2.5 测试工具
AQLoad， LoadRunner，WAS， WebLoad，RPT，OPENSTA
注意：工具是否支持被测系统的平台，协议，服务器类型，特殊要求等
2.6 准备工作，执行测试
搭建测试环境
录制脚本+数据准备+编辑脚本
布置测试场景
执行测试场景
2.7 结果分析
（1）系统：CPU利用率，磁盘利用率+I/O，内存利用率+I/O，系统吞吐量等
（2）网络：吞吐量，延迟，响应时间
（3）WEB服务器：IIS， APACHE， WebSphere， WebLogic，tomcat
总流程:
（1）认识被测系统
（2）需求分析和理解
（3）工具选择
（4）准备工作，执行测试
（5）结果分析
（6）回归测试
3. 常见的性能指标有哪些
（1） 虚拟用户数 VUser
Virtual User，模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。 Vuser脚本用于描述Vuser在场景中执行的操作。
（2）事务 Transaction
事务是性能测试脚本的一个重要特性。需要定义事务。每个事务包含事务开始和事务结束标记。事务用来衡量脚本中一行代码或多行代码的执行所耗费的时间。可以将事务开始放置在脚本中某行或多行代码的前面，将事务结束放置在该行或多行代码的后面。在该脚本的虚拟用户运行时，这个事务将衡量这些代码的执行花费了多长时间。
（3）每秒事务数 TPS
Transaction Per Second，每秒中系统能够处理的交易或事务的数量。是衡量系统处理能力的重要指标。
（4）Page View PV
Page View，用户通过浏览器访问的页面，对应用服务器产生的每一次请求，记为一个PV。性能测试环境下，将这个概念做了延伸，系统真实处理的一个请求，称为一个PV。也适用于接口。
（5）高峰PV （Peak PV）
PV峰值，一天中PV数达到的最高峰。
（6）并发 Concurrency
狭义的并发，是指所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。
广义的并发，即多个用户对系统发出了请求或者进行了操作，这些请求或操作可以不同，对整个系统来说，还是相当于有很多个用户同时进行操作。
（7）场景 Scenario
为了模拟真实用户的业务处理过程，构建的基于事务，脚本，虚拟用户，运行设置，运行计划，监控，分析等的一些动作的集合，称为性能测试场景。
场景包含了待执行脚本，脚本组，并发用户数，负载生成器，测试目标，测试执行时的配置条件等。
（8）响应时间 Response Time
是指从客户端发出一个请求开始计时，到客户端接收到从服务器返回的响应结果结束所经历的时间。响应时间由 请求发送时间+网络传输时间+服务器处理时间 组成。
重点关注：事务的响应时间。分为事务最小响应时间+事务平均响应时间+事务最大响应时间
（9）思考时间 Think Time
模拟正式用户在实际操作时的停顿间隔时间。
从业务角度来讲，思考时间是指用户在进行操作时，每个请求之间的间隔时间。
在测试脚本中，思考时间体现为脚本中两个请求语句之间的时间间隔。
（10）CPU资源
是指性能测试场景运行的时间段内，应用服务系统的CPU资源占用率。
是判断系统处理能力以及应用运行是否稳定的重要参数。
应用服务系统可以包括应用服务器，web服务器，数据库服务器。
（11）负载 Load
系统平均负载，是指在特定时间间隔内，运行队列中的平均进程数。在运行队列中的进程需要满足：它没有在等待I/O操作的结果。它没有主动进入等待状态。没有被停止。
（12）标准差 Std.Deviation
根据数理统计的概念而来。标准差越小，说明波动越小，系统越稳定。反之同理。
包括： 响应时间标准差，TPS标准差，Running Vuser标准差，Load标准差，CPU资源利用率标准差，Web Resources 标准差等。
4. 需要监控的指标有哪些
（1）服务器（Linux）
CPU,MEMORY, I/0,NETWORK
Mysql, Oracle（包括：缓存命中，索引，单条SQL性能，数据库线程数，数据池连接数等）
（2）中间件
Jboss, Apache
包括：线程数，连接数，日志输出等
（3）网络
防火墙，网卡，网线，吞吐量等
（4）应用服务
JVM内存使用和回收
JAVA内存使用
FULL GC频率
JAVA类装入和卸载
日志，线程运行状态（运行，等待，阻塞）等
（5）监控工具（常用LoadRunner）
用户执行情况，场景状态，事务响应时间，TPS，LOAD，CPU分析图表
（6）测试机资源
CPU, MEMERY, 网络，日志输出，磁盘空间，负载生成器等。
5. 常见的性能测试有哪些
背景：狭义的性能测试，是指以性能预期目标为前提，对系统不断施压，验证系统在资源可接受的范围内，是否能达到性能预期。在项目的性能点做性能测试。
5.1 负载测试（可置性测试）
（1）定义：
是指对系统不断地增加压力或增加一定压力下的持续时间。直到系统的某项或多项性能指标达到安全临界值。
另一种说法：在被测系统上不断增加压力，直到性能指标（如响应时间）超过预期指标或者某种资源使用已经达到饱和状态。可以找到系统的处理极限，为系统调优提供数据。
（2）场景：
一般是以服务器资源安全临界值为界限的测试。比如模拟某个应用在指定服务器上最大且最安全的负载量，属于负载测试。
（3）特点：
--- 主要目的是找到系统处理能力的极限
--- 在给定的测试环境下进行，通常需要考虑被测系统的业务压力量和典型场景
--- 一般用来了解系统的性能容量，或者是配合性能调优来使用
5.2 压力测试
（1）定义：
是指超过安全负载的情况下，对系统不断施加压力，是通过确定一个系统的瓶颈或不能接收用户请求的性能点，来获得系统能提供的最大服务级别的测试。
另一种说法：系统在一定饱和状态下，例如CPU、内存等饱和情况下，系统能够处理的会话能力，以及系统是否会出现错误。（2）场景：
一般用于大型的共享中心或核心的应用。
（3）特点：
--- 主要目的是检查系统处于压力情况下是应用的性能表现
--- 通过增加访问压力，是系统资源使用保持在一定水平，检验此时应用的表现，重点在于有无出错信息产生，系统对应用的响应时间等
--- 一般通过模拟负载等方法，使得系统的资源使用达到较高的水平
5.3 稳定性测试（可靠性测试）！！！最常见
（1）定义：
是指被测试系统在特定硬件，软件，网络环境条件下，给系统加载一定业务压力下，使系统运行一段较长的时间，以此检测系统是否稳定。稳定时间为12*N小时为计。
（2）场景：
针对需要长时间稳定运行的性能点，需要执行稳定性测试。注意性能优先级较高的性能点。
（3）特点：
--- 主要目的是验证系统是否支持长期稳定的运行
--- 需要在压力下持续一段时间的运行
--- 测试过程中需要关注系统的运行情况。比如：内存使用或者其他资源的使用以及响应时间有无明显变化
5.4 并发测试
（1）定义：
模拟多用户并发访问同一个应用、模块或数据记录时是否存在死锁或者其他性能问题
（2）特点：
--- 主要目的是发现系统中可能存在的并发访问时的问题
---主要关注系统中可能存在的并发问题。比如：内存泄漏、线程锁和资源争用等问题
---可以在开发的各个阶段使用，需要相关的测试工具的配合和支持（3）常用工具：
商业软件loadrunner：功能完整强大，内存占用大，需要收费
开源工具jmeter：开源免费，自由，操作较简单，能辅助完成日常的一些测试工作
5.5 配置测试
（1）定义：
通过对被测系统软硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则
（2）特点：
--- 目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作
--- 一般在对系统性能状况有初步了解后进行
--- 需要在确定的环境、操作步骤和压力条件下进行
--- 该方法一般用于性能调优和规划能力
5.6 基准测试
5.7 验收测试
（1）定义：
特定条件下验证系统的能力状况
（2）特点：
---主要目的是验证系统是否具有系统宣称的能力。方法包括：确定用户场景，给出需要关注的性能指标，测试执行，测试分析这几个步骤
---需要事先了解被测系统的典型场景，并具有确定的性能目标
---要求在已确定的环境下进行
5.8 失效测试
（1）定义：
检测如果系统局部发生故障，系统能否继续使用。针对有多余备份和负载均衡的系统设计
（2）特点：
--- 主要目的是验证局部故障下系统能否继续使用
--- 需要指出：问题发生时“能支持多少用户访问”和“采取何种应急措施”。一般只有对系统持续运行能力有明确指标的系统才需要该类型测试
6. 常见的性能测试模型
6.1 施压中心模型
（1）施压中心应用：
管理者核心数据和业务流程，直接与数据库或缓存服务器交互，统一对全网上层APP提供服务。
（2）前端页面性能测试模型：
Selenium：使用者在Seleniu中定制任务，定期自动运行批量任务
YSlow：Selenium各个任务分别调用YSlow，YSlow对前端页面进行评分。（现在被google的pagespeed取代）
ShowSlow：YSlow将评分发送给ShowSlow入库，并展示测试结果。
（3）模型优点：
1）实现测试，存储，结果展示的自动化。提高前端性能测试的效率。
2）框架化，简化前端性能测试步骤，复用，易用。
3）指导性强，YSlow能给出性能优化建议。
6.2 PV计算模型
（1）利用现有最新的数据得出性能测试PV的计算公式，以便让性能测试的PV计算更接近生产线真实情况。
（2）计算公式：
每台服务器每秒最高峰PV量 = （1.92*总PV）/（24*60*60）/ 服务器数量
（推导过程略）
6.3 PV->TPS转换模型
为了使PV在性能测试环境下可量化，根据PV的概念，通过以下方式可以转换成TPS。
即：1PV=1TPS
（1）性能测试脚本中，只保留与性能点相关的内容，如果是异步处理的，保留多个请求以确保压力目标。
（2）在执行场景中，不模拟浏览器缓存，确保每次请求都到达应用服务器，是的LoadRunner的一个请求等同于一个PV。
（3）在执行场景中，每次迭代，都模拟一个新用户，而且清除用户缓存信息，确保每个用户每次发送请求都是全新的。
6.4 TPS波动模型
（1） TPS在性能测试设计，执行，分析，评估等各个阶段，都是非常重要的参考指标。是直接影响着性能测试是否通过的衡量参数指标。性能测试依赖特定的硬件，软件，网络，应用服务等，TPS可能会出现稳定，波动，或者遵循一定的上升或下降等趋势。
（2）TPS的表现轨迹：一类是TPS有明显的大幅波动，不稳定。一类是TPS轨迹比较平稳但也有一定的波动。
（3）LoadRunner中， TPS分析图中的4个重要参数：最大值，平均值，最小值，标准差值。
（详情略，之后深入学习后再更新）
7. 性能测试策略
7.1 模拟生产环境
准备与生产环境相似的性能测试环境，用物理机做服务器。
7.2 服务器置于同一机房，最大限度避免网络问题
所有服务器放置在同一机房，属于同一网段，服务器之间的网络交互通过交换机进行。
7.3 以PV为切入点，通过模型将其转换成性能测试可量化的TPS
（1）在线用户不断变化，页面是固定的可统计的。所以，PV是可以统计到的，因此，以PV作为性能测试的切入点，将页面流量转换成PV，作为性能测试的语气目标。
（2）得到PV数值后，通过PV->TPS转换模型，转为TPS。
7.4 性能测试数据分为基础数据和物业数据两部分
（1）性能测试数据库和功能测试库相互独立。
（2）基础数据：为了使表中的数据达到一定的数量级而填充的数据，目的是测试出数据库索引是否足够优化，表空间，索引空间等是否足够。
（3）业务数据：为了使被测系统能够按业务逻辑运行起来的数据，就是功能测试所使用的数据，目的是测试出SQL语句是否足够优化，代码是否足够优化等。
7.5 日志等级设置成warn，避免大量打印log对性能测试结果的影响
（1）Java日志级别：info, debug, warn,error
（2）打印日志也会消耗服务器的IO和磁盘存储空间。会影响性能测试结果。
（3）将日志级别设置成warn，只打印warn和error的日志，能减少对性能的影响。
7.6 屏蔽ESI缓存，模拟最坏的情况
（1）ESI缓存：对于非频繁变化的数据，可以在容器中缓存起来，提高读的性能，同时减轻数据库压力。ESI缓存必须在数据被访问过后才会生效。缓存失效后需要重启缓存，即系统刚发布或重新缓存过程中，用户访问速度变慢，数据库压力也大。
（2）在性能测试过程中，我们需要模拟没有ESI缓存的场景。
7.7 先单场景，后混合场景，确保每个性能瓶颈都得到调优
（1）单场景执行
针对单个性能测试点，构建一个性能测试场景，而进行的性能测试。
可以详细测试到某个页面，某个接口等单点的性能，这种方式有利于定位性能瓶颈，优化代码。适用于性能测试，负载测试，压力测试，稳定性测试。。
（2）混合场景执行
在单场景优化完成后，按照一定的比例对各种场景进行组合，测试整个应用系统的总体性能表现。
为了尽量模拟生产线上运行的业务压力或用户使用场景，测试系统的整体性能是否满足性能需求，把经过一定规则筛选的性能测试点，按照呵护实际逻辑的虚拟用户请求，并发，组合成一个混合场景。
特征：包含两个以上的脚本组，执行时间长。适用于稳定性测试，负载测试。
（3）先执行单场景，后执行混合场景的策略
7.8 拆分问题，隔离分析，定位性能瓶颈
将各个应用或者一个应用的各个环节进行拆分，逐渐隔离掉没有问题的部分。
然后在可能有问题的部分进行再排查，直到定位到瓶颈为止。
7.9 根据性能测试通过标准，来判断被测性能点通过与否
将对应用程序的要求，历史性能测试结果数据，生产线真实监控结果，来制定性能测试通过标准。从服务端性能，前端性能，用户体验性能等多个维度界定，使标准更加科学性，指导性。
7.10 性能瓶颈，录入BUG系统进行跟踪
对于当前不能解决的BUG，进行风险评估，使用QC维护，跟踪性能瓶颈。
对于目前无法解决的瓶颈，在QC域中标注为Later状态，进行风险评估，决定是否上限。
将风险控制到最低水平。
8. 性能测试评估
（1）实施测试前，需要对被测项目进行评估。目的是明确是否需要做性能测试，确立性能点，明确该测什么，期望值是多少（根据情况评估）。
（2）评估分为测试前评估和测试后评估。
（3）测试前的评估有以下4个维度：关键业务，日PV量，逻辑复杂度，运营推广计划等。
1）关键业务：首要维度，明确被测项目是否属于关键业务，主要的业务逻辑点。
2）日PV量：第二维度，界定被测项目各功能点的PV量。如果PV量高，系统压力大，且是关键业务，则该项目需要做性能测试。
3）逻辑复杂度：第三个维度，判定被测项目各功能点的逻辑复杂度。如果一个主要业务的PV量不高，但是逻辑很复杂，也需要做性能测试。
4）运营推广计划：第三维度，根据运行的推广计划来判定待测系统未来的压力。降低运行风险是性能测试的主要目标，被测系统的性能不仅能满足当前压力，更要满足未来一定时间段内的压力。
5）其他：除了上述四点，当一个功能点属于内存高消耗，CPU高消耗时，也可能需要做性能测试。
9. 压力估算
（1）并发数估算
根据TPS估算并发数
1）TPS=(高峰日业务量*80%)/(用户使用系统时间*20%)*3600
2）并发数(Vu)=TPS*业务完成时间
3）并发数(Vu)=业务量(C)*单事务平均响应时间(T)/交易时间(H)
注：高峰日业务量可以从监控工具抓或从严密的行为分析得出
经验公式
1）C=用户总数的(10%-20%)
C=nL/T
1）C是平均的并发用户数，n是session的数量
2）L是session的平均长度，t指考察的时间段长度
峰值并发用户数
1）C` 约等于C+3
（2）脚本时间
Think_time
Runlogic_time
Waiting_time
1551
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
