无所不在的性能测试——《LoadRunner 没有告诉你的》之五
提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。
本文是《LoadRunner没有告诉你的》系列的第五篇，在这篇文章中，我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中，如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。
因此，本文的结构也将依据软件开发过程的不同阶段来组织。
另外，建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。
需求阶段
我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。
如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。
分析设计阶段
系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。
数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。
在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。例如：某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。
另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。
最后，要知道不同厂家的设备性能是不同的，而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器，表现出来的性能也是不同的。如果有足够的资源，应当考虑提前进行软硬件平台的对比选型；如果没有足够的资源，可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。
编码阶段
一片树叶在哪里最难被发现？——当这片树叶落在一堆树叶里面的时候。
如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。
另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。
测试阶段
产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标——如果有需求的话 ^_^
如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。
在这个阶段还有很多值得我们深入思考和讨论的东西，在本系列后续的文章中，我们将会更多的关注这一部分的内容。
维护阶段
维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统是否记录下了软硬件资源的异常或者警告。
与性能测试相关的其他测试
可靠性测试（Reliability Testing） 对于一个运营商级的系统来说，能够保证提供7×24的连续稳定的服务是非常重要的。当然，你可以通过一些“高可用性（High Availability）”技术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。
常用的测试方法是使用一定的负载长时间向服务器加压，并观察随着加压时间的延长，响应时间、吞吐量以及资源利用率的变化。要注意的是，所使用的负载应当是系统的最佳并并发用户数，而不是最大并发用户数。
可伸缩性测试（Scalability Testing） 对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？
一种常用的方案是使用负载均衡（Load Balance）和集群（Cluster）技术。但是在我们为客户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？
可恢复性测试（Recoverability Testing） 虽然我们已经可以准确的估算出系统上线后将要面对的压力，并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力的，但是这个世界上总是有些事情上我们所无法预料到的——例如9.11事件发生后，AOL的网站访问量在短时间内增长到了平时的数十倍。
我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务——就像从未发生过任何事情一样。
如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的最大并发用户数，并导致软硬件资源利用率饱和，响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。
当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉 ^_^
性能测试，并非网络应用专属
软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，但是软件性能和性能测试却并非网络应用的专属名词，因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解：
1. 当使用Word来编辑一个500多页，并包含了丰富图表、图片和各种格式、样式信息的文档时，是否每次对大段的文字或表格的修改、删除或重新排版，都要等待系统花几秒钟的时间进行处理？
2. 当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？
3. 杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描？
4. 是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应？
如果大家有兴趣，也可以通过Google搜索到更多的有关单机应用性能测试的资料。
点击这里了解整个系列的创作进度，查看文章目录，或浏览已经完成的文章。
理解性能 ——《LoadRunner 没有告诉你的》之四
本文是《LoadRunner没有告诉你的》系列文章的第四篇，在这篇短文中，我将尽可能用简洁清晰的文字写下我对“性能”的看法，并澄清几个容易混淆的概念，帮助大家更好的理解“性能”的含义。
如何评价性能的优劣: 用户视角 vs. 系统视角
对于最终用户(End-User)来说，评价系统的性能好坏只有一个字——“快”。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求，对于用户来说，由他所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能的评价。
而对于系统的运营商和开发商来说，期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验，这就要确保系统能够在同一时间内处理更多的用户请求。正如在《理发店模型》一文中所描述的：系统的负载（并发用户数）与吞吐量（每秒事务数）、响应时间以及资源利用率（包括软硬件资源）之间存在着一个“此消彼长”的关系。因此，从系统的运营商和开发商的角度来看，所谓的“性能”是一个整体的概念，是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。
换句话说，“好的性能”意味着更大的最佳并发用户数（The Optimum Number of Concurrent Users）和 最大并发用户数（The Maximum Number of Concurrent Users）。有关“最佳/最大并发用户数”的概念请参见《理发店模型》一文。
另外，从系统的视角来看，所需要关注的还包括三个与“性能”有关的属性：可靠性（Reliability），可伸缩性（Scalability）和 可恢复性（Recoverability）——我将会在本系列文章的第五篇“无处不在的性能测试”中专门讨论这三个属性的含义和相关的实践经验。
响应时间
上面这张图引自段念兄的一份讲义，不过我略作了些修改。从图中我们可以清楚的看到一个请求的响应时间是由几部分时间组成的，包括
C1：用户请求发出前在客户端需要完成的预处理所需要的时间；
C2：客户端收到服务器返回的响应后，对数据进行处理并呈现所需要的时间；
A1：Web/App Server 对请求进行处理所需要的时间；
A2：DB Server 对请求进行处理所需的时间；
A3：Web/App Server 对 DB Server 返回的结果进行处理所需的时间；
N1：请求由客户端发出并达到Web/App Server 所需要的时间；
N2：如果需要进行数据库相关的操作，由Web/App Server 将请求发送至DB Server 所需要的时间；
N3：DB Server 完成处理并将结果返回Web/App Server 所需的时间；
N4：Web/App Server 完成处理并将结果返回给客户端所需的时间；
从用户的角度来看，响应时间＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是从系统的角度来看，响应时间只包括(A1+A2+A3)+(N1+N2+N3+N4)。
在理解了响应时间的组成之后，可以帮助我们通过对响应时间的分析来更好的识别和定位系统的性能瓶颈。
吞吐量 vs. 吞吐量
在不同的测试工具中，对于吞吐量(Throughput)会有不同的解释。例如，在LoadRunner中，这个指标是以字节数为单位来衡量网络吞吐量的，而在JMeter中则是以事务数/秒为单位来衡量系统的响应能力的。不过在大多数英文的性能测试方面的书籍或资料中，吞吐量的定义使用的是后者。
并发用户数 ≠ 每秒请求数
这是两个容易让初学者混淆的概念。
简单说，当你在性能测试工具或者脚本中设置了100并发用户数后，并不能期望着一定会有每秒100个请求发给服务器。事实上，对于一个虚拟用户来说，每秒发出多少请求只跟服务器返回响应的速度有关。如果虚拟用户在0.5秒内就收到了响应，那么它会立即发出第二个请求；而如果要一直等待3秒才能得到响应，它将会一直等到收到响应后才发出第二个请求。也就是说，并发用户数的设置只是保证服务器在任一时刻都有100个请求需要处理，而并不一定是保证每秒中发送100个请求给服务器。
所以，只有当响应时间恰好是1秒时，并发用户数才会等于每秒请求数；否则，每秒请求数可能大于并发用户数或小于并发用户数。
大概在一年前的一次讨论中，我的好友陈华第一次提到了这个模型的最初版本，经过几次讨论后，我们发现经过完善和扩展的“理发店模型”可以用来帮助我们理解很多性能测试的概念和理论，以及一些测试中遇到的问题。在最近的一次讨论后，我决定撰写一篇文章来专门讲述一下这个模型，希望可以帮助大家更好的理解性能测试有关的知识。
不过，在这篇文章中，我将会尽量的只描述模型本身以及相关的一些扩展，而具体如何将这个模型完全同性能测试关联起来，我不会全部说破，留下足够的空间让大家继续思考和总结，最好也一起来对这个模型做进一步的完善和扩展^_^ 我相信，当大家在思考的过程中有所收获并有所突破时，那种快感和收获的喜悦才真的是让人倍感振奋而且终生难忘的 ^_^
当然，我要说明的是，这个模型仅仅是1个模型，它与大家实际工作中遇到的各式各样的情况未必都可以一一对应，但是大的方向和趋势应该是一致的。
相信大家都进过或见过理发店，一间或大或小的铺面，1个或几个理发师，几张理发用的椅子和供顾客等待的长条板凳。
在我们的这个理发店中，我们事先做了如下的假设：
1. 理发店共有3名理发师；
2. 每位理发师剪一个发的时间都是1小时；
3. 我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。
通过上面的假设我们不难想象出下面的场景：
1. 当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；
2. 当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；
3. 很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时；
从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。
当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。
不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时和剪发1小时。
通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。
在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。
我想并不需要特别说明，大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象，继续看下面的这张图 ^_^
这张图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。
在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。
根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃请求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。
当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。
对应到我们上面理发店的例子，每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。
当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。
进一步理解“最佳并发用户数”和“最大并发用户数”
在上一节中，我们详细的描述了并发用户数同资源占用情况、吞吐量以及响应时间的关系，并且提到了两个新的概念——“最佳并发用户数（The Optimum Number of Concurrent Users）”和“最大并发用户数（The Maximum Number of Concurrent Users）”。在这一节中，我们将对“最佳并发用户数”和“最大并发用户数”的定义做更加清晰和明确的说明。
对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。
要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^
而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：
1. 当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；
2. 在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。
对于一个系统来说，我们应该 确保系统的最大并发用户数要大于系统需要承受的峰值负载。
如果你已经理解了上面提到的全部的概念，我想你可以展开进一步的思考，回头看一下自己以往做过的性能测试，看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑，继续讨论下去。
理发店模型的进一步扩展
这一节中我会提到一些对理发店模型的扩展，当然，我依然是只讲述现实中的理发店的故事，至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来，就留给大家继续思考了 ^_^
扩展场景1：有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。
扩展场景2：理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。
扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。
扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。
扩展场景5：理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设800电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。
这篇文章就先写到这里了，希望大家在看完之后可以继续思考一下，也写出自己的心得体会或者新的想法，记下自己的不解和疑惑，让我们在不断的交流和讨论中走的更远 ^_^
性能测试相关术语的英文书写方法（不断更新ing）——知道了这些术语在英文中的正确书写方法之后，可以通过 Google 更加高效的获取到更多有用的资料。
LoadRunner中的90％响应时间是什么意思？这个值在进行性能分析时有什么作用？本文争取用最简洁的文字来解答这个问题，并引申出“描述性统计”方法在性能测试结果分析中的应用。
为什么要有90％用户响应时间？因为在评估一次测试的结果时，仅仅有平均事务响应时间是不够的。为什么这么说？你可以试着想想，是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求？
假如有两组测试结果，响应时间分别是{1，3，5，10，16}和{5，6，7，8，9}，它们的平均值都是7，你认为哪次测试的结果更理想？
假如有一次测试，总共有100个请求被响应，其中最小响应时间为0.02秒，最大响应时间为110秒，平均事务响应时间为4.7秒，你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信？
为了解答上面的疑问，我们先来看一张表：
在上面这个表中包含了几个不同的列，其含义如下：
CmdID 测试时被请求的页面
NUM 响应成功的请求数量
MEAN 所有成功的请求的响应时间的平均值
STD DEV 标准差（这个值的作用将在下一篇文章中重点介绍）
MIN 响应时间的最小值
50 th(60/70/80/90/95 th) 如果把响应时间从小到大顺序排序，那么50％的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th也是同样的含义
MAX 响应时间的最大值
我想看完了上面的这个表和各列的解释，不用多说大家也可以明白我的意思了。我把结论性的东西整理一下：
1. 90％用户响应时间在LoadRunner中是可以设置的，你可以改为80％或95％；
2. 对于这个表，LoadRunner中是没有直接提供的，你可以把LR中的原始数据导出到Excel中，并使用Excel中的PERCENTILE函数很简单的算出不同百分比用户请求的响应时间分布情况；
3. 从上面的表中来看，对于Home Page来说，平均事务响应时间(MEAN)只同70％用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内，那么从平均事务响应时间来看是满足的，但是实际上有10-20％的用户请求的响应时间是大于这个值的；对于Page 1也是一样，假如我们确定对于Page 1的请求应该在3秒内得到响应，虽然平均事务响应时间是满足要求的，但是实际上有20-30％的用户请求的响应时间是超过了我们的要求的；
4. 你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th，并利用Excel的图表功能画一条曲线，来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现，那个最大值的出现几率只不过是千分之一甚至万分之一，而且99％的用户请求的响应时间都是在性能需求所定义的范围之内的；
5. 如果你想使用这种方法来评估系统的性能，一个推荐的做法是尽可能让你的测试场景运行的时间长一些，因为当你获得的测试数据越多，这个响应时间的分布曲线就越接近真实情况；
6. 在确定性能需求时，你可以用平均事务响应时间来衡量系统的性能，也可以用90％或95％用户响应时间来作为度量标准，它们并不冲突。实际上，在定义某些系统的性能需求时，一定范围内的请求失败也是可以被接受的；
7. 上面提到的这些内容其实是与工具无关的，只要你可以得到原始的响应时间记录，无论是使用LoadRunner还是JMeter或者OpenSTA，你都可以用这些方法和思路来评估你的系统的性能。
事实上，在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说，性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识，例如数学和统计学，来帮助我们更好的分析性能数据，找到隐藏在那些数据之下的真相。
数据统计分析的思路与分析结果的展示方式是同样重要的，有了好的分析思路，但是却不懂得如何更好的展示分析结果和数据来印证自己的分析，就像一个人满腹经纶却不知该如何一展雄才
^_^一图胜千言，所以这次我会用两张图表来说明“描述性统计”在性能测试结果分析中的其他应用。
在这张图中，我们继续使用了上一篇文章——《描述性统计与结果分析》一文中的方法，对响应时间的分布情况来进行分析。上面这张图所使用的数据是通过对
Google.com首页进行测试得来的，在测试中分别使用10/25/50/75/100几个不同级别的并发用户数量。通过这张图表，我们可以通过横向比较和纵向比较，更清晰的了解到被测应用在不同级别的负载下的响应能力。
这张图所使用的数据与第一张图一样，但是我们使用了另外一个视角来对数据进行展示。表中最左侧的2000/5000/10000/50000的单位是毫秒，分别表示了在整个测试过程中，响应时间在0-2000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在2001-5000毫秒范围内的事务数量占成功的事务总数的百分比，响应时间在5001-10000毫秒范围内的事务数量占成功的事务总数的百分比，以及响应时间在10001-50000毫秒范围内的事务数量占成功的事务总数的百分比。
这几个时间范围的确定是参考了业内比较通行的“2-5-10原则”——当然你也可以为自己的测试制定其他标准，只要得到企业内的承认就可以。所谓的“2-5-10原则”，简单说，就是当用户能够在2秒以内得到响应时，会感觉系统的响应很快；当用户在2-5秒之间得到响应时，会感觉系统的响应速度还可以；当用户在5-10秒以内得到响应时，会感觉系统的响应速度很慢，但是还可以接受；而当用户在超过10秒后仍然无法得到响应时，会感觉系统糟透了，或者认为系统已经失去响应，而选择离开这个Web站点，或者发起第二次请求。
那么从上面的图表中可以看到，当并发用户数量为10时，超过95％的用户都可以在5秒内得到响应；当并发用户数量达到25时，已经有80％的事务的响应时间处在危险的临界值，而且有相当数量的事务的响应时间超过了用户可以容忍的限度；随着并发用户数量的进一步增加，超过用户容忍限度的事务越来越多，当并发用户数到达75时，系统几乎已经无法为任何用户提供响应了。
这张图表也同样可以用于对不同负载下事务的成功、失败比例的比较分析。
Note：上面两个图表中的数据，主要通过Excel中提供的FREQUENCY，AVERAGE，MAX，MIN和PERCENTILE几个统计函数获得，具体的使用方法请参考Excel帮助手册。
最近群里来了很多新朋友，大都是新做测试或准备做测试工作的，见好多新手上来就问关于LoadRunner的使用上的问题。对性能测试的理解也不是太清楚。公司说让他们对系统做个性能测试，他们听说LoadRunner是做性能测试的，在网上找了点LoadRunner的使用说明就开始对系统下刀了。对于一些大公司的专业性能测试人员来说，这个很可笑，但是这种情况是存在的，我当初刚到公司时也这么干的。
那时还真把性能测报告给整出来了，现在看来那报告没有任何意义。虽然对现在的我来说性能测试也只是只懂皮毛。但还是希望通过我这篇文章能让那些新手们对于性能测试有个入门的了解。
----//理发店模式
关于理解性能，记得我那时是看了“《LoadRunner没有告诉你的》之三---理发店模式”不管你有没有看过，我这重提一下理发店模式。
前提：
1、一个理发店有三位理发师傅
2、每位理发师傅理一个发需要一小时
3、顾客都很忙，从进理发店起最多只等三小时（等待时间+理发时间），如果三小时后还没轮到自己理发，立马走人。
思考：
这里我们来理解“最佳用户数”和“最大用户数”。
最佳用户数：
理发店的最佳状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客满意度最高（顾客随时到随时理，无需要等待）。在一个时间点来说，三个理发师傅服务于三位顾客，那么这个最佳用户数是三。
最大用户数：
理发店的最大承受状态，理发店收入最多（理发师傅没有休息时间，一直在理发），顾客的最大忍耐度（来的顾客等待+理发需要等上三个小时）。
假如理发店生意非常好，早上一开门一下子来了一群顾客（很多），A、B、C三位顾客先理，D、E、F顾客需要等待一小时才能得到理发师傅的服务，G、H、I三位顾客等待了两小时才得到服务，后面排队的J、K、L.....等顾客，已经等了三小时还没得到服务，因为这已经得达到了他们等待的极限，所以后他们气愤和无奈离开。
当然，理发店还会不断的来新的顾客，不断有等了三小时而没有得到服务的顾客离开，但对于理发店而言，他们在一个时间点上，能服务的最大用户数是九（三位正在接受服务、三位已经等待一小时，三们已经等待两小时）。
对于最大用户数，需要注意的两点：
1、在理发店里很大，可以容纳很多位顾客（大于9），总有一部分在这里等待了三小时而没有得到服务离开，不要把等待了三小而没有得到服务的顾客纳入最大用户数里。
2、假如理发店很小，最多只能容纳六位顾客，当第七个顾客来时，虽然，我们知道他只需要等待两小时就可得到服务（这个时间是他可以接受的等待时间），但由于理发店容量有量，这第七个顾客只有改天再来了。
关于理发店原理，详细请浏览http://www.51testing.com/html/58/n-10558.html
不知道通过上面对理发店的分析，你对性能有了一些眉目。假如理发店相当于我们的系统的话，顾客就我们向服务器所发送的请求，最佳用户数和最大用户数是我们衡量一个系统的处理能力的一种方法。 ----//要帐的模式
注：上图是自己找来修改的，凑合着看吧！呵呵
这个是我在给一朋友说浏览器与服务器之间交流时用到的例子，感觉比容易理解，所以拿来分享一下。
假设：
1）A、B、C三个人。
2）C欠A钱（这里不考虑多少）
3）B是专门要账
思考：
浏览器与服务器的信息传递次数：
A对B说，C欠我钱，你帮我去要。B接到指令后就去找C要钱。
B对C说，给我20块钱。
C说，没有。
B对C说，给我10块钱。
C说，没有。
B对C说，给我5块钱。
.........
最后，B回来对A说，哎呀妈呀，C那丫的忒抠门了，一分钱没有。
对于A来讲，只是来说，它只是让B问C要钱，具体的B与C之间交互了几次，A是不知道的，它所知道的就是B返回给它的结果，C一分钱没有。
浏览器与服务器传递数据的大小：
还是上面的过程，A对B说，C欠我钱，你帮我去要。B接到指令后就去找C要钱。
B对C说，给我20万块钱。
C说，没问题，没支票，只有1元硬币。
..........
B终于把钱拿回来给A。A很纳闷，怎么去了那么久，B委屈的说，丫的，C给我整了一堆硬币，太重了，路上走的慢，都快累死我了。
对于A来讲，只是来说，它只是让B问C要钱，谁知道C给的是支票还是硬币。所以，B去要钱消耗的时间就很长。
所以，要想提高浏览器对服务器的访问速度，应该减少数据传递次数与数据传递的大小。
这样就很自然的引出了浏览器的cookie
A在C哪里存了5毛钱。
A对B说，我在C哪里存了5毛钱，你去拿来我看看。B跑去问C要了5毛钱回来给A看。
过了一会，A又对B说，我在C哪里存了5毛钱，你去拿来我看看。B跑去问C要了5毛钱回来给A看。
过了一会，A又对B说，我在C哪里存了5毛钱，你去拿来我看看。这次C烦了，对B说，你把钱放自己口袋里吧，等A要的时候，你来问我5毛的人民币有没有改版，没有改版的话，你就直接把口袋里的5毛钱给A看就行了。
在这里A就相当于我们用户，B相当于浏览器，C是服务器。而cookie就是B的口袋，当然了cookie的用处还很多。比如我们登陆一个系统，提示我们是否保存密码（有的还有期限比如，一个星期或一个月），如果我们保存了，下次再访问登陆时，浏览器就已经帮我们填写好了账户密码或直接帮我们登陆。那这个账户密码就放在我们浏览器的cookie中。
为什么要说上面的例子呢？因为我们大部分的一部分性能测试是基于B/S架构系统的，理解了浏览器与服务器之间的数据传递，有助于我们理解性能测试。 ----//在开始性能测试之前，我们需要知道什么？
当客户或老板把你叫来，对你说，去给我们系统做个性能测试，千万别傻傻的说“好！”然后，就走了，我以前这么干过（那时不懂，打肿了脸充胖子），回到座位后，不知从何下手了。
那么，我们需要知道什么呢？
1、性能测试的目的
首先要知道客户的要求。
我把性能测试按目的分以下几种
1）客户有明确要求
这是一个好的结果，这说明客户对性能测试有一定的了解，知道他们需要的系统要达到一个什么样的标准。如：系统要求同时满足100用户登陆，平均每个用户登陆时间不能超过5秒。这个需求很明确，当然也不排除一些不懂装懂的用户，提一些不现实的要求。
不管怎么说，用户提要求了，这个比较容易，你可以对现系统做一次性能测试，至于，是通过优化系统还是增加硬件设备才能达到要求。就不是我们考虑的问题了。
2）只是想知道目前系统性能（容量测试）
可以把我们的目的就是求得最大用户数和最佳用户数。但是，这仍然是比较含糊的一个需求，我们需要对系统做出分析，找出系统的压力点。
3）找出系统性能瓶颈
这个同样需要分析可能对系统造成瓶颈的逻辑业务，然后才能进行性能测试。
4）了系统在长时间的压力下性能状况（强度测试）
这个一般验证系统的稳定性，因为系统一旦上线，就有可能会长期处在大用户的访问状态，可能以前没发现的一些问题就会暴漏出来。比较典型的就是内存溢出。
2、性能测试的环境
确定了我们的测试目的，当然需要测试环境。这里的环境，我们需要考虑一下几点
1）硬件环境
我们需要了解被测服务器硬件配置，用于加压客户端的机子配置，CPU 内存 等
2）软件环境
我们需要了解被测系统的架构，前端、中间件、服务器（这里指运行系统软件服务器，如tomcat）、数据库，以及他们的部署位置。
用于加压的客户端采用什么性能测试工具进行加压。
3）网络环境
网络环境很重要。在上面的几个目的中，除了找出系统性能瓶颈可以在广域网进行，因为这个目的可以不用设置太多的虚拟用户，只要找出系统哪个地方影响了整个系统的性能就行。
其他目的的测试都需要在，局域网进行，不然你压力工具所发送的请求都会卡死在网络的传输过程中。
3、寻找系统的压力点
我们需要对系统的哪个页面或业务进行加压。这个不是自己想出来的，需要与开发人员的沟通。系统的首页？系统的登录？还是系统的交易过程？各个业务的用户比例是多少？
只有获得有效的性能需求，才容易寻找和定位压力点。
获得有效的需求：http://www.51testing.com/html/68/n-10568.html
如果上面的几点，你都很清晰了，那么打开你的性能测试工具开始录制（或编写）你的性能测试脚本吧！
注：以上个人观点，如有错误的之处，请高手指证，以免误导别人。
在做性能测试之后需要知道些什么
之前写过一篇《在做性能测试之前应该知道什么》有博文，自我感觉讲的不好，举了两个例子，和做性能测试之前需要知道的一些要点。离我的题目有差距。二则觉得讲的不全。其实，要做性能测试需要知道的东西太多了。岂是一篇博文都能说全的。在这里表示一下愧疚之情。
好多测试新手，在做完性能测试之后，不知如何对测试数据进行分析。在这里我想谈谈一些性能测试参数的相关知识。当然，也不是一篇博文就能说清道明的。只希望在你的测试道路上能给你一丝帮助。
不怕啰嗦的再次忠告，那想成为测试高手的新人，多学学基础知识。别把过多的时间放在研究新工具的使用上。工具何其多，原理差不多。不要本末倒置了。也算是自我提醒吧！
性能测试常见指标
性能测试说白了就是通过工具模拟多个用户对被测系统进行访问。然后查看系统对于多个用户发来请求的处理能力。
左边的两个小人表示两个用户，向右边服务器发送请求，然后得到服务器的响应信息。
首先，我们要保证向服务器发送的请求的正确性，当然用户向服务器发送错误的请求，服务器也会个客户端响应信息，但响应的是报错信息；所以，为了保证测试数据的有效性，我们的要保证发送请求的正确性。
为什么一般的性能测试要在局域进行？
一般我们的性能测试都是在局域网中进行的。为什么一定要在局域网中进行呢？因为局域网中不受网络限制。这个说法不能绝对。但是一般测试工具的用户并发量是不会受到局域网带宽的限制，除非你做的是十万，百万级别的用户并发。相信懂一点网络知识的人都知道，当你上网很慢的时候，比如打开某某网站很慢，你肯定会骂电信的网络不给力，而不会骂这个网站响应速度不给力。因为，请求信息的耗时大部耗在传输过程中。
所以，刚做测试时，我们群里热议论，如果我们每个人都开一个压力工具对百度网站进行加压。百度，服务器会不会挂掉。有测友说这样是不道德人。呵呵！其实，完全不必有这个担心。就一般人家用的带宽，我确保，你向百度服务器发送的请求大部分都死在半路上，就算不死到了百度服务器已经不能叫并发了。何况百度服务器的集群技术以及其他各种分压技术。所以，做性能测试不了解被测系统的架构，以及各种技术的性能。很难做出有效的测试报告。
下面我们看看性能测试的一些技术指标。
Work Load = Virtual Users
工作负荷 = 虚拟用户数
对服务器产生多大压力，可以由多少用户同时对服务器发送请求来衡量。也就是服务器的性能可以看它同时处理多少用户发送来的请求来衡量。
虚拟用户数可以用进程或线程的方式进行模拟。
response time 响应时间
从客户端将数据包发出，到接收到服务器端发来的请求。这个过程的总体时间叫response time
这个时间用来衡量的处理请求的速度（抛出网速限制的前提下）
throughput ~Ti & To
这个表示，吞吐量，吞吐量越大表示系统性能越强。1个用户跑100天和10个用户跑1分钟。当然是1个用户跑100天的吞吐量大。所以，我们要想看系统的性能应该用“吞吐率”，就是单位时间的吞吐量，比如吞吐量/秒。
站在服务器端，T-in表示“吞”；T-out表求“吐”
Ti：T-in 主要衡量客户端的能力，看客户端往服务器发送的请求数据包的吞吐率。
To： T-out 主要衡量的服务器端的能力，看服务器处理返回请求数据包的吞吐率。
Hits/Request
网页点击数/请求
Response/Successful Response
响应/成功的响应
Request与Response是对应，一个请求对应一个响应。但当客户端对服务器的压力达到一直程度后，不是每一请求都能得到响应的。去年末火了个最牛B的“电子商务”网站。12306（铁路网上订票系统），虽然有很差的用户体验，但每天还是大把的人拼命的登录（过年回家的人伤不起），甚至用外挂登录。见有网友云云点击（请求）了几十几百次才订票（响应）成功。所以，成功响应率也是很重要的一个指标。客户端发送一千个请求的成功得到响应的几率。
Hits Per Second
每秒中点击次数
和吞吐量一样，单单用点击数（hits）来衡量系统也是不合理的。所以，用每秒钟的点击数才能衡量出服务器的处理能力。
响应时间图分析
横坐标表示用户数
纵坐标表示时间
红色虚线，表求的是一种系统的理想状态。
当服务器处理10个用户请求时所用的时间是2秒（假设），当服务器处理200用户请求时所用的时间也是2秒。所以说这种状态是一种理想的状态。现实中，不管是如何超级强的服务器当用户数达到一定数量时，响应时间必会变慢。
蓝色斜线，是服务器常见的一种曲线状态。
服务器的响应时间虽然用户数量的增加逐渐变慢。
当系统出现这种斜线，应该说系统性能是相当健壮的。随着用户的增长响应时间逐渐变长。
黑色曲线，个人觉得是服务器处理能力的真实曲线状态。
为什么说黑线才是真实服务器处理能力的曲线呢？当用户处理一个用户请求是2秒（假设），当处两个用户请求是马上变成3秒（假设），当处理3个用户请求时变成4秒（假设）。再差的服务器也有个处理范围，比如是，100用户同时并发，服务器可以轻松应对，不管是10个用户还是80个用户同时请求，服务器都可以即可响应（请参考理发店模式）。只有当用户数量达到某个数量点后，服务器性能急剧下降。如上图黑色十字星处就是系统的拐角点。
我们假设有一个门，在一个时间点上可同时过10个人，不管你是同时来3个还是10个都可以在同一时间点过门，假如来了11个人，必然有一个人要等10个人过门之后才能过。那么当超过10人来过门时，过门的速度就开始变慢。那么10就是服务器性能的拐角点。我们通常做压力测试找服务器的拐角点是很重要的任务之一。
关蓝色曲线与黑色区线只是我们常见两种曲线。现实的测试中可能出现各种样式的曲线。当然还要看你做测试的细度，比如，10个用户是系统的拐点，如果你做完5个用户的一轮测试后，就是20用户的测试。那么画出来的曲线就变成斜线，拐点将被护忽略掉。
吞吐率图分析
横坐标虚拟用户数
纵坐标有吞吐率（服务器端）
红色虚线，表示一种理想的状态。
随着用户数量的增加吞吐率也在持续增加。
黑色曲线，表示现实系统的吞吐率状态。
刚开始吞吐率随着用户数量的增加逐渐变大，当大到一定程度时，逐渐平缓直到变成一条平线。
如果用户还在持续增加中，那么吞吐率有可能下降，直到系统挂掉。
为什么会是这样呢？我们通过另一个例子来说，大家都在城市生活，相信上下班高峰期都会遇到堵车。在比较重要的红绿灯路口常会见到堵车现象。假如每个绿灯可以通过10辆，前期来三五辆车，遇到绿灯，一次都过去了。到了下班高峰期，车子变多，一下来了20辆，但这个路口的绿灯每天只能通过10辆，所以，这个时候，路口的通过率不会根据车辆的增加而继续增加。
好的系统好像好有个好的交警在位置秩序，虽然车辆还在增加，但每个车辆都有条不紊等待通过路口。
不好的系统如路口赶上交警拉肚子，车辆在增加，后面车辆等得不耐烦就往前挤，结果稿得互不相让。好嘛！之后还每个绿灯可通过10辆，现在只能有一辆车从夹缝中脱离苦海了。
响应时间图与吞吐率图并不是我们一轮性能测试下来就能得到结果。需要经过多轮测试才能得到。设置不同的用户数量，得到每次的测试数据，将每次数据连接，从而得到最终系统性能曲线。关于用户数量每次增加的数量自己把握。如果，想精确，可以每次增加1个用户的方式来做，不过这样势必加大工作量，也没必要。这个需要每做完一轮测试后对数据进行分析，然后确定下轮测试所要设置的虚拟用户数。
关于，性能指标的分析，就先谈到这里。关于内容，我反复经过思考，但难免有理解有误之处。还望高手点拨。共同进步。
从这一篇开始，虫师向性能方面发力。翻看自己的博客，最早的时候热衷于jmeter，于是写了几篇图文并茂的文章（其实，主要是操作截图加文字描述），之后，由于看到好多朋友关于性能的知识什么都不知道，下载个loadrunner 就说要做性能测试，结果可想而知，遇到各种概念与使用问题。于是写了《在做性能测试之前需要知道什么》《在做性能测试之后需要知道些什么》，关于loadrunner的我没有写一篇博客，因为介绍loadrunner的网站、资料、书籍和视频太多了。我想这个系列我也会把关注点放在思想上。
性能测试常见分类
常会别人说到性能测试、负载测试、压力测试、并发测试，很多人都是混合使用，或者一会叫压力测试，一会叫并发测试。这些概念除了非测试人员分不清楚，甚至许多专业测试人员也对这些名词也很模糊。关于这个分类我翻阅了几个本比较好的书籍，他们讲的也比较模糊，没有给出本质上的区别。只是从不同角度和关注点来解释。好吧我们先来看他们之间比较普遍的解释。
性能测试（狭义）
性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。
特点：
1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。
2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。
3、这种方法要求在已经确定的环境下运行。
也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。
负载测试
通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。
特点：
1、这种性能测试方法的主要目的是找到系统处理能力的极限。
2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。
3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。
也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“我的要求”或系统崩溃。
压力测试（强度测试）
压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误
特点：
1、这种性能测试方法的主要目的是检查系统处于压力性能下时，应用的表现。
2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
3、这种性能测试方法一般用于测试系统的稳定性。
也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。
并发测试
并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。
特点：
1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。
2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。
也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。
配置测试
配置测试方法通过对被测系统的软\硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。
特点：
1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。
2、这种性能测试方法一般在对系统性能状况有初步了解后进行。
3、这种性能测试方法一般用于性能调优和规划能力。
也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。
可靠性测试
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
特点：
1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
2、这种性能测试方法需要在压力下持续一段时间的运行。（2~3天）
3、测试过程中需要关注系统的运行状况。
也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。
上面的分类绝非全面，还有失效性测试，就是系统局部发生问题时，其它模块是否可以正常的运行。这个在极少数情况下进行，这里就不介绍了。
性能测试分类之我见
上面的类分完了，似乎得到不少专家的认同，并无不妥。但我们在性能测试过程中真的能把它们区别分的很清楚么？你能严格区分出你这次的测试到底并发测试还是压力测试。
笔者第一点不太赞同的是对“性能测试”的定义。笔者认为性能测式测试包含了上面的所有分类。而这种性能测试的定义只是一种狭义上的“性能测试”，属于性能测试的一种。
性能测试是相对功能测试来说的。他们之间最本质的区别就是对系统有处理能力是否够成压力。如果一个用户的一个操作（比如超大数据量的查询）对系统够成了压力，我也可以视其为性能测试。
其实，可以这样来划分性能测试
上面定交了那么多分类，是不是有点晕了。其实，以笔者认为我们进行性能测试时关注的就两点。耐力和爆发力。
初高中时练过几年体育，最好时代表学校参加县体育比赛，不过是去垫底的。哈哈！哈一个体育运动员来说，那么多的体育项目，其实，考核他的就两方面。一是爆发力。二是耐力。
爆发力：拿一个举重选手来说，他的重点在重量上，因为你只要能举起三秒就算你成功了。关键是看你能举起一个什么样的重量。
耐力：拿一个马拉松运动员来说，你百米速度跑得再快没用。关键是这40公里路程中，最先跑到终点的人才是赢家。
整体协调性：当然，身为一个教练员，我在选拔选手的时候，除了看这个运动员的耐力和爆发力，身体的整体协调性也是我考核的一个很重要的指标。比如一个运行员身体各位部位练得非常强壮，但右臂先天性萎缩。他的跑步成绩虽然不错。但他在跑的过程中，身体有各个部分都在分担右臂的不足。右臂影响了整个体能的发挥。
再到系统的性能上说，爆发力就是这个系统能承受的最大压力，没准这个系统承受的压力很大。但过半个小时之间就挂掉了。耐力就是这个每系统长时间处于压力下的稳定性，这系统超级稳定，跑个几十年都不用重启服务器。那么整体协调性就是看系统有没系统瓶颈，需不需要进行系统调优。
在做性能测试时请忘掉分类
这里只是告诉在做性能测试时不要想这个测试是属于性能测试的哪一类呢？是并发性测呢？还是压力测试？
我们还拿上面的教练员选拔选手做例子。
记得我进校体队的时候，教练说让我跑两圈。然后，我就开始围绕着操场跑起来。你说教练让我跑两圈是想看我的什么能力？
1、双腿的考核，一个是步幅，就是步与步之间的距离。一个是频率，两腿交替的频率。如果你一步拉得很大的话，那么频率一定会下降。如果想提高频率的话，那么一定会影响到步幅的大小。
2、双臂的考核，肩膀是否放松，摆臂是否有力，双臂的摆动与双腿的摆动是否协调。
3、呼吸是否匀称，目前的速度可以跑几圈。
我只做了一项体育运行，就考核了我这么多内容。我们在做一个性能测试时也不局限在某一分类上，也可能我们的一个测试包含多个分类。
《web性能测试实战》：
这么多类型的性能测试看起来很吓人，实际上它他们大多是密切相关的。例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试，等等。因此，在实施性能测试时决不能割裂它们的内部联系去进行，而应该分析它们之间的关系，以一种高效率的方式来设计性能测试。
学习任何语言，我们都不能与生活脱离，只有通过生活中的实例，与生活相结合，我们的学习更富有风趣、调动了我们的积极性，作为一名程序员，我们知道任何一门语言之间都是相同的，我们只有不断的分析语言之间的关系，通过生活中的实例，密切的结合在一起，织成一张大的知识网，相信我们的学习不再累、不再痛苦。
学习不只是你学习了多少知识、记住了多少知识。个人认为最主要的是我们通过学习不断地发现适合自己的学习方法，我这个人遇到问题，学习时时常联系生活中的好多故事来帮助自己理解，挺好玩的……
数据库：就是存放数据的仓库，生活中我们的衣服整齐的放在衣柜里，各种各样的衣服就是数据，衣柜就是仓库
数据库对象：是指表、视图、存储过程、触发器等：
数据库系统：是追踪所有其他数据库和存储配置信息的关键数据库，非常重要，控制着数据库和sql server的操作，是两者之间的司令，起着枢纽的作用，如生活中大桥一样，方便、控制着两边岸之间人员的流动，疏导、制约着来往的人员、车辆是生活中重要的枢纽系统。
批处理：指包含一天或多条t-sql语句的语句组，这组数据一次性地发送到sql server服务器执行。在生活中比如我们战争年代，打击日本鬼子，咱们一个一个的是可以杀100人，很费劲的。但是咱们可以一次性利用高科技武器次性解决掉100人，一次解决掉，一批处理掉。原来自己对批处理，不太理解，后来的学习中，通过生活中的实例慢慢的理解了。
游标（cursor）是系统为用户开设的一个数据缓冲区，存放SQL语句的执行结果。每个游标区都有一个名字。用户可以用SQL语句逐一从游标中获取记录，并赋给主变量，交由主语言进一步处理。
游标实际上是一种能从包括多条数据记录的结果集中每次提取一条记录的机制
事务：指最为单个逻辑工作单元执行的一系列操作，
生活中：设想网上购物的一次交易，其付款过程至少包括以下几步数据库操作：
● 更新客户所购商品的库存信息
● 保存客户付款信息--可能包括与银行系统的交互
● 生成订单并且保存到数据库中
● 更新用户相关信息，例如购物数量等等
正常的情况下，这些操作将顺利进行，最终交易成功，与交易相关的所有数据库信息也成功地更新。但是，如果在这一系列过程中任何一个环节出了差错，例如在更新商品库存信息时发生异常、该顾客银行帐户存款不足等，都将导致交易失败。一旦交易失败，数据库中所有信息都必须保持交易前的状态不变，比如最后一步更新用户信息时失败而导致交易失败，那么必须保证这笔失败的交易不影响数据库的状态--库存信息没有被更新、用户也没有付款，订单也没有生成。否则，数据库的信息将会一片混乱而不可预测。
数据库事务正是用来保证这种情况下交易的平稳性和可预测性的技术。
规则（Rule） 就是数据库中对存储在表的列或用户自定义数据类型中的值的规定和限制。规则是单独存储的独立的数据库对象。规则与其作用的表或用户自定义数据类型是相互独立的，即表或用户自定义对象的删除、修改不会对与之相连的规则产生影响。
生活中的法律，在一定程度上约束的人们的行为，社会有序的运转。
约束：数据的完整性是指数据的正确性和一致性，可以通过定义表时定义完整性约束，也可以通过规则，索引，触发器等。约束分为两类：行级和表级，处理机制是一样的。行级约束放在列后，表级约束放在表后，多个列共用的约束放在表后。
完整性约束是一种规则，不占用任何数据库空间。完整性约束存在数据字典中，在执行SQL或PL/SQL期间使用。用户可以指明约束是启用的还是禁用的，当约束启用时，他增强了数据的完整性，否则，则反之，但约束始终存在于数据字典中。
我们学习充满着动力，知识联系生活、生活中蕴含着知识，我们应善于用自己发现美的眼睛来学习与生活相结合，使今后无压式的学习，相信我们会成长的更快。
2、生成测试数据的流程分析步骤主要为：
1）按照等价区分法，将表切分成不同的集合（也就是表设计是的子表），这里最重要的是确定数据集的切分是的最大业务概念分类。
如本例中的往来单位信息表，应该首先按照顾客/收货人/供应商/运输商切分成4等分数据集。
以顾客为例，下一个的重要信息就是顾客状态了，失效顾客一般来说就是判断其是否生效，提示出错即完成，因此其他数据对测试用例来说是没有任何意义的，只要准备一条数据即可。
然后根据项目最大候选输入数，以及相互项目的可能的排列组合，进行数据的细分设计。
2）作为第2步来说，只用一条数据进行测试是危险的，因此需要准备多条的测试数据。
3）作为第3步，适当的准备Null/“”/Full-Width等的边界值、特殊值测试数据即可。
作为总体的数据量，大概20多条顾客数据就可以保证整个系统测试的测试用例使用。
基于我们假设的测试数据的覆盖率层次，我们可以按照下述图形示例进行测试数据的准备：
步骤1：通过等价区间法来减少数据复杂度
主要是要按照数据的大、中、小层次进行分类，减少数据准备的复杂度。
步骤2：通过识别项目相互间的影响要素提供数据覆盖率
由于很能做到穷举测试，因此需要使用直交法等手法取得测试质量和投入成本间的平衡。
步骤3：准备测试数据覆盖率=C1层的测试数
步骤4：结合边界值法准备多件测试数据
由于各种类型的测试数据只准备一件在测试上是危险的，因此需要对各种类型的测试数据准备多条测试数据。
步骤5：对数据下工夫，提高测试数据到数据覆盖率C2层
对准备的多条数据，可以在数据上下工夫，把空值、Null、最大值、最小值、数据位数等等的边界值和特殊值条件嵌入在数条的测试数据中，在尽可能少的测试数据下提供尽可高覆盖率的测试数据组合。
步骤6：在各个测试中，有必要时按需添加部分数据
根据上面提出的测试数据准备步骤，让我们用一个具体的示例来演示测试数据准备的技巧。
基本思路是按照排列组合、边界值、特殊值的多少，考虑测试数据覆盖率进行测试数据准备。
1、按照最大可选择的项目候选值进行数据设计的示意图如下：
看了这篇文章《什么是测试自动化？》
首先说明一下什么是自动化测试， 它主要完成2个方面的工作：
● 把手动的测试用例自动化，手动的测试用例可以自动执行
● 把没有办法手动的测试用例自动化，比如让你测试光驱可以打开几次，做个压力测试，人工测试显然不可行（也有人把这部分称之为自动化测试，但是我觉得这样太绕了，就全部称之为测试自动化吧）
然后再说明一下为什么要自动化，ROI如何；
● 研发要解决的问题是，一个是效果问题，一个是效率问题， 自动化可以提高效率（大部分人这么认为，虽然其实这个有待商榷），所以自动化有利于提高效率
● 这是一种工程师的态度，或者是套用一下流行的词，叫做Facebook的文化，Hacker的文化；因为不喜欢重复的做一个事情，把它自动化，看上去是很Cool的事情
所以自动化最重要的事情就是提高效率（当然能否提高效率，这个事情是这样的，因为UI经常变动，或者是由于其他的外部因素，自动化需要修改，维护，那么投入的人力和物力是否大于产出或者小于产出，这个每个公司，每个产品都不一样，具体就不在这里讨论了）以及实现手动无法完成的事情；
接下来回应一下《什么是测试自动化？》
文章里面提到测试自动化是无法自动化所有的测试用例，这点是肯定的，完全同意；所以这里来说说自动化的弊端：
● 自动化其实更多的是一种防御策略，是为了防止Regression，自动化发现的bug数量一般都是不及手动测试发现的bug数量；而且有人提出了有些系统比较难发现Bug的测试用例你即使在不同的版本多跑几次相同的测试用例效果甚微，就像杀虫剂效应一样，由于虫子有抗药性，同样Bug也有；所以不能期望自动化测试发现更多的Bug
● 自动化测试需要更多的投入，维护，由于系统需要经常变动，期望值发生改变，所以自动化测试也需要变动
另外说明一下对API的测试不能算成自动化测试的范畴，因为你本来就是要测试这些API，只是恰好这些都可以写成Code，可以自动的运行而已；
所以理想的情况是， 自动化的产出大于投入在自动化的人力，物力；然后解放出来的人力，物力可以花在发现新的Bug，解决新的Bug上面；而且由于大家不用去做重复的事情，真个团队的Productivity也很高。
相信这样的解释，大家对自动化就有一个合理的期望，然后心安理得的选择自动化或者是手工的测试。