深聊性能测试，从入门到放弃之：初识性能测试

本来想分成7篇来写，但是又考虑看到情深处，还得翻页，所以，索性合成一篇来写。
在写正文之前，先分享一个小故事：
人物：
小屌丝：测试经理
大佬：产品经理
小屌丝最近在做一个xx项目，项目马上结项，大佬突然要求小屌丝做性能测试。
俗话说做项目，要有规范流程，也要有项目计划。
小屌丝一脸懵逼，3秒后，小屌丝发出4问~ ~
小屌丝：大佬，首先我们在项目初期评估，这个项目是不是不需要做性能测试，二来，客户有没有要性能报告，三来，合同有没有提供软硬件设备信息，性能期望值等信息，四来，我们是不是需要到客户现场进行部署？
大佬：嗯…
小屌丝：那我们做性能测试，是为了体现报告的完整性，还是为了体现我们团队牛叉？
大佬：我就是想要性能测试报告！
小屌丝：…

哎！ 长叹一声吧~ ~
言归正传，既然作为一名专业性能测试工程师，一定要给出项目负责人/客户最合理，最优的解决方案，千万不要因为她们的不了解，而嘲笑她们。
毕竟隔行如隔山~ ~ ~

接下来，跟着小鱼，详细的学习，如何搞性能！
小鱼儿会让你，从入门到放弃，就是一瞬间~ ~

一、测试流程

引用鲁迅老先生的话：无规矩不成方圆。

当然，我们性能测试，也需要有流程规范，而且符合项目管理流程，你说帅不帅~~
我们来瞅瞅这个流程规范

有了上面的流程图，接下来，我们就来详细介绍一下各个环节：
①业务学习：通过查看文档，或通过实际操作来了解系统的功能。
②需求分析：分析系统非功能需求，划定性能测试的范围，了解系统性能指标。
③工作评估：工作量分解，评估工作量，计划资源投入(人、日)。
④设计测试模型：划定性能测试范围后，把业务模型映射成测试模型。
听到这句话，是不是一头雾水？什么是测试模型？
通俗的说，就是 ：性能测试用例设计+性能测试方案
用例只关注业务，模型还需关注如何实现，是否具有可操作性，可验证性等，最后还得根据不同的测试目的，组合成测试场景。
⑤计划编写：计划测试工作，在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。
⑥脚本开发：录制或编写性能脚本，开发测试挡板程序，开发测试程序。甚至如果没有第三方工具，还需要开发测试第三方工具后程序。
>挡板程序：自己开发程序来替代第三方的支持
>>如：需要与航空系统进行交互，奈何航空公司不提供技术支持，我们就要自己开发程序替代。
⑦测试环境准备：性能测试环境包括服务器和负载机两部分。
服务器：被测系统的运行平台(软件、硬件)
负载机：我们用来产生负载的机器，用来安装负载工具，运行脚本的。
⑧测试数据准备：根据数据模型来准备被测系统的主数据和业务数据。
⑨测试执行：这一步是成败的关键，因为不同的人，设计场景以及测试执行上，所以结果可能还会有较大差异。
⑩缺陷管理：性能测试过程中发现的缺陷
⑪性能分析：性能测试结果可能暴露的问题进行分析，找出原因。
>>如何进行性能分析，请看小鱼的这篇《性能分析流程》
⑫性能调优：这就需要协作，性能测试大佬与开发大佬一起来解决性能问题
>>如何进行性能调优，请看小鱼的这篇《性能调优怎么做》
⑬测试报告：对测试结果的总结。
>>常见性能指标包含：TPS、RT、CPU Using 等等
⑭报告评审：针对性能报告中的内容进行评审，确认问题，评估上线/交付风险。

二、成败要素

小鱼记得，在性能分析这篇文章说过：如果把项目的各个环节比作各个学科，那么性能测试就是理综，集成了需求、开发、测试、运维、协调沟通。
我们从以下几点来说一下性能测试的几大难点：
①需求分析
②场景设计
③性能诊断调优
④环境搭建和模拟

很多性能测试大佬由于在需求分析阶段没分析到位，不准确的预估用户行为，不能在场景上很好的模拟用户操作，无法真实的模拟系统的负载情况，
最后的结果就是：在测试或者UAT环境运行的非常好，在上线后，就问题频频发生，结果可想而知。
就好比 ：
2008年的奥运会，
2012年11.11 某宝，
2012年11.11 某东，
2014年1月9日的12306，
2014年11月6日亚马逊网站。

针对外行人，或者有些性能测试大佬，都以为性能测试就是使用一个工具或者写一个脚本，弄几台服务器，随便"跑跑"，然后出一个报告，就ok了。
通常关注并发多少、响应时间多少、能不能跑通等等。
性能测试如果真的那么简单，还对得起从入门到放弃这几个字吗~~~
接下来我们来看一下，性能测试重要关注点有哪些：
1.评估系统，需求分析
在客户没有明确要求哪些值，
我们需要引导运维大佬和需求大佬给出具体的需求数据，并对数据进行二次分析，得出我们需要的信息。
针对初次上线的系统：我们需要用同行的数据，进行用户行为分析和商业数据结构的估算为前提，来进行推算，来得到我们想要的性能需求。
针对已上线的系统：我们可以通过运维人员获取TPS和时间的比例分布图、用户数和时间的分布图、数据库ER关系图、容量数据等，直接精确的得出目前系统的用户行为和业务数据关系，进而得到我们想要的性能需求。
2.场景设计，用例设计
我们要尽可能的真实模拟线上系统的负载。
我们要决定哪些功能需要参与性能执行，参与方式怎样？这就是用例设计。
如何有效的组织测试用例就是场景需做的事情，如，按业务分布，业务量，业务时段，业务角色来综合分配用户数、执行时间、执行比例等。
这个场景设计、用例设计，花费的时间可不短。
3.测试执行，是否pass
模拟不同负载执行测试场景来识别系统弱点，做好各种监控，筛查各种问题，验证系统稳定性等。
4.性能诊断优化
性能测试的大佬，需要具备良好的、敏锐的性能意识，能够把问题细化(即分步分类)，协助各开发团队完成问题定位，分析调优。

三、大佬看性能

由于性能是一门综合学科，所以，我们就从不同的角度，来看看这些大佬对系统的要求有哪些：
1.黑盒测试大佬角度：
关心应用程序的单步响应时间，性能的好坏，就看应用的时间多少，即数据流经过服务器/服务器集群经过网络传输后往返时间总和。
2.开发大佬角度
①架构合理性
②数据库设计合理性
③代码
④系统里内存使用方式
⑤系统里线程使用方式
⑥系统资源是否有恶性，不合理竞争
3.运维大佬角度
①硬件资源利用率
②JVM
③DB
④系统是否支持7x24的服务
⑤扩展性，兼容性，最大容量，可能的瓶颈
4.性能测试大佬角度
①服务器硬件性能
②根据需求或历史数据制定性能目标
③建立性能通过模型
④对开发代码框架和硬件框架进行性能分析
⑤针对开发发布版本进行基准测试
⑥执行软件性能验收及稳定性测试
⑦生产环境的配比和优化
⑧执行性能测试用例、场景设计
⑨协调部分之间的配合
⑩特定的性能分析

四、相关术语

1.负载：
模拟业务操作对服务器造成压力的过程，比如2000个用户进行下单操作。
2.性能测试(Performance Testing)：
模拟用户负载来测试系统在负载情况下，系统的响应时间，吞吐量等指标是否满足性能要求。
3.负载测试(Load Testing)
在一定软硬件环境下，通过不断加大负载(不同虚拟用户数)来确定在满足性能指标情况下能够承受的最大用户数。
>>这里性能指标包含：TPS(每秒事务数)，RT(事务平均响应时间)，CPU Using(CPU使用率)，Mem Using(内存使用情况)等软硬件指标。
4.配置测试(Configuration Testing)
为了合理的调配资源，提高系统运行效率，通过测试手段来获取，验证，调整配置信息的过程。
5.压力/强度测试(Stress Testing)
在一定软硬件环境下，通过高负载的手段来使服务器的资源(强调的是服务器资源，硬件资源)处于一个极限状态，测试系统在极限状态下长时间运行是否稳定。
>>确定稳定的指标，包含：TPS(每秒事务数)，RT(事务平均响应时间)，CPU Using(CPU使用率)，Mem Using(内存使用情况)等。
6.稳定测试(Endurance Testing)
在一定软硬件环境下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。这里强调一下，稳定性测试并不是在极限状态下来运行的，这与上面第五条的压力/强度测试 是不一样的。
一般我们会在满足性能要求的负载情况下加大到1.5 ~ 2倍的负载量进行测试。
7.TPS
每秒完成的事务数，通常指每秒成功的事务数，性能测试中重要的综合性能指标。一个事务是一个业务度量单位。
举个例子：
比如支付操作，在后台系统可能会经历会员系统，财务系统，支付系统，会计系统，银行网关等，但是针对用户来说，我就想知道我从下单到付款成功共花费多长时间。
8.RT/ART(Response Time/average Response Time)
响应时间/平均响应时间，指一个事务花费多长时间完成。我们更多的时候，是统计很多次响应时间，然后去平均值，这样保证了时间的准确性，同时也更具代表性。
>>通常，我们写RT，来代替ART。
9.PV(Page View)
每秒用户访问页面的次数。
>>此参数是用来分析平均每秒有多少用户来访问页面
10.Vuser(Virtual user)
虚拟用户数。即模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。Vuser脚本用户描述Vuser在场景中执行的操作。
11.并发：
并发最主要要有两点：点层面上和线层面上。
①点层面上的：
例如：周一早上7:30半，小学生要统一到操场升国旗。
>>即：同一时间做某件事
②线层面上的：
例如：中午11:30-13:00，小学生有的跳皮筋，有的踢足球，但同时对服务器产生压力。
>>即：一个时间段做不同的事
这里不做过多介绍，详细可以看小鱼写的这篇《常见并发问题》，里面有对并发的详细解读。
12.场景(Scenario)
性能测试过程中为了模拟真实用户的业务处理过程，在LR中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等一系类动作的集合，称之为性能测试场景。
>>场景中包含：待执行的脚本、脚本组、并发数、负载生成器、测试目标、测试执行时的配置条件等。
13.思考时间(Think Time)
模拟真实用户在实际操作过程中停顿的时间间隔。
>>从业务角度来讲：思考时间是用户在操作时，每个请求之间的时间间隔；
>>从测试脚本来讲：是两个请求语句之间的时间间隔。
14.标准差(Std. Deviation)
根据数据统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之，则说明系统不稳定。
>>包含：响应时间标准差，TPS标准差，Running Vuser标准差，Load标准差，CPU Using标准差等等。

扫描二维码关注公众号，回复： 11808413 查看本文章

五、性能工具

市面上的性能测试工具，还蛮多的，但是我们熟知，且使用最多的 JMeter 和Loadrunner这两款，那么，我们要怎么选性能测试工具、市面上又有哪些性能测试工具呢？
别着急，我们慢慢介绍。
1.如何选择性能测试工具
我们在选择工具的时候，无非从以下几个方面来考虑：
①专业，稳定，高效。
②简单易上手，在测试脚本上不需要花费太多时间。
③有技术支持，文档健全。
④投入与产出比。
2.常见性能工具有哪些
①HP公司的 Loadrunner
②Apache JMeter
③Grinder
④CompuWare 公司的QALoad
⑤Microsoft 公司的WAS
⑥RadView公司的WebLoad
⑦IBM公司的RPT
⑧OPENSTA等
在这里，小鱼强调一下，性能测试的核心不是选择什么工具，而是性能分析，重要的是思想，实现方式，这与选择什么工具，并无太大关系，
所以一定要分析主次。

六、通过标准

判断性能测试是否通过，不仅是看TPS，RT，而是要从服务端性能，前端性能，和用户体验性能来分析。
常见的测试通过标准如下：

七、小结

以上跟大家分享了，性能测试的基本情况，相信大家都能很好的理解并消化掉这些姿势，不， 是知识。
性能测试，要求的很多，不仅仅要求专业技能，还需要的是沟通能力。
为了能更好的学习掌握性能测试，还想需要各位大佬多从分析的角度来提升自己，毕竟，其的核心点就是性能分析。