同样的项目、同样的性能需求让不同的测试人员来测会是相同的结果么假设有这样一个小论坛性能测试人员得到的需求是“支持并发50人响应时间要在3秒以内”性能测试人员A和B同时开始进行性能测试各做各的。只考虑发帖这个操作A设计的测试场景是50人并发发帖得到的测试结果是平均完成时间是5秒。于是他提出了这个问题认为系统没有达到性能期望需要开发人员进行优化。B设计的测试场景是50个人在线并且在5分钟内每人发一个帖子也就是1分钟内有10个人发帖子最后得到的测试结果是平均完成时间2秒。于是他的结论是系统通过性能测试可以满足上线的压力。两个人得到了不同的测试结果完全相反的测试结论谁做错了或许这个例子太极端绝对并发和平均分布的访问压力当然是截然不同的那我们再来看个更真实的例子。还是一个小论坛需求是“100人在线时页面响应时间要小于3秒”。A和B又同时开工了这时他们都成长了经验更加丰富了也知道了要设计 出更符合实际的测试场景。假设他们都确认了用户的操作流程为“登录-进入子论坛-浏览列表-浏览帖子×10-发帖”即每个用户看10个帖子、发一个 帖子。于是他们都录制出了同样的测试脚本。A认为每个用户的操作一般间隔30s比较合适于是他在脚本中的每两个事务之间加上了30秒的等待思考时间。B想了想自己看论坛时的情景好像平均每次鼠标点击要间隔1分钟于是他在脚本中的每两个事务之间加上了1分钟的等待。他们都认为自己的测试场景比较接近实际情况可惜测试结果又是不同的很显然A场景的压力是B的两倍。那谁错了呢或者有人说是需求不明确导致的那么你需要什么样的需求呢看看我随手在网上51testing找的提问吧和上面的内容如出一辙。一定有很多的性能测试人员每天接到的就是这种需求又这样就开展了测试结果可想而知。这里我想问几个问题希望各位看完了上面的小例子后想一想如果有另一个人和你测同样的系统你们的测试结果会一致么如果不一致那么谁是正确的如何证明测试结果是有效的如果你有了一些疑惑对之前的测试结果少了一些自信那么请继续。服务器视角 vs. 用户视角性能测试中非常重要的一块内容就是模拟预期的压力测试系统运行在此压力下用户的体验是什么样的。那么压力是什么压力是服务器在不断的处理事情、甚至是同时处理很多事情。压力是服务器直接处理的“事情”而不是远在网络另一端的用户。下图中每一个颜色的线段代表一种操作。在任意一个时刻服务器都知道它有10个事务需要处理这10个事务也是有10个用户产生的。但它不知道的是整个时间段内的所有事务是由多少个用户与系统交互而产生的。这句话好像有点绕我再试着更形象的解释一下。时刻110个当前事务是由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%的时间内完成。根据这些数据可以再做适当的调整设计出高峰期的测试场景。实际工作中可能还需要更多的测试场景比如峰值压力场景。什么是峰值压力呢比如一个银行网站可能会由于发布一条重磅消息使访问量骤增这个突发的压力也是性能测试人员需要考虑的。需要注意高峰期压力和峰值压力的区别高峰期压力是指系统正常的、预期内压力的一个高峰。而峰值压力是指那些不在正常预期内的压力可能几年才出现一次。这里只是举了个最简单的例子实际工作远比这复杂的多。需要哪些数据、如何获取很可能要取得这些数据就要花费很大的功夫。这其实就涉及到了一个很重要的内容用户模型和压力模型的建立以后会有专门的文章进行讲述。为什么要花这么大的精力来收集这些信息呢是因为只有通过这些有效的数据才能准确的去模拟用户场景准确的模拟压力获取到更加真实的用户体验。只有这样“不同的测试人员测出相同的结果”才会有可能实现而且结果都是准确有效的。要点回顾最后通过几个小问题来总结回顾一下你真的理解“并发用户”的意义么什么是用户视角和服务器视角什么是压力如何模拟预期压力最后下方这份完整的软件测试视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】​​​软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。