目录
前言
1.1 什么是 API?
1.2 什么是 API 测试?
1.3 常见的 API 测试类型有哪些?
1.4 列举 API 测试中使用的一些常用协议?
1.9API 常见测试有哪些?
1.10API 测试有哪些优势?
1.11API 测试中究竟需要验证哪些内容?
1.12 列举一些用于 API 测试的工具?
1.16API 测试面临的主要挑战是什么?
1.17 执行 API 测试时我们面临的 BUG 类型是什么?
1.18UI 测试与 API 测试有何不同?
1.19 列举一些最常用的 HTTP 方法?
1.27 什么是分层测试?
总结
大家新年快乐,过年的时候一直在忙也没时间更新,今天好不容易闲了下来就给大家总结一下自动化测试面试的一些常问问题,堪称自动化测试的面试宝典。方便大家年后面试找工作。我已经讲面试题目总结成word文档,需要的请添加我文章底部群聊领取。
API 是(Application Programming Interface)首字母缩略词,即应用程序编程接口。API 是一组用于 构建软件应用程序的规程,协议和工具。API 充当软件应用程序之间的接口,并允许两个软件应用程 序相互通信。API 是一组软件功能,可以由其他软件执行。
API 测试是一种软件测试,涉及直接测试 API,也是集成测试的一部分,用于检查 API 是否满足应用 程序的功能,可靠性,性能和安全性方面的期望。在 API 测试中,我们主要关注软件架构的业务逻辑 层。可以在包含多个 API 的任何软件系统上执行 API 测试。
API 测试通常涉及以下实践:
单元测试、功能测试、负载测试、运行时/错误检测、安全测试、UI 测试、互操作性和 WS 一致性测 试、渗透测试、模糊测试
Thrift、HTTP、REST、SOAP、JMS、UDDI、Dubbo
Web 服务:
所有 Web 服务都是 API
所有 Web 服务都需要通过 Web(HTTP)公开
Web 服务只有三种使用方式:SOAP,REST 和 XML-RPC 进行通信
接口:
API 有很多并不基于 HTTP
在 API 上执行的一些常见测试如下: 验证不同输入条件的返回、 验证不同数据结构、
验证 API 是否触发其他事件或请求其他 API、 在没有返回值时验证 API 的行为、
更快及更高的测试覆盖率。
API 测试有助于我们降低测试成本。通过 API 测试,我们可以在 GUI 测试之前找到小错误。在 GUI 测试期间,这些小错误将变得更大。因此,在 API 测试中发现这些错误将对公司具有成本效益。
API 测试与语言无关。
API 测试在测试核心功能方面非常有用。我们可以在没有用户界面的情况下测试 API。在 GUI 测试中, 我们需要等到应用程序可用于测试核心功能。
API 测试有助于我们降低风险。
数据准确性
HTTP 或其他协议状态代码 响应时间
API 返回任何错误时的错误代码 授权检查 非功能测试,如性能测试,安全测试
用于 API 测试的一些工具如下:
Curl 、 httpie 、 Requests: HTTP for Humans 、 、 Katalon Studio 、 SoapUI 、 Assertible 、 Tricentis Tosca 、 Apigee 、 JMeter 、 Rest-Assured 、 Karate DSL、API Fortress、Parasoft、HP QTP(UFT)、vREST、Airborne、API Science、APIary、 Inspector、Citrus Framework、Hippie-Swagger、HttpMaster Express、Mockbin、Ping API、 Pyresttest、Rest Console、RoboHydra Server、SOAP Sonar、Unirest、WebInject
另,Python 是目前接口测试使用最广的语言,Python 测试框架及 Python 抓包工具(Hardware)都 可参考。
适当的参数及其组合 正确分类参数
顺序 验证输出
由于缺少 GUI,提供输入值较困难
压力,性能和安全问题 功能重复或缺失 可靠性问题
消息不当 不兼容的错误处理机制 多线程问题 不合适的错误
UI(用户界面)测试是测试应用程序的图形界面部分。它的主要重点是测试应用程序的外观和感觉。 API 测试支持两个不同软件系统之间的通信。它的主要重点是应用程序的业务层。
GET:从服务器检索数据 POST:将数据添加到服务器中的现有文件或资源 PUT:它允许您替换服务器中的现有文件或资源
DELETE:它允许您从服务器中删除数据
PATCH:用于对资源进行部分修改选项:用于描述目标资源的通信选项 HEAD:它要求响应与 GET 请求相同,但没有响应正文
首先,分层即是有明显的层级关系。
例如: 国企中的领导级别,公务员级别,严格的层级关系;
面包也有层级,不同层次不同馅的面包或者蛋糕是不是好吃点? 那测试的层级是什么呢?就是不同的时间段,不同的团队(当然也可能是同一团队)使用不同的测试用 例对产品不同的关注点进行测试。
一个系统/产品,最先看到的是 UI 层,也就是外观或者说整体,这些是最上层,最上层依赖下面的服 务层,也就是接口或者模块,最底层就是单元,这个单元是函数或者方法。按照这三层选择不同时间 段,不同团队不同测试用例进行的测试就是分层测试。
其次,说下怎么分层测试? 以一个同行的比喻,拿造一辆车来说,从最重要的发动机开始,单元测试就是零部件检测,若是组装 发动机后发现某个零部件质量不过关,那不是要拆了后修理然后再组装,这不仅麻烦还占时间,
所以 轻易想到的一个方法就是在零部件制作好后,使用某些工具对零部件单独检测,那软件测试中的单元 测试就是对函数或者方法进行测试,这个需要开发来完成,有两种方法: 第一种就是代码走查,依赖个人或者团队能力,且不可重复; 第二种方法就是写单元自动化测试用例,可重复性高,但是这个要求覆盖率要高,否则也没多大用处, 所以底层的单元自动化测试用例量最多,打好地基,同时发现问题解决成本最小,不需要搭建环境, 简单快速执行。
零部件检查完毕后就需要组装成发动机,发动机提供一个接口给仪表盘提供实时车速, 那就需要对这个接口进行测试了,选用相应的工具。 同理,软件测试的服务层也是采用自动化测试,更注重组件测试/集成测试等,比单元测试难度大点, 运行速度相对慢点,需要搭建环境,因此测试用例比单元测试要少。发动机接口测试完毕后组装成整 个车辆,从外观整体各方面进行测试,那软件在最上层的也是界面测试,
这个层级只有很少可以进行自动化测试,其余部分依靠人力,执行慢,搭建环境复杂,用例更少,所以三个层级组成一个正三角形,按照这种方式编写用例并执行相应用例,是最稳固的,质量也是最高的。 然后,说一下分层的优势。 尽量测试前移,在开发前期发现问题解决问题,开发成本会迅速下降。 不同时间段关注不同,分重点测试,层层防护。
后续的测试根据前面的测试内容进行补充或者有计划的交叉,能在有限的测试时间里覆盖更多的风险 点。
有些功能点只适合白盒测试,开发前期有效分层,能解决后期无法测试的问题。 最后,说说实施时的注意点。 层级如何划分要设计好,相应的用例就好设计了,用例执行时要持续追踪,前面的工作要为后面的工 作起到实际作用。
因为文档有100多页,这里也展示不完。感兴趣的还是可以加我下方群聊免费领取,在这里也就不多说废话 。也欢迎对软件测试行业感兴趣的朋友加入,群里有大佬可以帮忙解答问题哦,赶快加入吧。