JMeter性能测试脚本的可靠性直接决定了测试结果的可信度。断言负责证实业务结果的正确性，事务控制器则保证性能标准的真实性。 

断言：

很多测试脚本中的断言只检查HTTP状态码是不是为200，或者响应中是不是包含success字样，这很容易产生断言幻觉-看似全绿通过，实则遗漏了大量业务思路错误。一个可靠的断言：

基础契约：检查响应状态和格式。这是最基础的检查。可以使用 响应断言 检查HTTP状态码（如200）和响应头（如Content-Type）。此外，不断时间断言 可以检查接口响应时间是不是在约定范围内，作为性能边界控制。对于返回XML的SOAP服务，应使用 XPath断言 进行分析和检查。

契约：准确检查业务数据。这是最重点的一步，直接检查业务思路是不是正确。

JSON断言：对于RESTful API，应使用JSON断言通过 JSONPath 准确定位并检查重点字段的值、存在性或类型，如$.data.orderId是不是存在。

避免使用正则一致整个JSON：使用正则去一致整个JSON响应体非常脆弱，一旦JSON结构（如字段顺序）稍有变化，断言就会失败。

兜底契约：处理复杂思路。当内置断言无法满足需求时，可以使用JSR223断言配合Groovy脚本编写自定义检查思路。

事务控制器：

性能测试的重要是模拟真实的用户行为，而用户完成一个业务操作（如下单）一般包含多个请求。事务控制器正是将这些请求打包成一个思路单元，统计其整体响应时间和成功率。

添加事务控制器很简单：在线程组上右键 -> 添加 -> 思路控制器 -> 事务控制器。配置时有几个点：

命名要有含义：为事务控制器取一个直观的名称，如用户登录事务、创建订单事务，这会让后续的报告一目了然。

Generate parent sample（生成父样本）选项：这是事务控制器的重要开关。

勾选：在监听器中只会看到事务整体的结果，内部各请求的明细被隐藏。这使报告非常简洁，适合在最后的性能测试报告中聚焦于业务事务的总体表现。

不勾选（默认）：在监听器中同时看到事务整体和内部每个请求的明细。这便于调试和问题定位，当整体事务响应时间超标时，可以快速分析是哪个子请求拖慢了速度。

Include duration of timer... 选项：此选项决定是不是将定时器、预处理和后处理等时间计入事务耗时。一般建议不勾选，以免引入额外干扰，影响对服务器本身处理时间的判断。

断言和事务控制器的协同

将断言和事务控制器结合使用，可以发挥出1+1>2的效果。

断言的归属：断言应该添加在事务控制器内部的各个取样器（HTTP请求） 之下。这样，任何一个子请求的业务思路失败（断言失败），整个事务都会被标记为失败。

双重证实：通过这种结构，你可以实现双重证实：

微观方面：每个子请求的断言保证组成业务的每一个步骤都是正确的。

宏观方面：事务控制器保证整个业务流程作为一个整体的性能标准（如总响应时间、成功率）是符合预期的。

误区和实践

断言不是越多越好：断言本身会消耗JMeter的资源。在正式的、高并发的性能测试中，建议只保留最重要的业务断言（如JSON断言），甚至可以暂时关闭复杂的断言，只保留对HTTP状态码的检查，以更真实地反映服务器压力。

重视整体，不忘细节：在调试阶段，不要勾选Generate parent sample，以便看到每个子请求的详细信息。在生成最后报告时，再勾选此选项以获得简洁的业务视角。

脚本思路要清晰：用简单控制器对请求进行分层管理，将断言添加到合适的层级，避免断言作用域混乱。

提升JMeter脚本的可靠性是用断言守住了业务正确的基础，用事务控制器抓住了性能标准的真实性。准确的断言能及时发现业务思路的偏差，而合理配置的事务控制器则能保证测量的性能是用户真实感受到的端到端体验。