关于前端接口测试的探究和挖坑

2019年8月25日 227次阅读 来源: fox_soyoung

最先

近来几年，前端测试逐渐被人注重，相干的框架和要领已比较成熟。
断言库有should, expect, chai。 单元测试框架有mocha, jasmine, Qunit。 模仿浏览器测试环境有Phantomjs, Slimerjs。 集成测试使命管理东西有karma。另外，另有一堆诸如Selenium、nightwatch（冰火出戏）等各色思绪差别的关注UI测试的东西。
本文重要关注的是接口测试。
接口是前后端合作的桥梁，是体系得以顺遂运转的症结。所谓接口测试，就是搜检体系供应的接口是不是相符事前撰写的接口文档。数据构造是不是完整，数据范例和取值是不是相符规范。
现实上，接口测试由后端来做会比较轻易，然则由于一些现实缘由（后端老大比较忙，人手不足等），后端每每不能确保接口数据肯定相符接口文档划定。此时，作为前端，我们为何不能另辟蹊径，探究一番呢？

思绪剖析

接口测试最大的难点是什么？我以为是登录状况的猎取。
尽人皆知，一个体系的大部份接口都只会对登录用户开放。在测试接口之前，起首必需确保此次会话已登录，发送给背景的请求中必需照顾登录后猎取的 cookie。面临这个题目，最直接的主意是在背景模仿登录。

背景模仿登录

mocha 可以运转在node中，理论上我们完整可以在node环境下，运用一些http client( request, superagent等)，模仿举行登录。手动猎取cookie，并加在以后的每一次接口请求中。获获得接口数据后，就可以够连系 mocha，愉快地举行测试了。
但是，现实试验以后，我发明这个计划存在一些缺点。

  1. 难以封装复用
    差别体系的登录流程并不相同。相当多的体系请求在登录时须要附带其他的 cookie 或许分外的表单参数。
    以本人测试的体系为例，登录时就须要带上一个 key 为 jsessionid 的 cookie，以及一个 key 为 nlt 的表单参数。这个 cookie 是怎样来的呢？是接见登录页时返回的 set-cookie 头设置的。这个表单参数又是怎样来的呢？是藏在登录页面的表单中的一个隐蔽域。
    所以，假如简朴地用 http client 向登录地点发一个 post 请求，仅仅带上自身的用户名暗码，你就会发明，登录毫无疑问的···失利了。
    更烦人的是，假如你的体系登录依靠 SSO，内部存在 302 请求转发，那末很有可能会涌现 cookie 丧失的状况（有两个 set-cookie header，浏览器能辨认并准确设置，然则许多 http client 只能拿到末了一个）。
    我们固然可以动用种种奇技淫巧，手动猎取和设置种种特定的 cookie，去网页里爬出隐蔽域的值。但是，这一切，仅仅对特定的体系有用。假如换一套体系，你就必需从新研究一遍登录流程，从新写一遍模仿上岸代码，觉得照样挺崩溃的。

  2. 难以应对考证码
    上面的题目仅仅只是运用不方便，这个题目就是直接就给该计划判了极刑。固然，爬虫界也有不少应对考证码的处理计划，比方依托 OCR 软件啊，人工鉴别 API 啦, 更凶猛的另有自身做图象处置惩罚和算法举行辨认。但是，作为一个简朴的接口测试，这类计划是不是是太小题大做了点？

浏览器扩大

mocha 也可以在浏览器环境运转，当背景模仿上岸遇到困难，我们很轻易想到，在浏览器环境举行测试是不是可行呢？
一般的浏览器环境确切会有肯定题目，那就是前端的老大难：跨域。
我们的目的是前端接口测试，原则上不该也不能让背景搭配测试事情去改接口，所以，CORS，jsonp 都是不可行的。
岂非这条路又堵死了？非也，我们另有一个选项，那就是——浏览器扩大。
以 chrome extension 为例，只需在 manifest.json 文件中设置好 permissions ,扩大提议的请求就可以够胜利跨域。事实证明，完整没有题目。不仅可以跨域，还可以照顾登录后的 cookie，所以，只需在浏览器一般登录后，再翻开插件相干页面举行考证，就可以够处理登录状况的题目。几乎圆满。

计划设想

既然定下了计划，下一步就是设想。作为接口测试的解（wa）决（keng）方（zhi）案（lv），我们必需具有通用性与易用性。运用者只需供应设置，不须要再进入源代码修正打包。
本计划中中测试框架和断言运用 mocha + chai。这方面的材料汗牛充栋，本篇不再赘言。

目次构造

apiTest
    │  package.json
    │  webpack.conf.js
    │  api.conf.dist.js
    │  api.conf.dist.js.map
    │  index.js
    │  manifest.json
    │  test.png
    ├─config
    │  index.js
    ├─css
    ├─html
    ├─js
    ├─lib
    └─TestCreator

个中，index.js 是进口文件; manifest.json 是 chrome 插件设置文件; config/index.js 是用户测试设置文件。css, html, js, lib 都用于寄存资本文件。

运用流程

  1. 装置插件（假如已装置过就可以够省略）

  2. 供应测试设置

  3. 用户去体系登录页完成登录

  4. 点击插件图标，翻开新 tab 页

  5. 在 tab 页中举行测试，并在页面上显现效果

让我们从 manifest.json 文件最先，一步一步深切，看目的流程是怎样完成的。

– manifest.json

"permissions": [
    "tabs",
    "http://*/*",
    "https://*/*"
],
"background": {
   "scripts": "js/background.js"
}

在 manifest.json 文件中，定义 background 属性。定义的 js/background.js 文件将自动在背景运转。permissions 属性定义了扩大的权限。“tabs”指明可以翻开浏览器自身的 tab 标签页，背面两个设置指明浏览器可以向任何 url 发送请求。（不设置会跨域）

– js/background.js

chrome.browserAction.onClicked.addListener(function(){
  var url = chrome.extension.getURL("../html/main.html");
  window.open(url, "main_page");
})

在 js/background.js 文件中，注册了一个事宜函数。当用户点击插件图标时，翻开一个 html/main.html 作为新的 tab 页。我们一切的使命都将在这个 tab 页中完成。

– html/main.html

<!doctype html>
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <link rel="stylesheet" type="text/css" href="../css/demo.css">
  <link rel="stylesheet" type="text/css" href="../css/mocha.css">
  <script src="../lib/mocha.js"></script>
  <script src="../config/index.js"></script>
  <script src="../api.conf.dist.js"></script>
</head>
<body>
  <div id="ext-box">
    <button id="startBtn">请在上岸后点击按钮最先测试</butotn>
  </div>
  <div id="mocha"></div>
</body>
</html>

在这个 html 中，载入了三个 js 文件。个中，config/index.js 是测试设置文件。api.conf.dist.js 是进口文件经 webpack 打包后的压缩文件。mocha 之所以自力载入，是由于在浏览器环境中，mocha 必需布置在 window 对象下，所以不能打包进去。中间的逻辑代码，放在 api.conf.dist.js 文件中。
页面中安排了一个按钮和一个 id 为 mocha 的 div。前者点击后会触发 mocha 实行，后者作为一个容器，用于显现测试效果。

– index.js 

import {expect} from 'chai'
import test from './js/main'

function click(e) {
  mocha.run()
  document.querySelector("#startBtn").style.display = 'none';
}

document.addEventListener('DOMContentLoaded', function () {
  var btn = document.querySelector("#startBtn")
  btn.addEventListener('click', click);
});

mocha && mocha.setup('bdd')
mocha.timeout(4000)

const mainTest = testCreator(window.apiTestConf)
mainTest()

index.js 是打包的进口文件。这里重要做了两件事：
第一，为按钮定义了一个事宜监听函数，点击时实行 mocha。
第二，初始化 mocha，设置其实行形式(bdd)和超时时候。
第三，实行 mainTest 函数，在这里定义了一切测试用例。测试用例依据用户设置文件动态，这也是中间逻辑。下面将进一步详述。

测试设置的设想

下面展现本文运用的测试设置：

window.apiTestConf = {
  name:"foo",
  path:"http://baz/japi/platform/",
  common:{
    success: {
      value: true,
      type:["boolean"],
    },
    errorCode: {
      value: [0]
    }
  },
  publicStruc:[
    "results>items",
    "results"
  ],
  apis:{
    AccountCenter:{
      "110620001":{
        name:"获收货地点列表",
        fullUrl:false,
        data:{
          length:{
            min:1
          },
          item:{
            area:{
                type:"string"
            },
            areaStr:"string",
            consignee:"string",
            detail:"string",
            id:"number",
            ifDefault:"boolean",
            mobile:["string","number"]
          }
        }
      }
    }
  }
}

测试设置决议了测试用例的构造和测试用例内断言的编写。其构造进修了一些表单考证插件，比表单考证插件庞杂的处所在于，表单考证仅仅针对一维的单一字段，而接口返回的数据则是具有肯定的嵌套构造的。下面临该设置举行简述。

  • path：接口地点的大众部份。

  • common：对接口返回数据的花样上的大众部份举行考证。比方 success 必需为 true，errorcode 必需为 0 等。

  • publicStruc：接口中间数据部份的途径。体系将依据该途径一步步寻觅。假如没找到将会在断言中报错。假如定义了多个途径，则会按递次夙昔今后查找。

  • apis：中间部份，对接口数据举行考证。

  • AccountCenter：该 key 可变。在这一层级对接口举行分组，比方 AccountCenter 申明下面定义的是账户中间的接口的测试设置。

  • 110620001：该 key 可变。这是实在接口的途径。该 key 值下的对象，就是针对详细数据构造和字段举行设置了。下面将引见这部份的设置和考证划定规矩，可能会有点死板，不感兴趣的读者可以略过不看。

字段考证划定规矩

字段考证划定规矩：
字段考证划定规矩指的是接口下data属性下定义的划定规矩。是对接口中间数据的存在与否、数据范例和值所做的划定

  1. 基础划定规矩划定规矩

    • 划定规矩仅仅对范例是数字，字符串，布尔值和数组的字段有用，假如要考证的字段是对象，则不起作用。须要对对象内的属性（一样看作字段）做进一步的考证，而不是对对象自身做考证。

    • 考证属性可写的值是对象，数组和字符串，其他范例的值都是不法的

    • 考证属性假如是一个空对象，则直接经由过程。

    • 考证属性假如是一个数组或字符串，则视为 type 处置惩罚

    • 考证属性假如是一个最少包含了required, value, type三者之一的对象，则举行规范化考证

  2. required

    • 考证实在字段必需指定，且必需不为空字符串（也就是说false,0能经由过程考证。）

  3. value

    • 假如 value 是数组，则考证实在值是不是最少即是数组中的某一个值

    • 假如 value 是数字，字符串或许布尔值，考证实在值与其是不是相称

    • 假如 value 是一个对象，则进一步推断：

      • min:划定最小值，仅仅对数字有用

      • max:划定最大值，仅仅对数字有用

      • not:不为其值。可以是一个数组，此时不为数组中的一切值

      • start:最先字符，仅仅对字符串有用

      • end:完毕字符串，仅仅对字符串有用

  4. type

    • type 可写的值是字符串。这些字符串的可选值为:”number”,”string”,”boolean”,”array”。没有”object”,”undefined”,”null”，由于没有意义

    • type 可以是一个数组，数组中的值也是上面的可选值。此时，只需满足数组中的一个值，就可以经由过程考证

  5. length
    当数据是数组时才有用，是对数组长度做的考证

    • min:划定最小值，仅仅对数字有用

    • max:划定最大值，仅仅对数字有用

  6. item

    当数据是数组时才有用，内里进一步划定对数组中每一项的考证

设想完种种划定规矩后，接下来就是依样画葫芦地编写代码了。由于代码量比较多，这里就不再赘述。其中间头脑就是依据设置项天生种种测试用例和断言。末了供 mocha 运转，输出效果。

《关于前端接口测试的探究和挖坑》

完毕和瞻望

本文所设想的计划基础可以满足前端接口测试的请求，但照样有一些缺点，弊病，及有待革新的处所。

  1. 考证划定规矩触及不够周全和周密，有待雄厚，

  2. 可以将整体目次构造以及内部的 TestCreater 封装成 npm 包，更轻易运用。

  3. 测试经由过程时，没法看到经由过程了哪些断言。测试失利时，只输出未经由过程的第一条断言的信息。输出信息不够周全雄厚。这肯定程度上是 mocha 和 chai自身的特征，不知道有什么体式格局可以优化。

末了，本文中若涌现了毛病，或是读者有更好的计划，望不悭吝见教。

    原文作者：fox_soyoung
    原文地址: https://segmentfault.com/a/1190000009523962
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞