vlambda博客
学习文章列表

1、按你的理解，软件接口是什么

就是指程序中具体负责在不同模块之间传输或接受数据的并做处理的类或者函数。

2、HTTP和HTTPS协议区别

• https需要CA证书（Certificate Authority，证书颁发机构）

• http是超文本传输协议，信息是明文传输，Https是具有SSL加密传输协议（SSL在传输层对网络连接进行加密）

• 两者连接方式不同，端口不同，Http是80，Https是443

• Http是无状态的连接方式，Https是由SSL+Http构建的，可进行加密传输、身份认证的网络协议，比http协议安全（Https=Http+加密+认证+完整性保护）

3、HTTPS在哪一层

在应用层

4、Post和Get区别

• Post更安全；Get会将参数作为url一部分，数据会保存在浏览器历史或web服务器的日志中，但Post不会

• Post发送数据量大；Get因浏览器和web server对url存在长度限制

• Post可发送更多数据类型；Get只能是ASCII字符

• Post比Get传输慢：

• 第三次握手时，对于Post，浏览器先发送header，服务器相应100 continue，浏览器再发送data，服务器相应200 OK 返回数据；对于Get，浏览器会把header和data一并发送，服务器相应200 OK 返回数据

• Post无缓存；Get可被缓存

• Post不能进行管道传输，即第一个请求发出去，尚未等到服务器应答，下一个请求紧接着发出，例如：支付功能；Get可以进行管道传输

• Post方式适合数据添加、修改或删除操作；Get方式适合查询操作

5、常见的POST提交数据方式

• application/x-www-form-urlencoded：键值对字符串，表单，value为纯文本字符串

• multipart/form-data：表单，value可为纯文本或文件

• application/json：raw，正文格式Json

• text/xml：raw，正文格式xml

6、什么是Http协议无状态协议？怎么解决HTTP协议无状态协议

• 浏览器发送Http请求后，服务器会根据请求发送响应数据，但服务器不记录客户端任何信息，这意味着每次请求都是独立的，如果后续处理需要依赖之前的信息，则必须重传之前的请求，导致每次连接传送的数据量增大

• 通过 Cookie或Session解决HTTP协议无状态协议

7、cookie和session的区别

• cookie通过客户端浏览器记录信息确认用户身份；session通过服务端记录信息确认用户身份

• cookie并不安全，别人可通过分析存放在本地的cookie并进行cookie欺骗；session相对比较安全

• cookie对服务器压力小，单个cookie保存的数据不能超过4K；session会在一定时间内保存在服务器上，当访问增多时，会比较占用服务器性能

• 可以将登录信息等重要信息存放为session；其他信息存放在cookie

8、请求接口中常见的返回状态码

• 1xx -- 信息提示（表示临时的响应。客户端在收到常规响应之前，准备接收一个或多个1xx响应）

• 2xx -- 成功（表明服务器成功地接受了客户端请求，但不代表已经提供了正确的响应）

• 3xx -- 重定向（客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求）

• 4xx -- 客户端错误（发送错误，客户端有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份证验证信息）

• 5xx -- 服务器错误（服务器由于遇到错误而不能完成该请求）

常见的返回码有：

• 200：服务器成功返回用户请求的数据

• 201：用户新建或修改数据成功

• 202：表示一个请求已经进入后台排队（异步任务）

• 204：用户删除数据成功

• 206：返回部分内容，客户发送一个带有range头的Get请求，服务器按照要求完成请求

• 302/307：临时重定向，新的url在location响应头中给出

• 400：用户发出的请求有错误，服务器没有进行新建或修改数据的操作

• 401/407：表示用户没有权限（令牌、用户名、密码错误）

• 403：表示用户得到授权（与401错误相对），但是访问被禁止

• 404：服务器不存在所请求资源

• 406：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）

• 500：服务器内部错误，服务器端CGI、ASP、JSP等程序发生错误

9、什么是DNS

DNS 域名系统 (Domain Name System)，将网址转换成IP，访问对方服务器

10、请问你们公司是如何做接口测试的

• 获取接口规范

• 设计接口测试功能用例（主要从用户角度出发看接口能否实现业务需求，类似黑盒用例）

• 各种入参验证（正常、异常：输入参数个数不对、类型不对、可选/必选、参数存在互斥/关联情况）

• 接口返回值各种验证（符合接口文档需求）

• 了解接口实现逻辑，实现逻辑覆盖（语句/条件/分支/判定/…）

• 接口是否可以并发执行、安全/性能是否满足要求

• 采用工具或者自写代码来验证

• bug记录jira并跟踪状态

11、怎么设计接口测试用例

通常，设计接口测试用例需要考虑以下几个方面：

• 是否满足前提条件：例如登录需要token

• 是否携带默认值参数：默认参数填写/不填写/不传参

• 是否满足业务规则、功能需求

• 参数是否必填：必填参数填写；必填/非必填参数缺失

• 参数之间是否存在关联：有些参数彼此之间存在相互制约的关系

• 参数数据类型限制：符合类型/类型不符

• 参数数据范围值限制：边界值、空值

12、你做接口测试，测什么

• 可用性测试：根据约定的协议、方法、格式内容，传输数据到接口经处理后返回期望的结果

• 接口功能是否正确实现

• 返回值测试：内容正确、类型正确，保证调用方能够正确地解析

• 参数值边界值、等价类测试

• 错误和异常处理测试

• 输入异常值（空值、特殊字符、超过约定长度等），接口能正确处理，且按预期响应

• 输入错误的参数，接口能正确处理，并按预期响应

• 多输入、少输入参数，接口能正确处理，且按预期响应

• 错误传输数据格式（如json格式写成form格式）测试

• 安全性测试：主要指传输数据的安全性

• 敏感数据（如密码、密钥）等是否加密传输

• 返回数据是否含有敏感数据，如用户密码、完整的用户银行账号信息等

• 接口是否对传入的数据做安全校验，如身份ID加token类似校验

• 接口是否防止恶意请求（如大量伪造请求接口致使服务器崩溃）

• 性能测试：如接口的响应时间、并发处理能力、压测处理情况

• 并发请求相同的接口（特别为POST请求），接口的处理情况（如插入了相同的记录导致数据出错，引发系统故障）

• 接口响应时长在用户可忍受的范围内

• 对于请求量大的接口做压测，确定最大的瓶颈点是否满足当前业务需要

13、平常用什么工具测接口的

常用http协议接口测试工具：postman、fiddler、jmeter；webService接口：SoapUI、jmeter等

14、没有接口文档，如果做接口测试

用抓包工具Fiddler把接口抓取处理，然后针对性进行测试；接口中字段信息不清楚的，找时间集中寻求开发解答

15、在手工接口测试或者自动化接口测试的过程中，上下游接口有数据依赖如何处理

用一个全局变量来处理依赖的数据

16、依赖于第三方数据的接口如何进行测试

可以使用mock测试

• 第一种是使用easy mock（这种方式适合于服务器端调用）:

• 如果测试对象是接口，以上步骤就已经可以成功使用mock了

• 第二种是使用moco的jar包（这种方式适合于本地调用，可模拟单个接口）：

• 下载jar包：moco-runner-0.9.2-standalone.jar

• 将要mock的接口内容写成json文件，例如payment.json文件，里面mock两个接口，写法如下：

  [{ "request": {

      "uri": "/baofoo",

        "queries": {

          "param": "pay"}},

     "response": {

        "json":{"biz_type":"0000",

            "resp_code":"BF00113",

            "txn_type":"0431"}}}]

• 执行语句：java -jar moco-runner-0.9.2-standalone.jar start -p 12306 -c payment.json

  (-jar是执行后面的jar包，start -p设置端口号，-c指定json文件）

• 在本地开发项目中设置spring-config.properties，内容为

  bf.requestUrl=http://localhost:12306/baofoo?param=pay

• 到postman中或者浏览器中进行验证，输入http://localhost:12306/baofoo?param=pay，可得到响应值

17、接口测试中，依赖登录状态的接口如何测试

在构建POST请求时添加必要的session或者cookie

把登录接口放在conftest里，先运行获取COOKIE并放在全局变量中，其他接口调用时直接获取COOKIE即可

18、如何模拟弱网做测试

答：Fiddler和charles都可以模拟弱网测试

https://blog.csdn.net/weixin_40543143/article/details/80405675

19、你平常做接口测试的过程中发现过哪些bug

• 异常值（空值、特殊字符、超出边界值等）处理不当致使程序异常退出或者前端展示异常

• 输入错误的参数、多输入/少输入参数，接口没有给予正确的返回信息

• 参数为null或空字符串“”等，没有给予正确的返回信息

• 权限未处理校验，导致能够访问其他用户的信息

• 逻辑校验不完善，可利用漏洞获取非正当利益

  例如：某网站兑换1块钱需要100币，当小于100币时调用后台接口是否能够兑换

  例如：购物结算时为100元，调用后台接口设为0元或者-100元

• 未进行超时处理，导致整个流程阻塞

• 超时后又收到接口返回，导致逻辑出现错乱

• 错误提示处理不当，导致用户看到晦涩的错误码

• 安全性问题，如明文传输、返回结果含有敏感信息，没对用户身份信息做校验，没做恶意请求拦截等

• 性能问题，如接口并发插入多条相同操作，响应时间过长，接口压测出现瓶颈等

20、当一个接口出现异常时候，你是如何分析异常的

• 先F12查看请求和返回报文

• 查看后端日志，查看是否有报错信息（命令：tail -f 日志文件）

21、如何分析一个bug是前端还是后端的

F12看请求报文，参照接口文档，看请求报文是否存在问题，若有，则前端发的数据错误

若无，则请求报文没问题，继续查看返回报文，若返回的数据不对，则是后端开发的问题

22、你们做接口测试自动化吗

测试工具：Jmeter、Postman

Python基础：Python + Request + Jenkins + Git

23、常见的几种协议的接口

• HTTP 接口（RESTful）：表述性状态传递，基于Http协议最简单的接口模式（restful-json）

• RPC 接口：分布式架构，无感知调用，安全性高，本质上是一种Client/Server模式，可以像调用本地方法一样去调用远程服务器上的方法（类似点外卖，A通过第三方调用B，B通过第三方返回结果给A）

• Web Service 接口：以web形式提供的服务称为Web Service（soup-xml）

• Dubbo 接口：分布式服务框架，dev和QA可通过dubbo监控中心和后台管理模块，监控服务端与客户端调用情况、调用次数、log等，方便问题查找

24、常见HTTP接口请求类型

• GET：请求指定的页面信息，并返回实体主体

• HEAD：只请求页面的头部 

• POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件），数据被包含在请求体中，POST请求可能会导致新的资源的创建和/或已有资源的修改

• PUT：向指定资源位置上传其最新内容， 从客户端向服务器传送的数据取代指定的文档的内容

• DELETE：请求服务器删除Request-URI所标识的资源，也就是删除所指定的页面

• OPTIONS：允许客户端查看服务器的性能。 

• TRACE：回显服务器收到的请求，主要用于测试或诊断

• CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

25、HTTP接口测试和Web Service接口测试区别

• Web service一般就是用SOAP协议通过HTTP来调用，可以理解为web service就是一个WSDL （Web Service Description Language）文档，客户根据WSDL描述文档，生成一个SOAP请求消息，嵌入在一个HTTP POST请求中，发送到Web服务器，Web服务器把这些请求转发给Web service请求处理器，请求处理器解析收到的SOAP请求并调用Web service，然后再生成相应的SOAP应答，Web服务器得到SOAP应答后，会再通过HTTP搜索应答的方式把它送回到客户端

• soap请求是HTTP POST的一个专用版本，遵循一种特殊的xml消息格式Content-type设置为: text/xml，任何数据都可以xml化

• web service的优点： 不用担心大小写问题；不用担心中文urlencode问题；代码中不用多次声明认证(账号,密码)参数；传递参数可以为数组，对象等；接口中实现的方法和要求参数一目了然 

• 两者区别：

• HTTPService基于Http协议，WebService基于SOAP协议

• HTTPService处理数据效率较高，WebService需要进行xml解析，处理数据效率有所降低，但能处理较复杂的数据类型

• HttpService方式不能处理跨域，WebService可以

26、什么是接口测试的幂等性校验

幂等性, 通俗的说就是一个接口, 多次发起同一个请求, 必须保证操作只能执行一次，比如：前端重复提交，接口超时重试，消息重复消费（消息重复发送）

常见解决方案：

• 唯一索引 – 防止新增脏数据

• token机制 – 防止页面重复提交

• 悲观锁 – 获取数据的时候加锁(锁表或锁行)

• 乐观锁 – 基于版本号version实现, 在更新数据那一刻校验数据

• 分布式锁 – redis(jedis、redisson)或zookeeper实现

• 状态机 – 状态变更, 更新数据时判断状态

27、接口常见的加密方式？如何测试加密接口

加密方式：

• 对称加密：加密和解密用的是同样的密钥。对称加密的一大缺点是密钥的管理与分配，在发送密钥的过程中，密钥有很大的风险会被黑客们拦截。现实中通常的做法是将对称加密的密钥进行非对称加密，然后传送给需要它的人

• 非对称加密：使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。虽然非对称加密很安全，但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去

测试方法：https://blog.csdn.net/yuxuan6699/article/details/99622685

• 摘要算法（MD5.SHA1 ）：造接口数据前调用MD5，SHA1进行编码，服务端对比编码后的字符串是否一致

• 对称加密算法（AES,DES ）：造接口数据前从开发获取对称公钥，基于对称公钥可以加密请求数据，解密响应报文

• 非对称加密算法（RSA）：造接口数据前从开发获取公钥私钥去加密解密接口数据

• 用户认证：一般的接口测试工具都会提供一个User Auth/Authorization的选项，在对应的工具上，选取对应的用户认证选项

28、Http常见的身份认证方式有哪些

• Bearer验证：标准请求方式 Authorization: Bearer [BEARER_TOKEN]，认证的核心便是BEARER_TOKEN，而最流行的Token编码方式便是：JSON WEB TOKEN (JWT)，特别适用于分布式站点的单点登录（SSO）场景

• Basic基础认证：客户端请求需要带Authorization请求头，值为“Basic xxx”，xxx为“用户名:密码”进行Base64编码后生成的值，用户名/密码经过Base64加码后，这个Base64码值可以轻易被解码并获得用户名/密码，所以此认证方式并不安全。为了传输安全，需要配合SSL使用。

• Digest摘要认证：

• 客户端访问Http资源服务器，服务器返回了两个重要字段nonce（随机数）和realm

• 客户端构造Authorization请求头，值包含username、realm、nouce、uri和response的字段信息。其中，realm和nouce就是第一步返回的值。nouce只能被服务端使用一次。uri(digest-uri)即Request-URI的值，但考虑到经代理转发后Request-URI的值可能被修改、因此实现会复制一份副本保存在uri内。response也可叫做Request-digest，存放经过MD5运算后的密码字符串，形成响应码。

• 服务器验证包含Authorization值的请求，若验证通过则可访问资源

• Digest认证可以防止密码泄露和请求重放，但没办法防假冒。所以安全级别较低

• Digest和Basic认证一样，每次都会发送Authorization请求头，也就相当于重新构造此值。所以两者易用性都较差

• SSL Client认证：

• 客户端请求服务资源，服务器要求客户端出示数字证书

• 客户端发送数字证书，服务器通过数字证书机构的公钥验证数字证书的合法性，验证通过后取出证书的公钥

• 服务端随机生成一个随机数即为对称密钥，并使用非对称算法和证书公钥加密。这个加密后的字符串，只有发送的客户端能解

• 客服端使用非对称解密算法和证书私钥获取服务端发送的对称密钥。后续客户端和服务端的请求直接基于对称算法和对称密钥

• HTTP 表单认证：表单认证一般都会配合cookie+sessiond的使用，现在绝大多数的Web站点都是使用此认证方式。用户在登录页中填写用户名和密码，服务端认证通过后会将sessionId返回给浏览器端，浏览器会保存sessionId到浏览器的Cookie中。因为Http是无状态的，所以浏览器使用Cookie来保存sessionId。下次客户端发送的请求中会包含sessionId值，服务端发现sessionId存在并认证过则会提供资源访问

29、说一说你所知道的接口安全测试

接口安全设计原则：

• 接口类型尽量使用https带SSL证书模式

• 接口参数使用签名（非对称加密算法）

• 接口参数需要校验

• 每次请求需要用户命令

• 多次失败后需要有锁定机制

• 接口对应用户权限，用户只能调用有权限的接口

• 系统接口做过负荷机制用来保护系统安全

接口安全设计注意事项：

• 对用户任何输入的都需要注意

• 不能只在客户端进行校验

• 服务端返回的任何服务错误信息不要返回给用户

常用接口安全测试类：

• sql注入：

• 不要信任用户的输入，对用户的输入进行校验，可以通过正则表达式，或限制长度；对单引号和双"-"进行转换等

• 不要使用动态拼装sql，可以使用参数化的sql或者直接使用存储过程进行数据查询存取

• 不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接

• 不要把机密信息直接存放，加密或者hash掉密码和敏感的信息

• 应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装

• xss攻击：向页面插入恶意js脚本，例如<script src=‘wrong URL’></script>，当用户浏览该页面时，嵌入在页面里的Script代码会被执行，进而获取该用户的cookie信息，对该用户资源进行操作

• 越权访问：A用户更改自己的id值就进入了B用户的主页，可以查看、修改B用户的信息

• csrf 请求伪造：攻击者盗用了你的身份，以你的名义发送恶意请求；简单来说，CSRF必须经过两个步骤：用户访问可信任站点A，并产生了相关的cookie；用户在访问A站点时没有退出，同时访问了危险站点B

  
  

• ajax请求尽量都加上token验证

• 使用post，不使用get修改信息

• 验证码，所有表单的提交建议需要验证码

• 在表单中预先植入一些加密信息，验证请求是此表单发送

30、自己用requests类封装比JMeter、postman的好处在哪

可以把脚本后期进行平台化，方便维护管理，工具操作起来步骤繁琐

31、 接口框架中哪些参数是做数据分离的？这样做的好处或者必要性

我们可以把自动化测试的用例数据放到Excel或者Json文件或者Yaml文件当中，然后在自动化测试的代码当中通过数据驱动的方式去获取这些数据。比如在unittest测试框架当中，可以引入DDT模块；如果是pytest测试框架，可以使用paramatrize这样一个装饰器去做数据驱动

32、接口里是否是用到了数据驱动，有什么意义？如何实现一个接口使用多种数据？

接口自动化一般都要用到数据驱动，数据驱动是指通过数据去驱动代码测试，测试代码写好并且封装后，基本只需要去管理数据，数据和代码两部分相互独立开，这样方便测试数据与测试代码的分离，在数据相关文件里，只修改数据而不需修改代码即可改变测试代码的运行结果

一个接口使用多种数据时，可以把数据存放在一个json文件里，按照规则读取不同数据即可