Loadrunner在脚本录制过程中，我们会先后分别碰见init、action、transaction、end、block等概念。本次打算以图文并茂的形式为大家分别讲解。
以下为一个简要的网站操作逻辑流程:
init
用于录制测试用例的初始化操作脚本。负载场景中只会执行一次，并且只在开始阶段执行。
通常将加载操作放置于此。
当且仅当测试用例没有将登陆操作作为测试点时，将登陆操作放置于此。
action
用于录制测试用例的测试点操作脚本。负载场景中会持续重复执行，当负载退出时停止执行。
通常将验证、检索、展示、提交等操作放置于此。
当且仅当测试用例涵盖登出操作作为验证点时，将登出操作放置于此。（不过我没遇见过这种事，我这样说的目的在于别僵化于我片面的描述，要按照实际情况录制脚本）
transaction
用于记录脚本回放与负载场景中脚本执行消耗时间，此时间通常被称作响应时间（英 response time）。
当然同时记录事务处理总数也会被记录，最后通过计算得出每秒处理事务数（英Transaction Per Second，缩写TPS）。
响应时间与每秒处理事务数，是性能瓶颈分析过程中极为重要的两大指标。
事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。通常由高级数据库操纵语言或编程语言（如SQL，C++或Java）书写的用户程序的执行所引起，并用形如begin transaction和end transaction语句（或函数调用）来界定。事务由事务开始(begin transaction)和事务结束(end transaction)之间执行的全体操作组成。（在此我不想把大家的思维局限于loadrunner中transation的概念。在做unit级别的性能分析时，事务的概念是极为重要滴！）
通常在设置事务，以一次单独操作或者一次request作为begin，以一次此次操作响应结束作为end。
transaction延伸
事务特性：ACID是原子性（atomicity）、一致性（consistency）、隔离性（isolation）和持久性（durability）的缩写。
- 原子性：即不可分割性，事务要么全部被执行，要么就全部不被执行。如果事务的所有子事务全部提交成功，则所有的数据库操作被提交，数据库状态发生转换；如果有子事务失败，则其他子事务的数据库操作被回滚，即数据库回到事务执行前的状态，不会发生状态转换。
- 一致性或可串性：事务的执行使得数据库从一种正确状态转换成另一种正确状态。
- 隔离性：在事务正确提交之前，不允许把该事务对数据的任何改变提供给任何其他事务，即在事务正确提交之前，它可能的结果不应显示给任何其他事务。
- 持久性：事务正确提交后，其结果将永久保存在数据库中，即使在事务提交后有了其他故障，事务的处理结果也会得到保存。
关于事务，其实可以延伸很多内容出来，给大家几个关键字自己去查吧。事务隔离级别、事务的状态、事务回滚
end
用于录制测试用例的退出操作脚本。负载场景中只会执行一次，并且只在退出阶段执行。
通常将登出操作放置于此。
block
用于将action分块管理，以实现较为复杂的测试场景。
分别有sequential 与 random可选特性。