|
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。接口测试大体分为两类：模块接口测试和 web 接口测试。
模块接口测试
模块接口测试是单元测试的基础。它主要测试模块的调用与返回。经常需要编写一些桩模块与驱动模块。
主要测试要点如下：
检查接口返回的数据是否与预期结果一致。
检查接口的容错性，假如传递数据的类型错误时是否可以处理。
接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。
接口的性能，接口处理数据的时间也是测试的一个方法。牵扯到内部就是算法与代码的优化。
接口的安全性
WEB 接口测试
web 接口测试又可分为两类：服务器接口测试和外部接口测试。
服务器接口测试：是测试浏览器与服务器的接口。用户输入的数据是输入到的前端页面上，怎样把这些数据传递的后台的呢？通过 http 协议的 get 与 post 请求来实现前后端的数据传递。这也可认为是接口测试。
外部接口测试：这个很典型的例子就是第三方支付，比如在我们应用中在充流量时，交话费时，都会调用第三方支付接口。
主要测试要点如下：
请求是否正确，默认请求成功是 200，如果请求错误也能返回 404、500 等。
检查返回数据的正确性与格式；json 是一种非常常见的格式。
接口的安全性，一般 web 都不会暴露在网上任意被调用，需要做一些限制，比如鉴权或认证。
接口的性能，这直接影响用户的使用体验。
测试用例设计与原则
因为在实际工作中测试的接口都是基于 HTTP 协议的，所以下面的测试用例及原则也是针对此类接口。
测试用例
正面测试用例：
覆盖所有的必选参数
组合可选参数
参数边界值
如果参数的取值范围是枚举变量，需要覆盖所有枚举值
还应考虑实际业务应用场景，去设计输入参数的组合。（这些用例可用来测试功能，作为 SMOKE 用例。也可将来用于压力测试模拟实际业务场景，但要注意保证用例的独立性，因为压力测试是多线程的。比如我们测试 ACCOUNT 创建接口，NAME 是不能重的，在写测试用例时，给 NAME 赋值时可以加一个时间戳, 这样用例在多线程并发测试时也不会有问题）
负面测试用例：
空数据
包含特殊的字符
越界的数据
错误的数据
验证点：
status code（正常情况下，所有请求都应该返回 200）
响应信息数据结构（目前大多数情况下，返回信息都是 JSON, 我们应该验证相应的结构当数据信息发生改变时）
验证结点的类型
验证结点的值（主要是针对固定的值或者值遵循某些规则，我们能知道预期的结果的）
对于列表，应该根据请求参数，也应该验证列表的长度是否与期望值一致
负面测试用例，应验证 ERROR INFO 是否与实际相匹配
测试原则
测试应该是独立的、可读的、抗变的、可维护的，其实这也是所有自动测试应该遵循的原则
每个测试用例都是独立的
测试用例都是可重复运行的 (这主要是说一些测试数据不能写死，不同的环境数据可能不同。在实际工作中，解决方案有二：自已创建所需要的数据，比如你要测试接口需要输入参数 ACCOUNTID,你可以先调用创建 ACCOUNT API, 然后从响应值拿到 ACCOUNTID, 当你测试完你要测的接口后，再把新建的 ACCOUNT 删除，也就是说一个测试用例分了三步。另外一种方法就是读取数据库，从数据库获取数据，这种方法在测试开发与测试环境还 OK，但如果测线上环境就比较困难了，因为我们不能随意更新上面的数据，也不能放过多的测试数据在上面。因此我个人比较推崇第一种方法，虽然增加开发用例的工作量，但一劳永逸）
测试能被运行在不同的环境里（平常测试环境至少会分 DEV/TEST/STAGING/ONLINE，我们在测试过程中，应该把域名，token/apikey 等应放在一个变量里，当切换环境时，我们只需改变变量的值即可
测试数据与业务相分离（测试数据包括参数接口数据/ 测试执行所需要的系统数据)
尽量统一共用的测试环境变量
测试完成后，要删除不必要的测试数据。
|