本文是关于接口测试自动化-自动化测试框架

一、序言

随着项目版本的快速迭代、APP测试有以下几个特点：

• 首先，功能点多且细，测试工作量大，容易遗漏；

• 其次，代码模块常改动，回归测试很频繁，测试重复低效；

• 最后，数据环境多样，用户场景复杂，功能回归覆盖难全面。

为节省成本，保证高效及高质量迭代，我们需采用更高效的测试方式，App自动化测试是较高效的手段。
之前自动测试实践过程中遇到的诸多问题（代码复用率低，Case开发及数据构造繁琐，问题定位困难，学习成本高等），为解决相关痛点问题，我们重新实现了一套APP自动测试框架。本文将着重介绍技术选型、设计思路及百度外卖App的具体实践。

二、自动化测试框架技术选型

一个项目中自动化测试是否能有效的展开，自动化测试框架是关键所在。因此，如何如何构建稳定的、易扩展的自动化的测试项目对于敏捷测试有重要的意义。在设计框架的时候应该尽可能的沿用自动化测试工具已提供的功能，避免重复开发，以减少开发成本。
通过对现有自动化测试工具的原理进行深入分析及优缺点比较，并基于Appium和TestNG两类自动化测试框架解决上述自动化测试中遇到的问题。

• 首先，通过利用TestNG结合csv的使用，将测试用例数据转化为测试代码中的数据，减少了测试人员录入数据和准备数据的工具；

• 再次，通过对appium的封装，按照面向对象的思想将测试中用到的页面元素封装成对象，增强测试代码的复用率，并减轻测试人员对底层代码实现的负担，提高测试代码编写效率；

• 最后，引入失败重跑、失败截屏，并通过reportng生成测试报告的方式，逐步完善测试过程，提高定位问题的速度；

TestNG

Testng是一个开源自动化测试框架，引入了许多新的创新功能，如依赖测试，分组概念，使测试更强大，更容易做到。 旨在涵盖所有类别的测试：单元，功能，端到端，集成等。TestNG框架可以很好地帮我们完成WebDriver+java的页面自动化工作,通过各种注释的灵活运行，可以使你的测试用例更加完美，定制符合要求的测试用例

1. TestNG是一个设计用来简化广泛的测试需求的测试框架，从单元测试到集成测试。 这个是TestNG设计的出发点，不仅仅是单元测试，而且可以用于集成测试。设计目标的不同，对比junit的只适合用于单元测试，TestNG无疑走的更远。可以用于集成测试，这个特性是我选择TestNG的最重要的原因。

2. 测试的过程的三个典型步骤，和junit(4.0)相比，多了一个将测试信息添加到testng.xml文件。 测试信息尤其是测试数据不再写死在测试代码中，好处就是修改测试数据时不需要修改代码/编译了，从而有助于将测试人员引入单元测试/集成测试。

3. 基本概念，相比junit的TestCase/TestSuite，TestNG有suite/test/test method三个级别，即将test/test method明确区分开了。

Appium

Appium一个开源、跨平台的测试框架，可以用来测试原生及混合的移动端应用。Appium支持iOS、Android及FirefoxOS平台测试。Appium使用WebDriver的json wire协议，来驱动Apple系统的UIAutomation库、Android系统的UIAutomator框架。相比其他的移动自动化测试工具，Appium测试由于调用了Selenium的client库使其可以使用任意的语言，包括Python、Ruby、Node.js、Objective-C等。

三、自动化测试框架的设计思路

测试设计过程和测试自动化框架必须作为两个单独的实体来开发。

测试框架应该独立于应用程序；

测试框架应该易于扩展 、维护和增强；

测试策略／设计应该对测试者隐藏测试框架的复杂性。

四、自动化框架介绍

该框架基于Selenium WebDriver开源技术开发。本框架使用Maven工具进行Project管理，采用TestNG工具组织测试，应用CSV文件存储测试数据，实现测试数据与测试用例的分离，方便测试数据管理，降低自动化脚本的维护成本，实现数据驱动。此外，该框架还封装了丰富的Selenium方法关键字，借鉴了QTP语法结构，实现了直观清晰的结构化代码语法，如：Page.Item.Operate，降低自动化代码的冗余与重复。借助Jenkins 进行CI测试，实现测试任务的Schedule 和Report功能，通过Jenkins Master/Slave模式管理虚拟机节点，实现多任务多机器分布式并发的执行管理，从而提高测试效率。

• 该框架的好处在于： 1、构建可复用的、稳定的代码集。通过封装appium实现用例执行与数据调用分离，参数化配置常用信息，并提供统一接口； 2、模块化管理自动化测试用例。主要根据TestNG工具的支持参数测试和依赖测试的特点实现； 3、测试结果分析和统计。利用jenkins工具建立持续集成，定期运行自动化测试项目，并将测试结果以定制化的形式展现。

测试框架分层

基于UI测试，我们希望除了支持web测试，还能支持app的测试，可能还需要接口测试，我们就需要考虑分层问题，将测试框架分为三层。上层是管理整个自动化测试的开发，执行以及维护，在比较庞大的项目中，它体现重要的作用，它可以管理整个自动测试，包括自动化测试用例执行的次序、测试脚本的维护、以及集中管理测试用例、测试报告和测试任务等。下层主要是测试脚本的开发，充分的使用相关的测试工具，构建测试驱动，并完成测试业务逻辑。

第一层：数据层

即执行用例时所需要的测试数据，如商户名、空间名、URL等，这些数据用来支撑整个脚本的执行。针对数据层，这里采了用数据驱动的方式。

第二层：驱动层

这一层主要封装各种driver。比如我们针对网页测试，使用selenium-webdriver开发包，针对app测试，我们使用appium开发包。我们在这一层进行封装，通过调用selenium-webdriver，appium提供的原生方法，封装成可读性很强的方法且加上容错机制。以后就算我们要换用其他的第三方包，我们的测试案例层和支持层的方法也不需要做任何的修改。只需要修改driver层实现的方式就可以了。在一层，我们主要实现两个方面的封装，一个是driver的封装，一个是基于基类自然语言函数的封装。

driver封装

我们需要封装，根据参数确实是基于web测试还是基于app测试。比如：

基类封装

主要是封装各种可读性很很强的方法以及将元素定位标识及driver也封装进去。为了支持网页测试和app测试，我们需要两个基类，一个是针对网页操作基类，一个是针对app操作基类。同时为了web和app操作的一致性，我们要求对外提供的方法，必须要将常用的方法保持一致的名字和一样的参数类型及参数个数。
APP基类示例如下：

通过对driver和基类的封装，driver层实现了对网页测试和app测试的支持，并且针对两种测试，都提供了统一的方法，能够方便使用者，使用相同的方法，测试app和web。

第三层：测试案例层

该层是测试案例的具体实现，就像上面写的case那样，用接近自然语言的方式，来实现测试案例。

第四层：支持层

该层主要提供workflow，通用工具，元素库的支持，便于测试案例层直接调用。

• Workflow：主要封装测试项目中需要经常使用的针对项目的公用方法，供测试案例层直接调用。比如用户登录，注册一个用户，搜索出用户等等经常使用的动作；

• 通用工具：提供一些通用方法，比如生成指定Page类，文件读取操作，DB操作，http操作支持等等；

• 元素库：每一个页面元素的定位表达式（xpath，id，name，css，link_text等等表达式）。 我们的测试案例，都是针对一个个元素进行操作的。将每一个页面的每一个元素，都看成一个继承了基类的特定类。所以，我们的第一步，就需要找到这个元素，定位到这个元素。测试项目的所有元素都放到这里。

第五层：结果保存层
将测试脚本的日志和结果以自定义的方式展示，这里使用了ReportNG,它可以丰富测试结果的展现形式，帮助团队更快定位和解决问题。

五、框架技术要点解析

5.1、PO模式

5.1.1、遇到的问题

使用webdriver做过一段时间的测试就会发现一个对某一个页面的元素进行定位的时候，程序行间充斥着id()、name()、xpath()等方法，这样会造成测试程序的可读性较差，不便于后期的维护以及修改。

虽然我们可以通过添加注释的方法使程序便于理解，但是还是不可以从根本上解决这种问题。我们可以通过对这些方法进行二次封装来避免每次对这些方法的直接调用，通过方法的封装虽然可以实现复用。但是我们发现通过封装无法实现页面元素的逻辑处理和测试数据的独立。

5.1.2、问题的解决办法：引入PO

Page Object模式是Selenium中的一种测试设计模式，是指UI界面上用于与用户进行交互的对象。主要是将每一个页面设计为一个Class，其中包含页面中需要测试的元素（按钮，输入框，标题 等），这样在Selenium测试页面中可以通过调用页面类来获取页面元素，这样巧妙的避免了当页面元素id或者位置变化时，需要改测试页面代码的情况。 当页面元素id变化时，只需要更改测试页Class中页面的属性即可。通过对界面元素的封装减少冗余代码，提高测试用例的可维护性。

一般情况下，对于一个Page Objects对象，它有两个方面的特征：

• 自身元素(WebElement)

• 实现功能 (Services)

仔细分析测试场景，抽出UI测试的核心行为，无非就是：

1、检查点：

页面元素是否存在；

页面元素显示内容是否正确；

页面元素是否可用；

……

2、辅助功能：

等待元素出现；

点击某页面元素；

给元素输入内容；

……

分析抽出来的核心行为，发现这些行为基本都是针对一个个页面元素进行的操作。那么我们就可以做如下的动作：

将页面元素看成一个对象，封装成一个类；

将上面分析得到的核心行为都封装成基类方法。然后确保，任何一个页面元素都继承该基类；
该基类提供类似于自然语言的方法名字，调用这些方法，就能很明确的知道测试案例在做什检查，在做什么行为，这样就能极大的提高测试案例的可读性。

该基类主要目的是在UI测试中，对元素共性的检查点和辅助方法进行抽取，将它们封装成一个个非常容易读懂的方法，且具有异常处理能力。

经过上述思路的整理，测试用例可以改写成如下：

在实际的使用过程中，可以让不太熟悉代码的QA专门负责测试案例的实现，底层的方法包装可以由经验丰富一些的同学做。

5.2、数据驱动

数据驱动的自动化测试框架是这样的一个框架，从某个数据文件(例如ODBC源文件、Excel文件、Csv文件、ADO对象文件等)中读取输入、输出的测试数据，然后通过变量传入事先录制好的或手工编写的测试脚本中。其中，这些变量被用作传递(输入/输出)用来验证应用程序的测试数据。在这个过程中，数据文件的读取、测试状态和所有测试信息都被编写进测试脚本里;测试数据只包含在数据文件中，而不是脚本里，测试脚本只是一个“驱动”，或者说是一个传送数据的机制。

1. 在数据文件中填写测试数据：

2. 生成Page类：

3. Page类中初始化页面元素：

基于数据驱动的好处在于：

在应用程序开发的同时就可以同步建立测试脚本，而且当应用功能变动时，只需要修改业务功能部分的脚本；

利用模型化的设计，避免重复的脚本，减少建立或维护脚本的成本。

5.3、失败重跑与失败截图机制

自动化测试过程中，常常由于网络、服务器响应过慢、JS特效及页面渲染时间较长，导致自动化测试失败。针对此类场景，本框架设计了一套NRetry机制，即某个case运行失败后，重跑N次，N可自定义。N次中有一次成功，则继续运行，若N次均失败，则截图、抛错，停止运行。NRetry机制，一定程度上可以降低由于网络、服务器响应过慢导致的自动化执行的不稳定性。

5.3.1、失败自动截图

1. 新建一个Java类继承TestListenerAdapter：

2. 重写onTestFailure、onTestSkipped等方法，在这些方法中加入截图操作：

3. 在testng.xml文件中配置自己编写的监听器类：

5.3.2、失败自动重跑

在运行自动化测试用例的时候，经常会出现一些异常的情况的情况导致用例失败的问题。所以我们可能会希望对于失败的测试用例再重新运行一次，框架中我们结合TestNG来实现这个功能。

1. 新建TestNGRetry类，实现用例失败自动重跑逻辑：

2. 添加用例重跑监听器RetryListener，用例失败自动重跑功能：

3. 在testng.xml文件中配置自己编写的监听器：

5.4、ReportNG

TestNG默认的HTML报表，其默认的报表虽然信息全面，但不易于理解。因此，我们利用ReportNG来替代TestNG默认的report。

ReportNG提供了一种简单的方式来查看测试结果，并能够对结果代码进行着色。还可以通过修改CSS文件来替换默认的输出样式。此外ReportNG还能够生成Junit格式的XML输出。
由于我们使用的是maven，所以我们主要来看看pom.xml的情况：

maven-surefire-plugin 这个插件主要是用于testng的。我们通过该插件，在对应的目录下./target/${timestamp}生成我们的测试报告目录。我们可以看到这个目录的结构。

这里实际上就是reportng的测试报告的生成路径。但是我们想要通过邮件发送会很难，因为html的内容需要加在额外的css,以及js文件。而邮件实际上是不支持外部的css以及js文件的。

HTML的生成

1、定义HTML模版

查看indexMain.html.vm：

在使用ReportNG替换TestNG自带报告时如果报告中含中文，由于ReportNG 里面Log 是不支持中文的，所以通过修改ReportNG.jar源码来支持报告内中文展示。

5.5、日志收集

日志是软件开发的重要组成部分。自动化执行过程的日志信息，对于失败用例的分析定位以及全过程的跟踪记录是十分重要的。

相对于简单的输出打印，本框架集成了主流的日志收集工具log4j。Log4j是高度可配置的，并可通过在运行时的外部文件配置。通过配置log4j.properties文件，定义日志级别内容及日志输出路径收集日志信息（诸如：数据库，文件，控制台，UNIX系统日志等），提供快速的调试，维护方便，以及应用程序的运行时信息结构化存储。

配置文件

Log4j可以通过java程序动态设置，该方式明显缺点是：如果需要修改日志输出级别等信息，则必须修改java文件，然后重新编译，很是麻烦；log4j也可以通过配置文件的方式进行设置，目前支持两种格式的配置文件：

xml文件；

properties文件（推荐）。

5.6、邮件发送

测试报告的发送可以结合Jenkins来实现，通过简单的配置即可实现。可是如果团队没有搭建jenkins或者有时jenkins不可用，我们应该如何去处理这部分的内容呢？

既然邮件不能够依赖jenkins,那肯定得自己去实现这部分的内容了。所以我们还是得依赖一些第三方的jar包。我们在pom.xml配置。

六、后续TODO

在后续的版本演进中，将把自动化测试、代码安全扫描、多机并行测试、持续发布都加入了整体过程，真正的做到全过程持续交付。

6.1、夜间构建加入自动化测试

夜间构建会按计划定期触发自动化构建过程，但这种构建只是简单的代码编译，没有可靠的或可重复的功能测试。后续考虑Appium结合Jenkins来实现构建后自动化测试工作。
无论任何时候，只要代码更新提交到git中，构建服务器就会触发一个构建，构建运行脚本去编译应用程序并且运行一系列的自动化单元测试和/或集成测试。通过自动化测试结果能够清晰的展示出那些功能特性是通过的，哪些是失败的。不管是有改动提交，还是定期在夜间触发构建，应用程序都会被自动部署到测试环境当中以便QA团队进行测试。

6.2、Jenkins与STF结合，实现多机并行测试

Jenkins构建脚本完成后，将没有安装stf组件电脑上连接的android设备，添加映射到装有stf平台服务的机器上，将集成测试用例push到STF平台，再由STF分发到可运行设备上，进行多机并行测试。

STF执行APPIUM测试带来的优势

第一、可以在真机上执行并行的Appium测试。由于最初的Appium使用对象是模拟器上或只是以每次一台设备的测试方法执行测试，而STF在原有的基础上扩展了Appium，最多可在数百台真机上同时执行测试的能力。

第二，不需要配置任何设备的Desired Capabilities。这种方式既简便，且减少了因为编辑脚本而产生的不同类型的错误。

第三，在STF上执行测试可以让用户即时浏览测试状况。也就是说，可以查看到测试执行的进度，即时的错误反馈，以及保留和查阅所有测试项目，测试脚本和测试结果（测试截图，测试日志，性能数据等）

6.3、代码质量度量

6.3.1、为什么要分析代码

对代码质量关注时，安排人工进行code review是需要的，但100%的code review却需要投入人员，消耗大量的工作量，而工具自动检查只需少量人工配置。

最主要的原因就是提高代码质量，了解RD在编码过程中犯过的错误可能对功能逻辑产生的影响，同时也推动RD让自己的代码更具有可读性和维护性，所以我们借鉴持续改进的流程，希望能够在这个过程中有所收获。

6.3.2、Jenkins引入Sonarqube进行代码持续审查

Sonar是一个用于代码质量管理的开源平台，用于管理Java源代码的质量。通过插件机制，Sonar 可以集成不同的测试工具，代码分析工具，以及持续集成工具，比如pmd-cpd、checkstyle、findbugs、Jenkins。通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。

6.4、email-ext实现Jenkins邮件通知功能

在Jenkins中配置实现邮件通知，Jenkins提供了两种方式的配置。

一种是Jenkins内置默认的邮件通知，但是它本身有很多局限性，比如它的邮件通知无法提供详细的邮件内容、无法定义发送邮件的格式、无法定义灵活的邮件接收配置等等。

在这样的情况下，后续考虑可以通过Email Extension Plugin来实现自定义邮件通知的方方面面，比如在发送邮件的同时可以自定义发送给谁，发送具体什么内容等等。

前 言

“接口测试”一个让人觉得非常高端的名词，特别是对于刚入门的测试同学而言。随着测试技术不断的深化，“接口测试”出现在我们视野中的频次越来越高。那么接口测试到底是如何做的？接口测试的优势又体现在哪些方面？

目录

前 言

接口

一、什么是接口？

二、接口的常见类型

三、前后端区别

接口测试

一、什么是接口测试

二、接口的组成

三、为什么要做接口测试

四、接口测试与UI测试优劣对比

五、接口测试流程

学习资源分享

接口

一、什么是接口？

接口：外部系统与系统之间以及内部各个子系统之间的交互点

-----百度百科

接口一般分为两种：程序内部接口、系统对外接口。

1、系统对外接口：例如最常见的系统对外接口—支付宝支付接口，很多app的支付功能都是调用支付宝的支付接口来进行支付，而该接口是支付宝系统提供给外部系统进行调用的

2、程序内部接口：模块与模块之间的交互，比如淘宝商城要购买商品，下订单前必须要先登录，那么下订单与登录之间就是一个交互，这个交互就是一个接口，让程序内部的其他模块进行调用的。

另外程序内部方法直接的接口调用。比如电商平台的前台和后台之间接口调用，前台开发人员用HTML或CSS或JS等技术，后台开发人员用JAVA,PYTHON等语言，若用户从前台输入数据，怎样将数据传到后台呢？主要是通过http协议的get或post请求来实现前后端的数据传递，这些都是接口测试的一部分。

二、接口的常见类型

webService接口：走soap协议通过http传输，请求报文和返回报文都是xml格式的。测试时需要通过工具才能进行调用、测试。少数公司还在使用这种接口，如医院等行业。

http api接口：走http协议，通过路径来区分调用的方法，请求和报文都是key-value形式的，返回报文一般都是json串，有get和post等方法。目前来讲，是最常用的。如RESTful基于http协议的接口。

dubbo接口: 走rpc协议，使用rpc协议进行远程调用，直接使用socket通信。传输效率高，并且可以统计出系统之间的调用关系、调用次数。使用Java语言开发，只能用于Java语言开发的项目间的通信，不具备跨语言，跨平台的特点！

硬件接口：USB 、充电接口（此处不做讨论）

三、前后端区别

做接口测试前，需要对两个概念有所了解，前端和后端

前端：通常为Web前端和app前端，前端的作用是为了展示数据内容，做简单的数据校验，比如我们看到的淘宝商城，那些商品信息，图片展示等等。

后端：进行复杂计算的业务逻辑，功能实现，例如我们购买商品后的价格计算，优惠活动的使用，最终的支付，都是通过后端实现的，而前后端就是通过接口来进行交互的。

接口调用示意图：

说明：输入条件也就是入参报文，经过接口程序处理之后，得到结果输出，也就是出参报文。

接口测试

一、什么是接口测试

系统组件间接口测试。主要是检测外部系统与系统之间，以及内部各个子系统之间的交互点，检查数据的交换，传递，和控制管理过程，以及系统间的相互逻辑依赖关系，适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部系统提供的接口，验证其正确性与稳定性。

-----百度百科

关于接口测试的说法：

1、接口测试即功能测试，是通过测试不同输入条件下，接口返回的结果是否与预期结果一致。

2、接口是用来连接客户端和服务端的，一般接口返回的数据都是json格式。

3、接口测试实质是数据测试，对数据库的各种操作(增，删，改，查)。

4、接口测试其实是一个非常简单的过程，将接口的业务逻辑处理看成黑盒测试中的黑盒子，我们只需要考虑各种输入条件下，会产生相应的什么结果。

接口测试是黑盒测试，但黑盒测试不一定只是接口测试。

我们知道黑盒测试又称功能测试，那么接口测试与功能测试是不是一回事呢？答案是否定的，为什么呢？

功能测试还包含了程序的UI层，包含了按钮，UI交互等功能，而接口测试是没有页面操作的，只能通过调用接口来进行测试，只需要给接口传递相应的输入条件，再检查接口输出的结果是否符合预期即可。某种程度讲，接口测试比功能测试还要更简单一些。

二、接口的组成

接口说明文档

接口url

请求方法：post或get

请求参数、参数类型、请求参数说明

返回参数说明

由接口文档可知，接口至少应有请求地址、请求方法、请求参数（入参和出参）组成，部分接口有请求头header，cookie。

标头 (header)：是服务器以HTTP协议传HTML资料到浏览器前所送出的字串，在标头与 HTML 文件之间尚需空一行分隔，一般存放cookie、token等信息

那么，header和入参有什么关系？它们不都是发送到服务器的参数吗？

首先，它们确实都是发送到服务器里的参数，但它们是有区别的，header里存放的参数一般存放的是一些校验信息，比如cookie，它是为了校验这个请求是否有权限请求服务器，如果有，它才能请求服务器，然后把请求地址连同入参一起发送到服务器，然后服务器会根据地址和入参来返回出参。也就是说，服务器是先接受header信息进行判断该请求是否有权限请求，判断有权限后，才会接受请求地址和入参的。

三、为什么要做接口测试

通过图我们知道，程序的前端(UI层)是用来展示数据以及简单的数据检验的，而真正的业务逻辑核心是后端。

在传统的功能测试中，如果前端工程师还没有将前端工作做完，我们测试是无法展开测试工作的，另一方面，既然前端有校验功能，那后端就有可能会遗漏该功能的数据校验，如果用户通过抓包绕过前端，直接进行后端操作，我们的程序就可能出现重大问题。

所以进行接口测试主要是因为：

尽早的测试介入，越早介入测试，发现的问题解决起来的成本是最低的。很多时候开发没有将完整产品提交给测试时，测试时无法工作的，就会有大部分时间处于等待状态，而接口测试可以在没有前端界面下进行测试

后端的功能校验在前端很难进行测试，因为前端已经有初步校验控制，所以接口测试可以发现很多在前端无法发现的问题

提升测试效率，降低人工回归测试的人力成本与时间成本，缩短测试周期

四、接口测试与UI测试优劣对比

接口测试的介入时间更早，越早介入价值越高。

接口测试的稳定性更高，变动少。接口测试通过，前端即时出现问题，解决起来也会非常快

接口测试发现缺陷后，解决的成本更低。越底层的缺陷，影响的面就越广，一个底层缺陷可能引起N个表面的缺陷，那时候解决起来就会非常麻烦，而且还不一定能找到源头缺陷

定位问题更加准确和快速。当我们接口测试通过后，在功能测试中出现问题，我们就可以更快速和准确的定位问题，因为已经排除掉接口层的干扰了。

五、接口测试流程

接口测试的原理跟功能测试是一样的，那么它的流程跟功能测试流程其实也是基本一致的。

接口测试 不等于 接口测试工具使用

很多人认为会使用接口测试工具就是会接口测试。其实接口测试远远不止是工具的使用，SoapUI也好，Jmeter也好，这些工具都是我们在进行接口测试过程中能够更方便的进行测试，而工具仅仅是工具，真正核心部分还是接口测试用例设计以及测试思维。那么当我们做接口测试时，到底需要做哪些方面的工作呢？

接口测试流程：

获取需求文档和接口文档

通过对需求文档分析出接口的业务逻辑要求以及业务边界

通过对接口文档分析出接口的技术指标（接口地址、请求方式、入参、出参）

接口测试用例设计（着重于接口测试数据准备）

使用接口测试工具进行接口测试

接口缺陷管理与跟踪

接口自动化持续集成

接口测试常用工具：

接口测试的工具很多，比如 postman、jmeter、loadrunner、SoapUI等，比较常见的是postman和jmeter。

简介下postman和jmeter：

1、Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get/post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。

2、jmeter是一款100%纯Java编写的免费开源的工具，它主要用来做性能测试，相比loadrunner来说，它内存占用小，免费开源，轻巧方便、无需安装，越来越被大众所喜爱。

接口测试怎么做：

通用接口用例设计

1、通过性验证：

首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。

2、参数组合：

现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id　　是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。

3、接口安全：

绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？

绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功

参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。

密码安全规则，密码的复杂程度校验

4、异常验证：

所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。

根据业务逻辑来设计用例

根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，这个每个公司的业务不一样，就得具体的看自己公司的业务了，其实这也和功能测试设计用例是一样的。

举个例子，拿bbs来说，bbs的需求是这样的：

1、登录失败5次，就需要等待15分钟之后再登录

2、新注册的用户需要过了实习期才能发帖

3、删除帖子扣除积分

4、......

像这样的你就要把这些测试点列出来，然后再去造数据测试对应的测试点。

请求状态码说明：

200 ：2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。

300 ：3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了，

400 ：400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面

500 ：5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果

自动化测试资源分享

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于进阶【自动化测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….

以上就是小编为大家整理的接口测试自动化-自动化测试框架

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。