接口测试理论与实践 ——PiTest + GT双管齐下,专治各种接口测试

最近做接口测试比较多,这里做一个小小的总结,也可以帮助接口测试的同学快速上手。

首先,在做接口测试前,我们来想一想:

接口测试是什么?——含义

接口测试测什么?——对象

接口测试怎么测?——方法

【接口测试是什么】——含义

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等

这里给了我们启示,在接口测试中我们需要重点关注的是:数据+逻辑

数据:参数,返回值,过程中的数据流

逻辑:正常逻辑,异常逻辑,单一逻辑,组合逻辑。

【接口测试测什么】——对象

(1) 测试参数——关注鲁棒性

接口测试中调用方唯一可见的就是接口参数,所以接口不仅仅只需要处理正确的数据,而且应该对各种异常的参数进行容错处理,增强接口本身的鲁棒性,从而提高系统稳定性。

常用参数测试方法: 边界值、等价类。

(2) 测试逻辑——关注是否符合需求

接口测试的最主要目的就是为了测试接口是否能够提供所期望的功能逻辑,所以在有预先设定的输入后,测试接口函数的执行结果是否正确。通常接口会被外部各种场景下调用,所以,测试接口在简单场景下的表现和复杂场景下组合调用的表现都是测试人员需要关注的。

通常情况下很多被测接口返回值只是简单的“是”与“否”,但是作为测试人员,我们关注点不应该仅限于返回值,还应该观察返回接口导致的上层变化,最直观的就是UI逻辑,是否符合接口需求中所定义的那样。

常用参数测试方法: 假设场景法、错误推测法

【怎么做接口测试】——方法

1、 接口测试可理解为如下过程:

数据准备☆☆

这里包含了上一部分提到的正常参数和异常的参数的准备。

触发接口☆☆☆

通常接口的触发依赖于被测接口的实现。举个例子:被测接口是一个简单的功能函数,触发接口即为在测试代码中调用被测函数;若被测接口是一个回调函数,触发接口则为包含触发事件的测试代码;再如被测接口是一个Handler处理消息,触发接口则为发送对应的消息。

观察结果:☆☆☆☆

(1) 观察返回值:可以知道接口是否执行,执行返回值是什么,一方面便于测试人员判断触发接口是否生效,另一方面方便测试人员粗略判断接口执行结果。

(2) 观察接口执行的现象:包括了数据流和UI变化

数据流可以方便测试员判断接口执行的进度,数据流的观察方法包括了查看Log和数据库变化等一切因接口调用而引起的数据变化的查看方法。

UI变化即用户层的执行结果。当然有的接口执行可能不会引起UI的变化,所以观察重心应该在数据流上。

测试代码编写原则:☆☆☆☆

1、 尽量减少对主线代码的修改。

——防止被测接口的变更而影响测试代码。

2、 降低测试代码和主线代码的耦合度。

——增强测试代码的独立性。

3、 测试代码的动态性,可动态调整测试用例

——方便各种用例的组合时(如配置参数,组合用例)不需修改测试代码

2、接口测试的工具

目前市面上的接口测试工具也是五花八门,当然包括开源的Junit、TestNG和腾讯自研工具,如手机管家PiTest插件。总体来说这些工具都是大同小异,这里不做详细介绍。

案例分享:PiTest + GT双管齐下,专治各种接口测试

背景:FT需要提供一个接口供给其他外部FT传递数据,用于我们自己做显示。

问题:如何在外部FT接入之前,自身保证接口的可用。

方案一:采用PiTest插件做mock测试

之前的文章有谈到在缺少事件、数据的时候我们可以自己来mock,具体可参考《手机管家Pitest辅助测试方法分享》。当然这是一种可行的方法,测试过程可以描述为:

(1) 使用PiTest插件给接口发请求,模拟一次数据的传递。

(2) 改变参数,再通过请求接口传递一次数据

这种方法虽然实现简单,只需要修改参数,但是问题也是很明显的。我们可以看看接口参数情况:

如表格所示:

(1) 接口的参数个数非常多,每一个参数都有多种情况

(2) 各种参数的组合情况就更多了

(3) 一种参数情况写一条请求,可想而知代码量是非常大的。

能不能实现一种测试中手动填写参数的方法呢?所以我们有了第二个方案

方案二:GT插桩,实现动态参数

GT不仅仅只是随身调这几个基础功能,GT的插桩也是经常在接口测试中使用的,如上述情况,我们只需要在接口函数第一行代码使用动态设置的参数替换掉发送过来的请求数据,理论上则实现了我们的参数动态化。具体防范可参考《GT用户使用手册》。

既然参数的问题解决了,那么如何来调用接口呢?也就是如何触发接口?这是使用GT不能解决的问题,所以GT只能解决参数的问题,不能解决接口触发问题。

这里我们可以把方案一和方案二总结如下:

工具

Pitest

GT

用途

逻辑验证

参数验证

场景

单一用例和组合用例

设置正确和错误的参数

方法

配置文件配置用例

插桩,手动设置参数

优点

能触发接口

动态设置参数

缺点

参数固定,修改麻烦

没有专门的触发机制

方案三:PiTest + GT双管齐下

回到接口测试的过程上来:

这里我们结合上述两个方案的优点,使用GT动态调节参数的功能和Pitest触发接口的优势来验证接口。

验证参数鲁棒性:

每一次触发请求,我们可以设置不同的正确的或错误的参数,使得接口参数得到充分验证。

例如这个BUG:

验证功能逻辑正确性:

(1)验证每一条功能逻辑正确,单独把具体的用例写成脚本:

(2)验证各种逻辑的组合,修改配置文件配置要测试的用例组合。

收益:

说了这么多测试办法,那这样的测试到底对我们有什么样的好处?这里我就来一一举例:

开发:开发可以通过这样一套测试工具自测,在提测前可减少bug流出。

测试:测试的收益不仅仅是几个bug而已,这里测试同学可以提前开展测试工作,不必等到各个FT接入数据再来测试,况且外部FT接入数据后,场景的模拟也是很难的。尽早介入质量管理,保证提供给外部使用的接口是正确有效的。

产品:产品童鞋可提早验收,确认需求项完成。如这次提测完毕后,测试、产品、开发同学一起确认了需求中文案颜色,字体对齐等,重新设计了testview。

设计:通过验收后,设计同学认为toast背景样式不和预期,提早进行了重新设计,早期露了风险。

Q&A

1、 为什么不在Pitest插件中增加设置参数的页面,同样也可以实现动态参数设置。

——当然可以,在插件端我们可以DIY自己想要的任何功能,不过我们需要考虑投入产出比,既然有现成的工具,为何不用起来呢。

2、在接口实现插件中总有地方可以触发接口,何必专门用Pitest来触发。

——可以可以,这都是可以的,一切以完成测试目标为原则,同样这里存在一个问题,在接口实现方来触发接口,需要修改主线的代码。若要自己实现接口的触发,其实不是一个明智的选择。主线代码更新非常快,每次打包都要check out最新的代码,使得测试代码难以维护。所以这里我选择测试代码和主线代码分开,这也是编写测试代码的原则之一。

原文发布于微信公众号 - 腾讯移动品质中心TMQ(gh_2052d3e8c27d)

原文发表时间:2016-05-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏枕边书

用C写一个web服务器(二) I/O多路复用之epoll

前言 继续更新“用 C 写一个 web 服务器”项目(上期链接:用C写一个web服务器(一) 基础功能),本次更新选择了 I/O 模型的优化,因为它是服务器的基...

17510
来自专栏Java帮帮-微信公众号-技术文章全总结

回顾Java 8 9 10的新特性,展望即将来临的11和明年的12【大牛经验】

1997年4月2日,JavaOne会议召开,参与者逾一万人,创当时全球同类会议纪录;

1022
来自专栏Java架构

正确的打日志姿势

1285
来自专栏Spring相关

spring websocket 和socketjs实现单聊群聊,广播的消息推送详解

随着互联网的发展,传统的HTTP协议已经很难满足Web应用日益复杂的需求了。近年来,随着HTML5的诞生,WebSocket协议被提出,它实现了浏览器与服务器的...

924
来自专栏Java技术栈

强悍!Java 9 中的9个新特性

来源:www.oschina.net/translate/java-9-new-features ? 你可能已经听说过 Java 9 的模块系统,但是这个新版本...

3148
来自专栏沈玉琛的专栏

当 MySQL 连接池遇上事务(二):消失的记录

ySQL连接池是一个很好的设计,通过将大量短连接转化为少量的长连接,从而提高整个系统的吞吐率。但是当跟事务一起使用时,如果使用方式不恰当时,就会发生一些奇怪的事...

3613
来自专栏Java技术分享

Java9 中的 9 个新特性

你可能已经听说过 Java 9 的模块系统,但是这个新版本还有许多其它的更新。 这里有九个令人兴奋的新功能将与 Java 9 一起发布。 1. Java 平台级...

1799
来自专栏专知

【分享】Java 9正式发布,9个新特性解读

转自:开源中国, www.oschina.net/translate/java-9-new-features Java 8 发布三年多之后,即将快到2017年7...

3345
来自专栏Java技术

Tomcat服务器顶层结构和启动过程

通过从部署的 1240 个 JVM 中得到的数据,我们能够确定出现了 862 个容器供应商,或者说是占到了运行环境的 70% 左右。这些容器的供应商分布如下:

632
来自专栏java思维导图

spring框架思维导图,简约概括

使用Spring MVC构建Web应用程序

3918

扫码关注云+社区