老王浅谈接口测试之功能测试

janewash · 发表于 2016-7-11 15:18:29

本帖最后由 janewash 于 2016-7-11 19:04 编辑

最近零零碎碎地读了一些接口测试方面的文章介绍。大多都是关于接口工具的科普，突发奇想，想把自己的工作经验总结一下，主要是针对接口测试的功能测试这一块。很多人将接口测试与功能测试区分开来，这样的区分是欠妥当的。接口是测试的对象，其中包括接口的功能测试，和非功能测试。度量维度是不同的。

为什么要突出讲功能，而不是自动化。一来是因为工作主要内容集中在功能测试上，而不是自动化。二来，在自动化方面，我并不是什么专家，只负责自动化的脚本编写，并不参与框架开发等较为高深任务。

老王所在的公司是一家互联网旅游公司，公司的业务非常成熟，提供的平台也是相当的大，很庆幸地在刚入职时，就加入了一个初创团队，一路走来2年多，不断地推翻重构，才有了这些体会，工作之繁重，比之前四五年之和还要多。

主题是接口测试，但是我们要说的不单单是测试这个动作。在执行动作之外，包含了一系列的前置和后续，有大家熟知的：需求理解（产品PRD），开发文档（接口协议说明文档），测试用例设计，测试执行过程中对测试用例维护与修正，线上监控等等。如此之多的基本要素，不多赘述。

除了以上这些从书本中我们就能轻易获得的方法论之外，还有一些是工作中需要加入的特性要点（maybe针对性太强，而少了些普适性）：

1. 业务逻辑与测试数据

这是老王认为对于接口测试来说尤为重要的一环。一组好的测试数据，每一个数据点都有它在用例中的意义。而对于接口组来说，数据处理（逻辑分支处理）是其的主要职责。

举个例子（简化抽象了的一个业务流程）：

机票预订流程：前端（数据展示）-查询组（数据的第一步处理）-下单（数据的第二步处理）-订单（数据落地）

任务：机票部门对机票中儿童节点属性进行修改，需要调用方进行回归验证。

任务分析：

a. 从流程上来说，大家需要验证的是儿童成功预订机票；

前端：儿童相关属性正确显示，例如机票的价格，儿童的退改签等。

查询组：儿童机票能顺利查询出来，并且吐给前端与下单接口。

下单组：从查询接口获取儿童机票数据，并通过验舱验价处理，进行下单。

订单组：儿童机票订单中的信息与前端展示的一致，包括价格、退改签、航班基本信息等等。

b. 那么问题来了，这样就算回归验证通过了吗？

显然不是，数据属性，结合业务的逻辑，可以扩充出多个场景，脱离数据的业务场景回归，最多就是冒烟测试的层次。

挖掘例子中的数据，我们需要分析的是儿童大节点下有多少个子节点，每个子节点是否有特殊的逻辑分支，碰巧的是：真的有。例如儿童机票节点下有2个节点ApplyChild和Issupportchild。第一个节点表示儿童是否可以享受成人的价格，第二个节点表示这个机票是否有儿童价格。

c. 结合流程用例和数据特性。我们可以把针对这2个判断条件的逻辑扩充如下：

TC_No	ApplyChild	IsSupportChild	Action
1	T	T	判断儿童价与成人价哪个便宜
2	T	F	使用成人价格
3	F	T	使用儿童价格
4	F	F	儿童不可预订此航班

结合这张表格，我们现在至少有了4个测试用例。这4个用例，不仅仅针对查询接口的，详情如下：

前端：至少3个场景：

儿童显示儿童价格+儿童退改签；

儿童显示成人价格+成人退改签；

儿童预订不存在指定航班

查询接口：

儿童有儿童价且有成人价，儿童价<成人价，吐出儿童价；

儿童有儿童价且有成人价，儿童价>成人价，吐出成人价；

儿童只有儿童价，吐出儿童价；

儿童只有成人价，吐出成人价；

儿童无可用价格；

除以上场景之外，还有一些反面用例，不做赘述

下单接口：

查询组传递儿童价；下单使用儿童价

查询组传递儿童价；下单使用成人价

下单接口根据自己的内部逻辑，也可以分出其他场景；

订单：

前端-下单，验证机票儿童下儿童价成功，落地儿童退改签；

前端-下单，验证机票儿童下成人价成功，落地成人退改签

以上例子简单地说了测试数据在测试中起到的作用，而作为整个流程中的一环，接口测试组需要向上游以及下游传递出的信息是：我们的逻辑分支可能出现几种场景，每种场景的入口数据，和出口数据分别是什么。

PRD的业务逻辑中，包含了对测试数据的处理，但PRD通常不会写的面面俱到，而我们可以通过分析测试数据与逻辑分支，来辅助大家进行需求评审，增加测试用例的覆盖度。如果说业务逻辑是测试用例框架的骨骼，那么测试数据就是流动于其中的血液。

2. 测试边界

测试边界是在集成测试中，需要面对和明确的一个问题。工作中，我们经常会为测试边界的问题所困扰，起因是系统太庞大，逻辑太繁琐。先来做个背景介绍：

我们的接口自底向上分为3层：

最底层：数据层。数据层的作用是获取资源数据，比如机票数据、酒店数据等等。底层接口通常是调用资源部门的openAPI，从其他部门开放出来的接口中，获取到我们能用的资源数据。

逻辑层：将底层资源接口获得的数据，根据我们的产品所要满足的需求，进行计算、过滤等等。

顶层：调用逻辑层接口，并将处理过的资源数据，吐出给接口调用方，比如：前端进行展示，webpage或者H5；比如下单，将用户选择好的数据传过去，进行下单处理等等。

从测试策略上来说，一个业务点的测试，必须是自底向上的方式进行集成的。下面三种场景是我们经常遇到的问题：

a. 最底层是其他部门的openAPI，我们是不是可以略过不测试了呢？理论上来说，的确是这样的。我们假设：资源部门吐出的接口数据是可靠的。但是，我们必须关注测试边界的问题。比如针对某个业务点，数据在录入平台被设置为IsPkgMatch=T，那么当我们去请求IsPkgMatch=T的资源数据时，openAPI的返回数据中，就必须包含该测试数据。

以上这个功能点，其实并非我调用方要测试的任务。而当IsPkgMatch恰巧成为某个业务点的关键字段时，我们还是应该考虑到openAPI的返回结果是否正确，错误的资源数据很可能对上层的逻辑处理有影响。

b. 再举一个例子，前端作为用户动作的模拟方，也是接口的调用方，与接口的请求和返回是息息相关的。通常我们在测试的时候，请求报文是从接口契约中获得，组员进行字段设置，模拟前端传过来的请求，再对返回报文进行验证。这样做的好处是，可以不依赖与前端组的提测日期，进行独立测试。缺点是：当我们的接口返回数据太庞大的时候（通常查询接口的返回都会在几万到十几万行），除了用例本身的关注点之外，很容易忽略其他字段的变化。

因此接口组在进行完本组的测试之后，倘若用例尚未来得及自动化，那么与前端的联调，成了必不可少的内容。一是因为前端发送的是更接近真实的接口请求，二是前端展示更直观。

c. 比如某个change request，要对接口中逻辑层做修改。在逻辑层接口验证通过之后，我们应该很自然地想到顶层作为调用方，应该从调用方的角度，进行集成回归测试。事实也证明集成回归测试这一步是万不能少的。

3. 发布策略

发布策略并不属于测试方法。项目管理中，较大项目的接口发布通常采用灰度发布，具体的作用和操作，百度百科里说的蛮清楚的了。这是一个非常好的质量监控手段。

上面这些是这两年的工作中最深刻的感受。希望对刚刚接触接口测试的测试同学们有所帮助。

呵呵，仅供参考啦。希望大家能多多留言交流。谢谢