性能测试新手误区（一）：找不到测试点，不知为何而测

有过一些性能测试经验的人很容易进入此状态，他们已经熟悉了性能测试的基本流程，能够比较熟练的使用测试工具开展工作。我大概从事性能测试一年左右时遇到了这个问题，那时我觉得性能测试的过程没有太多挑战，遇到的每一个系统，仿佛都可以用同样的流程完成。半天时间填写测试方案，一天时间来准备测试环境，一天时间准备测试脚本，一到两天来完成各种测试用例（基准测试、日常压力测试、峰值压力测试、绝对并发测试、稳定性测试等），然后就是调优、问题复测和完成测试报告。在我看来，性能测试好像变成了用一些工具去执行一个个固定的用例。

这样的工作持续了一段时间后，我感到有些不对劲，一定是哪里出了问题。性能测试难道真的这么简单，简单到把任何一个系统套入标准的流程中就可以了？于是我开始思考测试的意义，为什么要进行性能测试？是因为性能测试可以提供关于瓶颈、缺陷、效率等等我们认为有价值的信息。那仅仅通过一个工具，或者是一个固定的流程，就可以发现不同系统的这些信息么？这显然是不可能的。

我开始尝试尽量深入的去理解被测系统，这个系统的目的是什么，用户是如何使用系统的，用户对哪些业务的性能比较敏感，系统的一些关键业务实现逻辑是怎么样的，从设计实现的角度来看哪些业务的性能可能存在隐患。这些很少是技术层面上的问题，需要做的只是思考，再深入思考。慢慢的我有了些收获，开始了解为什么要测这个系统，针对这个特定的系统哪些内容是最重要的，为了获得需要的信息我需要从哪几个方面进行测试，为了实现我的想法又需要哪几种方法或者工具。（现在我的性能测试过程中，用于理解被测系统、理解用户、整理测试思路的时间投入大大增加了。你呢，投入了多大比例？）

要做好这些其实很难，每一个被测系统对我来说，仿佛就变成了一个新的挑战。但是逐渐的我发现自己思考问题更全面了、可以更快的抓住系统的重点、找到更重要的BUG、对系统的实际性能有了更准确的评估。这里提一个简单的问题，如何确保你的测试结果和生产环境的性能表现是一致的，也就是说测试结果能够真正的反应实际的性能，而不仅仅是代表了你选取的几个测试场景的性能。话说起来比较绕，但是请认真想一想，你有多大的把握呢？

上面只是写了一些个人的感想，我觉得如果在“思想”上没有办法上到一个新的台阶，你的性能测试生涯可能也就达到“瓶颈”了。如何突破这个瓶颈，那就需要努力改变自身，多思考多学习，最核心的能力恐怕不是能培训出来的。一定会有一些人认为性能测试的重点在于“技术”上，于是他们不断的记住各种调优配置参数，以为自己掌握了性能的精髓，仿佛什么系统到了他们手上，只要改几个参数就会出现奇迹。我也经历了这个阶段，也有过几次自以为挺高明的调优经历，也为自己会各种中间件数据库的配置调优而有些小得意。但现在想想，那还真是一个比较低的层次，思想上抓不住重点、看不全大局，技术上其实也只是一点皮毛。面对这类人，只要问几个为什么就会让他们无法回答，为什么要调优？为什么要调这个参数？如何证明这次调整的效果？

将上文简单的总结成几点，希望能给性能测试新手提供一丁点的帮助吧

性能测试的难点在于对被测系统的理解，在于对测试点的分析。为了实现测试的思想，可以有多种方法，手段永远只是辅助的，只有思想才是根本的。工具（如LR）更不等于性能测试，不要以为会用LR就懂了性能测试，那只是最低级的测试执行。也不要以为会调几个参数就懂了性能测试，那同样是个比较低的层次。

调优等技术不是性能测试的主要目的，好的性能也不是调出来的。测试人员一定要明白自己存在的价值所在，所谓的“技术”只是为了达成自己测试目的的一些手段，同开发人员、DBA相比，你在这些技术上永远是外行。

不要照着文档模板，填入测试方案。每一个系统都是不同的，要真正的认识到这一点，为每个系统设计出有针对性的测试方案。思考你每一步工作的意义和目的。

如何证明测试结果的有效性，其实是个很难的问题，值得花费时间去认真思考。这个过程涉及到一些很重要的内容，如用户模型的建立，后续会有专门的文章。

性能测试是一个需要不断改进的过程，每一次只需尽量的做到更好，多做一点点以前没有想到的东西。经过不断的积累，你会发现自己对性能测试有了更深的认识。

性能测试新手误区（二）：为什么我模拟的百万测试数据是无效的？

测试环境的重要性无需多说，大家都知道测试环境要尽量的模拟生产环境，当然也包括数据。这样测试的结果才会更加准确的反应真实的性能。就连开发过程，都已经开始在大数据量下加压开发了。那么，关于测试数据，你了解多少呢？

通常说的测试数据可以分为两类：

• 一是为了测试性能而准备的数据，这是用来模拟“压力”的数据。也就是常说的数据量、历史数据等。一般都会根据需求或者经验很容易估算出来，比如案件年增长量为5%，去年数据量为100W，测试需要保证3年后系统仍可正常运行，那么就需要计算并模拟出3年后的总数据量，在这个基础上进行测试。
• 二是用来辅助测试使用的数据。比如有一个对案件进行打分的功能，只有符合一定条件的案件才会出现在打分列表中。那么我们要测这个打分的操作，首先就要保证有可用的案件，这就需要去生成测试数据，该数据可能一经使用就失效了（已经打过分就不能再打了）。这样，每次测试这个功能，就需要准备这样一批数据。这里的测试数据，更多的是和测试流程有关，是为了能够正常的进行测试，而不是涉及到性能的。

我们这里要说的是第一类，对性能测试结果产生直接影响的数据。

先看两个小案例，涉及到了案件表（T_AJ）和法院编号列（N_FY）、立案日期列（D_LARQ）。案件表中模拟了一百万测试数据，测试简单的查询操作，根据经验，预期响应时间在2秒之内。

案例1. 查询本院案件列表，相应的SQL如下：

select * from T_AJ

where N_FY=10

order by D_LARQ desc

执行这个操作耗时近10s，显然达不到正常预期。

经排查，生成的100W测试数据中，所有的N_FY列值都为10。这样，最明显的问题就是，查询的结果集数量完全偏离了正常范围。如果实际有100家法院，正常分布下，每家法院只有1W的案件，但测试数据的FY只有一个值，通过这个查询，查出了原来100家法院的数据。无论是在数据库处理中（如本例的排序），还是在程序的处理中（如展现或者是对数据做进一步处理），两者的性能差异都是很显著的。所以这个测试结果是无效的。

有人说，这个例子太弱了，结果集差了100倍，性能当然不一样了。那是不是数据总量和结果集大小都一致，测试结果就是有效了呢？

案例2. 查询本院一个月内收的案件，相应SQL如下：

select * from T_AJ

where N_FY=10 and D_LARQ between '20110101' and '20110201'

这个操作，查出来的结果只有一千条数据，属于正常范围。但查询的时间还是超过5秒，依然超出了我们的预期。

查看数据发现，N_FY=10的数据有近50万,占了总数据量的一半，D_LARQ在一月份的数据也占了差不多一半。但是同时符合两个条件的数据还是一千条左右。那么这里的问题就不在于结果集了，而是是否能利用索引进行查询，看如下两个图就能很好理解了。

在正常数据中，每家法院的数据可能占总数据量的1％，一个月时间段内的数据可能占总数据量更少，假设是0.5％。那么这时我们通过N_FY和D_LARQ两个条件进行查询，数据库会进行估算：符合D_LARQ查询条件的数据大概有5000条，符合N_FY查询条件的数据大概有1万条，那么用D_LARQ上的索引进行查询是最快的，可以迅速的将查询范围缩小到5000条，然后在这5000条中去检查N_FY是否也符合条件。

过程如图一所示（手绘草图^_^）。

图一

注：数据按行存储，小方块表示符合该列查询条件的数据，阴影表示符合所有查询条件，也就是最终的结果集。箭头线段表示为了完成查询，需要扫描的数据量，本图中即符合LARQ查询条件的数据。下同。

但在本例中不正常的数据条件下，数据库会知道：符合N_FY查询条件的数据有50万条，符合D_LARQ的也有近50万条，如果使用其中一列的索引将一百万的范围缩减到50万，比从头到尾扫描整个表做的工作还要多（为什么呢？需要了解索引的结构和原理），那还是不要用索引了吧。于是数据库会依次检查每一条数据，判断N_FY和D_LARQ是否符合条件。

如图二所示。

图二

注：本图中实际扫描的数据量就是整张表的数据，但结果集和图一是一样大的。

这样，就可以知道，总数据量一样，结果集大小一样，为什么性能差了很多了。就是因为数据分布不合理，导致数据库无法正常使用索引，从而进行了全表扫描。当然，这个数据分布，我们依然可以归类到结果集中去，那就是要保证每一个查询条件“单独的结果集”都要符合真实情况，而不仅仅是整个查询最终的“总结果集”。

看个这两个简单的小例子，我们再来总结一下关于测试数据，需要注意的内容：

最根本、也是大家都知道的就是数据量，性能测试必须保证能在预期的数据量下进行测试。在一万条记录中查询，和在一百万数据中查询，显然是大大不同的，可以把数据量看做一种“压力”，这个就不用再解释了。

但是在比较大型的系统中，这一点可能也不是很容易做好，因为这类系统往往有着复杂的数据库，上百张的数据表。对每张表都进行数据模拟显然是不现实的，也是没有意义的，因为不是每张表都涉及到大数据量。那么如何选取不容易遗漏呢？通常通过两种方式：从设计和业务角度分析表间关系、从现有实际数据量进行分析推测。

确保结果集在正常范围内。结果集的大小直接影响后续很多工作的性能，如数据排序分组、分页、程序中的逻辑校验或者是展现。

数据分布必须合理，尽量接近真实。数据的分布，其实也就是数据的真实性，它直接决定了数据库是否使用索引、选用哪个索引，也就是常说的查询计划。不同的查询计划也就是不同的数据访问路径，性能差别可能会很大。

这里主要涉及到的是索引的问题，需要大家对索引的原理有一定的了解，索引如何工作、数据库如何选择索引、和索引有关的一写重要概念如区分度（selectivity）等等。

最好的数据来自生产环境。这是显而易见的，使用真实的数据测出来的结果才是最准确的。但是绝大多数情况下，我们没有这样的好运，可能是客户禁止、也可能是生产环境数据量比较小。那就只好自己想办法来模拟了，需要注意的也就是上面说到的几点。这里再推荐一种方法，数据翻倍。比如已经有了真实的数据十万条，但我们需要一百万条，那就可以通过写一些SQL或者存储过程，将现有的数据不断翻倍（简单的说，复制到临时表，根据需要修改一些列，再插回到原表），这样的数据真实性还是比较高的。

关于测试数据，我想说的就是以上几点了。另外再补充上一些相关内容，也是性能测试人员需要关注的。

重点了解IO的概念，更准确的说应该是物理IO。一般来讲，数据库的瓶颈或者查询的主要耗时就是IO。所以，数据库优化的一个重要方向就是尽量减小IO。

IO是不是只和数据量（行数）有关呢？举一个例子：

select co1, col2, col3, col4, col5 from T_AJ

where condition...

T_AJ数据量有100万，表中有近200列，此查询耗时大于10秒。而另一种实现方式，首先将col1-col5以及查询条件中的几个列的数据抽取到一张临时表（#T_AJ）中。然后，

select co1, col2, col3, col4, col5

from #T_AJ where condition...

临时表#T_AJ和原数据表有同样的数据量（行数），但是此查询却只需要1秒（暂不考虑抽取到临时表的耗时），这就是不同IO引起的差异。通常我们使用的数据库都是行式存储的，可以简单的理解为，一行数据从头读到尾，才能进入到下一行。这样，不管一行中的200列，你只读取其中的一列还是几列，其余的190多列仍然需要一定的IO。在大数据量下，这个性能差异就很明显了。所以上面的这个例子就是一种典型的优化手段，索引覆盖也是处理类似问题的典型方法，各位自行了解吧。列式存储数据库（如Sybase IQ）之所以性能这么高，也是同样的道理。

• 尽量深入了解这些概念，如执行计划，基于开销的估算，统计信息等等。我用一句话来简单描述：数据库通过统计信息来估计查询开销，统计信息不准时，开销估计就可能不准确，从而导致选择了错误的执行计划。
• 测试过程中数据的清理。性能测试过程中可能又会生成大量的数据，积累到一定程度又会对性能结果造成影响，所以每一轮测试时都应该清理掉之前测试过程中产生的数据，保证每次测试是在相同的条件下进行的。
• 性能测试过程中，如果定位到了某一个查询或SQL有问题，首先要确认的是数据是否合理。通过查询计划来判断是否按预期进行了查询，如果不是，查看数据的分布是否真实。一般数据库会提供很多种手段来进行验证。

性能测试新手误区（三）：用户数与压力

同样的项目、同样的性能需求，让不同的测试人员来测，会是相同的结果么？

假设有这样一个小论坛，性能测试人员得到的需求是“支持并发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个用户产生的。但它不知道的是，整个时间段内的所有事务，是由多少个用户与系统交互而产生的。

这句话好像有点绕，我再试着更形象的解释一下。时刻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%的时间内完成。根据这些数据可以再做适当的调整，设计出高峰期的测试场景。

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

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

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

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

要点回顾

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

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

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

什么是压力？

如何模拟预期压力？