接口测试填坑的那些事儿版本迭代快！QA缺人手！UI自动化ROI低

　　前言：谨以此文记录总结自己在实施接口自动化测试过程中遇到的坑和填坑过程，希望对做接口测试的同学有些许帮助~ 紧记一点：方法总比困难多，只为成功找方法，不为失败找借口！！！

　一：实施背景

　　版本迭代快！QA缺人手！UI自动化ROI低！单元测试技术要求高，QA做不动！

　　有没有同感？亲们。

　　其实，分层自动化测试(UI+接口+单元测试)的理论大家都懂，只是真到实施推进的时才发现效果和预期差的不是一点儿半点，赤裸裸"理想很丰满，现实很骨感"的节奏。

　　先来看下UI自动化吧，尽管框架设计的好，使用PageObject模式或者PageFactory模式和各种封装，但是你如何扛得住UI层的快速变动，有些团队对此的应对方案是跑UI自动化脚本之前先用爬虫爬去页面自动更新页面元素，嗯~ 这很OK！然而UI自动化脚本的执行效率呢？又有同学说我们用多线程(进程)来执行UI自动化测试脚本，这个点get的不错。

　　我想问的是：UI自动化测试框架和测试用例以及测试数据的维护需要占用多少人力/工时资源？而UI自动化测试的产出又有多么可观？

　　当然，我们并不是不做UI自动化测试，我们这边UI自动化测试仅仅是覆盖主干业务的新建、查询、更改、删除，维护的总用例数不到100个。

　　接着，我们来看单元测试，单元自动化测试执行速度是快(秒杀UI自动化执行)，可以快速发现底层问题，问题是有多少QA或者美其名曰的"测试开发"同学有实施单元测试的能力？

　　这个是一个因素，另一方面是你要做单元测试，前提是你得先明白开发同学写的方法是干什么用的，这无疑对QA（或者测试开发）的时间资源占用极大。综合各种因素，个人对单元测试实施的建议是：QA同学去设计用例，而单元测试脚本开发和执行由开发同学们去做。

　　最后，估计好多负责招聘的同学们都深有感触的一点是"好的QA同学太难招"，想干仗，首先你得有兵马有粮草。

　　那么妥妥的，把目标转移到接口测试来，接口自动化测试执行效率高(那也是轻松碾压UI自动化的执行)能很快的收到测试执行结果反馈，并且接口自动化测试维护比UI自动化简单，而技能要求又没有单元测试高，毫无疑问，接口自动化测试是最好突破口

　　PS：这里小小地透露一点：听话，出活儿(产出高)，执行力强(即时反馈)的同学谁不喜欢？

二：技术选型

　　如果团队使用的开发语言是Java，个人强烈建议接口自动化框架也使用Java语言来开发，常见套路是Java+TestNG(Junit4)+HttpClient这样，如此做法的好处是：

　　1：活跃团队氛围，你用Java开发测试框架，Java开发同学会更有话题和你沟通交流，彼此赶脚很亲切有木有~；

　　2：后续拓展去实施单元测试，你也可以逐渐轻易地看懂被测试对象，设计出更优秀的测试用例。

　　有些测试团队里，大家普遍技术不强，我还是推荐RobotFrameWork这个框架，做接口自动化测试也是溜的飞起。

　　我们测试组的同学普遍使用Python，那就没啥好说的了。

　　很多同学使用Python自带的测试框架Pyunit，断言呢也是使用自带的，然后脚本执行使用HTMLTestRunner，测试报告嘛，无疑是html格式。

　　我个人不建议使用Pyunit了，因为有更好用nose框架啊~

　　至于html格式的报告，更是不在话下nose-html-reporting，nose_htmloutput玩起来，如果你对Python-Web开发中的模板引擎Jinja2规则熟悉，那再好不过了，自己可以自定义测试报告格式，来个定制化报告是不是更炫^_^

　　还有断言，我不想执行过程中断言失败就中断后续的用例执行，所以选择是assery.py这个三方库来断言，assert库里的软断言soft_assertions谁用谁知道哈哈~别说我没告诉你哦

　　所以，我的选择是Python+Nose(超越pyunit的测试框架)+nose_htmloutput(自定义测试报告格式)+Json文件(管理接口用例数据)+assert.py(简单好用的断言库)

　三：知识体系科普

　　接口自动化测试ROI(投入产出比)虽好，首先我们需要掌握其关联的知识体系。

　　如果东一榔头西一棒子很容易形成知识点的碎片化，当真正去落地实施的时候反而受困。

　　我这里抛出问题，希望有机会看到此文的同学具体的答案在实践中充实

3.1：接口的定义

　　先弄明白什么是接口，接口有哪些类型。

　　搞清楚被测对象才能更好的去做测试工作，不要害怕，恐惧是因为陌生！！！

　3.2：http/https协议

　　http的报文格式，请求头，请求体。请求返回报文的格式，报文体。

　　接口设计的模式webservice/restful。

　　PS：重要声明----不要以为只有http协议接口，其他底层协议也可以多看看。

　3.3：测试用例设计

　　其实接口用例设计用到的方法比较常见。

　　对单个接口来说，就是用等价类，边界值方法，此外需要考虑的是参数缺失，重复操作等。

　　我负责任地告诉大家，接口测试的最大价值在于对业务场景的覆盖，所以~~~接口间的依赖是必不可少的，这时候设计用例就需要用到场景法了。

　3.4：Python基础知识

　　这个就无需费言啦，一种编程语言的基础语法(变量，条件判断，循环体等等)是首先要掌握的。

　　此外，很多不错第三方库推荐给亲们~

Excel文件处理：openpyxl

日期处理：Arrow

http请求处理：requests

断言处理：assert.py

测试框架：nose

Html格式报告文件生成：nose_htmloutput

　　除此之外还有很多哈~ 后续会和同学们分享个人在学习大数据测试过程中的一些总结~

四：环境搭建

　　4.1：包管理工具pip

　　先说一点吧，很多同学还在犹豫使用python2.x版本还是3.x版本，我的个人建议是：不要犹豫毫无疑问地选择3.x版本。

　　配置Python环境的步骤我就不写了，如果这个都不会或者不愿意去Google下，那么请不要继续往下看这篇文章了，我也强烈建议这样的同学别做软件测试工作了。

　　编辑器的话，个人推荐JetBrains公司出品的PyCharm，当然这个看个人喜好。

　　安装第三方库的话可以手动一个一个安装，还有一种方案是将所有的库文件名写在一个文件中，示例如下：

　　pip install -r D:\releate_package.txt

　　执行结果如下图，因为我已经全部安装了

4.2：抓包工具Fiddler

　　Fiddler安装不说了，一路下一步。

　　对移动端APP的https抓包的话还需要如下设置(Tools"Fiddler Options)

　　保证移动端和PC端的网络在同一个局域网内，设置移动端代理为PC端的ip地址，端口号是8888，然后下载并安装Fiddler根证书。

　　设置完成后，我这里以进入钉钉里的微应用为例演示下：

　　可以看到Fiddler中截取的报文

......

选自《51测试天地》原创测试文章(四十八）