下面提到的事务，在不同的行业和业务场景中粒度都有所不同，通常情况下，我们可以根据场景的目的来定义事务。
线上事务量(月/年)统计
目的：分析每月流量趋势找出流量最高的日期（流量巅峰日）
方法：
从生成环境，或行为分析系统，获取流量日志，查看分析访问量规律，一般选取数据量最大一天来进行后续分析。
线上事务量（日）统计
目的：分析出流量最高的时间段（峰值保障）
方法：
1、若事务量趋势在每天中都是相似的，则可以选择数据量较大一天进行分析；
计算压力时可以与业务部门共同商议在原有压力上增加部分压力，防止交易突高带来不必要的性能问题
2、若交易量趋势相差较大需要分析识别不同的事务量类型分别进行分析；
线上事务(日)占比统计
目的：梳理出需要关注的事务
方法：
１. 依据选择出的日事务量，筛选出不同类型事务的数据，并计算各交易的比例。
事务比例(线上)=各事务量/总事务量*100%
２. 选择占比超过1%的所有事务，同时排除一些因为环境或其他原因而不可测试的事务
确定测试事务(日)占比
目的：确定测试时使用的交易占比
方法：
1、选择某日交易中事务量最高的时段，计算每个事务量的TPS值。
这里需要选择交易量最高的时段，在细分过程中也需要对每个时间进行单独的数据统计。
若各时段事务比例相似，则可以进行第二步的测试场景模型的转化；
若交易比例差别很大，也需要进行独立的统计分析。
2.按交易占比，计算出各个交易的测试比例。
事务比例(测试)=各事务量/所选事务量之和*100%
确定混合场景模型
目的：确认每个事务的TPS模型，并组合为混合场景
方法：
1、确认单交易测试结果(TPS以及响应时间)
在编写完各个事务脚本后，以少量用户，运行脚本一段时间用来确认各交易的tps和平均响应时间
（此时一般不设置思考时间与pacing，由于这里是针对服务器的TPS做分析，所以这里不考虑模拟最终用户的行为。若想模拟最终用户的行为就要设置思考时间，并且还需要分析用户的操作习惯）
2、确定TPS模型
从单交易测试结果中可以获得每个事务的响应时间，在实际场景中我们可以通过设置pacing时间来控制TPS达到一个具体的值
理想情况下pacing 与TPS之前关系为： TPS = 1/pacing 值
3、各个事务的TPS模型确认后即为混合场景模型
备注：通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS
理论基础：
pacing时间：
为了更好的讲清楚pacing，需要引入iteration的概念。Iteration，迭代。通过设置，可以指定虚拟用户在同一个Action中重复执行多次，每次重复称之为一个iteration。Iteration可以帮助我们模拟现实世界的重复场景。
Pacing，步调。可以通过设置两次迭代之间的间隔时间，来调整各个action之间的步调（或者称之为节奏）。从定义上来看，Pacing是和iteration绑定在一起的，可以认为是iteration pacing。
思考时间(Think time):
可以通过设置思考时间，来模拟真实用户在操作过程中的等待时间。从定义上来看，think time是在iteration内部的某个action中各个步骤的间隔时间。
业务时间：
是从脚本开始到脚本结束的时间
Action时间：
粗略的说是整个脚本的执行时间(涵盖业务时间)
响应时间：
业务时间 +传输时间+服务器损耗时间等多种 通常情况下我们认为 响应时间=业务时间