标签：请求验证系统接口参数测试自动化

接口测试需要验证数据库么？

有的接口会返回很多数据，有的接口可能就返回一个状态码及success之类的消息，这些需要验证数据库么？现在在写一个测试框架，配置接口参数和预期返回值，生成xml文件管理用例，用一个比较方法对预期和返回作比较，不需要根据每个接口写脚本，现在的疑惑只是比较返回值，并不清楚接口是否真的成功了，比如删除之类的接口，返回说成功了，但数据是否真的删除了？如果要验证数据库，感觉得为每个用例写脚本去验证了，这就和初衷不符（只写个比较函数，比较返回的所有值，不需要为每个接口单独验证）。

不少同学在做自动化是都会问要不要验证数据库？我的答案是不要！

根据分层自动化测试的概念。

UI层自动化模拟的是用户操作，假设我是一个普通的用户，在你家的系统上购买了一件商品，我怎么知道有没有购买成功？难道要去查你家系统的“已购买表”？没权限，就算有权限我也不会！那我怎么验证？很简单啊！系统不是有“已购买” 商品列表嘛！点开“已购买”菜单看就可以了！（如果没有这功能，那说明你的系统设计有问题。用户体验不好，差评！！）

接口自动化模拟的是开发的代码操作，A开发写的接口给B开发去调用，A系统的接口给B系统去调用，假设我是一个开发，我调用了微信的接口去做获取用户头像，有个用户获取不到，来！微信团队，你让我查查你们的数据库呗！微信肯定不答应。（数据库不是你想查，想查就给你查！）

那接口返回了“success”，但没有把数据添加/删除成功怎么办？从我两年接口自动化的经验来说，这中情况基本非常少见，因为开发在写代码的时候，返回“success”的前提条件肯定是基于操作成功的。（开发写代码的时候肯定会自已运行一下啊！怎么会运行都不运行，哪儿来的自信！）

你们的开发就是粗心怎么办？我是这么做的，开发提交了新的接口，我会边读接口代码边设计接口用例（如果接口逻辑看不懂接口数据可能就构造不出来，接口用例自然也不会写。），代码有问题就直接告诉开发改了，在这个过程中，我是会查数据库的。一旦接口用例写好之后，后面再回归去跑的时候就不管了，当然，每条接口用例里面肯定不会加查询数据库的动作。

在特殊情况下，我调用了一个删除数据的接口，有没有真的删除一条数据，我可以调用查询数据的接口啊！查不出来刚才删除的数据，不就证明刚才的删除接口操作是ok的了。

大多数测试问这个问题就是把自己当测试了，在做手工测试的时候就是这么查数据库的呀！典型的站在测试的思维上想问题。我做UI自动化的时候，我就是普通的用户；我做接口测试的时候我就是开发。只不过，我会比普通用户和开发更细致更全面的“使用”系统所提供的功能而已。但“使用姿势”和他们是一样的！

1.如何做好接口测试

谈起软件测试，就不得不说一下接口测试，凡是有功能的软件都离不开接口，没有接口的软件只是一个模具或页面，不具备任何功能。

1.1什么是接口

硬件接口：USB接口，投影仪接口，鼠标键盘接口。

软件接口：称为API，微信（腾讯公司）：提现和充值。银行卡（银行系统），银联接口（想要调用必须拿到鉴权码：token，key，appkey）。软件的接口主要使用与数据交互。

业内常说的接口一般指两种：

API：应用程序编程接口，程序间的接口，软件接口测试中的接口特指API接口，接口测试又称API测试；GUI:图形用户界面，人与程序的接口

接口实例：系统与系统间的接口调用，作用：实现了两个或多个独立系统或模块间的通信和数据交换能力。

1.2接口测试是什么

接口测试就是验证这些信息能否正确传递，验证这个方法是否正确，有没有存在潜在的安全，性能问题。

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

系统调用外部的接口：开发的电商系统需要支付宝和微信支付。只需要测正例。
系统对外提供的接口：这种接口外部的用户是可以接触到，对安全性要求很高
程序内部的接口：方法与方法之间，模块与模块之间的交互，程序内部抛出的接口，比如bbs系统，有登录模块、发帖模块等等，那你要发帖就必须先登录，要发帖就得登录，那么这两个模块就得有交互，它就会抛出一个接口，供内部系统进行调用。

常见接口类型:

1．webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有SoapUI、jmeter、loadrunner等；

2．http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；

1.3为什么要做接口测试

1．互联网的快速发展，公司内部系统或与外部系统的关联越来越多，一个业务流程关联多个后端系统，它们的关联都是基于接口来实现，接口测试可以将复杂的系统关联进行简化，只要做好每个接口的测试就能够较好的保证系统质量。

2．单个系统的变更，是否会影响到关联业务系统，比较难用常规的测试方面来覆盖相关的应用系统（例如使用此接口的外部系统有N个，不可能每个做功能兼容性测试），但可以通过对接口功能的覆盖来验证是否影响它人对接口的调用。

3．接口功能比较单一，能够比较好的进行测试覆盖，也相对容易实现自动化持续集成，可以减少人工回归成本与时间，缩短测试周期。

4．接口相对于界面功能，会更底层一些，测试覆盖会更容易（如业务在调用接口时做了判断，当不满足条件时链接就不显示，此时从界面无法测试相关功能是否做好判断，通过接口就比较容易）

5．大家都知道，接口其实就是前端页面或APP等调用与后端做交互用的，所以好多人都会问，我功能测试都测好了，为什么还要测接口呢？OK，在回答这个问题之前，先举个栗子：

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

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

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

1.4接口的组成

首先，接口文档应该包含以下内容：

1．接口说明

2．调用url

3．请求方法（get\post）

4．请求参数、参数类型、请求参数说明

5．返回参数说明

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

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

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

1.5接口测试范围

业务功能（包括正常、异常场景是否实现）
业务规则（覆盖度是否全面）
参数验证（边界、业务规则是否达到要求）
异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
性能测试响应时间、吞吐量、并发数、资源要求）
安全测试（权限验证、SQL注入等）

1.6接口测试的重点

1．检查接口返回的数据是否与预期结果一致。

2．检查接口的容错性，假如传递数据的类型错误时是否可以处理。

3．接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。

4．接口的性能，http请求接口大多与后端执行的SQL语句性能、算法等比较相关。接口的安全性，外部调用的接口尤为重要。

1.7做好接口测试的前提

系统化的接口文档

传统的接口文档，一般采用word或wiki等系统来记录，从单次使用上似乎比较简单，因为大家会更习惯这样的操作，但这种形式存在比较大的问题：

1．接口文档非标准化，无法直接与接口测试工具接口使用。

2．接口维护困难，接口有变化时比较难标识清楚，沟通成本很高。

系统化接口文档，例如rap（淘宝分源的一个系统），具备接口维护标准化、版本化管理、MOCK测试等功能；对标准化的接口内容做二次开发，可以直接导出Soapui等工具使用的格式，直接导入工具中使用，有以下好处：

1．接口测试时不再需要手工输入相关字段，节省时间成本

2．版本化管理，能够清晰的知道哪些接口有变化

标准化的接口规范

接口管理是做好接口测试很重要的前提，如果一个系统有哪些接口都不太清楚，测试就很难覆盖到，接口管理建议采用以下方式：

按接口提供方为单位进行首次划分，按接口使用方进行二次划分，再按业务模块进行细分，分类原则根据内容多少进行优化，不需要固定，如本身接口较少就没有必要分得过细，较多时就需要多划分模块。

如：系统A，提供有 1、2、3、4、5、6、7、8、9 这9个接口，接口分别给B系统、C系统使用，其中1、2为公用接口，3、4、5为B专用，6、7、8、9为C系统专用，

按接口链接URL做为唯一，不同的接口参数做为接口变量，接口有参数变更时在原来接口上进行维护，而不是新增加接口。
为接口增加版本号，方便清楚哪些接口本次有变更，易于维护用例。

1.8接口测试怎么测

在进行接口测试前，还需要了解：

1.8.1 GET和POST请求：

如果是get请求的话，直接在浏览器里输入就行了，只要在浏览器里面直接能请求到的，都是get请求，如果是post的请求的话，就不行了，就得借助工具来发送。
GET请求和POST请求的区别：

1．GET使用URL或Cookie传参。而POST将数据放在BODY中。

2．GET的URL会有长度上的限制，则POST的数据则可以非常大。

3．POST比GET安全，因为数据在地址栏上不可见。

4．一般get请求用来获取数据，post请求用来发送数据。

其实上面这几点，只有最后一点说的是比较靠谱的，第一点post请求也可以把数据放到url里面，get请求其实也没长度限制，post请求看起来参数是隐式的，稍微安全那么一些些，但是那只是对于小白用户来说的，就算post请求，你通过抓包也是可以抓到参数的。所以上面这些面试的时候你说出来就行了。

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

1．200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。

2．300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。

3．400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面。

4．500 5开头的代=表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果

1.8.2接下来再说接口测试怎么测：

拿到api接口文档（规范：swagger，showdoc，不规范：word文档，没有：抓包或录制，一般需要抓包或者录制的接口很有可能只测正例），熟练接口业务，接口地址，接口鉴权，接口入参，接口出参，错误码。头痛的面试题：在你们的这个项目（App）你测了哪些接口？凡是有数据交互的地方就有接口。例如：查询支付宝余额接口。查询芝麻分接口。
编写接口测试计划和方案（接口怎么测）？

通用接口用例设计

通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。

l 参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。

l 接口安全：
     1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
     2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
     3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
     4、密码安全规则，密码的复杂程度校验

l 异常验证：所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。

根据业务逻辑设计

根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，这个每个公司的业务不一样，就得具体的看自己公司的业务了，其实这也和功能测试设计用例是一样的。

举个例子，拿bbs来说，bbs的需求是这样的：