loadrunner的几个测试步骤

摘自网上，个人觉得有道理。分享之.
1.使用loadrunner的VU生成脚本。
     脚本的生成方式就两种，一种是自写或嵌入源代码，一种是录制生成。常常听见有人说，这两种方式中首选录制生成脚本，因为它简单且智能化。但我个人总觉得手写脚本要好一些，因为：
     1．可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。
     2．手写的程序相比录制的脚本更能真实地模拟应用运行。因为录制的脚本是截获了网络包，生成了协议级的代码，而略掉了client端的处理逻辑。举个例子，用VU录制一个运行script和applet的IE行为，它只会生成http协议的API，在IE中运行的applet和script不会被模拟到，这就不是一个完整的系统。
     3．手写程序相比录制脚本更能增加测试人员的技术含量。开发和测试能力双重提高，何乐而不为呢？loadrunner提供了java user，vb user，c user等语言类型的脚本，就是给我们开发脚本用的，而不是录制用的。
     脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟程序真实有效为准，结合项目进度，开发难易程度等因素考虑。
     在这里我想要说的是，开发一个好的脚本是成功性能测试的必要条件。一个好的脚本应该能够最大程度再现client程序行为。如上面那个例子，脚本只模拟了client端的部分行为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。  
2.从VU运行成功到controller运行成功，一般需要以下几个步骤:
     1. 确认在VU里SUSI（单用户单循环次数single user & single iteration）
     2. 确认在VU里SUMI（单用户多循环次数single user & multi iteration）
     3. 确认在controller中MUSI（多用户单循环次数multi user & single iteration）
     4. 确认在controller中MUMI（多用户多循环次数 multi user & multi iteration）

     做这样一个步骤划分是有道理的，第一步骤是验证脚本编写的正确，第二步骤可以验证数据池是否正常运作。第三步骤验证并发功能，第四步骤是最终目的，验证软件系统的性能。在论坛上看到一些朋友提的问题，有一些就是于此的，在controller中运行场景时出现问题，首先得保证VU中运行成功，这是一个显然的逻辑。软件工程中把软件开发的种种行为都要制定一个proccess，即过程，性能测试也是如此，按照过程来调试脚本和场景，能及早发现问题和定位问题。除非是高手，烂熟于心中，才能超越proccess而不出问题。
     场景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。这其实是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。
遗留问题：手写脚本？我也想，可是一直没找到入门的路。。。