认识达内从这里开始

接口测试是程序员在做软件测试的时候会经常用到的一种测试方式，今天我们就通过案例分析来简单了解一下，接口测试实践需要关注哪些问题。

接口信息来源

与界面功能测试相比，除了要明确需求和测试目标之外，接口测试还需要有针对性地去设计测试数据和接口的组合，确定接口信息通常有两条路径，一是通过接口文档获取，二是通过接口抓包获取。

接口文档

开发人员一般不喜欢写接口文档，同时也讨厌别人不写接口文档，就像程序员一般不喜欢写注释，同时也讨厌不写注释的代码，所以测试人员想要获取一份相对完善的接口文档有时是比较麻烦的，这就需要驱动开发人员提供，这对于开发人员来说并不困难。

统一的接口文档管理方式也是比较多的，比如：在wiki上创建一个接口文档目录空间专门用于维护接口信息、系统后台管理中有专门的接口文档模块、在需求单子下面备注、使用apifox工具进行接口文档的维护管理等。

抓包

如果没有接口文档，那就只能自己动手丰衣足食，通过抓包分析的方式来获取接口信息，常见的抓包工具比如：浏览器F12、Fiddler、Charles等，还可以把Fiddler抓到的接口导出，通过工具转成接口平台可识别的脚本，进而提高效率。

在获取到接口信息后，还需要与开发人员多进行交流，明确接口参数的含义和来源，以便于我们有针对性地进行用例的设计，有不明确的点应当直接找开发同学问清楚，而不应该自己过多的猜想，避免自己的猜想有误造成后续用例设计的错误。在此阶段，还需梳理接口的优先级和重要程度，根据优先级顺序进行用例设计，在有限的时间内，做大价值的事。

单接口测试

单接口测试主要验证接口的请求地址、请求类型、请求格式、请求参数、权限、返回值等为主，目的是保证接口能跑通，这类用例一般在接口设计完成后定稿，使用过程中可配合Mock服务完成用例编写。

场景逻辑验证

场景逻辑验证是以用户场景为基础，验证接口间的参数传递和业务流程是否能够正常流转，比如：用户注册接口-->用户登录接口-->修改用户信息接口，使得业务流程形成闭环。

这个阶段的用例复杂度较高，需要非常熟悉业务与接口之间的关系，同时也是接口测试的核心部分、有价值的部分。

异常测试

与界面功能测试类似，除了测试各种正常场景外，还需要验证各种异常情况，主要验证参数异常，比如：某个参数的类型是String，当你传入其他类型时是否会报错并给出提示;某个参数的长度限制200个字符，当超过200个字符时是否给出提示;某个参数是必填，当不传为空时是否有非空判断。还需要验证逻辑异常等情况下接口是否能够处理并给出友好的提示信息、提示是否准确清晰以及返回的信息是什么。通常情况下，关注参数的异常场景会比较多，可以用等价类、边界值等方法进行传参的设计。

尽量自动化

所有用例应该是非交互式的，能自动化就不要手动去获取。常见的就是token的获取，获取token的方法也有很多种，常用的就是通过调用登录接口获取返回值中的token，用于后续接口的鉴权，还有一些开放平台接口，token有特定的生成规则，就可以将其写成脚本自动生成token，而不是每次执行测试用例之前，需要手动生成token再复制粘贴到脚本中，特别是分环境测试时就会很麻烦，而且token一般是有有效时间的，写成自动化脚本，每次都获取都是新的，就不用担心token过期的问题了。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。