性能测试之初窥门径_并发测试中,关注是否存在太多的临时对象,该类型的异常属于是-CSDN博客

本文链接：https://blog.csdn.net/qq_41587017/article/details/115642604

性能测试之初窥门径

几乎所有的测试工程师都听说或者接触过性能测试，并常困于其内容之广泛、过程之"玄妙"。我作为一个刚入门的测试工程师，初识性能测试时，便已倒在了众多性能指标、工具面前，对那复杂、精妙的性能测试设计思路更是望而却步。我深知，以我的积累，还暂时无法翻越性能这座高峰，但世上无难事，只要肯攀登，不积跬步，则无以至千里。

在阅读完段念前辈的《软件性能测试过程详解与案例剖析》、陈霁的《性能测试进阶指南后》，我决定对自己现阶段所学做一个总结。此文或许略显浅薄，只能待我日后来一一完善。

1. 什么是软件的性能

1.1 从用户角度出发，对于一个web应用而言，常常有这样的需求描述，”某某页面的响应时间要在多少秒之内“、”某系统能在多少用户同时使用的情况下稳定运行“、”某业务要支持多大的并发量“。这是用户关注的软件性能。

对于用户而言，整个软件的响应时间就是后端响应时间+前端响应时间

1.2 从运维的角度出发，他们更关心该软件所占的系统资源是否合理

系统管理员关注的性能	性能描述
服务器资源占用情况是否合理	资源利用率
系统能支持多少用户访问？系统能存储多少数据？	系统容量
系统能否24小时稳定运行	系统稳定性
更新哪些硬件能提高系统的运行速度	系统可拓展性

1.3 从开发的角度出发，软件的性能则更多的体现在某个方法、函数的运行时间为多少，一条SQL语句的处理时间是多少，某个算法的时间复杂度是多少

开发人员关注的性能	性能描述
架构设计是否合理	系统架构
数据库设计、SQL语句编写是否合理	数据库设计
代码是否存在性能问题	代码
是否存在因资源争夺而引起的死锁	设计与代码
线程处理是否有问题	设计与代码

2. 常见性能指标

2.1 响应时间

响应时间，简单来说就是系统响应一个请求的时间。对于一个基于交互的系统而言，这样的描述显然是没有问题的，往往系统响应结束则意味着与用户的交互完成。但针对一个web系统而言，用户关注的主要是客户端呈现给他们的内容，因此整个响应时间就由服务端响应请求的时间和客户端接受到服务端响应数据，进而执行脚本、渲染页面的时间构成。

有一点需要注意的是，响应时间是一个具有主观色彩的指标，很可能昨天用户涨了工资心情大好，对待响应时间的标准比较低，也可能今天买方便面发现没有调料包，对响应时间的要求及其之严格(I'm kidding!)。言归正传，在做性能测试时，我们不能根据自己的主观臆测来制定响应时间的标准，需要针对不同的业务做出调整。

例如：一个企业的官网、一个博客网站、一个电商网站，这类以呈现内容为重点、业务复杂度不高的网站，我们通常以2/5/10的标准来衡量其响应时间的优劣。一个页面2秒内呈现在我们的面前，则响应时间表现为优秀；倘若其加载时间在5秒之类，只能说是可以勉强接受，当然随着生活节奏加快、信息碎片化，对于我本人而言，此类网站加载时间为5秒左右，也是比较难接受的。当页面加载时间在10秒左右时，这个公司的IT部门基本可以宣告去世了，这个响应时间可以说是难以忍受的。

但对于一个数据量较大、业务复杂度较高的系统，其某个业务的单一页面响应时间较长也是可以接受的。例如：我司资产管理系统的资产盘点模块，用户一年也用不上几次，该业务需要对校内所有资产进行盘点、比对，最后上报教育部。该模块涉及到大量的数据处理，且不常使用，因此用户对其响应时间的长短并不是太关心。

2.2 并发用户数

并发用户数，就是指在同一时刻与服务器进行了交互的在线用户数量。这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。这里强调同一时刻，是因为很多人会将系统的在线用户数与并发用户数混为一谈。实际情况是，当前在线用户可能并未与系统发生交互，因此也就未对服务器产生压力。

那么如何比较合理的计算出一个系统的并发用户数呢？

https://my.oschina.net/ydsakyclguozi/blog/398236，可以参考这篇文章。简单总结，我们可以通过系统每日访问数量、平均访问时长以及考察的时长来估算并发用户数；也可以使用更为直接粗暴的方法，一个web系统，特别是OA系统，通常可以将并发用户数设置为其每日访问用户数的10%到20%。

2.3 吞吐量/吞吐率

吞烟吐圈

吞吐量也是一个系统十分重要的性能指标，它衡量了该系统处理请求速度的快慢。吞吐率则体现了单位时间内系统"生产"到”消费“的速率。吞吐率的单位可以是”字节数/秒“，也可以是”请求数/秒“。如果是”字节数/秒“，则更多是反应其网络传输、服务器架构这一层面的问题；如果是”请求数/秒“，则更多是体现服务器业务处理（代码）层面。

吞吐吞吐，一吞一吐，因此通常以发起一个请求为起点，服务器返回响应数据为终点。那么这里有涉及一个新的概念----事务。

事务，通常可以理解为一个完整的业务操作、用户完成单个操作或多个操作的组合。事务是根据我们的业务需求自己定义的，例如：用户实现登录可以为一个事务、用户提交一个表单可以为事务、一个完整的购物流程也可以为一个事务（主要保证其原子性）。

那么这里又可以引申出吞吐量的一个常用量化指标----TPS(Transaction per second)，译为每秒事务数。

当然，如果你用ab做过一些简单的压测，你就会发现还有一个东西叫QPS，英文名叫做Query per second。百度一下，相关内容不少，但都大同小异，因此我对其也是一知半解。从它的单位fetches/second，大概可以看出TPS也是用来衡量系统处理请求速率快慢的指标。那么它与TPS有什么不同呢？前面提到了，事务是一个模糊的概念，它可以是单个操作，也可以是一系列操作的组合，只要满足了4大特性，它就能被叫做事务。因此TPS可以表示处理单个操作的能力，也可以表示处理由多个操作组合的完整业务的能力。那么对应的，QPS则是处理单个请求的速率，这两个指标在某些特殊情况下是可能等同的。

2.4 性能计数器

性能计数器，是性能测试过程中需要重点监控的指标，这些指标通常与服务器硬件、操作系统有关，如Windows常见计数器Memory、Process、Physical Disk等，Tomcat这类J2EE应用服务器常见计数器JVM、JDBC Connection Pool等。详细内容可以参考下文https://www.cnblogs.com/zichuan/p/10166380.html

那么如何衡量这些计数器性能的好坏呢，这就需要我们去观察其对应的“资源占有率”。在为被测系统增加负载的时候，其性能计数器对应的资源占有率也是在不断变化的，例如：在10000的并发下，服务器CPU占有率为70%、内存占有率为65%。在分析性能测试结果时，我们通常对各个资源占有率进行横向比较，如果CPU占有率为100%，而其他性能计数器的占有率较低，则可以推断出该系统的性能瓶颈很可能是由CPU引起的。

3. 性能测试的几种常见类型

3.1 验收性能测试

在在软件开发初期，用户通常会给出一些性能需求，如：该系统最少支持多少的并发量且响应时间在多少秒以内、系统能在多久的运行时间内不出错等等。而在验收阶段，我们需要去验证在确定的测试环境下，系统性能指标是否达标，是否符合交付标准。

这是最常见的性能测试场景，其大概步骤也比较简单：

梳理用户的性能需求，并用对应的性能指标描述出来
根据用户实际使用环境，搭建测试环境
选择典型的、重要的业务场景，并编写对应的脚本
执行测试
分析结果

3.2 负载测试

负载测试，即是对被测系统不断增压，直至找到该系统的性能上限在哪。

需要使用负载测试的性能需求一般会这样描述，我总结为最大值原则，比如：”要求这个系统最多能承受1000个用户的并发，且响应时间最多不超过10s“、”要求能在1秒内处理1000笔业务，且CPU平均占有率不超过70%“。这两个需求都明显给出了一些性能指标的最大值，因此我们需要去验证系统的极限能否达标。

负载测试一般用来了解系统的性能容量，配合性能调优，观察执行调优策略后，性能容量是否增加。

注意：负载测试也要选取典型的业务场景，否则意义不大。

3.3 压力测试

压力测试可以说是采用了负载测试的方法，但其目的与负载测试不同。压力测试的目的是检测被测系统在高压之下能否稳定运行、有无错误产生、是否具有内存泄漏之类的安全隐患。简单来说，压力测试关注点在于这个系统能不能跑，负载测试则主要关注系统的各项性能指标

压力测试的需求描述一般为，”系统在一定的并发下(高于正常情况)，能否稳定运行24小时“、”在CPU或内存长时间平均占有率为70%以上时，系统能否不出现错误“，当然JVM的可用内存、数据库连接数等都可作为相关依据。

3.4 并发测试

并发测试，在前面的负载测试、压力测试中都会经常使用到。通常通过模拟多个用户并发访问同一个应用、同一个模块、执行同一个业务，并观察系统是否出现阻塞、死锁等情况。

并发测试在多个阶段皆可使用，可针对整个系统，也可针对某种架构设计的合理性。

关注的问题	问题描述
内存问题	是否有内存泄漏
	是否有太多临时对象
	是否有太多临时对象
数据库问题	是否有数据库死锁
数据库问题	是否经常出现长事务
线程/进程问题	是否出现线程/进程同步失败
是否出现资源争用情况导致的死锁	是否没有正确处理一场导致系统死锁