软件测试面试之接口测试

我的知乎原文在这里

https://zhuanlan.zhihu.com/p/538210976

服务器接口包含服务端对服务端接口，如项目中RPC接口或dubbo接口，还有面向APP的接口，但是两种接口测试设计的理论都是一样的，只不过测试工具不同，前者可能需要把服务部署到一些开元的框架中以便可以直接在界面上直接提交请求，或者借助于代码来提交，后者由于是面向APP的，可以直接访问，用postman或者Charles就能直接测试了。无论是哪一种接口测试，都需要参考接口文档，同时结合功能去测试，下面以面向APP接口为例分享一下我在项目中常用的接口测试方法，去面试也有用哦~~

一、接口是否使用https协议

首先接口要使用https协议，众所周知http协议是不安全的协议，这个就不多赘述了

二、传输的敏感信息是否加密

比如身份证、银行卡、手机号、姓名等隐私信息是否加密，密码是否采用安全的算法，如简单的MD5加密就是不安全的加密，可能通过彩虹表破解密码

（这部分除了接口的传输要加密外，服务器日志打印也不可以直接打印出来，身份证、银行卡存入数据库的数据也需要是加密的，尤其密码最好加盐）

三、鉴权

鉴权指验证用户是否拥有访问系统的权利，分为横向越权和纵向越权。

纵向越权：指的是一个低级别攻击者尝试访问高级别用户的资源。假设管理员可以访问xxx/admin.html的页面，但是普通管理员不能访问，如果普通管理员在登录后，直接在浏览器中输入xxx/admin.html，如果能访问管理员页面，那么就是纵向越权

横向越权：指的是攻击者尝试访问与他拥有相同权限的用户的资源。某网站每个会员只能自己看到自己的会员信息，会员A在登录后能看到自己页面的内容url为xxx/member.php?id=A，如果A想偷窥B的信息，在浏览器输入xxx/member.php?id=B，如果能访问B的页面，那么就是横向越权

以上举例是修改url，对于post请求，可通过修改请求参数中id等信息来进行测试。修改后的请求参数可以用postman提交，也可以用Charles打断点拦截请求来修改参数。

四、幂等

接口幂等就是用户对同一操作发起了一次或多次请求的对数据的影响是一致不变的。比如在支付系统中，我们对某订单进行了支付，如果客户端没有拿到服务端订单状态，可以再次到支付入口进行支付，如果支付成功就导致了重复支付，就造成了资损，那么这个接口就不符合幂等，也可以通过postman重复提交支付请求，看同一订单是否能多次支付成功。

（除了服务端可以做幂等，客户端也可以做防重，比如表单的提交，如果因为网络问题页面没有及时跳转，用户点了两次提交，客户端就可以做重复判断，阻断第二次请求的提交）

五、多接口依赖

服务器的接口多具有依赖性，如会员想看到自己登录后的页面，就必须经过登录，密码登录或是验证码登录。可尝试直接拼接参数去访问后面的接口，看是否能绕过登录。另外还需要注意，如果是验证码登录，请求验证码后，验证码不可以作为返回参数返回，否则就可窃取别人的验证码了。

六、边界值测试

大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内。测试输入除了在输入范围内的值，还需要覆盖小于左边界的值里最靠近左边的值，左边界，大于左边界的第一个值，小于右边界的值里最靠近有边界的值，右边界，大于有边界的第一个值

七、必传/非必传参数，非空参数校验

接口一般会约定必传和非必传参数，我们可以入参里逐个去掉必传参数、将非空参数置空，接口需要报对应的粗错误，还有不传非必传参数，不应该引起接口报错等。尤其是对于被业务方接入的系统，如账户系统，几乎每个业务都可能调用登录，那么就需要建立登录接口的规范以便业务方的接入。

八、验签

攻击者可能篡改接口中请求参数再向服务器发起请求，服务器需要识别参数的篡改，这个识别的过程就是验签。举例：攻击者在某商城下了两笔订单，订单A的金额为1000元，订单B为1元，两笔都是待支付状态，攻击者已经通过抓包获取到了支付接口的请求参数，在支付B订单时，攻击者将请求参数中的订单号篡改成了A订单，最终可能导致用1元支付了A订单。在订单生成的接口，服务器可对请求参数加签，返回给客户端，客户端将得到的签名赋给sign作为支付接口的请求参数再提交给服务端，然后服务端和调用支付接口过来的参数比对，不一样就是验签失败，非法请求。

九、数据单位测试

客户端和服务端需要约定好数据的单位，比如和金额相关的接口约定好是分还是元，如果约定的是元，客户端是否会传0.1，0.10，1.00， 1.0， 1的情况，服务端是否又能应对这些情况，给出正确的返回

十、对于任何接口异常，客户端都需要展示对应的用户页面

1、服务端需要对错误进行转码再返回给客户端

上游服务器如果出现错误，处理客户端请求的服务器需要处理错误，转成和客户端定义好的错误码。测试的时候可以关闭或重启上游服务，然后客户端发起请求，看服务器应对情况

2、客户端需对所有错误都有用户错误页面

APP应该对所有接口都有超时处理，给用户展示统一的错误页面。服务器的出错不能直接展示给用户，可以修改响应未客户端不能识别的格式，看客户端是否会处理。

以上为我工作中常用的接口测试方法，后面可能会再更新一个关于支付系统测试的，请持续关注，如果觉得对你有帮助可以点个赞哦~~转载请注明出处~~

已更新支付系统测试_houge呀的博客-CSDN博客