接口测试理论与实践 ——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双管齐下

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

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

验证参数鲁棒性：

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

例如这个BUG：

验证功能逻辑正确性：

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

（2）验证各种逻辑的组合，修改配置文件配置要测试的用例组合。

收益：

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

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

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

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

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

Q&A

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

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

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

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