在LoadRunner里，事务不是随便给一段脚本起个名字，而是用开始和结束函数把一段可分析的业务步骤圈出来。官方帮助把事务定义得很直接，事务要用开始函数和结束函数成对标记，后续分析才会把这段时间当成可统计的业务响应时间来看。

　　一、LoadRunner事务怎么定义

　　先把事务定义做对，后面的报表、SLA和瓶颈定位才有意义。定义事务时，核心不是多加几个名字，而是让每个事务都能准确对应一个用户可感知的业务动作。

　　1、事务用开始和结束函数成对包住

　　标准做法是在业务步骤前放开始事务，在业务步骤后放结束事务。官方文档说明，事务就是靠这两个函数标出分析范围，缺一边就不能形成可分析事务。

　　2、一个事务名只表示一个明确业务动作

　　事务名要和业务动作一一对应，例如登录、提交订单、查询结果，不要把多个无关动作塞进一个事务里。官方也要求事务名唯一，长度不超过256个字符，并且应使用可打印字符。

　　3、事务边界尽量贴近用户真正等待的区间

　　事务开始点放早了，会把无关准备动作一起算进去，结束点放晚了，又会把后处理时间一起带进去。更稳的做法是让事务只覆盖用户真正等待系统返回结果的那段业务流程。

　　4、嵌套事务可以用，但顺序必须正确

　　官方明确支持嵌套事务，但要求先结束内层事务，再结束外层事务，否则结果无法被正确分析；同时嵌套事务必须放在同一个Action里。

　　5、先用少量核心事务把主链路立起来

　　脚本初版不要一上来铺满事务，先把登录、查询、提交、退出这类主业务链路标清，再按分析需要细化。这样报表更干净，后续拆分也更容易。这个做法虽然属于实践建议，但和官方围绕事务做分析的使用方式是一致的。

　　二、LoadRunner事务拆分怎么更合理

　　事务拆分不是越细越好，也不是越大越省事。合理拆分的目标，是让你既能看出整体业务耗时，又能在出问题时快速定位到底慢在哪一段。

　　1、先按完整业务步骤拆，再按瓶颈点细化

　　第一层先按用户真正感知的步骤拆，例如登录、搜索、支付；只有当某一步明显偏慢时，再把它继续拆成查询、渲染、提交等子事务。这样最容易兼顾可读性和定位效率。

　　2、不要把事务拆得比业务还碎

　　如果一个页面里每个小请求都单独做事务，报表会非常碎，反而看不出主业务表现。事务应该优先反映业务动作，而不是机械地对应每一个技术请求。

　　3、外层事务看整体，内层事务看瓶颈

　　嵌套事务最适合做这一层分工。外层事务看整段业务耗时，内层事务看关键步骤耗时，但要控制数量，避免一个场景里套太多层导致分析口径变乱。

　　4、相同业务在不同脚本里尽量同名

　　如果多个脚本里都有同一业务步骤，事务名尽量统一。官方测试设置里提供了Group transactions功能，可以把同名事务按组汇总展示，这对横向比对很有帮助。

　　5、拆分时先想清楚思考时间口径

　　事务响应时间里是否包含思考时间，会直接影响趋势和对比结果。官方在运行设置和报表里都提供了是否排除思考时间的选项，所以拆分事务前最好先把这一口径定死。

　　三、LoadRunner事务怎么分层更清楚

　　事务定义和拆分做好以后，还要再做一层整理，否则脚本里虽然有事务，分析时仍然会乱。更清楚的分层方法，是把事务按总览层、定位层和报表层分别管理。

　　1、总览层只保留核心业务事务

　　这一层只看用户最关心的业务动作，数量要少，名字要稳定，主要用于看趋势、做SLA和汇报。

　　2、定位层保留少量关键子事务

　　当核心事务偏慢时，靠这一层继续往下查。它不追求全覆盖，只保留最可能出性能问题的环节，例如鉴权、搜索、提交。

　　3、报表层保持统一命名规则

　　事务名一旦混乱，后面分组、对比和趋势分析都会受影响。统一业务前缀、动作名称和环境无关命名，会让后续报表更清楚。官方对事务名唯一和可打印字符的要求，也说明命名规范本身就是分析基础。

　　4、回放时先看Replay Summary验证拆分是否合理

　　VuGen的Replay Summary会列出动作和事务的持续时间、状态和趋势。事务拆完后，先在这里看一遍，能很快发现有没有某个事务过大、过碎或边界放错。

　　5、每次改脚本后只增量调整事务

　　不要每次录制重来就把事务全推翻。更稳的方式是保留主事务，只对新增页面或问题步骤做增量调整，这样历史报表和新结果才有连续性。这个做法和官方围绕同名事务分组与持续分析的思路是一致的。

　　总结

　　LoadRunner事务定义的核心，是用开始和结束函数把一个可分析的业务动作准确圈出来，并保证命名清楚、边界准确、成对闭合。事务拆分时，先按完整业务步骤拆，再用少量子事务做瓶颈定位，不要一上来拆得过细。把事务再分成总览层、定位层和报表层后，脚本会更容易维护，分析结果也会更清楚。