227 lines
11 KiB
Markdown
227 lines
11 KiB
Markdown
---
|
||
title: 了解接口测试
|
||
date: 2020-06-24 11:25:09
|
||
tags: [接口]
|
||
categories: [接口测试]
|
||
author: Anges黎梦
|
||
---
|
||
## 什么是API（接口）？
|
||
|
||
> API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
|
||
|
||
看概念不得不很清晰的看得到，接口其实就是实现某种功能的能力。
|
||
|
||
比如，下单接口 -> 生成订单；编辑用户接口 -> 修改用户数据
|
||
|
||
这些对外暴露的接口，往往是为了某一个功能而做的具体实现。
|
||
|
||
当然，这只是对外接口。
|
||
|
||
那么接口有没有对内的接口呢？
|
||
|
||
答案当然是有！
|
||
|
||
对内的接口，当今比较流行的，其实是微服务架构中的内部接口。
|
||
|
||
这里我们举个例子来说明。
|
||
|
||
A 是一个商城服务，管理一些商品信息。
|
||
|
||
B 是订单服务，管理订单相关的信息。
|
||
|
||
如果要通过A服务下一笔订单，这个时候就需要用到B 订单服务中的一些功能。
|
||
|
||
他们如果也用对外的接口来进行通信，先不说效率如何，首先，他们之前的安全性就没有很高。
|
||
|
||
这个时候就需要内部接口。
|
||
|
||
微服务中的对内接口，一般是以RPC为通信协议的接口。
|
||
|
||
当然也不是说就没有其他协议的接口了。这个在用到的时候大家可以去详细了解一下。
|
||
|
||
## 为什么要做API（接口）测试？
|
||
|
||
接口测试一般会用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。
|
||
|
||
接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比，接口测试天生为高复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
|
||
|
||
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
|
||
|
||
不是所有的团队都可以在一个隔离的测试环境中进行测试工作的，因此使得对外部接口的测试显得困难。我们应该确保较早地与相关的组织协调好并确定进行外部接口测试的方案。有时候相关的组织只是人工的静态的审阅一次数据而并不真正的用这些数据来测试。等等这些都增加了实际测试执行中遇到的风险，但有些时候是可以避免的。
|
||
|
||
## API（接口）测试需要测试哪些内容？
|
||
|
||
|
||
|
||
一说接口测试，大家通常的反应都是请求参数和响应参数的测试。
|
||
|
||
但是实际的接口测试真的只是这么简单吗？
|
||
|
||
当然不是。
|
||
|
||
接口测试中对请求参数和响应参数的测试，只是其中必须的一部分。
|
||
|
||
参数相关的测试，可以按照接口文档中的参数，组合成任意想要的组合，进行测试。
|
||
|
||
那么接口测试他本身是通过接口，实现一个功能。功能相关的内容也是要测试的。
|
||
|
||
比如，接口中涉及的业务场景、细节功能。
|
||
|
||
这个功能中涉及到的数据变化，是不是也要加入我们的测试点中呢？
|
||
|
||
那是一定的。
|
||
|
||
这个数据有可能还会涉及到数据库、缓存，数据上的一些分析，关联数据变化等等等等。
|
||
|
||
除了这些还有没有其他的测试点呢？
|
||
|
||
有的。
|
||
|
||
从后端的角度上讲，每一个接口，都会他相对应的事物控制。
|
||
|
||
事物控制可以更好的接口优化一些细节功能，比如，同一个用户，在一定时间段内只能有一个有效请求。
|
||
|
||
这些并不是在前端限制就可以限制不会出错的。
|
||
|
||
另外还有一些很多研发不会注意的问题，比如参数认证等。
|
||
|
||
同时，除了以上问题之外，日志安全其实也可以包含在接口测试中。
|
||
|
||
每一个接口，在日志打印时，打印了哪些数据。
|
||
|
||
是否包含敏感信息，日志是否符合规范等。
|
||
|
||
而且，接口性能也可以在接口测试中完成。
|
||
|
||
`注：接口性能不等同于平常所说的性能测试。
|
||
`
|
||
综上所述，接口测试并不是单纯的出参和入参的测试。
|
||
|
||
## 如何来做API（接口测试）
|
||
|
||
### 如何编写接口测试用例
|
||
|
||
其实接口测试用例与功能测试用例没有什么区别，设计测试用例的方法也不近相同。
|
||
|
||
只不过功能测试用例，完全通过功能上的表现，来判断是否通过。
|
||
|
||
接口则是通过返回值，和其他的技术手段来判断是否通过。
|
||
|
||
那么在接口测试用例中，我们就要写明校验相关的内容了。
|
||
|
||
例如：返回值校验中有数据校验的，那么就需要把相关sql写入测试用例。
|
||
|
||
### (1)正常用例的设计方法。
|
||
|
||
具体是指根据该接口实现的功能分析出该接口的正常用例包括哪几种输入参数的组合，
|
||
|
||
从而在用例中构造相应的参数组合来覆盖所有的正常分支。
|
||
|
||
输入参数分为两种类型，一种是可以直接赋值的，这种参数直接赋值即可，
|
||
|
||
另一种参数是其他接口调用的输出参数，无法直接给出，
|
||
|
||
这种参数就需要在调用被测接口前先调用其他接口，将其输出参数作为被测接口所需要的输入参数传入，
|
||
|
||
或者事先将所需要的参数数据写入文件中，通过读取文件的方式获取输入参数的数据。
|
||
|
||
对接口输入参数的组合，一是需要根据自然逻辑进行排列组合，排除无效的组合，
|
||
|
||
以及将可以划分等价类的组合进行合并同类项，控制用例总数，避免冗余重复的用例耗费测试资源。
|
||
|
||
同时还应从业务上分析有没有特殊的组合是没有考虑到的，此类用例往往不止涉及单一接口，
|
||
|
||
而是涉及到根据某个特定业务流程而产生的接口调用流程，通过接口调用的方式模拟关键业务流程，
|
||
|
||
可以在不用搭建辅助测试环境的情况下单纯的测试被测接口，去除测试环境复杂性对测试结果的影响，
|
||
|
||
极大提升测试效率。
|
||
|
||
比如，要测试该接口涉及到的某个特定关键业务流程，
|
||
|
||
有两种方式覆盖测试，
|
||
|
||
第一种方式是搭建真实的测试环境，将该业务流程涉及到的所有模块，设备，软件全部准备到位，
|
||
|
||
然后进行业务流程测试，此种测试的优点是最大程度还原了用户真实业务使用场景，
|
||
|
||
缺点是出现异常极难定位问题原因到底是出在被测接口上，还是其他陪测设备或软件上，
|
||
|
||
或者是几者之间的衔接出了问题。
|
||
|
||
第二种方式则是刚才提到的通过调用接口模拟业务流程来覆盖业务测试的方式，
|
||
|
||
这种方式不需要额外搭建测试环境，只需要通过编写脚本的方式进行接口调用，来测试业务流程即可，
|
||
|
||
虽然会花费一些人力成本编写脚本代码，但测试结果直观，出现问题后便于定位解决。
|
||
|
||
还有一种情况会明显体现出这种业务测试方法的优势，就是不同型号的设备或软件都有类似业务流程，
|
||
|
||
测试该接口只需保证接口的业务流程测试通过，就可判断如果实际业务流程出问题，
|
||
|
||
多半是出在其他产品或者产品之间的衔接上，错误定位成本可控。
|
||
|
||
一个完整的用例，除了输入参数的组合，还包括接口执行结果的预期值，
|
||
|
||
预期值也包括两部分，一个是接口调用本身的返回值，该返回值反映了该接口调用结果是成功还是失败，
|
||
|
||
一般来说，结果为0表示执行成功，非0则表示执行失败。非 0 的值一般是事先定义好的错误码，
|
||
|
||
提示接口调用失败的原因，便于用户进行故障诊断。大部分接口的参数除了输入参数外，
|
||
|
||
还包括输出参数，对于正常用例的输出参数也需要在用例中明确写出预期值，作为用例是否成功执行的依据。
|
||
|
||
### (2)异常用例的设计方法。
|
||
|
||
异常用例的设计一般采用以下方法。
|
||
|
||
选取一条正常用例的数据作为基础数据，然后遍历所有的输入参数，针对每一个输入参数，
|
||
|
||
分别使用等价类法，边界值法等用例设计方法枚举出该参数的所有异常值，
|
||
|
||
该用例除了该参数为异常外，其余参数均保持正常值不变，以保证测试结果仅由异常的那一个参数导致。
|
||
|
||
当所有输入参数都使用上述方法设计了对应的异常用例之后，
|
||
|
||
进一步补充不方便在用例文件中输入的异常参数到测试脚本中，
|
||
|
||
通过 switch 分支判断，在测试脚本中将无法通过文件读取的异常输入值（如：错误指针等），
|
||
|
||
直接赋值给接口的输入参数，测试某些指针类型的数据错误是否被及时捕获并返回正确无歧义的错误码。
|
||
|
||
异常用例的设计需要注意的是以下几点：
|
||
|
||
首先，接口应在任何时候都返回错误码，而不能存在未经处理，直接导致调用接口的程序异常退出，
|
||
|
||
或者将底层错误信息直接返回给上一层调用程序。
|
||
|
||
调用程序异常退出会给用户非常不好的用户体验，同时，无法进行故障诊断和错误定位，
|
||
|
||
而未经处理的底层错误信息直接返回给调用程序，有可能将不应被用户知晓的数据信息返回给用户，
|
||
|
||
比如数据库相关信息，造成可能被攻击的漏洞或安全隐患。
|
||
|
||
其次，错误码的准确性很重要。错误码的准确性对接口调用失败原因的定位有非常重要的意义，
|
||
|
||
将极大降低后续维护成本，错误码的设置应当准确，无歧义，一种错误类型一个错误码，
|
||
|
||
尽量将错误码编得更细，更有利于错误排查。
|
||
|
||
比如：参数长度错误和参数类型错误应当为不同的错误码，而不应该是统一的参数错误的错误码。
|
||
|
||
同时，错误码应当在接口设计文档中有明确定义，并且在不同接口中保持一致。
|
||
|
||
一个很好的测试用例设计过程应该是建立在前期深入的需求分析和文档设计的基础之上。
|
||
|
||
需求分析得越深入全面、文档描述越详细清晰，则设计的接口测试用例就会越全面，越能暴露出接口的缺陷，
|
||
|
||
从而提供出高质量的服务接口。并且在后续接口维护过程中，有详尽的接口设计文档作为支撑，
|
||
|
||
也可以降低维护成本
|
||
|
||
## 附录
|
||
|
||
[常见HTTP状态码](http://www.angeszhu.cn/auto/api/http-status.html)
|
||
|
||
[RestFul接口规范](http://www.angeszhu.cn/auto/api/restful-info.html)
|