接口自动化测试设计

1.接口测试基础

1.1.什么是接口测试？

•     接口测试是测试系统组件间接口的一种测试。
•     接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
•     接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
•    从接口形式来看各类应用程序的API(最著名的Windows系统API)，硬件的驱动程序，数据库DAO层接口，及WebService 接口和Http Rest接口。
•    接口测试一般包括两类，底层模块之间的接口测试和上层服务接口测试。前者一般由开发工程师作单测覆盖，后者则一般由测试工程师测试保证。

1.2.接口测试原理？

    经过测试程序或工具模拟客户端向服务器发送请求报文，服务器接收请求报文后作出处理，而后将应答报文返回给客户端，即客户端发送应答报文的过程（Request -> Response）

 

1.3.接口测试分类？

•     系统与系统之间的调用：银行会提供接口供电子商务网站调用，或者说支付宝会提供接口给百度外卖调用。
•     上层对下层服务的调用：如Service层会调用DAO层的接口，而应用层又会调用服务层提供的接口。
•     系统内的服务之间的调用：如注册用户时，先调用用户查询的服务，查看该用户是否已经注册

1.4.为何接口测试？

    测试金字塔概念由Mike Cohn提出，在《Succeeding with Agile》中作详细论述。核心观点：底层的单元测试应多于UI层的端到端测试。

    1).UI：一般指 Web、App的测试；2).Service：通常针对接口、服务，如 HTTP、WebService 接口测试；3).Unit：包含比较多，如：Web应用的dao、service、model，controller的junit单元测 试，javascript、css的前端单元测试，大部分应由开发作测试保证。

    参考金字塔层次划分，不能层次的测试投入量是不一样的，越上层比重应越小，以尽可能低的测试成本防护不一样类型的风险。金字塔分层测试的ROI则是倒金字塔，即 Unit > Service > UI。Service测试层于QA而言是重要一环，也是性价比相对较高的。总之，分层自动化测试是追求覆盖的传统自动化测试的一种修正，充分利用自动化测 试的优势，规避自动化测试的缺点。

 

1.4.接口测试范围？

    新增及改动接口的测试（接口的改动点，可经过代码及配置 diff 测试，圈定最小测试范围。服务端接口迭代过程，需测试接口依次增多。测试时间足够条件下，固然须要进行全回归测试。但时间较短，应考虑接口的重要性与优先级，优先对核心且调用频繁的接口测试。）新增及改动业务功能测试。接口的性能与安全测试（是否须要对接口实施性能和安全测试，取决于接口特色。一个对第三方电商平台提供支付功能的接口，如：支付宝接口，性能和安全测试是 必需要例行化测试的。一个系统内部调用的获取列表页接口，性能和安全性考虑优先级相对不那么高。总体而言，从接口的业务特色，即流量大小、调用方式、服务 架构、业务闭环的重要性等角度考虑。）

 

2.接口测试策略

    检查： 接口设计检查，经过接口文档定义对接口交互数据作有效性检查，整数型数据位数、浮点型数据精度、字符串数据范围值等，要求客户端传入的整数型、浮点型、字 符串型数据及最大值和最小值都能做为服务端接口有效输入，确保服务端不会自动进行截断或四舍五入操做。(接口设计评审阶段便可进行)

               接口依赖关系检查，一般用户的一个操做可能对应服务端调用多个接口完成，从业务操做角度来看，各类业务操做所涉及的多个接口之间调用进行测试。依赖关系检 查，主要经过接口的输出值为另外一接口的输入值来实现的，所以在进行接口测试以前，须要分析所测试接口的输入值是经过客户端仍是其余接口输出来获取的，在设 计测试用例时，加入接口的依赖关系说明以便于测试。

    验证：接口输入/输出验证，服务端接口功能测试相似于单元测试，在设计测试用例时，侧重点在于接口模块输入/输出项的正确性验证，根据接服务端接口处理方式分类有多种：条件判断接口、数据查询接口、逻辑运算接口。

    构造：接口测试过程，经常须要构造测试数据。一般是数据库插入，mock 接口，调用依赖接口，开发脚本工具批量等。

    自动化：相对于UI层自动化测试，服务端接口的自动化测试更容易实施，较稳定且维护成本低。参考接口case的优先级作自动化覆盖，回归测试、线上监控等收益均较大。

2.1.接口测试关注点？

•     入参数据：每一个接口入参的默认值、异常类型、非空交易。 参数是否有默认值，若没有，接口逻辑是如何处理的；参数必须输入值，若不输入或输入错误，接口如何返回；接口报错，服务端和客户端是否都作了容错处理。
•     出参返回：接口返回数据是否正确。
•     页码页数的异常值：接口有翻页时，如：第一页有数据，翻到第二页。第二页的数据是否与第一页重复，第二页接口是否报错，页码、页数，传很大的值，接口是否报错。
•     数据库增删改查，如对某接口post请求后，对列表页接口刷新请求，新数据是否与post数据一致。典型case，发布评论，post请求后是否返回评论数据，若无则检查是否缓存未写入数据库致使。
•     参数个数：入参支持多个值时，考虑传值个数多的状况，接口是否报错，接口应返回友好提示。
•     参数类型：输入参数类型必须校验，输出参数必须正确。便是int类型的，不能返回string类型。
•     排序：列表页接口应考虑排序值，升降序、时间排序等是否正确。
•     版本兼容：接口的改动（增长、减小字段）须要兼容老版本。
•     参数联动性：校验返回的多个参数的实际结果是否符合需求，如：返回一个商户的列表，总数字段和列表数据是否一致。
•     业务：从业务中来，到业务中去。接口测试是对业务逻辑的测试覆盖，对业务架构的理解。

2.2.接口测试Case设计？

Case参考点：输入参数测试，功能测试，逻辑测试，异常状况。

设计思路：a)优先级-针对全部接口，外部接口 > 系统内部核心接口 > 系统内部非核心接口。

                 b)优先级-针对单接口， 正向用例 > 逆向用例（一般状况，非绝对)；前置条件 > 默认参数 > 参数必填 > 参数关联 > 参数类型限制 > 参数数据范围限制。

Case覆盖：主流程 -> 分支流程 -> 异常流程。

 

3.接口自动化演进

    接口自动化演进，一般是从手动测试 -> 工具测试 -> 代码测试 -> 平台服务化演进。

    手动：从客户端的业务场景测试去覆盖服务层接口，借助Fillder、Charles、FireBug等工具抓包分析。优势：简单，模拟真实业务场景；缺点：接口逻辑覆盖不够，异常和输入校验不足，重复繁琐，回归成本高。

    工具：使用PostMan，HttpRequest，Jmeter, SoapUI 等工具作接口测试。优势：容易保证接口逻辑覆盖，便于异常和输入校验，提升回归效率；缺点：缺少自定义灵活性，接口依赖处理繁琐，不便自动化工程化。

    代码： 选择如，Java + Httpclient，Python + Requests, PHP + Requests/cURL/HTTPFul，搭建接口自动化框架，开发接口自动化case。优势：灵活性好，扩展性强，逻辑覆盖容易，异常和输入校验充 分，回归效率高；缺点：存在必定学习成本，框架及case脚本需持续维护。

    平台：通用的接口自动化测试平台，简而言之知足接口自动化测试的Web平台，如：Numen。优势：通用性强，上手快，一键式，配套服务全等；缺点：业务契合度，灵活性，维护成本，API扩展等。

3.1.接口测试工具？

    代理抓包工具
        Fillder, http://www.telerik.com/fiddler
        Charles, https://www.charlesproxy.com/
        Wireshark, https://www.wireshark.org/
    
    调试工具
        Firebug(Firefox), https://addons.mozilla.org/en-US/firefox/addon/firebug/
        DevTools(Chrome), https://github.com/CN-Chrome-DevTools/CN-Chrome-DevTools
    
    Json&Url encode工具
        json在线解析,格式验证, http://json.cn/
        json压缩转义, http://www.sojson.com/yasuo.html
        jsonview插件(Chrome), https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc?hl=zh-cn
       url encode工具, http://tool.chinaz.com/Tools/URLEncode.aspx

    测试工具
        PostMan, https://chrome.google.com/webstore/detail/postman/
        SoapUI, https://www.soapui.org/
        Jmeter, http://jmeter.apache.org/

3.2.接口自动化框架设计？

接口自动化测试框架设计关键点，其实能够用Driven、Organize、Support、CI归纳。

Driven：Data Driven(数据驱动)，接口测试关注输入、输出及各类异常数据，归根结底其实就是作数据测试。如何设计合理的参数化实现，下降测试数据维护成本，是自 动化框架设计的重要内容。KeyWord Driven(关键字驱动，即封装)，将测试过程当中公共过程、通用步骤尽可能封装为通用函数，其中分别为业务、过程common 函数。合理的封装函数设计，将使得自动化脚本简洁化、一致性，可维护性高。

Organize：组织。考虑两个维度，如何管理组织自动化工程？如何组织自动化case？以Java语言举例，接口自动化case较少只有几个，建立一个普通java工程项目，在 main方法中，罗列写出case实现便可。无可厚非，这是一种简单实现。但随着接口数量增长，接口case愈来愈多，这种方式的维护成本愈来愈高，冗余愈来愈重。咱们须要考虑将自动化工程化而不是脚本化，即作工程管理，如使用maven管理工程，配置各种jar包依赖，定义测试等。测试case使用单测 工具管理组织，如：junit/TestNG，有什么好处？定义了case的执行顺序，通用丰富的assert验证，结果统计收集等。

Support：接口自动化测试不仅是模拟一个请求发送及响应解析的过程，作为框架需考虑的远不仅这些。如：json数据的比对，数据库增删改查操做，接口的数据mock构造，md5值校验，url的unicode/encode，report，email等等。

CI：自动化框架搭建了，自动化case工程化了。选择什么方式调度，何时执行。IDE 手动调度执行，bat/sh？CI 是一种高效的机制，每次代码编译打包部署，都应该触发CI的自动化执行，自动化框架须要考虑CI的集成。

 

4.外面团队，如何作接口自动化？

测试工具：PostMan, SoapUI，Jmeter……

自动化框架

    Java：java + httpclient + junit/testng + ant/maven + Jenkins

               java + jmeter.jar + + junit/testng + ant/maven + Jenkins

    Python：python + (robotFrameWork) + (requests) + (xlrd) + pyUnit + Jenkins

    Ruby：ruby + (cucumber/rspec) + (http/net) + TestUnit + Jenkins

    PHP：php + requests + phpUnit + Jenkins

    NodeJS：node.js + mocha +supertest + Jenkins