接口异常是什么意思？

接口异常的意思就是服务器崩了，网络导致视频播放失败，接口出现了异常。

检查自己的网路是不是已经连接成功了，网速限速没，连接成功后再次登录，就可以看自己想要看的视频了。

页面分为上下两个部分，顶部为导航，底部为登录表单

首先我们创建登录组件，然后配置路由

配置路由，跳转以后再设置

导航栏部分可以使用Vant的 NavBar导航栏 组件，经过一番处理：

使用Vant的 form表单 组件设置

创建services/userjs，封装登录接口： 地址

引入，登陆成功，提示：

可以使用 Button按钮 组件的loading属性进行加载设置

通过loading属性设置按钮为加载状态，加载状态下默认会隐藏按钮文字，可以通过loading-text设置加载状态下的文字

设置给按钮，根据请求状态进行加载，但是光是设置loading请求依然会持续发送，建议再加一个disabled

学习页面和用户页面在登陆前后的访问结果是不一样的，为了能在其他组件中访问登录状态，应该使用Vuex统一管理，同时呢，也要注意将数据设置到本地存储，避免刷新导致重新登录

登录成功后我们要提交mutation存储用户数据

用户功能 与 学习功能 是需要登录才能访问的，如果没有登录，就应该跳转到登录页面。这里通过Vue Router的导航守卫处理

登录后我们应该跳回到上次访问的页面，处理方式：

login登录成功之后的跳转需要取决于redirect

通过这种方式设置的路由会出现

诸如此类的报错，这个报错并不会影响程序的进行，就是告诉你重定向了，不用刻意去管理

用户功能需要用户登录才能访问，接口也是一样的，如果不登录就去请求用户功能接口是很不合理，也很不安全的，这类接口进行请求时需要进行接口访问的权限认证，称之为， 接口鉴权

在项目中，通 Token 方式进行接口鉴权， Token 数据由服务器产生，在登录成功之后就要响应到客户端

在接口文档中得知，客户端请求接口时，通过请求头的 Authorization 字段发送 access_token 来进行身份认证，失败时的状态码为 401

由于要进行鉴权的接口有很多，所以我们在requestjs中通过Axios的请求拦截器统一处理

步骤：

尝试请求用户信息接口（随便找一个组件测试一下就成），验证之后请求里有access_token就没有问题啦

Token是具有过期时间的，过期之后的token就不能再继续使用，这时候就有两种方法来解决这个问题

刷新Token的方式：

Token过期可能会发生在任意接口操作时，可以通过Axios响应拦截器进行统一的处理。步骤如下：

目的：测试接口的正确性和稳定性；

原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做处理并向客户端返回应答，客户端接收应答的过程；

重点：检查数据的交换，传递和控制管理过程，还包括处理的次数；

核心：持续集成是接口测试的核心；

优点：为高复杂性的平台带来高效的缺陷监测和质量监督能力，平台越复杂，系统越庞大，接口测试的效果越明显

用例设计重点：通常情况下主要测试最外层的两类接口:数据进入系统接口（调用外部系统的参数为本系统使用）和数据流出系统接口（验证系          统处理后的数据是否正常）；

输入参数主要从以下几各方面设计：

a 必填项校验

接口文档中有是否必填的说明。参考接口文档即可。

b 参数长度校验

参考接口文档即可。

c 参数值的有效性校验

所以参数有效性的校验就需要结合实际业务场景，判断哪些数据是真实有效的数据，一定要确保所有真实有效的数据是可以验证通过的。

d 参数组合校验

不同的参数组合可能会存在不同的业务场景；

e 如果参数是枚举值，一定要各种枚举值都要测试，因为可能不同的枚举走的不同的业务流程；

f 参数值的默认值的校验

参考接口文档。

g 某些参数具有特定的生成规则，要单独针对生成规则设计用例，一定要保证真实有效的数据是可以验证通过的。

接口逻辑我用的设计方法是分支覆盖—>路径覆盖—>场景覆盖,同样也是要结合实际业务场景，根本不发生的业务场景就是无效的测试用例。

a 第一步先把业务流程图画出来；

b 依据路程图中的分支分别设计，不同分支不同的场景，这里就要把异常的场景考虑进去；如接口超时，接口异常，接口请求成功或失败，成功后怎么处理，失败后流程是否继续执行，失败后的数据怎么处理；

c 测试逻辑设计完成后要想一想不同的业务场景怎么去测试，需要哪些人员协助，

如接口超时怎么去测试，请求重复怎么去测试，请求并发怎么去测试

输入结果：正常输出和异常输出，常用的方法有错误推断法（列举出程序中可能存在的错误或者异常，根据他们选择测试用例）

注册和获取API密钥、查阅文档、构建请求、发送请求、处理响应。

1、注册和获取API密钥：首先需要在供应商的网站上注册账号并获取API密钥。

2、查阅文档：获取API密钥后，查阅供应商提供的API文档，文档将提供详细的信息，包括API的终端点、请求方法、参数等。

3、构建请求：根据API文档，使用选择的编程语言或工具构建API请求。

4、发送请求：发送构建好的API请求到供应商的服务器。

5、处理响应：一旦收到响应，则需要解析和处理返回的数据。可以根据文档中提供的数据结构解析和提取所需的信息。

如果只是单个接口的测试还是归属于功能测试。

平时我们是怎么做接口测试的？

接口文档、接口文档，一定要看接口文档。

初学者做接口测试必须要先会一个工具，postman、fiddler、charles。后两者更多应用于抓包，但都可以使用。

也可以自己写一个接口请求函数，然后给返回的响应数据做断言。达到接口测试的目的。

一般做单接口测试我们是从这几个方面考虑：

1、通过性验证，在测这个接口之前必须保证这个接口是可用的，是通的，相当于冒烟测试。

2、请求接口参数组合传参，在正常规则内进行组合传参，请求参数各个字段值验证，参数是否必传。

3、请求接口顺序（绕过验证），例如，登录后才能下单购买，当未进行登录时，下单接口请求是不能成功的。

4、异常验证，必填项验证、字符类型、长度等等，就是不按照接口文档进行传参。

5、安全性，验证header，敏感数据加密等。

6、响应结果，各种场景下请求接口的返回结果，对应的结构体和参数。

7、响应时间，遵守1357规则，根据实际场景而定。

8、接口逻辑，提交多次接口、并发，业务逻辑等。

当然有些小公司为了赶工期或者其他各种原因是没有接口文档的，那么这样情况该怎么办？

一句话，没有接口文档很难搞，抓包看参数，先保证接口通过性验证，然后从开发和产品获取信息，决定对那些进行验证。

再说下怎么判断bug是前后端谁的问题？

接口请求参数有问题找前端，返回参数有问题先分析下具体问题，一般是找后端（常见的40X/50X），路径或者是服务器的问题。

了解了接口测试是什么之后，怎么做接口测试呢接口测试的流程其实和功能测试流程类似：接口测试计划-接口测试用例-接口测试执行-接口测试报告。测试用例设计的依赖对象主要是需求说明书和接口文档。

接口测试因其不是针对普通用户，而是针对的另外一个系统组件，所以不能直接测试，需要使用工具测试，比如服务端http接口测试，常用的工具有jmeter、postman、httpclient等。用工具测试，所以目标就是准备要测试数据测试脚本后直接执行即可， 在进行测试执行编写时，有如下的原则：

1不同的接口参数覆盖不同的业务场景;

2在后台构造合适的数据来满足接口的测试用例;

3根据接口的返回值，断言其是否返回期望结果，并查看数据库验证;

4测试用例涉及多个步骤的，应对涉及的步骤都验证;

5删除测试过程中产生的结果，确保每个用例执行前都是一个清洁的环境

俗话说"无规矩不成方圆"，但是我要说无规范不和谐，你可能觉得言重了「言重个毛」，下面就简单的说一下吧

来一个场景对话吧，以开发一个 APP 为例子来说明「纯属虚构，如有雷同那真是中奖了」，小明「开发 client」，小张「开发 server」

如此类似的事情的在需求、产品、销售、运营等等各个地方都会出现，何也--没有规范，最后导致权责不明，各干各的，反工是家常便饭，更甚者会干起架来

无规范不和谐，花很小的代价获取更多大价值有时就体现在规范当中，规范最好以书面的形式「别拿嘴说，谁也不会记的」，规范的编写有多种形式，今天我们就来看看其中一个 docsify「文档网站生成工具」

规范基本上都以文档的形式出现的，写文档我们可以使用的工具实在太多了，小到记事本，大到一个综合软件太多太多了，先说一下笔者主要使用的文档编写工具，分为两个阶段「未了解 markdown 之前和之后」

现在我大部分使用 gitbook 来记笔记和写文档，只要把 markdown 语法熟悉了玩起这些来都是小菜，、csdn、掘金等自媒体平台都支持 markdown 了，markdown 一定要掌握「现在还不懂 markdown 那就太 low 了」，简单的说一下 gitbook 的流程

gitbook 有多种玩法，有兴趣的可以看看这部分内容

用官方的话来说 docsify 一个神奇的文档网站生成工具，如果看过 vue 的官方文档界面那就相当于看到了 docsify 生成的界面了「很清爽有么有」

docsify 不同于 githbook 和 hexo 它不会生成将 md 文件化成 html 文件，这些转化工作都是在运行时进行的

比如阿里 weex ui 的开发文档

这里就不一一列举了，可以查看 https://githubcom/docsifyjs/awesome-docsify/blob/master/READMEmd 的 showcase 部分

这样就安装完了 docsify 命令行工具「前提要安装 node」，安装完以后我们就可以使用 docsify init /docs 初始化项目了，然后运行 docsify serve docs 就可以在本地跑一个 server 来看到对应生成的网站了

我们就来一个 API 接口文档吧，大概完成以后这样的

还做一个国际化「只做了英文版的--装个 B 」,直接点击上面导航的 EN 来 Look 一下

怎么样够 B 格吧 ,服务端把这个文档给出一扔，还管个毛毛呢，直接并行开发吧「还 qq 对接？，还拿嘴对接？」

由于 docsify 的文档非常的详细，我们照着一点点的配置和编写半个小时就能入门，这里我们就把以上完成的 API 文档目录解析一下

主页 indexhtml

侧边栏 _sidebarmd

侧边栏对应的网页左边的导航页

_coverpagemd 封面

user/READMDmd

user/READMEmd 对应的就是 user 的主页，在这个例子中我们在此中写登录接口

对应的就是我们在上图中看到登录接口「我们再来看一下，如下图」

其它的 md

其它的 getuserlistmd/getuserifnomd 都是侧边栏对应的接口界面，这里就不一一说了，和登录界面是一样的「不细说了，文档介绍的非常详细」

我们大概介绍完了所制作的文档，这里起一个抛砖引玉的作用，完了可以看 Demo 的源码「上传到 github 上，后面放出地址」

可以定制主题、还有一插件列表「搜索、统计、在 github 编辑等等插件」，也可以自己开发插件等「非常丰富，我们可以看官网查看」

我们写的文档可以部署在 GitHub Pages 上，也可以部署在所有的静态文件服务器上等

这节我们简单介绍了一下 docsify 文档编写工具，只是起了一个抛砖引玉的作用，具体的好多玩法大家可以自行去探所，当然拿 docsify 来写笔记是非常不错的「笔者一直使用 gitbook 来写笔记」，还可以用它来写个博客啥的都是不错的

如果还不熟悉 markdown 语法的，建议现在就看一定要把它掌握了「简单又牛 B ，写个模版什么的使用 markdown 再适合不过了」

案例地址： https://githubcom/tigerchain/docsifydemo

作者: TigerChain 订阅查看更多内容。

本文出自 TigerChain 侃大山

公号: TigerChain