本帖最后由 janewash 于 2016-7-11 19:04 编辑
最近零零碎碎地读了一些接口测试方面的文章介绍。大多都是关于接口工具的科普,突发奇想,想把自己的工作经验总结一下,主要是针对接口测试的功能测试这一块。很多人将接口测试与功能测试区分开来,这样的区分是欠妥当的。接口是测试的对象,其中包括接口的功能测试,和非功能测试。度量维度是不同的。 为什么要突出讲功能,而不是自动化。一来是因为工作主要内容集中在功能测试上,而不是自动化。二来,在自动化方面,我并不是什么专家,只负责自动化的脚本编写,并不参与框架开发等较为高深任务。 老王所在的公司是一家互联网旅游公司,公司的业务非常成熟,提供的平台也是相当的大,很庆幸地在刚入职时,就加入了一个初创团队,一路走来2年多,不断地推翻重构,才有了这些体会,工作之繁重,比之前四五年之和还要多。 主题是接口测试,但是我们要说的不单单是测试这个动作。在执行动作之外,包含了一系列的前置和后续,有大家熟知的:需求理解(产品PRD),开发文档(接口协议说明文档),测试用例设计,测试执行过程中对测试用例维护与修正,线上监控等等。如此之多的基本要素,不多赘述。 除了以上这些从书本中我们就能轻易获得的方法论之外,还有一些是工作中需要加入的特性要点(maybe针对性太强,而少了些普适性): 1. 业务逻辑与测试数据 这是老王认为对于接口测试来说尤为重要的一环。一组好的测试数据,每一个数据点都有它在用例中的意义。而对于接口组来说,数据处理(逻辑分支处理)是其的主要职责。 举个例子(简化抽象了的一个业务流程): 机票预订流程:前端(数据展示)-查询组(数据的第一步处理)-下单(数据的第二步处理)-订单(数据落地) 任务:机票部门对机票中儿童节点属性进行修改,需要调用方进行回归验证。 任务分析: a. 从流程上来说,大家需要验证的是儿童成功预订机票; 前端:儿童相关属性正确显示,例如机票的价格,儿童的退改签等。 查询组:儿童机票能顺利查询出来,并且吐给前端与下单接口。 下单组:从查询接口获取儿童机票数据,并通过验舱验价处理,进行下单。 订单组:儿童机票订单中的信息与前端展示的一致,包括价格、退改签、航班基本信息等等。 b. 那么问题来了,这样就算回归验证通过了吗? 显然不是,数据属性,结合业务的逻辑,可以扩充出多个场景,脱离数据的业务场景回归,最多就是冒烟测试的层次。 挖掘例子中的数据,我们需要分析的是儿童大节点下有多少个子节点,每个子节点是否有特殊的逻辑分支,碰巧的是:真的有。例如儿童机票节点下有2个节点ApplyChild和Issupportchild。第一个节点表示儿童是否可以享受成人的价格,第二个节点表示这个机票是否有儿童价格。 c. 结合流程用例和数据特性。我们可以把针对这2个判断条件的逻辑扩充如下: 结合这张表格,我们现在至少有了4个测试用例。这4个用例,不仅仅针对查询接口的,详情如下: 前端:至少3个场景: 儿童显示儿童价格+儿童退改签; 儿童显示成人价格+成人退改签; 儿童预订不存在指定航班 查询接口: 儿童有儿童价且有成人价,儿童价<成人价,吐出儿童价; 儿童有儿童价且有成人价,儿童价>成人价,吐出成人价; 儿童只有儿童价,吐出儿童价; 儿童只有成人价,吐出成人价; 儿童无可用价格; 除以上场景之外,还有一些反面用例,不做赘述 下单接口: 查询组传递儿童价;下单使用儿童价 查询组传递儿童价;下单使用成人价 下单接口根据自己的内部逻辑,也可以分出其他场景; 订单: 前端-下单,验证机票儿童下儿童价成功,落地儿童退改签; 前端-下单,验证机票儿童下成人价成功,落地成人退改签 以上例子简单地说了测试数据在测试中起到的作用,而作为整个流程中的一环,接口测试组需要向上游以及下游传递出的信息是:我们的逻辑分支可能出现几种场景,每种场景的入口数据,和出口数据分别是什么。 PRD的业务逻辑中,包含了对测试数据的处理,但PRD通常不会写的面面俱到,而我们可以通过分析测试数据与逻辑分支,来辅助大家进行需求评审,增加测试用例的覆盖度。如果说业务逻辑是测试用例框架的骨骼,那么测试数据就是流动于其中的血液。 2. 测试边界 测试边界是在集成测试中,需要面对和明确的一个问题。工作中,我们经常会为测试边界的问题所困扰,起因是系统太庞大,逻辑太繁琐。先来做个背景介绍: 我们的接口自底向上分为3层: 最底层:数据层。数据层的作用是获取资源数据,比如机票数据、酒店数据等等。底层接口通常是调用资源部门的openAPI,从其他部门开放出来的接口中,获取到我们能用的资源数据。 逻辑层:将底层资源接口获得的数据,根据我们的产品所要满足的需求,进行计算、过滤等等。 顶层:调用逻辑层接口,并将处理过的资源数据,吐出给接口调用方,比如:前端进行展示,webpage或者H5;比如下单,将用户选择好的数据传过去,进行下单处理等等。 从测试策略上来说,一个业务点的测试,必须是自底向上的方式进行集成的。下面三种场景是我们经常遇到的问题: a. 最底层是其他部门的openAPI,我们是不是可以略过不测试了呢?理论上来说,的确是这样的。我们假设:资源部门吐出的接口数据是可靠的。但是,我们必须关注测试边界的问题。比如针对某个业务点,数据在录入平台被设置为IsPkgMatch=T,那么当我们去请求IsPkgMatch=T的资源数据时,openAPI的返回数据中,就必须包含该测试数据。 以上这个功能点,其实并非我调用方要测试的任务。而当IsPkgMatch恰巧成为某个业务点的关键字段时,我们还是应该考虑到openAPI的返回结果是否正确,错误的资源数据很可能对上层的逻辑处理有影响。 b. 再举一个例子,前端作为用户动作的模拟方,也是接口的调用方,与接口的请求和返回是息息相关的。通常我们在测试的时候,请求报文是从接口契约中获得,组员进行字段设置,模拟前端传过来的请求,再对返回报文进行验证。这样做的好处是,可以不依赖与前端组的提测日期,进行独立测试。缺点是:当我们的接口返回数据太庞大的时候(通常查询接口的返回都会在几万到十几万行),除了用例本身的关注点之外,很容易忽略其他字段的变化。 因此接口组在进行完本组的测试之后,倘若用例尚未来得及自动化,那么与前端的联调,成了必不可少的内容。一是因为前端发送的是更接近真实的接口请求,二是前端展示更直观。 c. 比如某个change request,要对接口中逻辑层做修改。在逻辑层接口验证通过之后,我们应该很自然地想到顶层作为调用方,应该从调用方的角度,进行集成回归测试。事实也证明集成回归测试这一步是万不能少的。 3. 发布策略 发布策略并不属于测试方法。项目管理中,较大项目的接口发布通常采用灰度发布,具体的作用和操作,百度百科里说的蛮清楚的了。这是一个非常好的质量监控手段。
上面这些是这两年的工作中最深刻的感受。希望对刚刚接触接口测试的测试同学们有所帮助。 呵呵,仅供参考啦。希望大家能多多留言交流。谢谢
|