接口测试常用测试点
转载:https://www.cnblogs.com/fireporsche/p/9949805.html
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
测试的策略:
接口测试也是属于功能测试,所以跟我们以往的功能测试流程并没有太大区别,测试流程依旧是:
-
评审测试接口文档(需求文档)
-
根据接口文档编写测试用例(用例编写完全可以按照以往规则来编写,例如等价类划分,边界值等设计方法)
-
执行测试,查看不同的参数请求,接口的返回的数据是否达到预期
那么设计测试用例时我们主要考虑如下几个方面:
功能测试:
-
接口的功能是否正确实现了
-
接口是否按照设计文档中来实现(比如username参数写为了user,那么这就不符合,因为接口文档在整个开发中都需要使用,所以接口实际的设计要与接口设计文档中保持一致)
-
兼容性测试: 比如说今天接口进行了调整,但是前端没有进行变更,这时候需要验证新的接口是否满足旧的调用方式
-
错误码测试: 通用的错误码与业务错误码是否能够清晰的说明调用问题,错误码是否能够尽可能的全的覆盖所有的情况
-
返回值测试: 返回值除了内容需要是正确的,还需要类型也是正确的,保证调用方拿到这些参数能够正确的解析
-
参数边界值、等价类测试
-
json格式测试: 通常我们的接口一般设计的都是传递json串,那么就需要去测试 如果传递非json的情况,这时候程序会不会正确的处理,返回相应的 error code
-
默认值测试: 很多情况一些非必填的参数会有默认值,比如说一个查询的接口,参数count为返回查询的结果数量, 默认为10,那么就应该有一条case来测试,当然前置条件是数据库里面必须要存在这样的数据超过10条。
逻辑业务:
-
是否有依赖业务,比如查看订单,是需要用户首先登录的,所以肯定要保证登录了或有相应的cookie
-
业务逻辑测试: 传递正确的参数,接口对数据库进行查询的操作,需要去验证数据库查询是否正确,接口对数据库进行 增删改的操作,也需要看数据库是否同步进行了这些操作
异常测试:
异常分为两类,参数异常和数据异常
参数异常:
-
关键字参数:将参数写为开发语言中的关键字
-
参数为空:比如去掉了username参数
-
多或少参数:多或者少参数的验证,现在还不确定如果一个接口多了参数如果没有报错是否是合理的,或者是否需要优化,因为就目前开发给予的答案是,一般不对接口多了参数的处理
-
错误参数:比如将username参数写为了user等看是否能返回相应的error code
数据异常:
-
关键字数据:将参数的值填为开发语言中的关键字
-
数据为空:将参数的额值填为空
-
长度不一致:因为数据库中每个字段都设置有字段长度,填写不符合的长度进行验证
-
错误数据:就是将参数的值任意填写,或填写不存在的数值
- 异常类型测试: 比如count参数,这个参数的类型一定是可以转换为int类型的,这时候我们需要测试如果传的一些不可以 转换为int类型值来测试代码是否加入判断
性能测试:
-
响应时间
-
吞吐量
-
并发用户数
- 占用内存,CPU等
安全性测试:
-
敏感信息是否加密
-
必要参数是否后端也进行校验(现在很多系统前后端架构是分离的,从安全层面来说,只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前端太容易了), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证)
-
接口是否防恶意请求(SQL注入)
-
cookie:就是将header中的cookie修改或删除后看是否能返回相应的error code
-
header:就是删除或修改header中部分参数的值,看是否能返回相应的error code
-
唯一识别码:删除修改唯一识别码测试