性能测试用户的设计策略—“普遍撒网，重点查看”原则
性能测试是一个复杂的过程，因为它的对象是一个由多个模块甚至多个中间件构成的庞大系统，而每个模块在理论上都有存在性能问题的可能。不可能测遍所有的模块的性能，再给客户出性能报告。性能测试和其他类型测试一样，遵循软件测试定律：对软件的完全测试是不可能的。在做性能测试时要做到，设计尽可能少的测试用例来发现尽可能多的性能问题，这样设计的用例才是好的用例
“普遍撒网”：就是一个好的性能测试用例的执行应该调用软件系统中尽可能多的模块。不同的测试用例最好覆盖不同部分的模块。这样做至少有两个好处，一是软件系统被全方位调动起来，容易发现各个环节的问题。二是一次执行，多处测试，节约测试成本
“重点查看”则要求在做性能测试时特别关注软件系统中那些基本的、使用频率高的模块
保证数据的有效性
在做性能测试时，写好了脚本，面对被测系统时，有些茫然，不知道做什么，该怎么样才能找到性能瓶颈。在执行性能测试时，看到一堆监控数据，执行日志，不知该如何分析哪里出了问题
在这种情况下，如果不能让自己的技术经验指导自己的行为，那么就确信自己至少还有清晰的逻辑来维护自己的判断
性能测试是一个复杂的过程，因为它的目标是一个由多个模块甚至多个中间件构成的庞大系统。目标就是要从一堆结果数据中分析出瓶颈，前提：不仅要得到正确的数据，还要正确地得到数据。
在实际系统中，性能测试的环境和条件有很多
1、数据库中记录数量是不是差不多，在一个数量级上
2、各个中间件的配置是不是一样
3、Server是不是有其他人也在占用资源（性能测试最好保证Server是Clean的）
4、Client 和 Server 的 Cache要被清除掉或关掉
5、最好做完一组数据后，各个 Server 都 Restart 一下，释放掉原先的资源（除非就想在这个基础上测试）
6、有时日志不断地变大也会影响Server的性能表现，可以从I/O指标上看到
Web Click Vuser 的产生背景
60%的用户使用LoadRunner 做 Web 系统的性能测试。统计，Web系统性能测试有70%的时间花在开发和调试脚本上。在LoadRunner 8.1以前，测试Web系统都是使用HTTP Vuser来捕获 Web系统客户端和Server之间的交互，而生成基于HTTP协议的脚本。但是HTTP脚本同其他Vuser脚本一样，基于网络协议，又长又难以理解
Web Click Vuser 与传统 Vuser 的差别
基于这样的情况，LoadRunner 从 8.1版本开始使用 Click and Script技术（实际上是QTP技术，QTP是MI的一个基于Web UI 的功能测试工具），创造了一种新型的Vuser，叫做Web Click Vuser 和 WinRunner 、QTP一样，是基于Web UI事件的。用户对Web系统的操作被记录成基于UI事件的函数，如：点击一个Button，填写一个Edit Box，而不是一个HTTP协议上的get请求、post请求。因此，Web Clic Vuser 能像浏览器一样，去执行Java Script 和 Applet
web_edit_field：在一个Eidt Box中填写数据
web_text_link：点击一个链接
web_button：点击一个Button
Web Click Vuser 还是会记录网络协议级别上的事件，用户可以随时从Web Click Vuser脚本转换到HTTP Vuser脚本
Web Click Vuser可以像我们操作浏览器一样执行脚本，Web Click Vuser用途、限制以及License
用途：目前，Web Click Vuser的运行环境是LoadRunner X.X + SP2。在HP网站中的patch list 中叫做 FP2。Web Click Vuser是基于界面对象的脚本，好处就是它度量的是一个完整的系统时间，从客户端界面发起请求一直到服务器的响应返回。使用过Web Click Vuser后，发现同样事务的响应时间比HTTP Vuser慢了0.2秒左右
限制：由于Web Click Vuser 是 LoadRunner 新推出的功能，还不是很稳定，也有不少需要完善的地方：
1、只支持IE录制（windows）
2、目前Web Click Vuser只支持英文
3、对Applet、ActiveX控件的支持不够
License：Web Click Vuser 被要求和HTTP Vuser同样的License，也就是说，如果有HTTP Vuser的License，那么就可以使用Web Click Vuser
（1）并发指的是多个客户端同时对服务器发起网络连接请求，并发送数据。从服务器看来，它必然要开启大量的线程，消耗内存、网络套接字、句柄等资源。这是并发测试的考察目标所在
（2）并发用户！=系统注册用户数，不是所有的系统注册用户都是活跃用户，而且不是所有的活跃用户都能构成并发关系。因此软件系统性能需求的并发用户数要远远小于系统注册用户数。占比可依据不同的业务模型而定
（3）并发用户数！=在线用户
“用户在线”看起来像是系统级别的概念，这是它能迷惑很多性能测试工程师的原因，误以为“用户在线” 是一个标准的性能指标，能够衡量不同的软件系统
如：QQ在线主要靠心跳报文来维持在线，即每隔一定时间间隔就在Socket连接上和Server交互数据。而网站在线目前很多实现方法都是靠Session 来维持用户在线的，如果Session 存在 Cookie 里，那在线就是非常简单的事情，几乎都不占用什么CPU资源。因为Cookie 只会占用硬盘空间或很少的内存空间。服务器是通过校验客户端发送上来的Session是否超时来判断它是一个“活着”的用户，还是新用户
1、通过LoadRunner来完成，是否能够使用这种方式取决于被测系统的架构。LoadRunner 的 License 是基于虚拟用户的，而虚拟用户可以以进程方式运行，那么知道在进程里可以开启多个线程
2、无论如何，让LoadRunner 实现 10000个用户并发不是一件很容易的事情，LoadRunner胜任负载测试，压力测试却不是它的长项。这种情况下，可以自己写程序实现压力测试
1、发出交易请求，由交易一方会员通过会员端机器向Web服务器发出交易请求
2、完成检查，在Web服务层，首先进行各项检查，包括交易请求的有效性、请求者的身份合法性等。对不合格的交易请求，则拒绝继续向交易主机报价，并向交易请求者发送处理结果
3、提交交易请求。通过检查后的交易请求由Web服务器向交易主机进行提交，同事记录日志
4、主机处理。交易主机接收Web服务器请求的交易，进行处理，如生成交易号、记入交易表、交易请求转发等。
5、交易请求接收确认，交易主机将处理结果反馈给请求的Web服务器
6、记录交易请求库。Web服务器接收到交易主机的反馈信息后，记录本地交易请求库，以备查询
7、交易请求接收确认，Web服务器将报价接收确认转发给会员机
8、传送交易请求，交易主机获得交易对方的Web服务器信息，将交易请求发送给对应的Web服务器
9、Web服务器继续将交易请求信息发送给对方会员
10、对方会员查看交易请求，系统将该状态向Web服务提交、系统记录会员是否查看了交易请求
整个流程来看，从交易终端发起的交易业务压力能贯穿整个流程、并施加到各个节点，以收到的反馈结果和反馈时间来考证系统的性能指标
同一流程，同样可以在客户端发起查询业务的压力，来考验WebLogic服务器的承受能力，相应业务逻辑的计算能力和数据库的加锁机制
流程相互对立，又相互依赖的。由于是对同一个数据库系统进行读操作和写操作，查询流程的结果依赖于交易流程数据的产生，交易流程产生的数据又通过查询流程得到验证，在进行压力测试时，两者的协同会对数据库形成压力的冲击
针对各个流程可能出现的薄弱环节，性能测试分为如下几个子测试来进行：
1、并发测试
在业务终端模拟多个用户进行并发登录，通过服务器的返回信息、响应时间和服务器的性能行为表现来考证系统的并发处理能力
2、负载测试
●交易流程测试：在交易终端上，通过模拟多个用户，产生大亮请求业务交易报文，直接施压在前置机上，本流程测试主要考证交易流程上各个节点在并发和持续性大批量业务请求情况下的处理能力
●查询流程测试：在查询终端上，通过模拟多个用户，产生大量请求查询的报文，直接施压在查询前置机上。查询成功与否以是否得到所请求的Web页面为标准。
●综合测试：在上面两种测试都通过的情况下，进行综合测试，即同时在交易终端和查询终端上发起大量请求，分别施压在交易前置机和查询前置机上。该测试流程主要考证数据库的并发处理操作和写操作的能力
LoadRunner可以调用QTP脚本，和Web Click Vuser有什么区别？
QTP脚本的确可以被LoadRunner调用，但如果据此认为LoadRunner可以使用QTP脚本做性能测试，那就错了，因为使用过QTP的知道，QTP脚本是基于界面事件的，也就是说，QTP脚本在运行时，它要独占一台计算机，因为键盘和鼠标资源是唯一的。因此，如果把QTP脚本引用到LoadRunner里来做负载测试，就必须一个Load Generator只能开启一个虚拟用户，一味着如果要做100个用户的并发，就需要100台安装Load Generator的计算机，因此得出，使用QTP脚本做负载测试理论上可行，但是实践上却行不通。这是和Web Click Vuser最大的区别之处
