MOCK API 的定义
根据百度百科的定义, mock 测试就是在测试过程中, 对于某些不容易构造或者不容易获取的对象, 用一个虚拟的对象来创建以便测试的测试方法. 这个虚拟的对象就是 mock 对象, mock 对象就是真实对象在调试期间的代替品.
在瀑布流开发模式中, 如果前端开发人员需要进行页面对接, 需要后端先完成 API 的开发工作, 如果没有 mock, 那么前后端开发的进度会互相影响.
通过 Mock API 事先编写好 API 的数据生成规则, 由工具动态生成 API 的返回数据. 开发人员通过访问 Mock API 来获得页面所需要的数据, 就可以轻松地完成对接工作.
MOCK API 能用来解决什么?
1. 依赖的接口尚未开发完成
在系统交互双方定义好接口之后, 我们可以提前进行开发和测试, 并不依赖上游系统的开发实现.
2. 自定义返回测试结果 (比如 HttpservletRequet,JDBC 对象等)
在测试时使用 Mock, 可以自由方便的构建配置接口对象的信息参数;
在测试过程中, 需要第三方接口返回特定的数据以符合特定的测试场景, 这种情况往往需要跨条线的沟通协调测试数据, 成本高, 效率低; 利用 Mock 可以自定义返回测试结果, 支持手动构造依赖接口的返回值.(这个功能将在后面重点提及)
3. 自动化测试
在自动化测试概念和发展要求下, 自动化测试的规模也逐渐增大到一定程度;
大型业务系统下测试接口多, 测试用例也日益增多, 依赖环境的稳定就成为了自动化测试执行的关键所在;
自动化测试过程中, 经常会因为依赖的第三方环境不稳定, 导致测试执行失败, 长期以往的出现问题, 导致测试人员对自动化的稳定运行失去维护的信心;
利用 Mock 技术, 在测试过程中, 只关注被测业务逻辑, mock 掉依赖不相关的系统, 这种情况下自动化测试运行失败, 就一定是被测系统本身的业务逻辑问题, 而不是第三方系统, 数据的问题;
4. 更多场景, 欢迎看客老爷补充.
应用场景示例 (自定义返回结果)
接下来我们从测试的层面举个场景:
我所在的项目是企业管理咨询, 项目最经常需要的是根据企业详情判断返回不同的状态. 涉及到的数据其实很多, 但是为了方便举例, 我计划写三个接口进行演示, 第一个是登录, 第二个是获取企业详情, 简化了复杂的判断, 直接用判断 corpld(企业 ID) 来作为识别的凭证, 第三个是设置企业状态, 有注销和恢复两种状态. 会根据企业的 corpstatus 进行判断. 接下来带你一一设置:
登陆接口不必多讲, 我们直接到第二个接口, 新建一个期望, 请求触发条件不写, 在返回数据这里添加 corpstatus 可能值为 1 或者 2.
第三个接口是设置企业状态 (注销 / 恢复), 这里需要两个请求参数, 第一个是 corpld 企业 ID, 对应上个接口的 corpld; 第二个是 corpstatus 企业状态, 这里引用了全局变量, 用两对花括号表示.
还是进入 mockapi 新建期望, 因为这里有两个状态 (注销 / 恢复), 所以需要写两个期望. 当请求参数 corpstatus=4 条件触发时, 返回参数 content = 注销成功; 当请求参数 corpstatus=2 条件触发时, 返回参数 content = 企业已恢复.
由于这三个接口都是应用在一个场景里面的, 我们不妨用一个流程进行测试的, 总共三个测试用例:
1. 登陆
2. 获取企业详情
3. 设置企业状态 (注销 / 恢复)
在测试前需要在第二个用例中要写好一个响应预处理, 通过 JavaScript 代码动态改变返回的结果, 实现 corpstatus=2 或者 4, 从而对应上之前的全局变量.
然后就可以点击进行测试. 从测试记录可以看到会根据 corpstatus 的不同返回了不同的信息.
这就是一个简略完整的一个场景用例设计. 那如果没有 mockapi 的话, 等着后端开发, corpstatus 可能就拿不到, 进度势必会被影响, 为了模拟数据测试, 这时候 mockapi 的优势就凸显了.
下面再讲一个使用 mock 自定义功能的项目场景:
之前所在公司子系统较多, 我们为了减低集成和维护成本, 采用了 ESB 的架构. ESB 架构可以解决多个应用系统互联所面临的的复杂性. 也是因为子系统较多导致整个业务系统的运转比较复杂, 其中便涉及到和多个外部系统的对接及数据交互, 比如仓储和物流, 势必会跟 EMS, 顺丰等有数据交互.
当然, 跟外部系统对接时系统间的联调测试必不可少, 有些外部系统提供测试环境, 有些甚至不提供. 即便是提供测试环境的外部系统, 一般也仅在开发联调阶段配合提供联调测试对接服务, 一旦联调测试结束, 也不再继续提供测试服务.
那么, 当这些外部系统的联调测试环境不可用时, 我们就需模拟这些外部系统来和自己的系统进行数据交互, 以便支持完整业务测试流程的正常进行.
再具体到 API 开发层面的话, 就是开发的 API 经常遇到在 URL 一样的情况下, 需要根据请求头或者请求体的不同, 返回不同测试结果. 以前没用 mockapi 自定义的功能的话, 解决的方式只有新建多个接口分别进行, 十分麻烦.
举个例子, 在 API 文档建立后, 在进行测试时, 我的要求是在 URL 一样的情况下, 根据不同的请求头部返回不同结果.
1. 当标签头部
- Contest-type=application/JSON
- Clientld=purchase.consemer
- OperationCode=medicine.purchase.consemer.List
那么返回参数
- Floor=2
- Room=2
- Cabinet=2
2. 当标签头部
- Contest-type=application/json1
- Clientld=purchase.consemer1
- OperationCode=medicine.purchase.consemer.List1
那么返回参数
- Floor=3
- Room=3
- Cabinet=3
使用 eolinker 进行自定义 mockapi
eolinker 是一款接口管理工具, 提供 API 管理, 测试功能, 本次我们使用它来进行 Mock API, 官网地址: https://www.eolinker.com
1. 先建立好文档
2. 建立期望进行测试
3. 写完后测试后返回的数据与我们的想要的一致.
4. 第二种情况类似, 就不赘述了.
本篇文章主要从测试层面和角度去介绍 mockapi, 下篇我会从开发的层面去介绍 mockapi 的实际应用. 希望对大家有所帮助. eolinker 官网: https://www.eolinker.com
来源: http://www.jianshu.com/p/988e77024c98