web接口测试总结

上一篇 / 下一篇  2015-06-09 20:00:02 / 个人分类:接口测试

                          web接口测试总结(转载请注明)
                                        
        面试中我偏爱问的一个问题是这样的:"接口测试(仅限controller层,不设计service和dao层接口)有什么用,应该怎么做?"。答案当然五花八门,有根本不做的、有模式化的模拟发送请求查看响应体是否符合接口文档的、有把接口中每个参数都修改后排列组合重新发送的。我之所以问这个问题是想从各个公司各类人的测试观点中提取可用之处,但是几乎没有遇到过相对新颖和高效的观点。
下面阐述我所理解的接口测试。


Q:接口测试是什么?
我认为接口测试是功能测试不可或缺的一部分,抛开了UI层的逻辑和限制对于服务端的功能进行了完整的测试。


Q:接口测试有没有作用?
当然有用,而且作用很大。从接口测发起的测试弥补了界面测试的遗漏点。界面测试起码遗漏了 1.接口参数校验 2.接口参数组成 3.响应消息体。能将接口测试纳入功能
测试的一部分并且完成,我想已经脱离了初级工程师这一范畴,测试的完整性得到了很大的提高。


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

图一图二是一个请求消息头与消息体(如果消息头消息体搞不清的话,先去恶补http知识先),请求消息中的每个字段都有意义且可以更改,这个现象就很有意思了,测试人员应
当如何去操作这个请求消息呢?

第一步:【看】
(a)看接口的访问方式是get、post、或者上传文件图片
(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中传输某些信息,也是值得关注的测试点。

下班了,先写到这。

TAG: 接口

 

评分:0

我来说两句

我的栏目

日历

« 2024-03-28  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

我的存档

数据统计

  • 访问量: 6566
  • 日志数: 7
  • 建立时间: 2015-06-09
  • 更新时间: 2015-06-09

RSS订阅

Open Toolbar