初次接触性能测试，从测试方案到测试执行，再到结果分析，确实不是一件易事，时间耗费之长，在我记忆中实属少见，粗略记录一下我的体验心得，希望对自己以后的测试有所启发。
1.明确被测产品功能结构；
这一点还是蛮重要的，本文中也多次提到。
2.明确本次性能测试的需求；
与开发组、测试组讨论本次测试的目标，毕竟有了目标才能根据目标制定相应的测试方案。首先需要确定的是，本次性能测试是需要获取性能指标？单纯的压力测试（服务器可承受多大压力）？还是一定压力下的稳定性测试？
对于获取性能指标的测试，首先需要明确，性能指标是什么。这一点我走弯路了，一直以为性能指标就是获取多个并发数量下单个事物的响应时间，实则不然，要看用户关注的是什么，以及该产品的特点。一方面，如若用户并不关注响应时间，关心的是一定时间内的数据量（可称为吞吐量），那么我最初确定获取响应时间的路线就是错误的；另一方面，如若产品本身的特性并不能通过单个事物的响应时间很好的体现出来，那么获取了这些响应时间就是无意义的，根本不能体现产品的特点。这些东西都需要在制定测试策略前掌握清楚。
我接手的这次性能测试主要是获取性能指标，但是当我将获取的指标与大家一起讨论时，却没有被大家认同，获取单个事物响应时间的指标，不是用户需要的。
重做的代价是很大的，测试策略变了，测试脚本要修改，测试数据也要重新配置，包括测试环境。总之，这是很令人恼火，但又不得不做的事情。
3.测试数据、测试环境的确认。
根据已知的测试需求，要求预先整理好测试数据，测试数据的选取也是需要斟酌的事情，并非什么数据都好，也并非只要数据多样化就没问题，并且，数据量的大小，是否可以重复使用，也是需要预先明确的，其实这就要求做性能测试的朋友，一定要先了解产品，很了解产品才可以。
测试环境的确认问题，客户端（loadrunner及客户端程序）、服务器端（只运行服务器），怎样的配置（一般来说使用现有的最好配置就ok了）、客户端及服务器端网卡，网络带宽如何都要明确在心，并明确在测试方案中。
有些客户端程序，要求测试服务器与客户端在一台服务器上的情况，一来为了验证客户端性能对服务器的影响，二来可以验证网络传输对性能测试结果的影响。
4.录制、编写测试脚本
如果需求有了，数据、环境也搭建好了，方案定下来了，编写测试脚本就比较容易了。
这里说一下，我使用的是java vuser编写测试脚本，首先需要掌握loadrunner的运行原理，否则很难在它的action中编写自己的测试脚本，也就是说很难通过代码控制loadrunner。
因此有时间的话，loadrunner的手册要读一下，不要只根据tutorial学会怎么用loadrunner就开始测，当然前提是时间允许的话。
另外一点，loadrunner给我们提供了不少内部方法可以直接调用（lr.*），适时的看一下VuGen里的Function Reference，可以增强测试脚本。
5.结果获取后的分析
获取性能指标，多大压力下就可以停止测试，不再加压？是否存在性能瓶颈，瓶颈在哪？有时候蛮迷茫的。
一种情况，如若在压力不断增大的情况下，吞吐量响应增大到一个峰值，接着回落，这种情况估计谁都可以一眼判断出最优并发在哪，如果这时cpu占用率仍在70%以下，我们可以考虑被测服务器对cpu时间利用率没有控制好，cpu没有被充分的利用，那么应该还有存在调优的可能。
如果当cpu时间已占用80%以上了（一般情况下认为75%以上就算cpu满负荷），如若再给服务器增加压力，并且该情况下，吞吐量还是一直处于增长状态，直至cpu100%，那么这种状态下，我们是否可以认为cpu就是性能瓶颈呢？或者应该认为被测程序应当削减效率，减少cpu使用率？
我这里引用的关键词“吞吐量”是与TPS（每秒完成事物个数）密切相关的，如果只看吞吐量并不能确认最优并发的情况，可以看一下响应时间，即使用户对响应时间没有概念，或者说没有要求，引用某个朋友的话叫做：我们应也当给予一些专业性的建议。
6.关于脚本录制协议的选择。
因为此次测试没有录制脚本，所以一直对此比较不解，如果录制脚本时协议选择不合适，会是什么结果？协议的选择，是否具有不唯一性？比如上层为soap协议，底层为socket协议，该选择哪个？
