1. 录制脚本
a) 选择协议
i. 录制协议时只考虑客户端与它所连接的服务器间的协议，如B/S结构，一般选择HTTP协议，如果用户界面使用XML定义和描述，可以选择webservice协议（infogis项目），但协议只支持最多100个用户
ii. HTTP协议：录制考虑
1、 Recording Level：如果程序中包含了Javascrīpt并且该脚本向服务器产生了请求，选择URL-based scrīpt，否则选择HTML-based scrīpt。在advance选项中选择默认方式。
2、 Browser：除对浏览器有特殊要求后，都默认或选择IE进行录制。
3、 Advanced:需要录制思考时间，并支持字符集：UTF-8
b) 初始化、活动、结束
LR场景在执行时，只执行一次init和end中的脚本，但可以对action中的脚本进行多次迭代，所以要进行区分。如进行“需求录入”测试时，登录退出只执行一次，那么“登录”和“退出”脚本可以分别放在init和end中，而“需求录入”脚本放置在action中。
c) 添加事务
事务可以在录制脚本完成时添加，但最好在录制时添加重要的事务，以防止多个事务在脚本生成后无法区分开来。
2. 验证脚本
a) 录制完回放
i. 录制完脚本后，应该立即回放一次，主要是目的是验证脚本中是否存在关联，象动态的端口或session值，服务器端每次返回的不一样，如果下次客户端提交上次服务器端返回的结果，就会报错。此时，可以让LR自动检查关联，或者手工设定。手工设定关联时，可以以树形脚本的形式，查看服务器端返回的内容，以确定哪些是需要关联的值，也可以明确一下关联值的左右边界。
ii. 有一些内容是录制完成后，无法重新回放的，象增加订单，如果订单号重复，是无法插入到数据库中的，此时，需要对脚本稍微地修改一下，再进行回放。
b) 查看回放结果
i. 回放完成后，可以查看回放的结果，只有回放结果中显示脚本回放正确，才可以进行下一步的工作。
c) 验证数据库和客户端
i. 如果脚本执行完成后，在数据库中会增加记录，或者在客户端可以查看到，需要进行验证。如增加需求书，在数据库中可以查到新增的记录；而登录，有时有会有登录日志可以查看到。
ii. 如果一个脚本中，分多个事务，并且多事务可以分别验证的话，需要设置断点，对多个事务分别验证其正确性。
3. 增强脚本
a) 增加交易
i. 脚本录制并验证成功后，需要对脚本中的交易进行明确，如“需求录入”，前面有“打开需求书”页面的过程，此时要添加交易，把脚本按交易划分开来。
b) 参数化
i. 如果脚本中有需要变化的值，需要进行参数化。参数化的内容需要和开发讨论，主要的原则如下：
1. 真实：尽量模拟实际环境，其参数执行的方法也要尽量真实。如删除时，需要数据库中存在足够的数据，并且每次只删除一条，那么参数中应该选择唯一值的方法。
2. 数据量：数据量要保持足够，最保守应该同数据库中的数据量在同一个数量级上。少于一定量数据的话，最好将数据库中的所有数据都拿来做参数。
3. 数据来源：应该从数据库中导出。如果数据库中无数据，可以自己编造一些参数。
c) 检查点
d) 集合点
i. 使并发用户在集合点前等待，然后统一释放，以给服务器最大的压力。一般我们的测试尽量模拟真实环境。这种情况，象一些公用网站会发生。如奥运订票系统，一打开，马上就会有非常大的压力发生，这时需要增加集合点，模拟大而集中的压力。
e) 备注
i. 好的脚本象好的程序一样，需要明确详细的备注，以备维护和重用。
f) 日志
i. 输出日志到文件是查看结果好的方式，在运行后可以用来查看交易的详细信息
4. 准备负载
a) 要重新验证修改后的脚本。尤其是参数化后，参数选择的方式是否同设置的方式一致，结果是否正确
b) 可以检查检查点、和日志输出是否正确。
5. 完成脚本
里面还有很多东西未写:(
