jmeter作为接口测试的常用工具之一，在我们的测试中经常会用到，往期的文章中，我们也分享过jmeter的各种功能和用法，基本覆盖了方方面面，可以满足各种接口测试的需求。但实际测试中我们也会发现，jmeter这么强大的一个工具，具备这么多的功能，然而某些情况下反倒会让我们觉得用起来不是那么的顺手，甚至导致测试效率降低和工作量增加。本期文章，小编将着眼于jmeter的一些使用心得，重点分享如何更简单地利用jmeter进行测试以及如何避免一些问题的发生。
一、jmeter在测试中的定位 对于测试工具或测试框架，我们可能会觉得，如果一个工具就能满足所有的测试需求就好了，测试数据生成、自动测试、结果分析、报告产出、日志回溯等等，全部由一个工具来实现。于是，当了解到jmeter有这么强大的功能之后，我们很自然就去研究如何用jmeter来实现上述种种功能。然后经过长时间调研发现，jmeter确实可以做到，因为jmeter有各种控制器、取样器、断言、监听器，甚至还有BeanShell这样可以在中间某个环节自己写代码来处理一些逻辑的方法。 第一感觉，好像确实这些工作都用jmeter来实现就好了，但实际上，这里的坑却有不少。举个最简单的例子，当我们用jmeter来处理请求数据、返回数据时，每个请求相当于会在jmeter这里增加额外的耗时和资源占用，如果处理的逻辑比较复杂，比如写个超级复杂的BeanShell，这些额外的开销可能会很大程度上影响我们测试的结果。小编曾经遇到过，为了实现一个对返回结果进行判断和分类的功能，导致测试得到的接口QPS比之前下降了很多，虽然最后实现了将返回结果进行自动化分析、归类等操作，但最重要的性能指标却出现了偏差，还得返工再测，得不偿失。 所以，在这里，我们需要明确下jmeter在测试中的定位，小编认为，jmeter最重要的功能是实现自动化并发测试 日志收集，而并非是用来做数据处理和统计的。在jmeter接口测试的脚本中，如果存在很多的与请求无关的逻辑处理，在这里强烈建议大家对脚本进行精简，避免出现问题。
二、jmeter线程组的使用 利用jmeter的线程组，我们可以很方便地对接口进行并发测试，无论是性能测试还是稳定性测试，我们都可以用线程组来实现。jmeter一个测试计划中可以添加多个线程组，每个线程组都可以独立起若干个线程进行测试。于是有时我们会在测某个服务时，把该服务的所有接口分成不同线程组放到测试计划下，期望实现“一个脚本测所有”。但往往这样做又会产生一些意想不到的问题。小编在实际测试中就遇到过类似定时器跨线程组使用的时间问题，多个线程组共享变量导致的问题、多个线程组的启停问题等等，给测试带了比较大的困扰，虽然每次可以找到解决方法，但这样频繁踩坑也着实不爽。 为了避免麻烦，后来我逐渐换了一种设计脚本的方式，那就是尽量在一个脚本中只使用一个线程组，不同的接口，如果互不关联，就分成不同的脚本来进行测试。这样看似增加了脚本的数量，但实际上却大大优化了设计、修改脚本以及执行测试的效率和自由度。测试时，每个接口的测试都是单独的进程，彼此之间不会产生影响，且可以做到每个接口的测试随起随停，在NO-GUI模式下操作起来非常方便。
一个极简的jmeter脚本，只需一个线程组、一个请求
三、使用NO-GUI模式进行测试 jmeter支持使用GUI和NO-GUI两种模式进行测试，这两种模式的各有特点。在GUI模式下，我们可以通过图形化界面直观地进行测试脚本的设计以及通过监听器实时观察测试结果，使用起来十分方便；而NO-GUI模式与GUI模式执行测试脚本的方式是相同的，但由于不显示图形界面，也不实时打印测试结果，使得测试中jmeter本身对资源占用的影响降到最低，在并发测试中可以很大程度得减少对性能结果的干扰。在公司环境中，性能好的机器一般都使用centos等linux操作系统，几乎不会用到图形界面，加之为了获得更准确的测试结果，在进行大并发测试时，我们一般会采用NO-GUI模式进行测试。 所以，在脚本设计阶段，我们依然可以在PC上使用GUI模式进行设计，发挥图形化设计的优势。当脚本设计完成后，我们只需将脚本放到linux机器上，然后用NO-GUI模式执行，以最大程度保证获得更准确的测试结果。测试完成后，如果需要在GUI模式下查看测试结果或图表信息，将NO-GUI模式下产生的日志文件在GUI模式下导入即可。
小结
本文主要分享了在使用jmeter进行测试时的一些心得体会。以上内容均来自小编自身在测试中所遇到的问题以及总结的经验，后续还会继续为大家带来这方面的分享，如果大家有不同的看法或更好的建议，欢迎一起讨论~~
