接口测试那些事

lsekfe

谈起软件测试，就不得不说一下接口测试，凡是有功能的软件都离不开接口，没有接口的软件只是一个模具或页面，不具备任何功能。

那么什么是接口呢?

  接口说白了就是实现软件功能的方法，而这些方法的最终目的就是传递信息，实现软件功能。

那么接口测试又是什么呢？

   接口测试就是验证这些信息能否正确传递，验证这个方法是否正确，有没有存在潜在的安全，性能问题。

所以总结一下接口测试的测试点就有三个：接口功能测试，接口安全测试，接口性能测试。

那么接下来我就给大家讲讲我所遇到过的一些接口和测试吧！

1.一个查询本地数据库数据的查询接口.

这个接口的功能是这样的：

1）查询条件：订单编号，产品名称，产品型号，订单日期，可单独一个条件查询也可多个条件联合查询，多个条件查询的时候查询出来的结果取并集。

2）结果展示：根据查询条件查出来所有产品的配置信息展示给有权限的用户看，展示的字段有订单编号，产品名称，产品版本号，产品型号，配件编号，配件描述，订单日期。

  对这个接口的功能进行进一步的了解我们知道了如下信息：

1)  这些数据都是存在于本系统后台数据库中，涉及两张表：订单表，产品配置表。

2)  开发通过获取页面输入的查询条件，去数据库查询这两张表里面的页面需要的相关信息并展示出来。

3)  订单表中订单编号是主键，产品配置表中产品名称+产品版本号是主键，两张表通过产品名称+产品版本号进行关联。

4)  产品名称存在特殊字符的现象。

通过以上的了解，对这接口测试点进行分析：

1）这是一个结果可见性的查询接口，可以通过页面功能直接来测试，可以不借用工具，另外它也不涉及外部系统数据，不用考滤联测。因为字段表中查询条件相关的字段有特殊字符，所以在测试输入条件查询的时候要关注特殊字符查询条件的查询

所以综合以上分析，输入这块的测试场景有：

1）输入特殊字符

2）输入超长字符

3）输入空字符

4）SQL注入安全测试

2)  从查询条件分析，这个查询条件是单独或多个联合使用的，且多个条件联合时取的并集。

   所以从查询条件的组合来看，测试场景有以下四种情况：

1）输入一个查询条件

2）输入两个查询条件

3）输入3个查询条件

4）输入4个查询条件

根据组合，我们罗列出查询条件的测试场景，为防止有重复，我用了一个表格来画如下：

1）对后台两个表中的数据进行分析,发现由于历史原因，存在版本号为空的数据，而且存在数据量比较大的查询数据，所以在测试的时候还需要关注版本号为空的场景，大数据查询结果的场景。

2）另外出于性能考滤，我们还要关注多人并发查询的场景和一人频繁查询的场景，及异常场景：数据库宕机的场景。

所有测试的场景分析完了，接下来就是把这些场景转化为具体的测试用例，执行测试了。

2.  中间接口，一个传递数据信息的通道

这是一种常见的且最简单的接口，没有任何逻辑，也不做任何处理，只是把A系统传过来的数据再转手传给B系统，功能比较单一，这种接口功能大致流程如下：

1）

我记得当时测试有这样一个接口，系统B想要获取系统A产品的版本号信息，但系统B又没有直接跟系统A交互，只能通过我们这个中间系统进行交互，所以系统B就把存在他们系统的产品名称和产品型号传到我们系统，我们系统再把这个信息推给系统A，系统A返回一个版本信息到我们系统，我们系统就直接把这个信息传给了系统B。

  记得当时story测试时，直接用的soapui工具，自己手动构造的系统B的产品信息传给了系统A，这样虽然验证了本系统接口功能的正确性和性能，但它的测试充分性却是不足的，为啥呢？

   因为我们对系统A产品的特殊参数了解的不多，只能测试普通的共同性问题，不能测试到个性问题，所以必须进行联测来完善测试，让对方系统的测试人员根据他们的测试场景去构造测试数据进行测试。  

3.一个涉及到外部系统的查询接口

这种接口的流程一般如下：

像这种接口的测试输入，输出都在本系统但有一个中间结果在页面是不可见的，我们虽然可以在页面上看到输入，输出，但却不能判断输出结果的正确性，这个时候我们就要通过接口测试工具和页面功能相结合的方式来验证了。

  有这样一个页面查询功有就是这样的，那个页面查询功能是：

当登录人A，所在公司下有子公司时，他可查询到总公司及其所有分公司的订单，当所在公司下没有分公司时，只能查看当前公司的订单。

而这登录人所在公司下是否有分公司只能通过查询系统B才能知道，而系统B返回的结果在页面上并没有展示，而是直接拿他作为查询条件进行了查询，所以要测试这个查询接口查询结果是否正确，就要结合B系统返回给我们的结果进行测试。

  通过接口工具先查看系统B返回的结果，然后再对比页面上的查询结果看是否与我们预期的一致。

  这里用接口测试工具查看返回结果还有一个好处就是可以看到对方系统返回给我们的参数格式，便于我们根据他们的返回结果格式去构造适合的测试场景来验证我们的查询结果，使我们的测试更充分。

4.输入在本系统，输出在外系统的接口

  这类接口的测试一般我们采用接口工具和页面功能相结合的方法进行测试，就是在我们的系统页面触发调用这个接口的功能，通过接口工具查看监控此接口的信息来验证信息的传递情况以及查看相关的输出结果。

   当然这种接口也可以直接用测试工具进行测试，但是我一般是不这样的，为啥呢？因为数据构造太麻烦，而且构造的数据没有直接在页面调用接口形成的数据的可靠性高。

  同样的这种接口还是少不得联测的，联测就是检测我们系统存在的各种场景的数据传递过去后是不是都能被对方系统正常接收到。

我碰到过的这样的接口是这样的一个功能：我们系统订单生成的产品价格要传给系统C，他们要做记录进行预算。

  这个接口前期的各种参数输入都在我们的系统页面上可以完成，只是后期生成订单后的价格和对应的产品信息要传到对方系统后的结果我们是看不到的，在这个时候，前面的测试就是根据我们系统各种参数场景组合测试，那这个参数到底传没有传过去，因为两个系统的开发并不同步，无法直接联测，前期只能通过接口工具调用日志查看参数是否传过去及各个参数的值与我们系统页面上是否一致，后期两边系统功能都实现了就要进行一个联测了，在这个联测的过程中你不单要把自己系统的各种数据场景覆盖到，还要了解对方系统有什么特殊的地方，根据他们的特殊要求构造特殊的数据传给数据进行更深一步的验证。

   好了，我碰到的接口类型大概就是这些了，希望我的这些测试对你有所帮助。

千里

现在的接口测试做起来了