企业官网建设流程全解析

搞接口压测的人应该都有这种经历：一个业务流程下来，浏览器F12里看着是十几个请求，到了JMeter里就得一个个手动创建HTTP请求，URL要粘、Header要复制、Body还要挑格式，弄完经常还少个参数，跑起来才发现。最早接触Fiddler导出JMeter脚本这个插件的时候，我的第一反应是终于不用当人肉搬运工了。但真正用起来才发现，它解决的问题和你期望解决的问题之间，隔着一层需要对原理有清楚认知的距离。这篇文章就围绕这个插件的基本用法、运行原理、以及实际压测时最常踩的坑展开，给准备用它提升效率的朋友一个完整的参考。

1. 为什么需要把Fiddler请求转成JMeter脚本

1.1 手工建接口脚本的日常

我见过不少同事做接口压测，脚本全是手写的。一个登录接口还好，十几行就搞定；但一旦碰到那种完整的业务链路——登录、查询、下单、支付、查询订单详情——每多一个接口，工作量就指数上升。每个HTTP请求的域名、端口、路径、请求方式、Header、Cookie、Body参数，全都要在JMeter的界面里一项一项填。

更折磨人的是Header里的参数经常有一大堆，Content-Type、Accept、Authorization、User-Agent、Referer，每个都要从抓包工具里复制过来。复制的过程中很容易漏掉一两个不怎么起眼的Header，结果就是接口直接返回400或者签名错误。排错的时间比新建脚本的时间还长，放在日常开发里，这个成本完全不可接受。

所以当年我第一次知道Fiddler可以把抓到的HTTP请求直接导出成JMeter能打开的脚本时，脑子里只有一个念头：这玩意儿为什么没早点出现。从本质上讲，它就是抓包工具和压测工具之间的一座桥，把"已录制的流量"变成"可回放的脚本"。

1.2 常见的录制转脚本方案，谁更顺手

在聊这个插件之前，有必要先横向看看市面上还有哪些"录制转JMeter脚本"的方案。我自己都试过一轮，各有各的适用场景，做个表格放在这里：

从我实际的感受来说，如果你日常已经在用Fiddler抓包，那直接用它的导出插件是最顺的，因为你不需要改变任何操作习惯，抓完包顺手就导出了。JMeter自带的代理录制也不是不行，但每次录制前要改代理、录完要记得关，多线操作容易出错。Badboy现在用的人不多了，界面和功能都停留在老时代，处理现代的前端交互逻辑会很吃力。

2. 插件原理：从抓包会话到jmx文件，映射逻辑全拆解

2.1 Fiddler会话里到底存了什么

要理解这个插件，得先清楚Fiddler的Session列表里存的到底是什么。Fiddler是一个HTTP代理，所有经过它的请求和响应都会被它记录下来。一个会话（Session）其实是一个完整的HTTP事务记录，保存的东西包括请求方法、请求URL、请求头和请求体，还有响应状态码、响应头和响应体。

关键的一点是，如果你开启了HTTPS解密，那你看到的请求和响应都是解密后的明文。这就意味着，插件拿到的数据是干净的、可直接用的HTTP语义层数据，它不需要自己去处理SSL加解密的逻辑，只需要做数据格式转换就行。这算是这个方案天然成立的基础。

Fiddler本身没有直接暴露"生成JMeter脚本"的内置能力，它是通过插件机制来扩展的。社区里流传比较广的是Fiddler2JMeter这样的扩展，安装完之后，在导出会话时，导出格式列表里就会多出一个JMeter选项。

2.2 jmx文件到底是什么

很多人用了很久JMeter，却没打开过jmx文件本身。实际上，JMeter的脚本就是一个XML文件，只不过它的结构非常符合JMeter的组件树模型。

一个典型的jmx文件大概是这样的层级：最外层是TestPlan，TestPlan下面可以挂ThreadGroup线程组，ThreadGroup里再挂Sampler取样器、配置元件、断言、监听器这些节点。每个节点都有特定属性，比如HTTPSamplerProxy节点里面，就记录了domain、port、protocol、path、method、body这些信息。

所以，Fiddler导出插件的本质工作，就是把Fiddler的Session数据翻译成JMeter的XML节点树。它是一个"格式转换器"，不是"测试设计器"。这个定位决定了它的能力边界：它能把你录到的流量忠实地变成JMeter里的Sampler，但它不会替你想清楚"这个接口该不该做参数化""那个token应该怎么提取"这类测试设计问题。

2.3 核心字段的映射关系

具体到字段层面，映射逻辑大概是这样的：

这个映射关系很直白，也从侧面说明：插件的思路就是"一对一搬运"。它不会去判断某个Header是不是无关的，也不会去分析请求体里的某个字段是不是动态变化的，它做的是纯粹的翻译工作。

2.4 为什么不能指望"录完就能压"

正因为插件只是一个搬运工，所以它有一个天然的局限性：录制得到的脚本，描述的是某个用户在某一次操作中的完整请求序列。但性能测试的核心是模拟大量用户的并发行为，这两者之间有着本质的差异。

举个例子，你录制的时候登录接口会返回一个token，这个token被后续接口通过Authorization头携带。录制时这个token的值是固定的，插件会原样把这个值写进脚本。但等你用100个用户并发压测的时候，每个用户都有一个不同的token，这时候脚本里的固定值就会导致后续接口全部401失败。

这个过程说白了就是业内常说的"关联"问题。不只是token，订单号、用户ID、随机数、时间戳、验证码，凡是服务器动态生成、后续请求又依赖的值，都需要你在导出之后手工处理。插件不会替你做这一步，因为它不理解业务逻辑。它不是不行，而是它的职责范围本来就止步于此，剩下的工作要由测试人员自己完成。

3. 安装与前置配置：这几步做不对，导出菜单都不出现

3.1 插件安装与版本匹配

这个插件的安装方式不算复杂，但网上很多教程讲得不清楚，导致不少人卡在"装完之后根本找不到导出选项"这一步。

常见的Fiddler导出JMeter扩展，安装方式是把对应的dll文件放到Fiddler的Scripts目录下。不同版本的Fiddler，Scripts目录路径有可能不一样，常见的位置是：

C:\Users\用户名\Documents\Fiddler2\Scripts

把dll放进去之后，一定要完全关闭Fiddler再重新打开。重启之后，在会话列表里选中若干条会话，然后打开File菜单下的Export Sessions，这时导出格式列表里才会出现关于JMeter的选项。如果你在导出格式里没看到它，先检查dll是不是放对了目录，再检查Fiddler是不是完全重启了，这两个原因占了绝大多数情况。

需要提醒的是，Fiddler的版本和插件的匹配度可能会影响功能是否正常。我遇到过一次装完插件后导出无响应的情况，换了对应版本的Fiddler就好了。所以安装之前，最好先在插件的项目说明页上看清楚它支持哪个Fiddler版本区间，不要盲目用最新版Fiddler去配老插件。

3.2 HTTPS解密和证书配置

如果你的被测系统是HTTPS协议，那Fiddler必须开启HTTPS解密，否则你抓到的请求体全是密文，导出的脚本也毫无意义。开启方法是在Fiddler的Tools > Options > HTTPS中勾选Decrypt HTTPS traffic。

第一次勾选的时候，Fiddler会要求你安装它的根证书到系统受信任的证书存储区，要确认安装。之后抓取浏览器里的HTTPS流量，Fiddler就能帮你做中间人解密。

如果你要抓的是手机App的流量，还需要把Fiddler的证书安装到手机上，并且让手机的代理指向Fiddler所在电脑的IP和端口。这个操作各家手机略有差异，但核心思路是一样的：手动安装证书并信任它。证书这块如果配不好，你录到的就是一堆TLS握手失败的错误，导出的脚本自然没法用。

3.3 过滤规则：别把静态资源全录进去

录制过程中最容易被忽略的一步是设置过滤。如果你不做任何过滤，打开一个网页可能有几十上百个请求，其中有大量的图片、CSS、JavaScript、字体文件请求。这些东西录进去之后，导出的JMeter脚本会非常臃肿，一个简单的页面跳转操作，可能生成几百个Sampler，不仅看着头大，回放时还会拖慢脚本执行速度。

Fiddler左侧有Filters页签，可以设置只显示某个Host的请求。比如你的被测系统域名是testapi.example.com，那就在Host过滤器里填上这个域名，只显示这个域名的请求。这样录制完的会话列表，基本就只包含真正需要压测的业务接口了。

真到了导出阶段，还要养成手动再过一遍的好习惯。因为有些第三方统计请求、上报请求跟被测系统同域，也会被录进来。这些请求对业务链路没有影响，但会出现在脚本里。压测的时候打到第三方统计接口上，既浪费资源，还可能搞出不必要的脏数据，及时删掉是明智的选择。

4. 完整操作流程：从清理会话到脚本进JMeter

4.1 录制前的准备清单

我自己用这个插件的时候，已经形成了一套固定的流程，每次都按这个来，基本不会出幺蛾子。

第一步是清空Fiddler的会话列表。操作很简单，按快捷键Ctrl+X即可清空。为什么要事先清空？因为导出插件很多时候是把当前会话列表里选中的会话导出，如果你不清理，列表里可能残留着之前抓包的其他请求，一不小心就导出混了。

第二步是确认过滤规则。检查左侧Filters是不是只显示了被测系统的Host。我在实际录制中吃过亏，有次过滤器没设好，把本地静态服务的请求也录进去了，导致导出后脚本里多了一大堆localhost的请求。所以这个步骤值得认真确认一下。

第三步是确认Fiddler底部状态栏的Capturing开关是开着的，保证流量能够被捕获。如果你开着Fiddler但没开启捕获，那怎么操作都是白搭。

4.2 手动走一遍业务流程

准备工作做完之后，就是在被测系统上进行操作。无论是用浏览器还是手机App，操作的时候要尽量覆盖完整的业务路径，并且顺序要和自己预期的压测场景一致。比如准备压测"登录—查询—下单"这个链路，那就要按这个顺序完整走一遍，不要跳步骤，也不要操作到一半去点别的页面，那会塞入无关流量。

操作完成后，回到Fiddler界面检查会话列表。按时间顺序核对这些请求，确认它们确实覆盖了核心业务接口。如果有漏掉的接口，宁可重新清空再来一遍。在这个阶段花几分钟检查，比导出后再返回去补请求要省事得多。

4.3 选中会话并导出jmx文件

会话确认没问题之后，在Fiddler中选中需要用到的会话。如果整个列表里的请求都相关，可以直接Ctrl+A全选。如果只有部分请求相关，就按住Ctrl逐个点选或Shift连选。

然后打开File > Export Sessions，在导出格式列表里找到JMeter格式。选择保存路径，文件名通常以jmx结尾，比如login_query_order.jmx。

这里有个细节要注意：有些插件导出时会弹出选项，让你选择是否包含请求的Headers、是否生成Cookie配置等。有选项的话，建议全部勾上，因为导出后删东西容易，缺了再补反而麻烦。

4.4 导入JMeter并试跑验证

导出完成后，打开JMeter，通过File > Open打开刚才的jmx文件。你会看到插件已经帮你建好了TestPlan、ThreadGroup和一组HTTPSamplerProxy，整个结构看起来和手工搭建的脚本一样。

首次打开后先别急着跑压测，我的习惯是先做三件事：

1. 检查线程组配置。插件默认的线程数、循环次数通常就是1个线程跑1次，要根据实际压测需求调整。在调试阶段可以先保持1个线程，先把脚本跑通再说。
2. 添加一个查看结果树的监听器。没有监听器，跑完只能看到汇总数据，接口返回的具体内容看不清楚。调试阶段加一个View Results Tree非常有必要。
3. 跑一次单线程，检查所有Sampler是否都返回成功。重点关注返回状态码，以及业务层面的成功标志。有些接口返回200但业务逻辑失败了，这个在查看结果树里能看得很清楚。

试跑通过后，再清理掉调试用的监听器，按实际压测场景配置线程数、循环次数、持续时间，添加聚合报告或其他监听器，这样才算完成了一个可用的压测脚本。

5. 导出的脚本为什么经常跑不通：问题定位与修复

5.1 动态令牌是最大的变量

不管插件用得多熟练，导出后的脚本十有八九不是一次能跑通的，最典型的原因就是动态令牌。

你录制的时候，系统会为你的登录请求生成一个token，这个token写在响应体里，后续很多接口用Authorization头带着它。插件导出时，只会把这个token的固定值放进脚本。等你回放的时候，登录接口可能每次都生成不同的token，但后续接口用的还是录制时那个旧值。服务端一校验，发现token不对，直接拒绝访问。

解决办法就是在JMeter里做关联：在登录请求下面添加一个JSON提取器或正则表达式提取器，从登录响应里提取token，存成变量。后续接口的Header里，把固定的token值替换成变量引用，比如写成${token}。这样每次执行时，登录接口都会先拿到一个新的token，后续接口再通过变量引用它，整个链路就串起来了。

JMeter默认在同一个循环内按顺序执行线程组里的Sampler，所以这个流程是能保证的。需要注意的是，提取器的作用域和变量命名要对，不要把两个接口的token提取到同一个变量名下面，否则会出现串数据的问题。

5.2 Cookie与登录态在不同路径下的表现

Cookie是另一个常见的坑。录制时，Fiddler会话里记录的Cookie是当前登录用户专属的，插件会把这些Cookie原样带进脚本。

第一次回放时，如果JMeter启用HTTP Cookie Manager，它会把登录接口返回的Set-Cookie自动管理起来，后续接口使用新的Cookie，这个行为是符合预期的。但如果你没有正确地配置Cookie管理器，或者录制导出的脚本里本身就写死了Cookie参数，那脚本运行时就可能出现登录态丢失、接口返回未授权的情况。

我建议的做法是：导出的脚本中如果有写死的Cookie参数，先删掉这些硬编码值，在测试计划里添加一个HTTP Cookie Manager标准配置。这样做的好处是，JMeter能像真实浏览器那样自动维持会话状态，而不是用一个过期的固定Cookie去访问接口。

5.3 请求之间隐含的数据依赖

除了token和Cookie，业务链条里还有大量隐性的数据依赖。比如查询订单的接口需要传一个orderId，而这个orderId是创建订单接口返回的。录制时这个值固定，但压测中每次创建订单都会生成一个新的orderId，如果你没做关联，查询订单接口就会因为找不到id对应的数据而失败。

这种依赖关系的处理方式跟动态token完全一致：在前置接口上挂后置处理器，从响应里提取关键数据，存成变量，下游接口引用这个变量。区别只在于提取的方式和提取的字段不同。

这里有一个经验性的建议：不要试图一次性把所有关联做完再跑脚本。更高效的做法是，从第一个Sampler开始，逐个往后跑，每跑到一个失败接口就停下来查看结果，看看它的请求参数里有没有引用了上一个请求返回值的地方，有就做关联。这样一轮一轮迭代下来，整个链路就跑通了。一次性全改完再跑，出问题了反而不好定位是哪一步改错了。

5.4 静态资源和无关请求让脚本臃肿

即使录制前过滤了Host，导出的脚本里仍然可能出现一些不属于核心业务链路的请求。比如前端页面会自动请求的一些监控上报接口、埋点接口，它们和被测业务没有强依赖，但同样在同域名下。

这些请求在调试阶段往往不显眼，但压测时它们会占用线程的执行时间，拉低核心接口的请求量，而且埋点上报数据在服务端累积起来，可能干扰测试结果的准确性。所以在试跑之前，建议花点时间把脚本里的Sampler逐个过一遍，看到明显非业务性的请求就删掉。

删除Sampler的时候要注意，不能只看URL就删，还要确认它没有被后面的请求引用。如果不确定是否有依赖关系，可以先禁用而不是删除，跑一轮看看后面的请求是否正常，确认没影响再删除。

5.5 缺少断言，接口不是200就算成功

还有一个新手特别容易忽略的问题：导出的脚本里默认是没有断言的。这意味着即使接口返回了错误信息，只要HTTP状态码是200，JMeter就会把它算成成功的事务。

比如登录接口因为参数不对返回了200，但响应体里明确写着"账号或密码错误"，聚合报告里看到的事务成功率仍然可能是100%。这种情况在压测中很容易误导人，产生"脚本一切正常"的错觉。

正确做法是在关键接口后面加响应断言，判断响应中是否包含业务成功的标志字段。比如登录成功会返回"success": true，那就在断言里检查"success"这个文本是否存在。这么做之后，凡是业务失败的请求都会标红，压测结果才真的可信。

6. 插件选型与适用边界：什么场景建议用，什么场景别浪费时间

6.1 最推荐使用的场景

用了这个插件这么久，我最推荐的使用场景是业务流程长、接口数量多、并且接口参数相对稳定的系统。

举个例子，如果你要压测的是一条包含十几个接口的完整交易链路，手工去建脚本确实费时费力，用插件录制导出，十分钟就能生成一份完整的jmx脚本。只要动态参数不多，简单处理几个关联点，脚本就能跑起来，效率提升非常明显。

另一种很典型的场景是，你已经有了一个可以正常执行的手工脚本，但业务版本升级导致接口增加了几个字段。这时候用插件重新录制一次，对比新旧脚本，把新增的Sampler合并进去，比逐一检查手工脚本快得多。

6.2 不建议硬用的情况

也有几种场景，我不建议花时间在这个插件上。

第一种是接口大量依赖动态签名和加密参数。很多App接口每次强求都会生成nonce、timestamp、sign这几个参数，服务端验签逻辑很严格。录制导出的脚本没法自动生成新的签名，即使你做了参数关联，要模拟签名算法也是一项大工程。这种情况还不如直接写代码调用SDK生成签名，或者用JMeter的JSR223脚本自己实现签名逻辑。

第二种是超高并发、需要精确控制参数和数据模型的场景。录制导出是基于一次真实会话的，参数范围和取值都比较窄。要在压测中精确模拟不同账号、不同业务数据分布，手工设计脚本反而更可控。

第三种是最简单的场景。如果核心接口只有两三个，参数也不复杂，手写一个JMeter脚本可能五分钟就完成了，这种情况下折腾录制导出反而是舍近求远。

6.3 我目前的工作流

经历了这么多之后，我现在的工作流已经比较固定了：先判断被测接口的复杂度，简单接口直接手写；复杂长链路才用Fiddler录制导出做底稿；导出之后一定会腾出时间做关联、加断言、清理多余请求，再进压测流程。

插件在这个过程中更像是高效的搬运工，把最枯燥的录入工作给省掉了。它不替你想测试设计，也不替你理解业务逻辑，但只要你理解它这个边界，它在很多场景下都是非常值得用的效率工具。

最后再分享一个小技巧：录制导出之后，别急着把Fiddler关掉。压测过程中如果发现某些接口请求数据异常，Fiddler还能帮你实时对比请求内容和JMeter发送的内容，排查问题会快很多。工具之间的配合，有时候比工具本身的功能更重要。