接口测试的必要性和意义
接口，即API，应用程序编程接口，关于接口的介绍。
这里主要说说接口测试的必要性和意义：
接口测试实施在多系统的平台架构下，有着极为高效的成本收益比（当然，单元测试收益更高，但实施单元测试的成本投入更大，技术要求更高，所以应该选择更适合自身的才是最好的方案）。
接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力，平台复杂，系统越庞大，接口测试的效果越明显。
总的来说，接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益驱动作用下的最佳方案，主要体现在如下三个方面：
节省了测试成本
根据数据模型推算，底层的一个程序BUG可能引发上层的8个左右BUG，而且底层的BUG更容易引起全网的死机；接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。
接口测试不同于单元测试
接口测试是站在用户的角度对系统接口进行全面高效持续的检测。
效益更高
将接口测试实现为自动化和持续集成，当系统复杂度和体积越大，接口测试的成本就越低，相对应的，效益产出就越高。
做接口测试需要哪些技能
做接口测试，需要的技能，基本就是以下几点：
业务流：了解系统及内部各个组件之间的业务逻辑交互；
数据流：了解接口的I/O（input/output：输入输出）；
协议：包括http协议，TCP/IP协议族（之前的博客有系统的介绍过协议，传送门：http协议：菜鸟入门系列）
工具：工具可以辅助我们更好更高效的完成工作，常用的接口测试工具有：jmeter、loadrunner、soapui、postman等；
数据库知识：无论是从数据库获取知识，还是确认数据落地，抑或接口对数据执行了哪些操作，都需要确认，因此数据库知识（其实就是增删改查）就很有必要；
补充：接口文档的几个必要点：完整性、一致性、容错性；
接口自动化测试
1、如何开展
首先，调试单个接口，保证单个接口的正确和通畅（类似于性能测试中的基准测试）；
其次，明确数据流，业务流；
最后，将N个接口测试脚本串起来，执行即可；
最重要的一点，别想太多太复杂，先把最基础最简单的做起来，就成功一大半了，至于扩展性的第三方接口、https、定时任务、自动出测试报告、自动发邮件等等功能，这都是不断累计和优化的，
行动起来就行，想太多不如行动起来，让接口自动化测试落地，才是我们首先需要考虑的！
2、开展之前需要知道的
现在的测试对象包含几个页面？
每个页面涉及几个接口？
分别在哪一步调用？
每个接口包含哪些字段？
各个字段对应数据库哪张表？
每个表中各个字段是什么意思？
各个接口对表产生了怎样的操作？
3、自动化框架
什么是框架？
你可以理解为一个完整的环，也可以理解为让接口测试脚本运行的一整套环境，平台，随便什么都可以；一般一个自动化测试框架包含以下几点：
数据池：即测试数据的存储管理，一般集成为一个data包，其中包括：
log（日志文件）、report（测试报告文件，一般为xml格式）、case-data（单个接口的测试数据，一般为json格式）、server-data（接口业务串联的数据，可以用excel管理）
脚本管理中心：接口测试脚本的统一管理、存储、调度中心，常用的工具有maven、ant等，或者可以使用编程语言中的单元测试框架提供的功能，选择自己适用的即可；
运行平台：一般是借助工具来运行这些测试脚本，工具可以使用上面提及到的几种（jemter、loadrunner、soapui等），同样，选择合适的很重要；
持续集成工具：最常见的就是Jenkins，它的作用就是监控外部程序的调用执行，定时或者触发调度任务，测试脚本执行等功能；
通信服务：dubbo、spring_boot、thrift等RPC、REST同步调用服务；
测试结果统计管理中心：比如testlink，目的是为了测试结果自动更新上传，更好的统计测试结果，以便后期的优化；
上面说了这么多，实际上它的意义就是：数据与脚本分离，测试结果自动提交通知，提高测试脚本和测试数据的维护便利等等。。。
我正在使用的框架为：jemter+maven+Jenkins+dubbo+MySQL…
关于接口自动化测试，基本就是上述的内容，当然，选择适合自身实际情况的框架，落地实施，才是重点，行动起来，才能咸鱼翻身。。。
接口自动化大致步骤：
1、发送请求
2、解析结果
3、验证结果
定义三个和业务相关的类
1、一个用来封装HTTPclient，用来发送请求
2、解析结果xml的类
3、一个用于比较测试结果和期望值的类，用于验证
4、自动生成报告的类：自动发送报告之类的
（locust的python工具）
服务级：Web server（服务） Database（持久化工具-数据库）、Cache（短时间持久化工具-缓存）
接口测试：
1、构造数据
（1）通过接口构造
比如获取一个blog的文章信息，怎么构造数据呢？（文章哪里来？？）—返回blog信息
通过添加文章的接口，临时构造数据（blog文章），然后断言的时候看看是不是自己造的数据——会造成接口耦合（两个程序模块有关联就叫做耦合。）—和造文章的接口耦合（如果创建文章的接口挂了，那返回blog信息的接口也就挂了）
公交卡充值依赖支付宝的支付接口服务，调用支付接口会有代价，所以模拟一个支付接口，所有通过mockserver（测试桩）去模拟支付接口的服务----不管输入是什么，返回一直成功或是固定的
（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测试
# coding:utf-8
import requests,unittest
class V2ETestCase(unittest.TestCase):
def test_ger_node_api(self):
python_node_id = 90
url = "https://www.v2ex.com/api/nodes/show.json"
node_name = 'python'
querystring = {"name":node_name}
res = requests.request("GET", url, params=querystring).json()
print res
self.assertEqual(res['id'],python_node_id)
self.assertEqual(res['name'], node_name)123456789101112if name==‘main’:
unittest.main()
在命令行运行（以后做自动化测试用）：
报告可以生成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的测试报告虽然也很清楚，但是并不是我想要的东西，我理想的测试报告应该有一下那么两点
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。
暂时没有评论，来抢沙发吧~