下图中，每一个颜色的线段代表一种操作。在任意一个时刻，服务器都知道它有10个事务需要处理，这10个事务也是有10个用户产生的。但它不知道的是，整个时间段内的所有事务，是由多少个用户与系统交互而产生的。

     这句话好像有点绕，我再试着更形象的解释一下。时刻1，10个当前事务是由10个用户发起的。时刻2，依然是10个正在进行的事务，但可能是完全不同的10个人发起的。在这段时间内，服务器每一个时刻都在处理10个事务，但是参与了这个交互过程（对服务器产生压力）的人可能会达到上百个，也可能只有开始的10个。

     那么，对于服务器来说，压力是什么呢？显然只是每时刻这10个同时处理的事务，而到底是有10个人还是1000个人，区别不大（暂不考虑session等问题）。

     下面再从用户的视角来看看。实际的情况中，不可能出现很多用户同一时刻开始进行操作的场景，而是有一定的时间顺序的。正如下图所示，在这个时间段内，一共有23个用户进行了操作。

     但是服务器能看到这些用户么？它知道的只是某一个时间点上，有多少个正在执行的事务。大家可以数一下，此图中任意时刻的并发事务依然是10个。

     其实这两个图描述的本来是同一个场景，只不过观察者的视角不同罢了。

     那么大家想想，在性能需求中常见到的“并发用户”到底是指的什么呢？

并发用户

     很多使用“并发用户”这个词的人，并没有从服务器视角进行考虑。他们想的是坐在电脑前使用这个系统、对系统产生压力的人的个数。基于这个原因，我很少使用这个容易让人误解的词汇，而是进行了更细的划分。主要有这么几个：系统用户数（注册用户数）、在线用户数（相对并发用户数）、并发用户数。

     上面几个例子中所说的“并发用户”，实际是在线用户数。其实我更喜欢叫做相对并发用户数，因为这个词更容易让人感受到“压力”。相对并发用户数指的是，在一个时间段内，与服务器进行了交互、对服务器产生了压力的用户的数量。这个时间段，可以是，也可以是一个小时。而需求人员必须要描述的，也正是这个内容。

     而并发用户，主要是针对某一个操作进行测试，即多个用户同一时刻发起相同请求。可以用来验证是否存在并发逻辑上的处理问题，如线程不安全、死锁等问题；也可提供一些性能上的参考信息，比如1个用户需要1秒，而10个用户并发却需要30秒，那很可能会有问题，需要进行关注，因为10个用户请求排队处理也应该只需要10秒啊。但这种并发的测试，同实际压力下的用户体验关系不大。

     再回到相对并发这个概念上来，它与服务器的压力到底是什么关系呢？如果你理解了前面的所有内容，那么会知道这两者其实没有直接联系（当然了，同一个测试用例中，肯定是用户数越多压力越大）。也是说，你得到的这种性能需求，是无法知道服务器到底要承受多大压力的。

那么如何开展性能测试？

如何模拟压力

     既然我们知道了所谓的压力其实是从服务器视角来讲的，服务器要处理的事务才是压力，那么我们从这出发，来探寻一下性能测试需要的信息。依然用之前的小论坛为例，我们需要测试活跃用户为500人时，系统的性能是否能还能提供良好的用户感受。

     假设现在的活跃用户有50个人（或者通过另一个类似的系统来推算也行），平均每天总的发帖量是50条、浏览帖子500次，也是每人每天发一个帖子、浏览十个帖子（为了方便讲解，假设论坛只有这两个基本功能）。那么我们可以推算，活跃用户达到500时，每天的业务量也会成比例的增长，也是平均每天会产生500个新帖子、浏览帖子5000次。

     进一步分析数据，又发现。用户使用论坛的时间段非常集中，基本集中在中午11点到1点和晚上18点到20点。也是说每天的这些业务，实际是分布在4个小时中完成的，如下图（随便找了个图意思一下，数不一致）。

那我们的测试场景，是要用500个用户在4小时内完成“每人发一个帖子、浏览十个帖子”的工作量。

     注意上面的两处，“平均每天……”、“分布在4个小时……”。敏感的测试人员应该能发现，这个场景测的是平均压力，也是一个系统平常的使用压力，我喜欢称之为日常压力。

     显然，除了日常压力，系统还会有压力更大的使用场景，比如某天发生了一件重要的事情，那么用户会更加热烈的进行讨论。这个压力，我习惯叫做高峰期压力，需要专门设计一个测试场景。

     这个场景，需要哪些数据呢，我们依然可以从现有的数据进行分析。比如上面提到的是“平均每天总的发帖量……”，那么这次我们要查到过去高一日的业务量。“分布在4个小时”也需要进行相应的修改，比如查查历史分布图是否有更为集中的分布，或者用更简单通用的80-20原则，80%的工作在20%的时间内完成。根据这些数据可以再做适当的调整，设计出高峰期的测试场景。

     实际工作中可能还需要更多的测试场景，比如峰值压力场景。什么是峰值压力呢，比如一个银行网站，可能会由于发布一条重磅消息使访问量骤增，这个突发的压力也是性能测试人员需要考虑的。

     需要注意高峰期压力和峰值压力的区别，高峰期压力是指系统正常的、预期内压力的一个高峰。而峰值压力是指那些不在正常预期内的压力，可能几年才出现一次。

     这里只是举了个简单的例子，实际工作远比这复杂的多。需要哪些数据、如何获取，很可能要取得这些数据要花费很大的功夫。这其实涉及到了一个很重要的内容，用户模型和压力模型的建立，以后会有专门的文章进行讲述。

     为什么要花这么大的精力来收集这些信息呢？是因为只有通过这些有效的数据，才能准确的去模拟用户场景，准确的模拟压力，获取到更加真实的用户体验。只有这样，“不同的测试人员，测出相同的结果”才会有可能实现，而且结果都是准确有效的。

要点回顾

后通过几个小问题来总结回顾一下：

你真的理解“并发用户”的意义么？

什么是用户视角和服务器视角？

什么是压力？

如何模拟预期压力？