1、什么是并发？

从用户业务的角度，并发分为狭义和广义两类。

• 狭义并发即所有的用户在同一时刻做同一件事情或操作，这种操作一般针对同一类型的业务，或者所有用户进行完全一样的操作，目的是测试数据库和程序对并发操作的处理。比如，所有用户同一时刻做并发登录，同一时刻做表单提交。

• 广义并发即多个用户对系统发出了请求或者进行了操作，但是这些请求或操作可以是不同的，但对整个系统而言，仍然是有很多用户在同时进行操作。比如，在同一时刻有的用户在登录，有的用户在提交表单。

狭义并发强调对系统的请求操作是完全相同的，多适用于负载测试、压力测试；广义并发不限制对系统的请求操作，多适用于混合场景、稳定性测试。

从服务器的角度来看并发

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

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

2、什么是并发用户数？与在线用户数和注册用户数的区别是？

并发用户数是指现实系统中同时操作业务的用户数，在性能测试工具中一般称为虚拟用户 （Virutal User）数。并发用户数跟注册用户数、在线用户数有很大差别：

• 并发用户数：一定会对服务器产生压力的用户数量。

• 在线用户数：只是“挂”在系统上对服务器不产生压力的用户数量。

• 注册用户数：一般指的是数据库中存在的用户数量。 

假设一个网站有20万注册用户，那20万就是这个网站的“注册用户数”。网站有一个在线统计功能，从统计数据中可以看到，同时登录网站的人数的最高记录是2万，就是有2万人同时用浏览器打开着这个网站，2万就是“在线用户数”

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

3、什么是TPS、QPS？

TPS（Transaction Per Second）：每秒事务数，即每秒系统能够处理的交易或事务的数量，它是衡量系统处理能力的重要指标。

QPS（Queries Per Second）：每秒请求数，即每秒系统能够处理的请求数，它也是衡量系统处理能力的重要指标。

4、并发用户数、响应时间和TPS之间的关系是？

事务是靠虚拟用户（并发用户）产生的，假如1个虚拟用户在1秒内完成1笔事务，那么TPS就是1，要想达到1000TPS至少需要1000个虚拟用户；如果某笔业务响应时间是1毫秒，那么1个虚拟用户在1秒内能完成1000笔事务，TPS就是1000。

因此1个虚拟用户可以产生1000TPS，1000个虚拟用户也可以产生1000TPS，主要看响应时间的快慢。

由此我们可以得出一个公式：TPS=虚拟用户数（并发用户数）/响应时间

5、如何选择并发用户及施压策略？

对于已上线的系统，可以选取高峰时刻在一定时间内使用系统的人数，这些人数可以认为是在线用户数，并发用户数取其10%就可以了。例如在1小时内使用系统的用户数为10000，那么取10%作为并发用户数基本就够了。

对于新系统，没有历史数据作参考，只能通过业务部门进行评估。

性能测试需要一套标准化流程及测试策略，并发用户数只是指标考虑的一个。在进行压测时一般会按照梯度施压的方式增加用户数，以此观察系统在不同压力下的各种反应。而不是在没有预估的情况下，一次加压大量用户，这样会导致系统失败率高响应时间长，最终得到的测试结果也没有太大意义。

一般情况下，大型系统（业务量大、机器多）做性能测试 5000 个并发用户就够了，中小型系统做性能测试 1000 个并发用户就足够了。

6、如何获取TPS？

对于已上线系统，可以通过高峰时刻，在5或10分钟内获取系统每笔交易的业务量和总业务量，然后按照单位时间内完成的笔数计算出TPS， 即业务笔数 /单位时间（5*60或10*60 ）。

对于新系统，因没有历史数据可供参考，只能通过业务发展趋势来预判各项指标。

7、如何评价系统性能？

在做性能测试的时候，很多人都用并发用户数来衡量系统的性能，觉得系统能支撑的并发用户数越多，系统的性能就越好。

其实，针对服务器端的性能，应该以TPS为主来衡量系统的性能，并发用户数为辅来衡量系统的性能。如果必须要用并发用户数来衡量的话，需要一个前提，那就是交易在多长时间内完成。因为在系统负载不高的情况下，将交易响应时间加到脚本中，并发用户数基本可以增加一倍，因此用并发用户数来衡量系统的性能没太大的意义。

8、测试脚本中事务选择的原则是什么？

测试脚本中事务选择的基本原则是：根据您的实际需求来设计。以一个网站为例：

• 如果您的压测目的是为了测试系统某个页面的对外服务能力，则可以用其页面的访问url作为一个事务。

• 如果您的压测目的是为了测试某个功能的服务能力，比如一个页面里某个url的服务能力（例如页面里有一个url需要访问数据库，想测试数据库的访问能力），则可以只压测这个url。