企业官网建设流程全解析

一，接口测试

1.1 初步认识接口

接口一般分为两种，一种是程序内部的接口，一种是系统对外的接口

程序内部的接口：

程序内部的接口是指方法与方法之间、模块与模块之间的交互。比如贴吧系统，有登录模块、发帖模块等等，那你要发帖就必须先登录，要发帖就得登录，那么这两个模块就得有交互，它就会抛出一个接口，供内部系统进行调用。这种接口通常不对外暴露，只服务于系统内部各组件之间的协作。

系统对外的接口：

系统对外的接口是指从别的网站或服务器上获取资源或信息时，对方不会把数据库直接共享给你，而是提供一个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法，从而达到数据共享的目的。比如咱们用的 app、网址这些，它在进行数据处理的时候都是通过接口来进行调用的。

接口类型有很多，如 HTTP API 接口、RPC 等等，接下来我们基于 HTTP API 接口继续讲解。

1.2 详解接口测试

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试重点为数据的交换，传递和控制管理过程，以及系统间的逻辑依赖的关系。简单来说，接口测试就是通过测试不同情况下的入参与之对应的出参信息来判断接口是否符合或满足相应的功能性，安全性要求。

一个完整的接口文档应该包含以下内容：

• 接口说明
• 调用 URL
• 请求方法（get/post）
• 请求参数、参数类型、请求参数说明
• 返回参数说明

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

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

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

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

1.3 如何执行接口测试

接口其实就是前端页面或 APP 等调用与后端做交互用的，有人会问，功能测试都测好了，为什么还要测接口呢？

先举个栗子：比如测试用户注册功能，规定用户名为 6~18 个字符，包含字母（区分大小写）、数字、下划线。首先功能测试时肯定会对用户名规则进行测试，比如输入 20 个字符、输入特殊字符等，但这些可能只是在前端做了校验，后端可能没做校验，如果有人通过抓包绕过前端校验直接发送到后端怎么办呢？试想一下，如果用户名和密码未在后端做校验，而有人又绕过前端校验的话，那用户名和密码不就可以随便输了吗？如果是登录可能会通过 SQL 注入等手段来随意登录，甚至可以获取管理员权限，那这样不是很恐怖？

所以，接口测试的必要性就体现出来了：

• 可以发现很多在页面上操作发现不了的 bug
• 检查系统的异常处理能力
• 检查系统的安全性、稳定性
• 前端随便变，接口测好了，后端不用变

在进行接口测试前，还需要了解以下内容：

1. get 和 post 请求

get 和 post 是常见的请求方法。如果是 get 请求的话，直接在浏览器里输入就行了，只要在浏览器里面直接能请求到的，都是 get 请求；如果是 post 请求的话，就不行了，就得借助工具来发送。

2. http 状态码

每发出一个 http 请求之后，都会有一个响应，http 本身就会有一个状态码，来标示这个请求是否成功，常见的有以下几种：

• 200，2 开头表示这个请求发送成功，最常见的就为 200 代表这个请求是正确的且服务器也返回了
• 300，3 开头的代表重定向，最常见的是 302，表示把这个请求重定向到别的地方了
• 400，400 代表客户端发送的请求有语法错误，401 代表访问的页面没有权限了，403 表示没有权限访问这个页面，404 代表没有这个页面
• 500，5 开头代表服务器有异常，500 代表服务器内部异常，504 代表服务器端超时，没返回结果

接口测试可分为两部分去完善：通过接口设计用例 + 结合业务逻辑来设计用例

1.4 接口用例编写

1.4.1 接口用例的编写

通过性验证：首先要保证这个接口功能是好使的，也就是正常的通过测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。这是最基础的一步，只有接口能正常跑通，后续的各类验证才有意义。

1.4.2 参数组合

现在有一个操作商品的接口，有个字段 type，传 1 的时候代表修改商品，商品 id、商品名称、价格有一个是必传的，type 传 2 的时候是删除商品，商品 id 是必传的，这样的，就要测参数组合了，type 传 1 的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。参数组合测试的核心思路是：同一个接口在不同参数搭配下，后端能否正确处理每一种合法组合，同时也能识别出非法组合。

1.4.3 接口安全

接口安全测试主要关注接口在异常或恶意场景下的防护能力，常见的有以下几类：

• 绕过验证：比如购买了一个商品，它的价格是 300 元，那我在提交订单的时候，把这个商品的价格改成 3 元，后端有没有做验证；更极端一点，把价格改成 -3，是不是我的余额反而会增加？这类问题往往隐藏在后端对关键字段的校验逻辑中。
• 绕过身份授权：比如修改商品信息的接口，必须得是卖家才能修改，那我传一个普通用户，能不能修改成功？我传一个其他的卖家，能不能修改成功？这考验的是接口对操作者身份的校验是否严格。
• 参数是否加密：比如登录接口，用户名和密码是不是加密传输的？如果不加密，别人拦截到你的请求，就能直接获取到你的账号信息；同时还要看加密规则是否容易被破解。
• 密码安全规则：密码的复杂程度校验是否到位，比如是否强制要求包含字母、数字和特殊字符，长度是否有限制等。

1.4.4 异常验证

所谓异常验证，也就是不按照接口文档上的要求输入参数，来验证接口对异常情况的校验能力。比如必填的参数不填，输入整数类型的地方传入字符串类型，长度限制为 10 的传入 11，总之就是文档说怎么来，我就不怎么来。归纳起来其实就三种情况：必传非必传、参数类型、入参长度。通过这类测试，可以很好地暴露后端在参数校验上的漏洞。

1.4.5 结合业务逻辑来设计用例

根据业务逻辑来设计用例，就是结合自己系统的实际业务场景来设计测试用例，这一点每个公司的业务不同，需要具体问题具体分析，其实这也和功能测试设计用例的思路是一致的。

举个例子，拿贴吧来说，贴吧的需求可能是这样的：

• 登录失败 5 次，就需要等待 15 分钟之后再登录
• 新注册的用户需要过了实习期才能发帖
• 删除帖子会扣除积分
• 连续签到会有额外的积分奖励

像这样，需要把这些业务规则梳理成测试点，然后再去构造对应的测试数据，逐一验证每个测试点是否符合预期。业务逻辑测试往往能发现单纯从接口文档出发发现不了的问题，因为很多规则是隐藏在业务背后的。

二，小结

hello啊老铁们，消失人口回归了。其实每天上班也没有特别累，但是回来就是因为这样那样的事情没有学习。后面不会这样了(希望吧)。一篇文章不想写的太长，想把内容细化一点，所以大概率等会还会在更新一篇哦