性能测试知多少——常见性能问题

Posted 2023-04-17

参考技术A 在日常生活当中，如果你的应用运行太慢或者经常出现各种使用不方便的问题，那很多情况下用户都是会选择离开，因此性能说的简单一些就是站在用户的角度去测试实际的感受，如果说功能测试是确保软件可用，易用。那么性能测试就是让这些功能变得更流畅，用户使用的更舒服。

不过很多刚刚进入测试家庭的新同学很容易将性能测试这个过程片面的理解成找工具或者写工具进行测试最后给出一个图表结果，仅仅看中了过程而忽略了在测试过程中发现定位并解决问题的能力。针对分析问题这个步骤，我也是在网上拜读了一部分前辈的测试经验，并希望在此将一些常见的思路分享给大家。

说到性能测试，我们首先要明确性能测试的目的，只有明确测试的目的才能更好的发现软件的不足：

1.功能验证：验证某软件在一定条件下具有什么样的功能

2.能力规划：如何使系统达到我们要求的性能能力

3.应用程序诊断：比如内存泄漏，通过功能测试很难发现，但通过性能测试却很容易发现。

4.性能调优：满足用户需求，进一步进行系统分析找出瓶颈，优化瓶颈，提高系统整体性能。

性能测试的整体步骤可以按照下图划分：

其中分析结果是整个步骤中重要的一环，接下来就为大家介绍一些常见的问题：

硬件上的性能瓶颈：

一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈、服务器操作系统瓶颈（参数配置）、应用瓶颈。

应用程序上的性能问题：

一般指的是开发人员开发出来的应用程序或者新功能。例如，程序架构规划不合理，程序本身设计有问题，造成系统在用户使用时性能低下。在此处出现的问题往往是应用开发在进行功能实现上使用错误的方法而导致的（完全可以避免），因此这也是需要测试人员快速定位并解决的问题。

操作系统上的性能瓶颈：

例如ios操作系统。例如，在进行性能测试，出现内存不足时，系统会发出对应用的低内存警告，如果应用没有及时响应系统的警告就会将程序进程终止，造成程序崩溃。这时认为操作系统上出现性能瓶颈。

网络设备上的性能问题：

一般指的是防火墙、动态负载均衡器、交换机等设备。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络环节存在问题。

由于性能测试出现的原因及其定位都十分复杂，这里只是简单介绍常见的几种问题类型和特征，而性能测试所需要做的就是根据各种情况因素综合考虑，然后协助开发人员一起定位性能瓶颈，下次作者会结合实际测试情况和大家一起寻找定位问题的方法。

性能测试知多少---并发用户

虫师 大人不华，君子务实。 独立博客：http://www.testpub.cn

性能测试知多少---并发用户

2012-06-25 23:49 by 虫师, 24863 阅读, 10 评论, 收藏, 编辑

 

　　在做性能测试的时候，我们常常听到并发用户、响应时间、吞吐量专业术语，也许大家都理解，这里有一个理解的层次与深度概 念。最近有看断念《软件性能详解与案例分析》一书，看了他的讲解，原来我对这些术语的理解还是比较肤浅，其实，这里也主要受制于自己的知识面。所以，再拿 出来与大家重温一下。

 ps:按照惯例先上个图，因为看纯文字的文章比较累！^_^

 

 

并发用户数

　　大家都知道我们的性能测试就通过工具模拟多用户对系统进行操作，对系统造成压力，来验证系统的性能（不太标准的解释）。 好多人也简单的把性能测试当成并发测试。那么这个“多用户”和“同时”两个因素缺一不可。只多用户不同时，很难对系统构成压力；没有多个用户，同时的概念 也就自然不存在了

 

并发的两种情况

　　一种是严格意义上的并发，即所有的用户在同一时刻做同一件事或操作，这种操作一般指做同一类型的业务。比如，所有用户同一时刻做并发登陆，同一时刻做表单提交。

　　另外一种并发是广义范围的并发，这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或都操作可以是相同的，也可以是不同的。比如，在同一时刻有用户在登录，有用户在提交表单。

 

从服务器的角度来看并发

　　前面的两种解释都是从用户业务的角度来解释并发的，因为我们平时所做的性能测试也是从用户端对业务层的操作来进行并发测试的。

　　如果考虑整个系统运行过程中服务器所承受的压力是这样的：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个就是所谓的服务器所承受的最大并发访问数。

 

真正意义上的并发不存在

　　上面试谈了这么多并发，现在又说真正意义上的并发不存在。何解？学操作系统原理的同学都知道，CPU在一个时间点上只能干一件事儿。为什么我们可以边看电影，边打字，边语音。因为CPU很快很快，他可以处理一下电影，再处理一下打字，再处理一下语音。因为它很快，所以，它可以在多个程序之间快速瞬间的切换，给你造成的假象就是它在同时做这些事情。（现在的双核、四核的CPU另说）

　　那么我们的系统在接到用户的请求后也要调用CPU来 完成某些处理，然后返回给用户。那么我们对系统有做并发测试是测什么呢？举个简单的例子。假如有一位神医，他的看病速度非常快，假设他的看病速度是不变 的；然后有一群接待人员来接待看病的客人，有成千上万的病人来看病，接待人员要想各种办法来做好接待工作，使病人更快的看到病。比如，可以事先咨询病人得 的什么病，然后将病人进行分类，比如可以扩大接待室，让更多的病人可以进到医院来看病等。

　　神医就是我们的CPU， 接待人员就是我们的系统，病人就用户，我们做性能测试的目的就是了解接待人员哪个地方给医院看病造成了瓶颈。只来一个病人，医院的看病速度与服务很好。一 下子来十万个病人各种问题就出来了。接待人员的服务态度下降，多余的人员跟本进不到医院去，医院的洗手间不够用，造成病人无法上则所而离开，这些都属于系 统问题。所以，我们一般测试的目的是看医院的接待能力。

 

系统用户数与同时在线人数

　　在实际的性能测试中，经常接触到与并发用户相关的概念还有“系统用户数”与“同时在线人数”下面通过一个实例来描述他们之间的差别。

　　假设有一个网站，注册用户才能登录使用各种功能，如上传头像，阅读专家文章等。该系统有20万注册用户，这就是说有20万用户可以使用这个网站的所有功能，20万就是这个网站的“系统用户数”，网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的最高记录是2万，就是有2万人同时用浏览器打开着这个网站。2万就是“同时在线人数”

　　那么系统的并发用户数是多少呢?2万么？NO!这2万只表示在系统最高峰时有这么多用户登录了网站，并不表示实际服务器的承受压力。因为服务器承受压力还与具体的用户访问模式相关，在这2万用户中考察某一个时间点对用户发出请求数，可以会大大缩水。那么，该系统的服务端承受的最大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过服务器日志的分析得到。

 

求并发用户数公式

在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务的角度关注应该设置多少个并发数比较合理。

下面找一个典型的上班签到系统，早上8点上班，7点半到8点的30分钟的时间里用户会登录签到系统进行签到。公司员工为1000人，平均每个员上登录签到系统的时长为5分钟。可以用下面的方法计算。

　　　　C=1000/30*5=166.7

C表示平均并发用户数，那么对这个签到系统每分钟的平均在线用户数为166

当然，在性能测试上，任何公式都不是严谨的，最重要的是对系统做出有效正确的分析。

 --------------------------

      根据 Teaey 的提醒已经做了改正，计算结果是每分钟，而且是在线用户数，而非并发用户数。