接口自动化测试基本流程及测试思路

Posted 2020-11-22 yanghj010

接口自动化大致步骤：

1、发送请求

2、解析结果

3、验证结果

定义三个和业务相关的类

1、一个用来封装HTTPclient，用来发送请求

2、解析结果xml的类

3、一个用于比较测试结果和期望值的类，用于验证

4、自动生成报告的类：自动发送报告之类的

（locust的python工具）

服务级：Web server（服务） Database（持久化工具-数据库）、Cache（短时间持久化工具-缓存）

接口测试：

1、构造数据

（1）通过接口构造

比如获取一个blog的文章信息，怎么构造数据呢？（文章哪里来？？）—返回blog信息

通过添加文章的接口，临时构造数据（blog文章），然后断言的时候看看是不是自己造的数据——会造成接口耦合（两个程序模块有关联就叫做耦合。）—和造文章的接口耦合（如果创建文章的接口挂了，那返回blog信息的接口也就挂了）

公交卡充值依赖支付宝的支付接口服务，调用支付接口会有代价，所以模拟一个支付接口，所有通过mockserver（测试桩）去模拟支付接口的服务----不管输入是什么，返回一直成功或是固定的

如何进行mock？？
mockserver介绍：https://www.cnblogs.com/fnng/p/7511539.html
使用：https://blog.csdn.net/qq_35049819/article/details/77839495 （未验证）

（2）通过持久化层构造（更好）

意思就是在数据库直接插入数据

2、调用接口

postman/jmeter–win

CURL-linux

Paw–mac

3、对接口返回进行断言

通过不同的输入-判断不同的预期----数据驱动（输入数据）
断言参考方法：对比数据库值，code验证

4、接口测试的用例设计

功能测试用例
业务逻辑设计
业务逻辑方面的测试用例主要是针对服务端接口的处理逻辑进行的用例设计，这种用例设计不是针对某个功能点是否实现，而是对接口的处理逻辑以及一些相互依赖的业务进行验证，通常依照接口的逻辑流程图来进行。举一个例子，购物系统中的两个动作：登录和下单操作，这两个业务是相互依赖的，下单操作必须在登录完成后（登录状态下），否则无法完成下单，这个时候我们就可以设计这样一条case：没有登录的状态下进行下单操作，看服务端如何处理。

可以看到这一块有两个判断，我们需要对不同的判断分支都设计用例，以保证流程图中涉及到的分支我们都有测试用例覆盖。图中涉及到的不同的分支有：
1.abdf；
2.acg;
3.abdeg;
相应的，我们的用例就应该是：
1.userInfo != null && value(userGroup) != 0;
2.userInfo == null;
3.userInfo != null && value(userGroup) == 0;
业务逻辑的用例设计主要是以服务端接口内部的逻辑流程图为基础，针对流程图中的判断和分支进行用例设计，保证服务端接口的每一种逻辑下都有测试用例覆盖。

异常处理情况
服务端接口和客户端之间通常是通过HTTP请求来传递数据，在发送请求的时候，客户端会携带各种不同的参数，此时服务端会根据不同的参数进行不同的处理，所以异常处理主要是针对请求中的参数情况：比如参数增加和缺省、参数的数据类型错误，参数携带错误的值、参数为空等等，这需要我们根据接口文档中各种不同的参数去构造不同的参数异常，检查服务端的响应情况。

性能和安全性方面
服务器的性能往往是个非常重要的关注点，在实际的测试中我们主要关注的是接口的QPS数值，以及CPU和内存占用等性能指标，通常借助于其他工具比如LoadRunner进行性能测试。安全性方面，主要考虑一些常见的安全策略比如请求加密、sql注入等等。

二、接口测试实例

1、postman测试

2、python测试

1 # coding:utf-8
 2 import requests,unittest
 3 class V2ETestCase(unittest.TestCase):
 4     def test_ger_node_api(self):
 5         python_node_id = 90
 6         url = "https://www.v2ex.com/api/nodes/show.json"
 7         node_name = ‘python‘
 8         querystring = {"name":node_name}
 9         res = requests.request("GET", url, params=querystring).json()
10         print res
11         self.assertEqual(res[‘id‘],python_node_id)
12         self.assertEqual(res[‘name‘], node_name)
13 
14 if __name__==‘__main__‘:
15     unittest.main()

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15

在命令行运行（以后做自动化测试用）：

报告可以生成html形式的-加进去

python为例：

unittest库

Requests库

Json

Dict字典

assert断言

用postman做接口测试，选择get还是post，加入数据发送请求，查看返回的结果—然后给接口做断言（点右上角的code，选择js语言，写断言）

当接口返回的数据时动态的，比如一个网站文章的最新评论----还是测试环境问题，搭建一个专属的测试环境，不产生新的数据，一样的可以测试接口—相当于动态数据静态化

“怎么做接口测试”这个问题可以分解为两个问题：
怎么设计接口测试用例？
怎么执行接口测试？

怎么执行接口测试？
Fiddler、SOAPUI、PostMan等可以做半自动的接口自动化测试；
使用Robot Framework做全自动化的接口自动化测试；
自己用代码做全自动的接口自动化测试，如Java+testNG；

自动化接口测试+生成报告思路：
在接口的开始测试阶段，我用POSTMAN来手工测试接口，单一接口测试通过后，把测试用例Copy到Jmeter中，作为后续的定期执行的基础，在接口手工全部测完后，用Jmeter+Ant+Jenkins来定期检查每天的接口，并生成测试报告，再写一个爬虫每天监控测试报告，如果出现了异常，发邮件报警。

1、每天的历史报告肯定也是需要留存的
2、有案例失败时的邮件通知

Jenkins有邮件报警和report展示的插件~ 楼主不用自己写。。。

最后应该就是测试报告了，集成于自动化的接口测试，每天的接口测试报告也是挺重要的，Jmeter的测试报告虽然也很清楚，但是并不是我想要的东西，我理想的测试报告应该有一下那么两点

测试通过率
每条测试的过程展示
测试通过率是方便查看报告的人直观的了解本次测试的结果。

测试过程的展示需要展示如下内容：测试结果、请求地址、输入参数、输出结果、断言结果。并且成功和失败的标识需要非常明显。