Parasoft SOAtest怎么测试接口 Parasoft SOAtest接口断言怎么设置

Parasoft SOAtest测试接口的方法，和接口断言怎样设置，这两件事的关键，是先把接口的请求调通，然后再一步一步把需要校验的地方补上去。SOAtest这个工具，能够支持REST、SOAP、微服务、数据库这些不同的测试场景，也能够根据流量或者自然语言去生成API的测试，还可以创建那种靠数据来驱动、分好几个步骤的测试流程。所以，它的用处不只是发出一个请求然后去看返回的结果，它更适合把接口的调用、参数的准备、响应的校验，还有回归的执行这一整套东西都串在一起。

一、Parasoft SOAtest怎么测试接口

在使用SOAtest测试接口的时候，需要先把接口是什么类型、请求发到哪个地址、用什么方式去认证、请求里面要带哪些参数，以及期望它返回什么结果，这几样东西都弄清楚。在接口本身还没有跑通之前，不应该急着去加那些很复杂的断言，不然的话，等到测试失败的时候，就很难判断这到底是调用接口的时候出了问题，还是因为断言用的规则写错了。

1、先把接口的测试项目建立起来

进入到【Test Suite】这个界面以后，根据要测的接口是什么类型，去选择REST Client或者SOAP Client，然后再把请求的方法、URL、Header、Body和认证的信息都配置好。

如果测的是REST接口，要先去确认GET、POST、PUT、DELETE这些方法是不是选对了；如果测的是SOAP接口，就要确认WSDL、Operation，还有消息的结构是不是能够对得上。SOAtest能够通过REST Client去测试RESTful服务，也可以围绕服务的定义去创建接口的测试。在第一次进行配置的时候，最好是先用一个最简单的请求去把接口跑通，不要在一开始的时候，就把所有的参数、数据的来源，还有断言全都加到里面去。

2、接着去把测试的数据整理好

接口测试这件事，不能只去测一个正常情况下的值。可以围绕着【正常的参数】、【处于边界位置的参数】、【缺少了的参数】和【不正常的参数】这几个方面，去把要用的数据准备好。

比如测试查询接口的时候，要去测有效的ID、无效的ID、空着的ID，还有长度超出限制的参数；测试新增接口的时候，就要去测那些必须要填的字段、字段的格式、重复提交，还有权限不够这些情况。如果接口里面还有分页、排序、状态变化这些逻辑，还需要把这些组合起来的场景给拆分开。把数据都整理清楚以后，SOAtest的数据驱动测试，才会有它的意义。

3、把好几个接口串成一个业务场景

有不少接口，它们并不是独立存在的。比如，需要先调用登录接口去获取一个token，然后再去创建订单，接着再去查询这个订单的状态，最后才去取消这个订单。SOAtest这个工具，更适合把这种一连串的接口调用，放在同一个测试的场景里面去执行。这样做，不光能测试单个接口是不是返回了成功的信息，还能检查接口与接口之间的数据传递，是不是正常的。

二、Parasoft SOAtest接口断言怎么设置

接口的断言，说的就是用一些条件去判断接口返回的结果，是不是跟预期的结果相符合。光看HTTP的状态码是不是200，这是不够的，因为状态码正常，并不代表业务处理的结果就一定是正确的。断言这种东西，需要覆盖到状态码、响应的字段、数据的格式、业务的规则，还有出错时候的信息。

1、先加上那些最基础的响应断言

可以围绕着【状态码】、【响应的头部信息】，还有【响应的主体内容】这几项，去设置最基础的校验。

比如说，登录成功了就应该返回200，权限不够就应该返回401或者是403，创建成功可能会返回201。响应头部信息里的Content-Type、缓存使用的策略、返回内容的编码方式这些，也是可以去检查的。这些基础的断言，要先把接口在协议这一层面没有问题的结论给保证住，然后再继续往下去看业务相关的字段。

2、再去加上针对JSON或者XML字段的断言

如果接口返回的内容是JSON格式的，就去检查字段是不是存在、字段里面的值是不是对的、数组里面的数量是不是符合预期；如果返回的是XML格式的，就去检查那些节点、属性还有文本的值。SOAtest可以为SOAP Client和REST Client去添加一种叫做assertor的校验工具，能用它来比较快速地增加对响应的校验。就拿订单查询的接口来说，不能只是去判断返回有没有成功，还要去检查返回结果里的orderId是不是跟请求时用的订单号一样，status是不是在一个被允许的范围里面，amount是不是跟创建订单的时候是一致的。这些对字段的断言，越是贴近业务本身的规则，接口测试的价值就越大。

3、对那些会动态变化的字段，不要把值给固定下来

有一些字段，它们的值是每一次都会发生变化的，例如token、timestamp、requestId、流水号、还有随机的验证码。要是把这些字段全都写成一个固定的值再去做断言，那这个测试就会很频繁地失败。一种比较合理的做法，是去检查这些字段是不是真的存在、它的格式是不是正确的、长度是不是符合当初定下的规则，而不是非要强求它每次的值都完全一模一样。

4、对出错的情况，也要设置相应的断言

有很多接口的测试，注意力都只放在了成功返回的那一部分上面，那些出错的情况反而没有人去管了。然而在实际的项目里面，错误码、错误的信息、权限的提示、参数校验的提示，这些东西全都是要去进行断言的。比如说，在缺少了必须要填的字段的时候，接口就应该返回一个明确的错误信息，而不是直接就返回一个500的状态码。把出错场景的断言也做好以后，接口质量的稳定性，是会更加容易得到保证的。

三、接口断言维护时要注意什么

接口的断言，并不是设置过一次就再也不用去管它了。当接口的字段发生了变更、错误码被调整了、或者认证的方式发生了变化以后，以前设置的那些断言，很有可能就会失效。在做维护工作的时候，需要去区分，这到底是“接口真的出错了”，还是“断言使用的规则已经过时了”。

1、断言要跟接口的文档保持一致

要对照着【接口的文档】、【字段的定义】和【错误码的说明】这些材料，去检查断言是不是还合理。

如果接口的文档，已经把字段的名称从userName改成了name，而旧的断言却还在那里继续检查userName，那这个时候测试出来的失败，就不是接口本身的问题了，而是测试用的这套资产，没有跟着一起同步地进行维护。接口被变更了以后，测试的用例和断言，也是需要跟着一起修改的。

2、不要设置那种过于严格的断言

断言设置得太少，会漏掉一些问题；但是断言设置得太细碎，同样会带来维护上的压力。比如说，测试那种会返回多条记录的列表接口时，不一定每一次都要让返回结果的完整顺序，都保持得完全一样，除非是这个接口明确地规定了排序的规则。可以重点地去检查那些核心的字段、数量的范围、状态的值，还有业务上最关键的几个结果。

3、把断言的结果纳入到回归测试的流程里

接口的断言全都设置好了以后，需要把它们放进持续回归的流程当中去。每一次版本发生变更之后，都把接口的测试跑上一遍，这样就能比较早地去发现字段的缺失、返回结构的变化、权限的异常，还有业务逻辑上的问题。SOAtest这个工具，支持自动化测试的创建和维护，很适合把接口测试纳入到持续测试的流程里面去。

总结

Parasoft SOAtest怎么测试接口，还有SOAtest接口断言怎么设置，它的重点，是先要把请求的配置做正确，然后再围绕响应的状态、返回的字段、业务的规则，还有异常的场景，去把断言设置好。接口测试，不能只是去看请求有没有成功，也不能把所有的字段都用机械的方式写死。比较稳妥的做法是，基础的响应先进行校验，核心的业务字段重点去校验，会动态变化的字段按照格式去校验，出错的场景单独去覆盖。这样做，SOAtest才能真正被用在接口的回归测试里，而不是只做一次简单的调试。