接口测试入门，部分人员主要从事功能测试，有的同学不了解接口测试，本文简要介绍了接口测试的定义与相关流程，适合刚入门的同学。

1 接口的定义

现实中我们的接口比如插销、插座等都是遵循一定的标准和规范制作的，以至于不同厂家生产出来的插头、插座可以共用。那么程序的接口也跟现实的接口的类似。

什么是程序接口，就是程序之间协作要遵循一套规范和标准，开发人员按照规范和标准进行工作，接口一般都是由高级开发人员设计出来的。

2 接口的优点

程序系统一般分为前端和后端，前端就是咱们看到的浏览器或者客户端，后端是后台的一些逻辑检查和控制，接口可以有效的将前端和后端区分出来。

责任划分清晰，找到问题能够划分出是前台的问题还是后台的问题，这样能够很快的定位问题，检查是否前台传值传错还是后台错误，这样能够很快的给开发人员修改问题。

缩短开发周期，标准一致，前台与后台按照同样的标准、规范，各自干各自的工作，并行开发，能够缩短开发周期。

可扩展性强。

3 API接口的概念

应用程序接口（API,Application Programming Interface），以某种协议的形式提供，定义输入、输出规范和相关功能的描述。

举例：登录功能，前端输入用户名和密码，提交后，后台收到前台请求进行处理，然后返回给前台响应结果。

接口文档定义字段为

用户名：user_name

密码：user_passwrod

前端开发人员与后台开发人员都应按照接口约定去传值和取值，当前台浏览器传值为name和password的时候，后台程序取的是user_name ，user_passwrod，导致数据无法获取，最终报错，因为前台没有按照接口文档来传值导致，很容易能判断出是谁的问题。

需要前后台开发人员都遵循接口的标准来传值与取值就可以了，也就是都用

用户名：user_name

密码：user_passwrod

这样就不会有问题了。

4 接口的测试流程

1）接口功能是正确的，保证基础功能是正确的

2）接口的测试数据（特殊数据）检查是否有问题，各种特殊数据对接口进行验证，边界值、特殊字符、空值等

3）自动化脚本的编辑与测试，接口测试过程中，需要多次进行测试，为了提高效率，可以使用工具进行测试，编写脚本，后续可以多次回归运行，比如jmeter

4）接口的性能和压力测试，基础功能都验证完毕后，也要检验下接口的性能，自动化脚本编辑好后，根据要测试要点，设置好测试数据，进行接口的性能和压力测试，检查是否存在瓶颈。

5 普及客户端、服务器、请求、响应概念

客户端：移动应用，web应用等，比如微信、网银、还有柜面程序等。

服务器：为客户端提供服务、提供数据、提供资源的那台机器，比如手机银行查询账户余额，余额的相关信息都保存在核心的服务器上，那想要获取数据，就要访问核心的服务器。

请求：客户端向服务器索取数据的一种行为，比如手机查询余额时，点提交按钮，这就是发出了一个请求。

响应：服务器对客户端的请求，做出的反应，一般指的就是返回数据给客户端。

6 http协议与URL

协议：计算机网络两台机器之间进行通信所必须共同遵守的规则或者规定。

http协议：超文本传输协议，是一个基于请求与响应模式的、无状态的、应用层的协议，只有遵循统一的 HTTP 请求格式，服务器才能正确解析不同客户端发的请求，同样地，服务器遵循统一的响应格式，客户端才得以正确解析不同网站发过来的响应。

URL（统一资源定位符）：简单来说，就是互联网上的地址、位置，每一个资源都有一个唯一的URL

格式：协议：//主机地址/路径

比如：

# URL格式
https://host:port/path?xxx=aba&ooo=bbc

##  http/https：这个是协议类型
##  host:服务器的IP地址或者域名
##  port:HTTP服务器的默认端口是80
##  path:访问资源的路径
##  url里面的？这个符号是个分割线，用来区分问号前面的是path，问号后面的是参数
##  url-params:问号后面的是请求参数，格式：xxx=aaa
##  多个参数用&符号连接

7 get与post请求

1、get请求重点在从服务器上获取资源，而post请求重点在向服务器发送数据。

2、get传输数据是通过URL请求，以字段=value的形式，用？连接置于URL之后，多个请求数据之间用&连接，这个过程用户可见，不安全，参数暴露。post传输数据是将字段与对应值封存在请求实体中发送给服务器，这个过程用户不可见，隐藏式的请求，相比是安全的。

3，get传输的数据量小，受URL长度的限制，但是效率高。post传输数据量不受限制，可以传输大量数据，所以传输文件时只能使用post，但是效率较低。请求较多时可能形成一个请求队列。

4，get方式只支持ASCII字符，因此向服务器传输中文有可能出现乱码。post支持标准字符集，可以正确传递中文字符。

7 测试工具

jmeter：Jmeter是一款优秀的开源测试工具， 是每个资深测试工程师，必须掌握的测试工具，熟练使用Jmeter能大大提高工作效率。

Jmeter 是一款使用Java开发的，开源免费的，测试工具， 主要用来做功能测试和性能测试（压力测试/负载测试），而且用Jmeter 来测试 Restful API, 非常好用。

官方网站：http://jmeter.apache.org/

解压后， 运行 “bin/jmeter.bat”

8 测试实战

目的：获取某个城市的地区代码

发送request 请求获取城市的城市代号，http://toy1.weather.com.cn/search?cityname=北京 ，从这个请求的response 中获取到北京的城市代码. 比如:北京的地区代码是101010100_beijing北京

jmeter配置：

1）建立线程组

2）线程组下建立http请求

3）配置http请求参数

4）添加查看结果树，便于查询运行结果

5）试着运行，查看

请求数据如下：

响应结果数据如下

获取到了城市代码，说明接口已经调通，然后就可以根据接口的测试流程来验证整个接口的功能。

本文主要介绍了接口方面的测试知识，相对比较初级，希望能对刚入行的伙伴有一点帮助，喜欢的话可以点个“在看”哟，鼓励一下。

最后： 可以关注公众号：伤心的辣条 ！ 进去有许多资料共享！资料都是面试时面试官必问的知识点，也包括了很多测试行业常见知识，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

好文推荐

转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！

面试经：一线城市搬砖！又面软件测试岗，5000就知足了…

面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作？

那个准点下班的人，比我先升职了…

测试岗反复跳槽，跳着跳着就跳没了…

Jmeter是一款性能测试工具，因轻量级、开源、社区接受度高、容易入门等优点，也被测试人员广泛用于做接口测试。在使用Jmeter做较大规模、复杂场景的接口测试时，往往会遇到一些困难。阅读本文你将了解：

• 在工作时间紧张情况下，如何做好自动化测试？
• 如何设计一套完整的、结构优化的jmeter接口自动化测试方案？
• 如何设计复杂的Jmeter接口测试用例？
• 如何提升编写Jmeter自动化脚本的能力？

项目背景

被测系统是泰康云TDS平台，该平台整合敏捷开发与DevOps研发管理工具，提供产品规划、项目管理、代码托管、代码检查、持续集成和持续发布、制品管理等能力，简化研发协作过程，帮助研发团队完成软件生命周期管理。本篇内容以TDS平台测试为背景，介绍测试人员如何设计接口自动化测试。

遇到的问题

本文从我们工作中常遇到的问题入手，展开问题，详细解答。
问题一：被测项目迭代频繁，测试用例设计、维护、执行已经占用了测试工程师大部分工作时间，没有时间搞自动化怎么办？

问题二：为什么选jmeter做接口自动化测试？

问题三：多人协同测试情况下，自动化脚本结构如何设计？

问题四：单接口测试用例设计、执行、断言比较简单，但是涉及多接口、异步等复杂场景该如何设计用例？

问题五：接口测试用例如何断言？只断言被测接口返回值就可以了吗？

问题六：Jmeter与流水线集成，除了jmeter+ant+jenkins，还有更优的方案吗？

问题七：如何度量接口自动化结果？接口用例成功率达到100%就够了吗？

问题八：测试脚本执行过程中遇到的稳定性、执行效率等问题如何解决？

实践分享

问题一：没有时间搞自动化测试？

下面将从敏捷项目迭代特点和自动化测试时间规划这两个方面，介绍我们是如何确认自动化测试目标、安排自动化测试时间的。

1>分析敏捷项目迭代特点，确认自动化测试目标

下图展示了在敏捷开发模式中，随着项目迭代进行，新功能特性与已有功能特性的数量变化。每个迭代新特性的测试工作量变化不大，但是已有特性的回归测试任务量却是累计增加的。

因此我们自动化接口测试的目标是针对已有特性做自动化回归测试，提升回归测试效率。而对当前迭代的新特性以手工测试为主，自动化测试为辅。

• 针对当前迭代新特性，手工测试为主，自动化测试为辅。原因分析：

  当前迭代中的新功能是逐渐成长起来的。功能可能不稳定，需要修改优化，对新功能立即开发自动化测试脚本投入成本大；

  当前迭代中的新功能，借助沟通，通过手动形式直接验证更有效；

  每天发好几个版本，增加什么就测试什么，手工测试灵活性高。

• 针对上一个迭代已有特性，采用自动化回归测试。原因分析：

  上一个迭代已有功能相对稳定，自动化脚本开发和调试都没有障碍，脚本开发效率更高；

  自动化测试发现缺陷的能力比手动测试弱，用于回归测试更符合自动化测试的特点。

2>为自动化测试腾出时间

方法：

• 在迭代初期，通过思维导图梳理测试点，而不一定要写详尽的测试用例，从而节省时间编写上一个迭代特性的自动化测试脚本和脚本维护；
• 在迭代测试过程中，利用探索式测试风格，持续开展测试学习、设计、执行、结果分析，提高测试效率，积累测试经验，节省测试时间。

问题二：为什么要用Jmeter做自动化接口测试？

用Jmeter做接口测试工具有以下优势：

• 支持测试脚本录制，badboy、blazemeter等；
• 支持多平台部署，易于与流水线集成；
• 开源免费，提供丰富组件及第三方插件库；
• 支持多线程组并行，提高接口测试效率；
• 一学多用，接口测试->性能测试。

问题三：多人协同测试，自动化脚本结构如何设计？

Jmeter元件组合是非常灵活的，为了提升用例维护效率、方便多人协作，我们参考相关资料及项目实践经验，总结了如下图脚本结构：

以下为主要脚本结构及对应Jmeter元件说明：

测试计划：项目根节点

jmeter相关元件说明：

TestPlan：控制测试用例执行方式：并行/串行

全局参数配置：

jmeter相关元件说明：

User Defined Variables：存放测试环境（dev/test）配置信息

JDBC Connection Configuration：存放数据库连接配置

HTTP Request Defaults：配置http接口默认参数，全局生效，eg：请求timeout=10000ms

当前脚本通用模块库：存放所有测试相关采样器，由用例模块通过模块控制器调用

包含健康检查相关、webShell相关、数据准备模块、变量初始化模块、数据断言模块、登录模块、团队管理模块、流水线模块、制品管理模块等业务模块

jmeter相关元件：

Transaction Controller

HTTP Request Sampler

JDBC Request Sampler

WebSocket request-response Sampler

WebSocket Open Connection Sampler

Response Assertion

JSON Assertion

BeanShell Assertion

历史组件/模块设计参考

接口测试模板

用例模块：存放接口测试用例，通过模块控制器调用当前脚本通用模块库

包含：项目管理、部署组管理、svn管理、团队管理、流水线管理、代码库管理、制品管理等相关测试用例集合

jmeter相关元件

Test Fragment：作为用例分割符

Thread Group：用例组，存放一组相关测试用例

Transaction Controller：事务控制器

Module Controller：调用当前脚本通用模块库

User Defined Variables：存放用例相关测试数据

BeanShell Sampler：实现用例编号自增，参数传递等

测试结果展示

View Results Tree

Summary Report

问题四：复杂场景如何设计用例？

复杂场景用例设计之前，先分享下从功能角度出发，我们是如何设计用例的。如下图所示：

除此之外，结合项目实际情况，还需要考虑其他非功能场景：

• 异常测试，eg：幂等（重复提交、超时重试）、接口事务、分布式场景、环境异常、大数据量等；
• 性能测试，eg：响应时间、吞吐量、资源利用率等；
• 安全测试，eg：敏感信息是否加密、接口权限控制、sql注入等。

下面以实际项目中的两个场景为例，来分享我们是如何应对复杂测试场景的。

1、多接口实例：流水线执行场景测试，涉及6个接口

方法：

步骤1、分析相关接口调用顺序、阶段。

前置准备

新建项目接口、项目关联代码库接口、新建部署组接口

用例执行

新建流水线接口、流水线执行接口

后置处理

项目删除接口

步骤2、测试数据梳理：

需要在运行前初始化的数据，包含：

环境配置信息，eg：ip、端口、数据库配置等

测试场景共享数据，eg：代码库信息

单接口测试数据

运行时动态生成的数据，包含：

某个接口的返回数据，其他接口需要使用，eg：项目id、部署组id、流水线id等

需要调用相关函数或工具动态生成的数据，eg：uuid、时间戳等

步骤3、梳理测试用例，编写相关脚本，脚本图示如下：

2、异步实例：流水线配置定时任务后，验证定时任务是否按照配置时间成功触发

难点分析：流水线配置定时任务不会立即执行，定时任务触发需要等待websocket推送消息
方法：

步骤1：新建流水线配置定时任务执行时间为当前时间+1min

使用beanshell采样器实现

Calendar calendar = Calendar.getInstance();//获取当前时间
calendar.set(Calendar.MINUTE,calendar.get(Calendar.MINUTE)+1);

步骤2：通过WebSocket request-response Sampler监听定时任务推送的消息，完成断言。脚本图示如下：

问题五：接口测试用例如何断言？

对于接口的正确性验证，只验证被测接口返回body很明显是不够的，这里总结了如下断言方法：

• 基础断言：

  响应断言

  正则匹配

  响应码匹配

  jackson + beanshell断言

import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
  //获取接口返回body--实际结果
String json_response = prev.getResponseDataAsString();
  ObjectMapper mapper = new ObjectMapper();
JsonNode rootNode = mapper.readTree(json_response);
  JsonNode dataNode = rootNode.path("data");
  JsonNode totalNode = dataNode.path("total");
  String actual = totalNode.toString();
  //接口返回的总条数--期望结果
  String except = vars.getObject("program_source_data").size().toString();
  if(actual.toString().equals(except)){
    Failure = false;  

  }else{
    Failure = true;
    FailureMessage = "期待数量："+except+" VS 实际数量:"+actual+"不一致";
  }

• 相关接口辅助验证：

• 数据库匹配，JDBC Request + BeanShell断言，示例如下：

// JDBC Request 采样器 获取返回结果  -> triggers_count
SELECT
count(*)
FROM
  qrtz_triggers a 
WHERE
  a.JOB_NAME LIKE '%${search_key}%' ORDER BY JOB_NAME desc;
//  BeanShell断言
String except = vars.get("except_count");//期望结果
String actual = vars.get("triggers_count_1");//数据库查询到的总条数
if(actual.equals(except)){
  Failure = false;
}else{
  Failure = true;
  FailureMessage = "期待数量："+except+" VS 实际数量:"+actual+"不一致";
}

问题六：jmeter+ant+jenkins如何改进？

jmeter+ant+jenkins是一种常用的流水线集成方法，但在集成过程中存在环境配置繁琐的问题，比如：

• 需要安装jdk、ant、jmeter环境，版本变更还需要重新卸载安装

• jmeter依赖第三方jar包，每次都需要手动打包上传服务器

• jmeter配置文件变更，需要去服务器手动修改

• jenkins中不同流水线依赖jmeter版本不一致时，需要手工安装多个jmeter版本

针对以上问题，我们采用的替代方案是 jmeter-maven-plugin + mvnw ，运行环境只需要安装jdk就可以了，将maven、jmeter版本以及第三方jar包管理，都托管到gitlab一个代码库中进行集中管理。

进行接口测试只需要git clone代码，然后执行 mvnw clean verify就可以触发测试执行。代码库配置如下图：

工具依赖

问题七：如何度量接口自动化结果？

1、jmeter原生报告优化

jmeter CLI运行方式产生的测试报告统计信息偏向性能指标，无法满足jmeter接口测试需求。因此使用dom4j解析jmeter生成的xml结果文件，使用ExtentReports5生成html报告，报告示例如下：

2、使用jacoco统计接口测试代码级覆盖率报告

接口测试用例成功率即使达到100%，仍然会存在漏测。因此使用jacoco来统计代码覆盖率，分析接口测试未覆盖的代码，进行测试用例补充完善。

关键步骤说明：

步骤1：被测服务打桩

java -javaagent:jacocoagent.jar=includes=*,output=tcpserver,port=9002,address= * -jar 被测服务.jar

步骤2：调用jmeter脚本执行测试

./mvnw clean verify --settings=settings.xml

步骤3：dump覆盖率报告

java -jar jacococli.jar dump --address 被测服务IP --port 9002 --destfile ./jacoco1.exec

步骤4：生成覆盖率报告

java -jar jacococli.jar report ./jacoco1.exec --classfiles BOOT-INF/classes --sourcefiles /src/main/java --encoding utf-8 --html jacoReport

报告展示如下图 ：

问题八：如何提升用例执行稳定性和效率？

当测试case数量持续增加时，需要考虑执行稳定性和效率。

总结如下：

预置数据代替创建过程

由于操作越多稳定性越低，使用预置数据而非实时生成的数据，速度更快，稳定性更高。

隔离

使用不同账号等进行隔离。通过隔离，用例执行失败的脏数据就不会影响其他用例；

自动化脚本测试数据与功能测试数据隔离。

jmeter配置优化

设置全局采样器超时等待，eg：timeout=12000ms , 超时自动失败；

针对性能较差的接口配置jmeter定时器 , 防止被测服务压力过大；

设置JMeterProcessJVMSettings，增大内存。

防御式编程

编写测试代码时 , 不能假设数据已存在或者没有脏数据残留，所以预先的判断和清理很重要，比如检查到数据缺失就实时修复、用例运行之前考虑清除临时数据。

不足之处，欢迎指正。

最后： 可以在公众号：伤心的辣条 ！ 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！喜欢软件测试的小伙伴们，可以加入我们的测试技术交流扣扣群：914172719（里面有各种软件测试资源和技术讨论）

好文推荐

转行面试，跳槽面试，软件测试人员都必须知道的这几种面试技巧！

面试经：一线城市搬砖！又面软件测试岗，5000就知足了…

面试官：工作三年，还来面初级测试？恐怕你的软件测试工程师的头衔要加双引号…

什么样的人适合从事软件测试工作？

那个准点下班的人，比我先升职了…

测试岗反复跳槽，跳着跳着就跳没了…

一、关于Mock测试

1、什么是Mock测试？

Mock 测试就是在测试过程中，对于某些不容易构造（如 HttpServletRequest 必须在Servlet 容器中才能构造出来）或者不容易获取的比较复杂的对象（如 JDBC 中的ResultSet 对象），用一个虚拟的对象（Mock 对象）来创建以便测试的测试方法。

2、为什么要进行Mock测试？

Mock是为了解决不同的单元之间由于耦合而难于开发、测试的问题。所以，Mock既能出现在单元测试中，也会出现在集成测试、系统测试过程中。Mock 最大的功能是帮你把单元测试的耦合分解开，如果你的代码对另一个类或者接口有依赖，它能够帮你模拟这些依赖，并帮你验证所调用的依赖的行为。比如一段代码有这样的依赖：

当我们需要测试A类的时候，如果没有 Mock，则我们需要把整个依赖树都构建出来，而使用 Mock 的话就可以将结构分解开，像下面这样：

3、Mock对象适用场景

（1）需要将当前被测单元和其依赖模块独立开来，构造一个独立的测试环境，不关注被测单元的依赖对象，只关注被测单元的功能逻辑。

　　-----比如被测代码中需要依赖第三方接口返回值进行逻辑处理，可能因为网络或者其他环境因素，调用第三方经常会中断或者失败，无法对被测单元进行测试，这个时候就可以使用mock技术来将被测单元和依赖模块独立开来，使得测试可以进行下去。

（2）被测单元依赖的模块尚未开发完成，而被测单元需要依赖模块的返回值进行后续处理。

1）前后端项目中，后端接口开发完成之前，接口联调；

2）依赖的上游项目的接口尚未开发完成，需要接口联调测试；

　　-----比如service层的代码中，包含对Dao层的调用，但是，DAO层代码尚未实现

（3）被测单元依赖的对象较难模拟或者构造比较复杂。

　　-----比如，支付宝支付的异常条件有很多，但是模拟这种异常条件很复杂或者无法模拟，比如，查询聚划算的订单结果，无法在测试环境进行模拟。

4、Mock测试的优势

（1） 团队可以并行工作

有了Mock，前后端人员只需要定义好接口文档就可以开始并行工作，互不影响，只在最后的联调阶段往来密切；后端与后端之间如果有接口耦合，也同样能被Mock解决；测试过程中如果遇到依赖接口没有准备好，同样可以借助Mock；不会出现一个团队等待另一个团队的情况。这样的话，开发自测阶段就可以及早开展，从而发现缺陷的时机也提前了，有利于整个产品质量以及进度的保证。

（2）开启TDD模式，即测试驱动开发

单元测试是TDD实现的基石，而TDD经常会碰到协同模块尚未开发完成的情况，但是有了mock，这些一切都不是问题。当接口定义好后，测试人员就可以创建一个Mock，把接口添加到自动化测试环境，提前创建测试。

（3）可以模拟那些无法访问的资源

比如说，你需要调用一个“墙”外的资源来方便自己调试，就可以自己Mock一个。

（4）隔离系统

假如我们需要调用一个post请求，为了获得某个响应，来看当前系统是否能正确处理返回的“响应”，但是这个post请求会造成数据库中数据的污染，那么就可以充分利用Mock，构造一个虚拟的post请求，我们给他指定返回就好了。

（5）可以用来演示

假如我们需要创建一个演示程序，并且做了简单的UI，那么在完全没有开发后端服务的情况下，也可以进行演示。说到演示了，假如你已经做好了一个系统，并且需要给客户进行演示，但是里面有些真实数据并不想让用户看到，那么同样，你可以用Mock接口把这些敏感信息接口全部替换。

（6）测试覆盖度

假如有一个接口，有100个不同类型的返回，我们需要测试它在不同返回下，系统是否能够正常响应，但是有些返回在正常情况下基本不会发生，比如，我们需要测试在当接口发生500错误的时候，app是否崩溃，别告诉我你一定要给服务端代码做些手脚让他返回500 。而使用mock，这一切就都好办了，想要什么返回就模拟什么返回，不用再担心我的测试覆盖度了！

5、Mock测试存在的问题

使用Mock测试有时可以提高团队的开发效率，但当B、C都开发完成代码后，这时应该把E2E测试代码从使用Mock测试改为调用真实的模块，以避免出现模块之间集成部分漏测的问题。这里说mock存在的问题，主要是让开发和测试不要过分的依赖/相信mock接口。

使用mock时，切记的几点：

1）测试人员不应该被覆盖率高的E2E自动化测试所迷惑，覆盖率高不代表没有问题。尤其在接手新项目中，需要查看E2E测试中有没有使用Mock测试，进一步去判断这些地方使用Mock测试是否合理，这些Mock测试是否应该换成真实模块间的调用和集成。

2）当把mock接口换成实际接口后，测试/开发也必须把之前的测试重新做一遍。

ps: 当你使用mock接口来提高效率，请注意：你的工作量其实是比 直接只用实际接口 多了 一倍的。如果测试时，偷懒，替换成实际接口后，只是简单测试，那么 当实际接口和mock预期接口有差异时，故障便和你相遇了。

建议： mock接口只能主流程联调/ 异常返回测试，不要过分依赖mock接口进行测试。

3）测试完毕，上线前，请一定确保 为了mock而做的相关代码/配置文件的修改，已经完全恢复了。

建议：上线checklist中条条列出，并上线前review

---------------------

原文：https://blog.csdn.net/huazhongkejidaxuezpp/article/details/67018676

二、Mock测试方式

1. Mock Server-Moco

这是一个jar包，只要执行该jar包，指定配置文件，就可开启一个http服务器提供服务，并且修改配置文件后也无需重启服务，支持动态加载。我使用的是moco-runner-0.10.2-standalone.jar，运行方式如下：

```java -jar moco-runner-0.10.2-standalone.jar start -p 8080 -c XXX.json```

XXX.json就是我们的mock配置文件，比如：

[     {         "description": "api 1",         "request" :{             "method" : "get",         "uri" : "/foo"         },         "response": {             "json": {"foo":"bar"}         }     } ]

以上就可以实现当我们访问127.0.0.0:8080/foo时，返回一个json为{"foo":"bar"}。

具体其他使用方法请参照官方文档：https://github.com/dreamhead/moco/blob/master/moco-doc/apis.md

2. fiddler

fiddler大家都很熟了，在windows环境可以随便自定义返回内容，但一个很大的缺点是，它不跨平台，而我们平时的很多场景下，是需要在Linux下进行mock的。

还有一些其他mock工具，大多都是通过编写js代码或者python、java等代码来达到mock目的，此处就不再介绍了。

在选择mock工具时，可参考以下几个方面：

一是数据要好管理，别让我管理一堆文件；

二是mock接口最好可以设置成和真实接口完全一致，这样就只需要切换hosts就可以切换mock接口和真实接口，不需要修改代码；

三是跨平台，mock接口在windows和Linux下都需要可用。至于跨域、动态加载什么的，这是必须条件。

三、Mock测试示例

1、使用Fiddler进行Mock测试

------这种调试方式适用于rest接口调试，web界面调试等。

测试工程师在做测试时，也需要服务器返回一些特殊的数据来做测试，使用 Fiddler AutoResponder功能来伪造测试数据（创建虚拟对象），能大大减少测试工程师的工作量。

1.1 Fiddler AutoResponder工作原理

使用Fiddler可以替换自动返回的一个【伪造】的HTTP响应，这与使用断点修改HTTP响应类似，只不过AutoResponder是自动的，操作更加方便。即，浏览器发出的HTTP请求并没有到达服务器，而是被Fiddler直接返回了一个【伪造】的HTTP响应。

1.2 使用Fiddler进行Mock测试

（1）接口抓包-----找到要mock的接口

以掘金首页为例，找到下面的接口 https://gold-tag-ms.juejin.im/v1/categories

（2）复制接口数据到本地

在接口上进行右键点击，选择save -> …and Open as Local File -> 默认会保存至桌面，示例中的数据，保存到了桌面的test.json

（3）修改数据

修改保存到本地的json文件，示例中仅修改了页面的标签数据。

（4）替换json文件

在web session 面板中找到对应的请求，然后将其拖到AutoResponder面板中，在RuleEditor中单击“Find a file...”，选择本地json文件的路径。

（5）激活规则

选中“Enable rules”，激活规则。选中“Unmatched requests passthrough"，放行不匹配的HTTP请求。

（6）save，刷新页面

单击“Save”按钮。只需修改本地保存的json文件，然后刷新浏览器（或直接访问接口），就可以看到效果了。

*PS：部分内容根据网上资源整理，此博客仅作个人学习使用。