l如何在一个脚本中实现不同事务不同次数的循环呢？
l当然不用，LR早就想到了你的需求，下面让我们隆重推出Block。
l位置：Run-timeSettings--General--RunLogic
l操作：
l将你所要考察的事务设置在不同的Action内。
l在RunLogic中的Run中删掉默认的Action。
l在Run中插入Block。
l在插入的Block中再插入我们要考察的Action。
l设置Block的properties。这里有两种选择，Sequential和Random。如果选择Sequential，在下面的Iteration中直接填入数值，那么Block中的Action都会按输入的次数执行。如果选择Random，下面的properties还可以设置Block内各Action执行的百分比。
l按照我们前面的案例，我们只需要设置3个Block，每个Block中分别插入一个Action，设置执行次数分别为1，2，3就可以了。
l本人理解补充
2、在NumberofIterations中设置的循环次数，作用于Run(x)下的所有Action，而不作用于Block下的action。即Block下的action可以通过设置Block的Properties来指定循环的次数。
l为了解答上面的疑问，我们先来看一张表：
l在上面这个表中包含了几个不同的列，其含义如下：
lCmdID测试时被请求的页面
lNUM响应成功的请求数量
l我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下：
l事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。
l数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展雄才^_^
l一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。
l
lGoogle.com首页进行测试得来的，在测试中分别使用10/25/50/75/100几个不同级别的并发用户数量。通过这张图表，我们可以通过横向比较和纵向比较，更清晰的了解到被测应用在不同级别的负载下的响应能力。
l这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。
lNote：上面两个图表中的数据，主要通过Excel中提供的FREQUENCY，AVERAGE，MAX，MIN和PERCENTILE几个统计函数获得，具体的使用方法请参考Excel帮助手册。
l相信大家都进过或见过理发店，一间或大或小的铺面，1个或几个理发师，几张理发用的椅子和供顾客等待的长条板凳
l在我们的这个理发店中，我们事先做了如下的假设：
l1.理发店共有3名理发师；
l通过上面的假设我们不难想象出下面的场景：
l我想并不需要特别说明，大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象，继续看下面的这张图^_^
l根据这种性能表现，图中划分了三个区域，分别是LightLoad（较轻的压力）、HeavyLoad（较重的压力）和BuckleZone（用户无法忍受并放弃请求）。在LightLoad和HeavyLoad两个区域交界处的并发用户数，我们称为“最佳并发用户数（TheOptimumNumberofConcurrentUsers）”，而HeavyLoad和BuckleZone两个区域交界处的并发用户数则称为“最大并发用户数（TheMaximumNumberofConcurrentUsers）”。
l当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。
l进一步理解“最佳并发用户数”和“最大并发用户数”
l而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：
l对于一个系统来说，我们应该确保系统的最大并发用户数要大于系统需要承受的峰值负载。
l如果你已经理解了上面提到的全部的概念，我想你可以展开进一步的思考，回头看一下自己以往做过的性能测试，看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑，继续讨论下去。
l理发店模型的进一步扩展
l这一节中我会提到一些对理发店模型的扩展，当然，我依然是只讲述现实中的理发店的故事，至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来，就留给大家继续思考了^_^
l扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。
l扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。
l如何评价性能的优劣:用户视角vs.系统视角
l对于最终用户(End-User)来说，评价系统的性能好坏只有一个字——“快”。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求，对于用户来说，由他所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能的评价。
l换句话说，“好的性能”意味着更大的最佳并发用户数（TheOptimumNumberofConcurrentUsers）和最大并发用户数（TheMaximumNumberofConcurrentUsers）。有关“最佳/最大并发用户数”的概念请参见《理发店模型》一文。
l吞吐量vs.吞吐量
l在不同的测试工具中，对于吞吐量(Throughput)会有不同的解释。例如，在LoadRunner中，这个指标是以字节数为单位来衡量网络吞吐量的，而在JMeter中则是以事务数/秒为单位来衡量系统的响应能力的。不过在大多数英文的性能测试方面的书籍或资料中，吞吐量的定义使用的是后者。
l并发用户数≠每秒请求数
l这是两个容易让初学者混淆的概念。
l简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。
l需求阶段
l我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。
l如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。
l分析设计阶段
l系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。
l数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。
l在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。例如：某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。
l另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。
l编码阶段
l一片树叶在哪里最难被发现？——当这片树叶落在一堆树叶里面的时候。
l如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。
l另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。
l测试阶段
l产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标——如果有需求的话^_^
l如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。
l维护阶段
l维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统是否记录下了软硬件资源的异常或者警告。
l可靠性测试（ReliabilityTesting）对于一个运营商级的系统来说，能够保证提供7×24的连续稳定的服务是非常重要的。当然，你可以通过一些“高可用性（HighAvailability）”技术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。
l一种常用的方案是使用负载均衡（LoadBalance）和集群（Cluster）技术。但是在我们为客户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？
l我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务——就像从未发生过任何事情一样。
l当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉^_^
l性能测试，并非网络应用专属
l软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解：
l2.当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？
l3.杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？
l4.是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？
l如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。
l一个实际的例子
l为了便于大家的理解，我们先来看一个性能需求的例子，让大家有一个感性的认识，本文后面的讨论也会再次提到这个例子。
l这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的，不过看起来像是真实的^_^
ll系统总容量达到日委托6000万笔，成交9000万笔
ll系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔
ll实际股东帐号数3000万
l这个例子中已经包括几个明确的需求：
ll最佳并发用户数需求：每秒7300笔
ll最大并发用户数需求：峰值处理能力达到每秒10000笔
ll基础数据容量：实际股东帐号数3000万
ll业务数据容量：日委托6000万笔，成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型
l什么是“有效的”性能需求？
l要想获得有效的性能需求，就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。
l1.明确的数字，而不是模糊的语句。
l2.有凭有据，合理，有实际意义。
l如何获得有效的性能需求
l1.客户方提出
l这是最理想的一种方式，通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。
l2.根据历史数据来分析
l3.参考历史项目的数据
l如果该产品已有其他客户使用，并且规模类似的，可以参考其他客户的需求。例如在线购物网站，或者超市管理系统，各行业的进销存系统。
l4.参考其他同行类似项目的数据
l如果本企业没有做过类似的项目，那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到，包括系统容量，系统所能承受的负载以及系统响应能力等。
l5.参考其他类似行业应用的数据
l如果无法找打其他同行的数据，也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试，可以参考电信计费系统的需求——虽然不能完全照搬数据，但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些，应该考虑到的情况有哪些种。
l6.参考新闻或其他资料中的数据
l又一块砖抛出来了，希望大家在看完之后也有更多的玉丢过来^_^
l当时我们要做的是使用性能测试工具模拟大量用户在线点播Movie的业务，这个点播Movie的业务在第一次点播成功后，如果同一用户再次点播同一Movie，系统的处理流程与第一次点播是不同的。另外，我们在执行测试时，通常都会连续执行几个小时以获得尽可能多的样本数据。
l其实方法很简单。无论上LR还是JMeter，都提供了将多个参数的取值存放在同一个文件中，或者每个参数单独指定一个文件的功能，针对上面这个例子，我们只是简单的创建了两个文件和三个参数，第一个参数和第二个参数（用户账号和密码）存放在第一个文件中，有1000条记录；第三个参数（Movie的ID）存放在第二个文件中，有999条记录。然后在测试工具中设置参数取值的读取为顺序读取并且循环读取。通过这种简单的方法组合出了大量的数据。
l问题被解决了。
l下面我来讲解一下LR中ThinkTime的设置。
l自动：
l手动：
l添加好后，我们在Run-timeSettings中设置执行的策略。
l位置：Run-timeSettings－ThinkTime。进入后，我们会看到两个选项。Ignorethinktime：忽略thinktime，也就是即使你添加了thinktime，脚本执行的时候也不会理睬，忽略不执行。Replaythethinktime：下面还有３个子项。Asrecorded：按照录制的执行。不用多说。Multiplyrecordedthinktimeby：这就是我录制的thinktime乘一个系数。如，你录制的thinktime是4秒，在这里设置2，最后执行时就会按4秒×2＝８秒来执行。如果你想要执行２秒，就在这里填0.5。Userandompercentageoftherecordedthinktime：这里随机设置一个百分比，并规定上下限。如，录制的thinktime为4秒。Min为50％，Max为200％。那么执行的时候它就会从2秒到8秒内随机取一个数来执行。Limitthinktimeto：为thinktime设置一个上限，不管上面的如何设置，执行的时候，取值都不会操过这个上限。
l讲到这里，thinktime的设置大家应该很明白了。不知道让大家思考的问题是否想通了。需求说的是100用户同时在线操作，注意，是在线！大家想想，100人在线肯定有人在操作，也有人只是在线，没有对服务器发出任何请求。如果不设置thinktime，相当于100人并发操作，每个人都不停的向服务器发送请求，这比需求的压力可是大很多的呦～
l所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）资料，转变成是摘取自服务器所送的、动态的、每次都不一样的资料。举一个常见的例子，刚刚提到有些比较聪明的服务器，这些服务器在每个浏览器第一次跟它要资料时，都会在资料中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要资料的是不是同一个浏览器。一般称这个辨识码为SessionID。对于每个新的交易，服务器都会产生新的SessionID给浏览器。这也就是为什么执行脚本会失败的原因，因为VuGen还是用旧的SessionID向服务器要资料，服务器会发现这个SessionID是失效的或是它根本不认识这个SessionID，当然就不会传送正确的网页资料给VuGen了。
l当录制脚本时，浏览器送出网页A的请求，服务器将网页A的内容传送给浏览器，并且夹带了一个ID=123的资料，当浏览器再送出网页B的情求时，这时就要用到ID=123的资料，服务器才会认为这是合法的请求，并且把网页B的内容送回给浏览器。
l在执行脚本时会发生什么状况？浏览器再送出网页B的请求时，用的还是当初录制的ID=123的资料，而不是用服务器新给的ID=456，整个脚本的执行就会失败。要对付这种服务器，我们必须想办法找出这个SessionID到底是什么、位于何处，然后把它摘取下来，放到某个参数中，并且取代掉脚本中有用到SessionID的部份，这样就可以成功骗过服务器，正确地完成整个交易了。