性能测试初体验

软件测试的分类

可以看来测试根据不同的维度可以延伸不同的个测试分类对应不同的个测试方法。通过具体分类可以看到性能在整个测试周期占了很重要的比重。性能测试价值是保障系统的性能，提供良好的用户体验，尽可能地找出系统的性能薄弱环节进行优化。

性能测试分类：

性能测试的流程

1、业务学习：通过查看文档，手工操作系统了解系统功能
2、需求分析：分析系统非功能需求，圈定性能测试范围，了解性能指标
3、工作评估：工作量分解评估，计划资源投入（需要人力，完成日期）
4、设计模型：圈定测试范围后，把业务模型映射成测试模型
测试模型：
1、比如一个支付系统需要以银行系统进行交互，由于银行不能提供支持，我们需要开发程序去替代银行系统功能（这就是挡板程序，Mock程序）保证功能的性能测试能够开展，这过程就叫测试模型
2、再比如我们下单购物之前需要先登录，那么我们在开发脚本时就需要先把登录和购物的场景绑定在一起进行测试，这就是测试模型
测试用例只关注业务，模型还关注如何实现，是否具有可操作性，可验证性等问题最后我们根据不同的测试目的组建不同测试场景
5、计划编写：计划测试工作，在文档中明确测试范围，人力投入，持续时间、工作内容、风险评估、风险应对侧率等。
6、脚本开发：录制或者编写性能测试脚本
7、测试环境准备：服务器和负载机两部分，安装配置测试前置
8、测试数据准备：根据数据模型准备被测系统与业务数据，数据量变会引起性能的变化，在测试时往往准备一些存量/历史业务数据。数据需要考虑数量和分布。
9、执行测试：执行测试时性能测试的成败所在，同样脚本不同执行人员得出的记过可能差异较大，这些差异主要体现场景设计和测试执行上
10、缺陷管理：对性能测试过程发现缺陷集中管理
11、性能分析：对测试过程中暴露的问题进行分析，找出原因
12、性能调优：测试工程师和开发一起解决性能问题
13、测试报告：测试工作重要交付件，对测试结果进行报告，主要包括常见的测试性能指标说明（tps、rt\cpu\内存…），发现问题等。
测试最主要交付件：
1、测试计划
2、测试报告或阶段性测试报告
3、测试脚本
4、测试程序

性能测试术语：

1、负载

模拟业务操作对服务器造成压力的过程。
　　 比如模拟100个用户进行发帖。

2、性能测试（performance Testing）

是指通过模拟生产运行的业务压力或用户使用场景（负载）来测试系统的响应时间、吞吐量等指标是否满足性能要求。

3、负载测试（load testing）

在一定软硬件环境下，通过不断加大负载（不同虚拟用户数）来确定在满足性能指标情况下能够承受的最大用户数（超负荷）。

是通过逐步增加系统负载，测试系统性能的变化，并在满足最终确定性能指标的情况下，系统所能承受的最大负载量的测试 。

通过负载测试得到系统的负载模型，找到“性能拐点”和“有效峰值”。
　　性能指标包括 TPS（每秒事务数）、RT（事务平均响应时间）、CPU Using（CPU利用率）、Mem Using（内存使用情况）等软硬件指标。

4、配置测试（Configuration Testing）

为了合理地调配资源，提高系统运行效率，通过测试手段来获取、验证、调整配置信息的过程。
　　通过这个过程我们可以收集到不同配置反映出来的不同性能，从而为设备选择、设备配置提供参考。

5、压力/强度测试（Stress Tesing）

是在一定的负荷条件下，长时间连续运行系统给系统性能造成的影响。

压力测试的目标是测试在一定的负载下系统长时间运行的稳定性，尤其关注大业务量情况下长时间运行系统性能的变化（例如是否反应变慢、是否会内存泄漏导致系统逐渐崩溃、是否能恢复）；

压力测试是测试系统的限制和故障恢复能力，它包括两种情况：

稳定性压力测试：在选定的压力值下，长时间持续运行。通过这类压力测试，可以考察各项性能指标是否在指定范围内，有无内存泄漏、有无功能性故障等；

破坏性压力测试：在稳定性压力测试中可能会出现一些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的手段，往往能快速造成系统的崩溃或让问题明显的暴露出来；

最简单来说：
负载测试是测试软件本身最大所能承受的性能测试；
压力测试就是一种破坏性的性能测试；

6、稳定性测试（Endurance Testing）

在一定的软硬件下，长时间运行一定负载，确定系统在满足性能指标的前提下是否运行稳定。
　　与上面的压力/强度测试区别在于负载并不强调是在极限状态下（很多测试人员会持保守观念，在测试时会验证极限状态下的稳定性），着重的是满足性能要求的情况下，系统的稳定性、比如响应时间是否稳定、TPS是否稳定。
　　一般我们会在满足性能要求的负载情况下加大 1.5 到 2 倍的负载量进行测试。

7、TPS

每秒完成的事务数。通过指每秒成功的事务数，性能测试中重要的综合性性能指标。
　　一个事务是一个业务度量单位，有时一个事务会包括多个子操作，但为了方便统计，我们会把这多个子操作计为一个事务。
　　比如一笔电子支付操作，在后台系统中可能会经历会员系统、账务系统、支付系统、会计系统、银行网关等，但对于用户来说只想知道整笔支付花费了多长时间。

8、RT/ART（Respone Time/average Response Time）

响应时间/平均响应时间，指一个事务花费多长时间完成（多长时间响应可以请求），为了使这个响应时间更具代表性，会统计更多的响应时间然后取平均值，即得到了事务平均响应时间（ART），为了方便大家通常会直接用 RT 来代替 ART ，ART 与 RT 是代表同一个意思。

响应时间 = 客户端 + 服务器端 + 网络（性能工具拿到的是后两个数据）

9、PV（Page View）

每秒用户访问页面的次数，此参数用来分析平均每秒有多少用户访问页面

10、Vuser虚拟用户（Virtual user）

模拟真实业务逻辑步骤的虚拟用户，虚拟用户模拟的操作步骤都被记录在虚拟用户脚本里。Vuser 脚本用户描述 Vuser 在场景中执行的操作

并发用户数和在线用户数。并发，操作的，对系统造成压力的。在线的，有可能只是挂着系统，但是没有实际操作，对系统几乎没有压力。

11、Concurrncy并发

并发分为狭义和广义两类。
　　狭义的并发，即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。
　　广义的并发，即多个用户对系统发出了请求或者进行了操作，但是这些请求或操作可以是不同的。对整个系统而言，仍然有很多用户同时进行操作。
　　狭义并发强调对系统的请求操作是完全相同的，多适用于性能测试、负载测试、压力测试、稳定性测试场景；广义并发不限制对系统的请求操作，多适用于混合场景，稳定性场景

12、场景（Scenario）

性能测试过程中为了模拟真实用户的业务处理过程，在LoadRunner中构建的基于事务、脚本、虚拟用户、运行设置、运行计划、监控、分析等一系列动作的集合，称之为性能测试场景。场景中包含了待执行脚本、脚本组、并发用户数、负载生成器、测试目标、测试执行时的配置条件等。

13、思考时间（Think Time）

模拟正式用户在实际操作时的停顿间隔时间。从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。在测试脚本中，思考时间体现为脚本中两个请求语句之间的隔间时间。

14、标准差（Std. Deviation）

该标准差根据数理统计的概念得来，标准差越小，说明波动越小，系统越稳定，反之，标准差越大，说明波动越大，系统越不稳定。包括响应时间标准差、TPS标准差、Running Vuser标准差、Load标准差、CPU资源利用率标准差、Web Resources 标准差等。

15、点击数

点击数不是鼠标点击次数，是发送的请求数

16、吞吐量

单位时间内被测系统处理的业务或者请求的数量

17、PV和UV
　　PV：访问一个URL，产生一个PV（Page View，页面访问量），每日每个网站的总PV量是形容一个网站规模的重要指标。
　　UV：作为一个独立的用户，访问站点的所有页面均算作一个UV（Unique Visitor，用户访问）

压力测试与负载测试两者区别

相同点：都是性能测试
负载测试强调系统正常工作情况下的性能指标
压力测试的目的是发现在什么条件下系统的性能变得不可接受，发现应用程序性能下降的拐点。

无论使用测试工具还是模拟，本质上市通过一个程序去测试另一个程序。

性能测试通过标准

性能测试从需求、设计、准备、执行到分析，最后需要判断性能测试是否通过，性能测试工程师最终需要考虑很多因素，判断的标准相应也会有很多个维度。
性能测试通过标准包括服务端性能、前端性能、和用户体验性能组成，常见标准请看下图：

性能测试趋势

提高工作效率是人类一直的追求，性能测试将会在自动化道路上越走越远，持续集成也将会更好的集成性能测试。
近年来开始流行devops，开发与运维、开发与测试的边界越来越窄，很多运维及测试的事情都在开发的考虑范围内，自动化工作性能测试工作都会有一部分并入devops中，我们面临的系统复杂度越来越高，分析问题难度加大，自然价值更高。

------------------------------------------END------------------------------------------------