论soapui与java httpclient测试框架各自优缺点及心得

liyinb

2016-6-2016-10  是我用soapui测试公司app接口的时间，之后自己利用httpclient研究了一下java编写框架测试

利用技术
java+testng+httpclient+excel

发现soapui在易用性和后期维护上有缺陷  
soapui  优点：
                      1  调试接口方便，返回结果直观可以很容易看出，对调试有好处
                      2  功能强大 支持各种功能 还可以进行压力和安全测试
            缺点：
                      1 若后期接口多显示不直观，几十个接口下面有上百种方法，如果有具体接口需要调试就得一个个点开去找相当烦人
                      2 后期将接口得一个一个添加到testsuit中去，若只改Testsuit外接口中参数，内部是不变的，实际往往需要同步修改，若忘记了修改哪些东西后期去找很麻烦
                      3 当接口用例需要添加header时 相当麻烦必须手动去添加参数一个一个去点，试了其他设置header为参数的方法又行不通
                      4 若做接口继承需要在testsuit中添加一个step->properties来存放参数，接口多了需要添加的properties就多显得会很乱不易维护
                      5 断言目前只能做到非常简略，资料少，且不够灵活
                      6 testsuit运行完成后成功的表绿报错标红，没有一个统一的报告
下面说说用java 写接口框架的优点
            优点：
                     1 后期某一个查找方便
                     2 后期修改接口参数只需要该excel中对应的参数即可
                     3 header直接写在excel中了，只需要复制粘贴程序自己去读即可
                     4 对应后期接口集成测试可以直接 用java代码返回参数直接调用即可，可以灵活设置需要返回的参数
                     5 断言解析返回的json字符串，可以灵活设置
                     6 灵活设置需要执行的接口脚本，结合testng可以出一个测试报告
                     7 excel中的数据一定程度上上可以作为接口用例来读
                     8 soapui中的json字符串作为传入值直接复制到excle中即可
            缺点：
                      1 调试时返回结果展示不友好，不直观，很费劲
                      2 现在只支持基于http协议的接口
                      3 断言设置需要每个@TEST方法去写脚本添加断言

但现在 有一个问题，restful协议的返回每个接口数据格式不一致，参数也不同，不能统一去写脚本去调用，需要根据每一个接口的返回数据格式及业务需要层层去解析设置断言

我的总结是，结合两者的优缺点，在测试项目接口时，先用soapui写一个脚本去进行调试,在接口测试通过后去复制json参数，url和head到excel中去，对每个Test单独加断言，尽量另写一个脚本去封装好出现次数多的解析方法，直接调用

栖息海角

666

清晨一缕阳光

学习了！

梦想家

支持分享

liyinb

还没有写完呢怎么不能编辑了，好吧继续上次的

接口测试一般都是先于功能测试开始的，接口开发开发完接口将地址及参数暴露给前端开发去调用，所以我们测试接口时都是开发完一个接口出一个sprint子任务，测试接口一定要有接口文档且接口文档必须包含：

1 url 即服务地址端口和接口地址

2 传递参数  参数是否必传，参数类型都需要写清楚  

3 提交格式是POST还是GET或者ADD，DELETE，我们公司的协议都是restful的标准一律采      用POST也可以。

4 返回参数，接口响应返回的字段都有哪些及展示形式

然后根据接口的注释及功能去原型图查找这个接口所在的页面，弄清接口的参数怎么传递，然后去写接口用例（注：一个接口并不是一次性要传所有参数，而是根据前端用户的操作去传递的，这个要和开发弄清楚）接口用例包含以下几种：

1 正常的业务用例：如字段审核verify:1,2,3  1为审核中，2 审核通过，3 审核不通过，要写三个用例去包含这三种情况

2 异常用例：如为字段值为null，长度溢出，格式非法，此处根据实际情况只要不影响正常业务（这块涉及到一个通病，此些情况前端一般不会传递的，模拟不到，实际不可能发生，因为我们跳过了前端，所以才会出现，但是确实接口没有做相应处理，开发会推辞这个就看你个人的测试魅力让他给你改不改了，有些东西，前前端、接口、服务都可以加限制但是接口这块测出来了，要不要加比如长度溢出，这个就需要和他们讨论了，个人认为我们测试宁可多提一个不能漏一个万一有黑客攻破前端呢，此时在接口与服务这块加限制就很有必要了）

3 想不到的用例：如参数默认值、有排序的返回结果的排序、不传即为默认的、业务之间有关联的接口之间自然有关联了，必须把接口当前端功能一样串起来想怎么去写用例

写完用例要去准备测试数据了，此时需要知道接口用到了哪些表及哪些字段，此时就用文档吧或者先写一个接口调试一下去后台把sql摘出来

去准备各种参数同时看后台打印传入的参数，（根据检查sql和传入此处很能发现bug）

把开发的sql所有表述的业务功能理解后自己去根据业务做比对（开发的sql一般比较复杂，但是我们只需要看懂后拆分一步一步去根据业务自己写sql用我们的理解去比对他们的返回值，若产生分歧，此处就需要做好和产品和开发的沟通了）。

然后根据文档去检查返回值（返回值也不是一定要按照文档的来的，因为一个接口里面会包含好几个服务，我们需要灵活参照需求及原型图去查看，返回值显示是否正确，是否缺失返回值，显示是否正确等），不止要根据文档还要根据原型图原型上展示什么大概检查一下他们就会需要返回什么，此处也会因为开发和前端或者产品沟通不畅理解不到位会经常出现bug。

根据以上用例及流程测完一个接口后就会八九不离十了了，就是过程可能会比较麻烦，需要辛苦了。至于后期的接口之间业务集成测试那就是后话了。