Parasoft SOAtest录制接口用例总失败怎么办 Parasoft SOAtest请求参数该从哪里校对

接口用例在录制完成以后，一到回放环节就频繁报错，这通常并不是录制功能本身不能用了，而是代理、认证信息、动态参数或者请求结构没有被处理利索。Parasoft SOAtest可以借助Parasoft Recorder把接口流量采集下来，再照着流量生成Smart API Test；录制期间，SOAtest Web Proxy这个代理需要一直保持运行。着手排查的时候，不要一遍又一遍地重新去做录制，应该先看一看失败的请求和真实流量之间，究竟是在哪一个层面上出现了偏差。

一、Parasoft SOAtest录制接口用例总失败怎么办

在录制接口用例的时候，得先确认流量真的进到了Recorder里面，然后再去处理已经生成出来的那些测试步骤。浏览器页面上的操作顺顺当当地完成了，可不代表接口请求就一定会被采集得整整齐齐。

1、检查代理和录制范围

首先要确认Parasoft Recorder服务已经跑起来了，浏览器或者调用端发出来的流量，是经过了SOAtest Web Proxy的。录制的范围啊，可别放得太宽，那些静态图片、埋点信息、不相干的域名，还有反复轮询的请求，都可以把它们排除在外；要是反过来，一股脑都收进去，生成出来的用例就会特别杂乱，真正需要你去维护的那些业务接口，反倒不容易被看清楚了。

2、检查登录态和请求头

当接口回放的时候冒出来401或者403这样的状态码，头一件事应该去查一查Token、Cookie、Authorization、Content-Type，还有那些自定义的Header。Smart API Test的生成规则，是能够借助HTTP Authentication和HTTP Header这些工具，把认证信息再补充上去的，也可以直接把录制时采到的请求头给覆盖掉。对于那些登录态会自然过期的项目，千万不能把一次录制拿到的Token长时间地写死在用例里头。

3、检查动态参数

像订单号、会话ID、验证码、时间戳，还有那种临时性的令牌，这些值大多是从上一个接口返回的结果里带出来的。录制时写进请求里的是当时那一刻的数值，等到回放的时候再接着用那些旧数，就免不了要失败。SOAtest提供了一个叫作Data Bank的功能，能从响应的报文里把发生变化的值给提取出来，再传给接下来的请求去用；Text Data Bank呢，则可以从纯文本格式的响应里把动态内容抽出来，并把抽出的结果当作参数反复去使用。

4、检查调用顺序

有一些接口的调用顺序是定死了的，你得先登录、把数据创建好，然后才能去查询或者删除。录制结束以后，要是你不小心把前面的这些步骤给删掉了，或者动手调整了请求的先后次序，那么后头那些步骤需要用到的参数就抓不到了。比较稳妥的做法是，先把整条链路完整地跑通一回，再一步一步地把那些不需要的请求清理出去。

二、Parasoft SOAtest请求参数该从哪里校对

参数校对这件事情，可不能光盯着URL看。一个接口到底能不能顺顺当当地回放成功，还要连带着去检查它的请求方法、路径里夹带的参数、查询参数、请求头、认证方式，还有请求体的内容。

1、先看Traffic Viewer

头一步，给测试步骤把Traffic Viewer这个查看器附加上去，等到用例跑完一遍之后，再点开里面的【Request】和【Response】来查看。Traffic Viewer不光能把请求头、请求体、响应头和响应体都亮出来，还能把每次测试运行的记录给存下来。你要是把那条失败的流量，跟接口调试工具里发送成功的请求并排搁在一起比对，它们之间的差异立马就会变得非常直观。

2、再看Transport页

接下来，打开REST Client或者是Messaging Client，找到【Transport】这个页面。在【General】这一块里，需要核对端点的地址和HTTP方法有没有写对；在【URL Parameters】里面，重点检查那些GET类型的参数；在【Security】那里，要确认好认证方式选得对不对；至于【HTTP Headers】，就可以逐条核对请求头的信息了。根据官方文档给出的说明，URL参数既可以按照名称和值一条一条地添进去，也允许用数据源来做参数化。

3、单独检查请求体

对于POST、PUT还有PATCH这几类请求，一定得把Payload或者请求消息那块区域打开来，仔仔细细地确认JSON结构、XML格式、表单里的字段，以及编码的方式是不是都合规矩。字段名称的大小写、不小心留空的数值、数组嵌套的层级，还有Content-Type的设置，这几样东西只要有一处对不上，服务端就很有可能直接把请求给拒掉。

三、Parasoft SOAtest接口用例录制后怎么复核

就算接口回放已经跑通了，仍然需要再做一轮小范围的复核。要是不走这一步，用例可能只会在当初录制时的那个环境里头乖乖执行，一旦换上一组新数据，或者切到另一套测试环境里，马上又会重新失效。

1、替换一组测试数据

可以拿另一组完全不同的账号、业务编号，还有输入参数，把原来的数据整套换掉，用这种方法来确认用例并没有死死地依赖录制时那几个固定的数值。

2、连续运行多次

把同一套用例连着跑上好几轮，专门去观察那些Token、会话ID，还有临时生成的编号，能不能在每一次运行当中都被重新提取出来。如果从第二轮开始就持续失败，一般情况下，这就说明动态参数仍然被写死在了用例里面。

3、保留失败流量

万一在运行中碰到了异常情况，及时把Traffic Viewer里面抓到的请求和响应都保存下来，同时记好测试步骤、当时所用的环境、发生时间，还有返回的状态码。以后再来调整参数的时候，就能直接把这些记录拿出来对着改，不用再凭感觉重新去猜了。

总结

Parasoft SOAtest在录制接口用例时老是失败，头一步应该顺着代理、认证信息、动态参数和调用顺序这几个方向去排查；而要校对请求参数，就可以从Traffic Viewer和REST Client的Transport页面开始下手。把请求的端点、方法、URL里的各项参数、请求头、认证方式，连同请求体，逐项都核对过一遍，再换用另外的数据去连续做几次回放，这样操作下来，接口用例才更容易稳稳当当地站住脚。