接口测试 web 接口测试总结

鱼肚白 · May 27, 2016 · Last by yangqinyuan replied at June 28, 2017 · 5715 hits

声明:接口仅限controller层,不设计service和dao层接口,仅限功能测试中的接口测试,不涉及后续的自动化或者框架 。

接口测试有什么用,应该怎么做?网络帖子上的回复各有侧重点,有模式化的模拟发送请求查看响应体是否符合接口文档的、有把接口中每个参数都修改后排列组合重新发送的。下面阐述我所理解的接口测试,当然我所理解的接口测试也仅仅是一部分,各人理解不同,希望通过交流能得以补充完善。言辞拙劣,不喜勿喷。

Q:接口测试是什么?
我认为接口测试是功能测试不可或缺的一部分,抛开了前端的逻辑和限制对于服务端的功能进行了完整的测试,一个好的功能测试人员应该充分了解所测系统有多少个接口,接口的核心参数和响应,完成对接口代码走读,接口有没有白名单,防刷,内部接口or外部接口等。

Q:接口测试有没有作用?
当然有用,而且作用很大。从接口测发起的测试弥补了界面测试的遗漏点。界面测试起码遗漏了
1.服务器端接口参数校验
2.接口是否存在安全漏洞或者逻辑漏洞,实时性,防刷等
3.接口是否存在越权的可能 。

能将接口测试纳入功能测试的一部分并且完成,测试的完整性得到了很大的提高。

Q:接口测试怎么做?
接下来到了核心的部分,如何做好接口测试。
首先,工具的选择很重要,需要一个好的抓包工具或者代理,浏览器方面的推荐firefox的firebug和chrome自带的开发者工具,快捷键都是F12。工具方面推荐fiddle2和
charles、postman,这几款款工具的功能还是比较齐全的,包括抓取http和https包、请求包结构、时间、断点调试、mock、重复发送请求等等,囊括了你对于一个抓包工具所有的诉求。现在抓包工具有了,我们抓取一个典型的post请求如下:

图一


图二


图三
图一图二是一个请求消息头与消息体,请求消息中的每个字段都有意义且可以更改,这个现象就很有意思了,测试人员应当如何去操作这个请求消息呢?

第一步:【看】
(a)看接口的访问方式是get、post、delete及header中的cookies信息或者UA信息等重要信息,看响应头中诸如referer等信息
(b)看接口的参数构成是否合理。举个例子,大家看下面截图,有个接口名称为cancelOrder,传入参数有3个:原始状态、修改订单后的状态、订单code。有没有觉得这个接口的设计师一个悖论,接口的作用已经明确确定为取消订单,还需要传入状态。你可能说,即使加上这两个参数也没错啊。这种观点是错误的,订单状态在数据库中已经有明确的定义,不需要再通过不确定的前端传入,这样会减弱程序的健壮性,增加冗余。原则是能在服务器端获取的尽量不要传,参数个数尽量精简。


图四
(c)看所传参数有无敏感数据需要加密传输。比如说用户userid、password等数据如果不使用https进行通信,最好使用加密的方式进行传输,这也是业界通用的标准,并且入库也需是加密的。
(d)看所测服务的代码。第一看对于传入参数的校验部分,第二是看整体逻辑处理部分。举个例子,大家在测试过程中经过会遇到如图五所示,有多个必填或者选填项、输入条件特别多、每个输入条件都需要做校验。有些测试人员会对此类问题用正交的方式一项一项测试,这类效率太慢。个人认为效率最高的方式为对于接口参数的校验,以静态测试为主,review代码的过滤条件,页面控件实际输入测试为辅助。很多的输入界面,其中判空处理是必须的。开发代码中常用的一个判空函数是if(xxx.isempty())。首先界面类查找是否有控件对象未使用该函数,若未使用肯定存在bug;其次即使使用这个函数也是有bug,该函数并未完全满足需求。这个函数漏掉了输入空格的情况,正确的做法是if(xxx.trimme().isempty())。那么如果在全工程内,搜索isempty,对比发现bug,最后可以选择一个输入项进行测试,通过后所有输入控间判空测试均告完毕。静态测试最多只需要10分钟,对应所有可输入业务控件不为空以及过滤空格的功能点用例可能有几十个,执行时间至少半个小时以上。静态效率比大于1:3。


图五
(e)看接口的返回体是否返回一些不必要的敏感信息,返回格式是否合理等

第二步:【改】
(a)请求体中参数的常规修改。常规修改就是通用的边界值方法,如极大值、极小值、极长值、null、空。未对这些值做校验的后果可大可小。小的方面仅仅是服务器throw一个统一的错误提示,如网络错误等。中等一点的为前端页面会返回如图六形式的内部错误,这种错误会泄露一些敏感信息。严重的后果可能就是影响现有或者后续业务,使得业务往不可控的方向进行。

图六

(b)与业务强相关的参数修改。在本文中强调的一点就是接口测试是功能测试密不可分的一部分!在上段图二中,各项参数都对应了数据库中的某个业务字段。比如修改taskid为一个还未上线的任务id,会不会就领取了这个任务。又或者修改taskid为已下线的任务id,是不是可以领取这个任务。这一类的参数修改法无定法,需要测试人员深入到功能内部,加上对于业务源代码的走读进行用例设计。
(c)请求消息体中的字段修改。有些人习惯在cookie中传输大量的信息,也是值得关注的测试点。

分享一些测试案例来印证观点:
1.
bug描述:http://www.wooyun.org/bugs/wooyun-2010-046547(我们网站也确实存在此问题)
危害:在一个验证码有效期内,可重复使用这个验证码进行注册、登陆

2.
线上存在漏洞,有些用户的交易密码被无故修改,通过排查发现,黑客是通过调用绑定交易密码这个接口来直接修改交易密码的,由于这个接口不需要传入oldpwd,就导致了黑客在无需知道老交易密码的情况下就可以修改交易密码,

共收到 17 条回复 时间 点赞

测试思路我是赞同的,但接口测试始终都是要自动化的,是要加入到持续集成框架中的。靠手动执行始终太耗费人力,毕竟又要验UI,又要验接口的。 如果没有自动化起来的话。还不如直接验UI比较靠谱。 当然了,如果你们人多势众就当我啥也没说吧哈哈

鱼肚白 #2 · May 27, 2016 作者

#1楼 @ycwdaaaa 是的。我是分开说的,有自动化的,我们是python封装类库+robotframe+jenkins,这个里面说,一篇写不下。。谢谢建议

能否举个几个实例详细说一下用例具体要怎么设计?怎么设计才能更好地保证不遗漏最后的两个案例里面的安全问题?

我觉得无论是否自动化,用例设计都是比较重要的。

#1 赞同!!
目前正在弄jmeter + jenkins的自动化测试, 后续会把selenium加入到jenkins里头去。

鱼肚白 #5 · May 30, 2016 作者

#3楼 @chenhengjie123 是的。我说的就是功能方面的用例设计。。你可以看一下【接口测试怎么做】这一节,如果没有思路,再交流一哈。

鱼肚白 #6 · May 30, 2016 作者

#4楼 @archonwang 是的。我们现在是有robot+jenkins的框架的,自动化用例数1200+的样子,前段时间改了ride源码做自动化用例转化的,不太成熟,现在想用postman作为入口做自动化用例转化。。WEB UI已经放弃啦。

赞同!!

鱼肚白 #8 · May 30, 2016 作者

#7楼 @chenjialu 谢谢,欢迎讨论。。

“请求体中参数的常规修改。常规修改就是通用的边界值方法,如极大值、极小值、极长值、null、空。”

最近在做接口自动化,想请教下对于这些异常的情况,需要全部覆盖到case里去吗?还是说只覆盖正常的情况,做冒烟测试,保证主功能流程的正确性

鱼肚白 #10 · May 30, 2016 作者

#9楼 @isaac 你好。对于接口测试我认为接口的安全&越权优先级最高,就是对于核心参数的逻辑校验。接下来对于常规修改就是通用的边界值方法,如极大值、极小值、极长值、null、空这类情况,可以在一个自动化用例中用数据驱动的方式进行校验,这一类的预期结果应该都是类似的。接口测试和UI测试不同,接口测试的覆盖范围比UI更易实现覆盖,投入更少,建议在一个用例中用数据驱动的方式全覆盖,收益大于投入。

鱼肚白 #11 · May 30, 2016 作者

#9楼 @isaac 补充一句,我们接口自动化实现数据驱动是用的robotframe的template功能来实现的

#11楼 @1875884881 感谢回复,目前我这边用的是java脚本+Jmeter的形式来做的,一个java方法相当于规定好一个接口的默认参数,然后在Jmeter里添加多个sampler请求来模拟多种参数组合的输入,做了一段时间,感觉维护起来还是工作量略大。打个比方,一个接口有10个入参,每个入参均需校验1、是否为空;2、极大;3、极小; 这样下来,我就需要添加30个sampler请求才能实现这个接口的异常参数校验。 数据驱动大法是好,可以在一个case里实现关于这个参数的各种情况处理,可是即便是你的RF的template,对于这种情况,应该也需要加30个template,感觉还是略微繁琐

鱼肚白 #13 · May 31, 2016 作者

#12楼 @isaac 说实话,正交覆盖100%很不现实的,对于接口参数校验这一块,并不是被测系统的核心逻辑,并且校验方式轻易不会被修改。
按你打的比方,一个接口10个入参(参数有点多,考虑是否可以减少)这个接口自动化设计基于以下考虑
1.有些入参是诸如type这种枚举型或者datetime这种就不存在极大或者极小的问题
2.被测系统代码层的参数校验逻辑是什么,极大极小很多时候都可以规定为等价类
3.核心入参只有几个,重点是对这些参数根据业务逻辑进行设计然后实现自动化
4.template只需要一个,但是数据有很多组,类似下图

对于接口自动化用例,我建议是要结合服务端的代码进行设计的

#13楼 @1875884881 恩,是数据有很多组,我理解错了template的定义。就你说的要结合服务端的代码进行设计,我觉得这样会不会导致自动化覆盖的点不够全面,完全和研发保持步调一致不一定是好事吧?因为研发在coding的时候肯定都是觉得自己想的很全面了,但往往还有漏掉的思维盲区,如果我们测试都跟着代码走,也很容易形成思维惯性吧,默认就觉得代码已经考虑的很全了
在我的用例设计中,基本还是对照PRD和接口文档来做的, 我认为只要保障了PRD里要求做到的点,就是个质量过关的产品了

鱼肚白 #15 · May 31, 2016 作者

#14楼 @isaac 嗯。我建议是要结合服务端的代码进行设计的,知道他的实现方式,不是和研发保持步调一致,而是结合你的场景设计进行验证,验证你自己的想法,用你的场景去覆盖它,这也是测试的价值所在。你也说了:“但往往还有漏掉的思维盲区”,那我们测试可能也存在思维盲区,能了解研发的思维方式不是很好么。
接口用例设计的时候,功能方面一般都是实现了的,但是通过很多次实践已经证明,他们的接口设计会存在漏洞,会导致用户信息泄漏、接口越权、系统漏洞等问题,这些个PRD是保证不了的。比方说:http://www.wooyun.org/bugs/wooyun-2010-046547 这个bug,它已经实现了功能,但是有漏洞而已。还有一些经典的接口bug案例。

哥们 加个QQ交流下吧?我的:515298495

  • 感谢楼主分享;最近也在做接口自动化,但总觉得robotframe做起来碍手碍脚,不如python灵活;
  • 想请问楼主是怎么管理测试用例的,能否分享一些用例的截图~ 不胜感激
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up