软件测试之接口测试理论知识
文章目录
- 前言
- 接口的定义
- 接口的分类
- 接口测试
- 什么是接口测试
- 接口测试的基本原理
- 为什么要进行接口测试?
- 接口测试的测试范围(测试维度)
- 接口测试的流程
- 1.需求分析
- 2.接口文档分析
- 接口文档分析要素
- 3.编写接口测试计划
- 4.编写接口测试用例&评审
- 接口测试用例模板(仅供参考)
- 5.接口测试执行
- 6.生成接口测试报告
- 接口自动化测试(本文仅介绍概念)
- 接口测试持续集成、持续交付、持续部署(本文仅介绍概念)
- 接口测试质量评估标准
- 参考目录
前言
阅读本文前请注意最后编辑时间,文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信,指出错误或是进行交流等。
接口的定义
注:我们这里只关注软件层面的接口
接口(通常被称为API,Application Programming Interface,应用程序编程接口):是指系统或组件之间的交互点,通过这些交互点可以实现数据的交互。(也就是数据交互的通道)
如上图,假如我们在某一前端网页页面中进行登录。在输入用户名和密码之后,点击登录按钮。前端会与后端服务器通过接口进行传输数据,后端接收到数据后会进行一系列的处理,并会生成响应数据,这期间后端服务器可能会通过接口与数据库进行数据交互。最后,后端服务器会将生成的响应数据返回给用户的前端界面。在前端/后端/数据库之间的数据交互点就是接口,他们会通过接口进行数据的交互。
接口的分类
按照范围划分为以下两类
-
系统之间的接口:比如你要从别的网站或服务器上获取资源,别人肯定不会把数据库共享给你。他会提供一个他们写好的接口,你引用他提供的接口就能使用他写好的方法来获取资源。
-
程序内部的接口:方法与方法之间,模块与模块之间的交互,程序内部的接口,比如bbs系统,有登录模块、发帖模块等等,那你要发帖就必须先登录,要发帖就得登录,那么这两个模块就得有交互,它就会抛出一个接口,供内部系统进行调用。
如上图,客户端想要从后端(内部系统)获取信息,或者是图中三个系统之间进行数据交互,就需要通过不同系统各自所给出的接口进行数据交互。后端(内部系统)内部有用户系统/订单系统/商品系统(也可以称为模块,模块内部还有方法),这些系统要互相通信也要通过各自所给出的接口进行数据交互。
接口测试
什么是接口测试
接口测试:是对系统或组件之间的接口进行测试,主要是校验数据的交换、传递和控制管理过程,以及相互逻辑依赖关系。
接口测试的基本原理
通过模拟客户端向服务器发送请求,服务器接收请求后进行相应的业务处理,并向客户端返回响应数据,检查响应数据是否符合预期。
为什么要进行接口测试?
- 测试可以提前介入,提早发现Bug,符合质量控制前移的理念(例如前端界面还没有开发完成,没有办法通过前端界面操作进行测试)
- 稳固代码底层:在开发的初期阶段,业务层面无法检测到底层内容,代码底层不稳固牢靠,故此需要对底层内容进行接口测试,否则底层代码错误可能会引发更多外部系统或调用模块的错误。
- 可以发现很多在页面上操作发现不了的bug
- 带来高效的缺陷监测和管理能力,提高软件的整体质量
接口测试的测试范围(测试维度)
对比之前的界面手工操作功能测试,接口测试同样会进行功能测试。会根据单一模块、业务场景、异常情况等采用等价类划分法、边界值法等进行测试用例设计、测试。此外,接口测试还会进行性能测试、安全测试。(性能测试、安全测试会单独写博客来进行阐述)
接口测试的流程
公司有接口测试需求或测试人员收到接口测试任务时开始正式介入接口测试的流程阶段
1.需求分析
需求文档描述了软件产品应达到的功能、性能、安全等方面的要求,为开发团队提供了明确的功能和设计指导,也为测试团队提供了详细的测试依据和标准。可让测试人员对该软件的功能、性能、安全、兼容性、可用性等方面有一定的了解,为后续进行测试用例编写提供支持。(关于需求文档的模板或样例,可自行搜索资料进行学习)
2.接口文档分析
开发人员提供需求文档书写接口文档,测试人员拿到接口文档后分析测试需求,了解各个接口的功能以及相关信息、熟悉接口业务。(接口信息 包括但不限于 接口地址、服务器地址端口、请求方式、请求参数、约束条件、返回状态码等)
通过分析接口文档或者需求文档提取测试点, 可以提取以下三个方面的测试点:
- 功能性测试点
- 性能测试点
- 安全性测试点
接口文档分析要素
请注意,需提前掌握Http协议的知识。关于Http协议的知识,会写在另外一篇博客中。
接口文档应该包含以下内容:
1、接口说明
2、接口地址url
3、请求方法
4、请求参数、参数类型、请求参数说明
5、返回参数说明
我们可以通过查看公共的接口文档来进行学习
3.编写接口测试计划
测试计划和功能测试计划基本一样,5w1h
why—为什么要进行接口测试;
what—测试接口包括哪些;
when—测试接口不同阶段的起止时间;
where—相应接口文档,接口缺陷的存放位置,测试环境等;
who—项目有关人员组成,哪些接口分配给哪些人;
how—使用哪些测试工具以及测试方法进行测试。
关于接口测试计划文档模板或样例,可自行搜索资料进行学习
4.编写接口测试用例&评审
根据接口文档中具体的某个接口来编写测试用例,一般会分为单接口和多接口(业务)两种场景来编写测试用例。
- 单接口测试场景:对单一的接口或者模块进行正向和反向测试
正向测试:正常发送请求,正常获取响应的数据,一般我们从三个方面去组织测试用例:
填写请求所需要的所有必填参数
填写请求所需要的所有必填参数和所有选填参数
填写请求所需要的所有必填参数和部分选填参数
反向测试:在请求中填写不符合规范的数据,发送请求,检查服务器能否正常处理。我们可以从以下方面去组织测试用例:
填写异常数据:数据为空,数据过长或者过短(边界值外),数据类型不符,错误的数据
请求中参数异常:不传参数,少传参数,额外传输不存在的参数,传递错误的参数
- 多接口(业务)测试场景:对有关联的接口或者模块进行正向测试。尽量遵循用户实际的使用场景,按顺序调用接口进行测试。尽量用最少的测试用例,覆盖最多的业务场景。
举个例子,假设有一个员工管理系统。该系统包括了对员工信息的增删改查功能,且对单一的接口都进行了正向和反向测试。随后,将这些单一接口按照业务场景,关联起来测试。假设某用户登录该系统进行了以下操作:
登录——添加员工——查询员工信息——修改员工信息——再查询员工信息——删除员工信息——再查询员工信息
可见, 之前所测试的单一接口(增删改查等),按照业务场景有顺序的串了起来。且不同模块之间还会存在一定的数据交互,也即模块与模块之间需要通过接口进行交互。
接口测试用例模板(仅供参考)
接口测试用例设计完成后, 可能会需要由上级进行评审,评审通过后再进行测试用例的执行。
5.接口测试执行
接口测试一般使用工具和代码两种方式进行测试
常用测试工具列表:
Postman:接口测试、接口自动化测试
JMeter:接口测试、接口性能测试、接口自动化测试
Fiddler/Charles:接口抓包工具
Loadrunner:接口性能测试
Wireshark:可抓各种协议的包进行分析
Soapui:既可以做接口测试也可以做自动化测试
还有Apifox、poster、Httprequester等工具
代码实现:通过编写测试脚本进行测试
常见的有 Pytest+Request+Allure:接口测试、接口自动化测试
6.生成接口测试报告
接口测试报告记录和展示接口测试结果,验证了接口功能的正确性、性能、安全性等。(接口测试报告的模板可自行搜索资料,可以根据具体项目需求进行调整和扩展)
生成接口测试报告的工具或代码实现多种多样,例如Postman+Newman、Pytest+Request+Allure,其余工具可自行查阅资料学习。
接口自动化测试(本文仅介绍概念)
- 接口自动化测试是指使用自动化测试工具和脚本对软件系统中的接口进行测试的过程。其目的是在软件开发过程中,通过对接口的自动化测试来提高测试效率和测试质量,减少人工测试的工作量和测试成本。
- 接口自动化测试可以有效地支持持续集成和持续交付,实现自动化构建、测试和部署。
- 虽然初期需要投入一定的时间和资源来搭建自动化测试环境,但长期来看,自动化测试可以减少重复测试的工作量,降低测试成本。
简单来说,自动化测试主要针对的是接口测试执行该阶段,利用工具或者代码将接口测试用例转换成可以运行的脚本。这样就可以一键自动执行所有的测试用例,并快速的出具测试报告,减少了手工测试的工作量,大大加快了速度,非常适合对接口进行回归测试。
接口测试持续集成、持续交付、持续部署(本文仅介绍概念)
接口测试的持续集成(Continuous Integration,CI)是软件开发过程中的一个重要环节,它要求开发团队的成员将代码变更集成到共享的代码库中,并在每次集成后自动执行接口测试,以确保软件的质量和稳定性。
持续集成强调开发人员提交了新代码之后,立刻进行构建、测试。根据测试结果,可以确定新代码和原有代码能否正确地集成在一起。
持续交付(Continuous Delivery,简称CD)在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如,我们完成单元测试后,可以把代码部署到连接数据库的环境中进行更多的测试。如果代码没有问题,可以继续手动部署到生产环境。
持续部署(Continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。
接口测试质量评估标准
- 业务功能覆盖是否完整
- 业务规则覆盖是否完整
- 参数验证是否达到要求(边界、业务规则)
- 接口异常场景覆盖是否完整、
- 接口覆盖率是否达到要求
- 代码覆盖率是否达到要求
- 性能指标是否满足要求
- 安全指标是否满足要求
参考目录
https://blog.csdn.net/AI_Green/article/details/119996355
https://blog.csdn.net/weixin_37600187/article/details/128186481
https://blog.csdn.net/2301_79535618/article/details/142659154
https://blog.csdn.net/cs888zsy/article/details/135884636
https://blog.csdn.net/weixin_37600187/article/details/128186481
https://blog.csdn.net/whowhowhoisimportant/article/details/123833587
https://blog.csdn.net/YLF123456789000/article/details/140405621
https://blog.csdn.net/MXB_1220/article/details/130815645
https://blog.csdn.net/qq_43331014/article/details/141399817
https://blog.csdn.net/weixin_42724501/article/details/123092695