开通网站后环球军事新闻最新消息

开通网站后,环球军事新闻最新消息,商标注册申请需要什么材料,网站建设项目职责#x1f345; 点击文末小卡片#xff0c;免费获取软件测试全套资料#xff0c;资料在手#xff0c;涨薪更快一、接口的介绍软件测试中#xff0c;常说的接口有两种#xff1a;图形用户接口#xff08;GUI#xff0c;人与程序的接口#xff09;、应用程序编程接口…点击文末小卡片免费获取软件测试全套资料资料在手涨薪更快一、接口的介绍软件测试中常说的接口有两种图形用户接口GUI人与程序的接口、应用程序编程接口API。接口API是系统与系统之间模块与模块之间或者服务与服务之间相互调用的入口。它的本质其实就是一种约定在开发前期我们约定接口会接收什么数据在处理完成后它又会返回什么数据。开发岗位分为前端和后端他们相互配合完成工作会协商接口的定义方法。一般后端定义接口前端调用接口。前后端分离是web应用开发的发展趋势优势有后端不用精通前端技术只专注与数据的处理对外提供API即可。前端的专业性越来越强通过API获取数据并专注与页面设计。前后端分离可扩大接口的应用范围开发接口即可应用到web应用上也可应用到app上。接口的分类HTTP接口、Web Service接口、RESTful接口。二、接口测试的定义、必要性/优点、原理1、接口测试的定义接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换传递和控制管理过程以及系统间的相互逻辑依赖关系等。--百度百科接口测试其实就是验证接口内部处理逻辑是否正确我们既要保证单接口的正确性也要保证接口的业务逻辑正确性主要体现在两方面输入正确的测试数据验证接口正常处理后返回的结果是否正确数据结构数据内容输入异常的测试数据验证接口能否正确处理异常数据并返回特定提示是否合理是否健壮接口测试目的测试接口的正确性和稳定性持续集成是接口测试的核心2、接口测试的必要性/优点开展接口测试可以及早发现问题有效降低测试成本接口一般较UI相对稳定更利于进行自动化和持续集成特别适用于高复杂性的平台可以带来高效的缺陷监测和质量监督能力平台越复杂系统越庞大接口测试的效果越明显提高测试效率提升用户体验降低研发成本PS以保证系统的正确和稳定为核心以持续集成为手段提高测试效率提升用户体验降低产品研发成本。持续集成是接口测试的低成本、高收益的根源是接口测试的灵魂。没有持续集成接口测试带来工作量会成指数增长3、接口测试的原理测试借助工具模拟客户端向服务器发送请求报文服务器接收请求报文后对相应的报文做处理并向客户端返回应答工具模拟客户端接收应答然后测试人员检查应答是否准确。三、接口测试的范围、原则、重难点1、接口测试的范围1. 需要测试的接口随着系统的复杂性越来越高接口越来越多覆盖所有接口是很困难的事。通常主要测试最外层的两类接口数据进入系统接口调用外部系统的参数为本系统使用和数据流出系统的接口验证系统处理后的数据是否正常。2. 被测接口需要测试的方面关注被测接口的功能是否实现性能是否达标安全性是否满足。重点关注数据的交换、传递、处理次数、以及控制管理过程。可参考下面用例设计中的接口测试点。2、编写和执行测试时的原则不同的接口参数覆盖不同的业务场景在后台构造合适的数据来满足接口的测试用例根据接口的返回值断言其是否返回期望结果并查看数据库验证测试用例涉及多个步骤的应对涉及的步骤都验证删除测试过程中产生的结果确保每个用例执行前都是一个清洁的环境3、接口测试的重难点动态变量参数化接口依赖及中间变量问题异步接口结果验证问题相应参数及嵌套很多的验证问题接口测试框架的稳定性问题资源清理问题多接口场景测试四、接口测试的用例设计接口测试对象主要为接口但随着系统复杂度越来越高接口越来越多完全覆盖是一件很困难的事情且实际过程中任意接口的变动都可能导致我们接口测试用例不可用。1、接口测试点参考2、接口用例设计优先级优先级--针对所有接口暴露在外面的接口因为通常该接口会给第三方调用供系统内部调用的核心功能接口供系统内部调用非核心功能接口优先级--针对单个接口正向用例优先测试逆向异常用例次之 (通常情况非绝对)是否满足前提条件 是否携带默认参值参数 参数是否必填 参数之间是否存在关联 参数数据类型限制 参数数据类型自身的数据范围值限制是否满足前提条件有些接口需要满足前置条件才可成功获取数据。常见的需要登陆 Token。逆向用例针对是否满足前置条件 (假设为 n 个条件)设计 0~n 条用例是否携带默认值参数设计 1 条正向用例带默认值的参数都不填写、不传参必填参数都填写正确且存在的 “常规” 值非必填参数不填写、不传参业务规则、功能需求根据实际情况结合接口参数说明可能需要设计 n 条正向用例和逆向用例参数是否必填针对每个必填参数都设计 1 条参数值为空的逆向用例参数之间是否存在关联有些参数彼此之间存在相互制约的关系。逆向用例根据实际情况可能需要设计 0~n 条用例参数数据类型限制针对每个参数都设计 1 条参数值类型不符的逆向用例参数数据类型自身的数据范围值限制针对所有参数设计 1 条每个参数的参数值在数据范围内为最大值的正向用例针对每个参数 (假设 n 个)设计 n 条每个参数的参数值都超出数据范围最大值的逆向用例针对每个参数 (假设 n 个)设计 n 条每个参数的参数值都小于数据范围最小值的逆向用例以上几个方面考虑全的话基本可以做到如下几个方面的覆盖主流程测试用例正常的主流程功能校验分支流测试用例正常的分支流功能校验。异常流测试用例异常容错校验五、接口测试的流程接口测试的流程和功能测试流程类似依据的对象是需求说明书和接口需求接口测试流程如下1、接口测试需求分析从 UI 交互和接口参数分析接口的设计逻辑首先根据接口设计的技术架构方案了解清楚被测接口对应的公共入参、入参、出参及返回数据的 Json 结构规范根据测试场景进行测试。理解接口参数熟悉接口参数的输入要求、输入值范围、必填项等理解接口输出熟悉返回 json 的结构构成、返回值类别、返回值范围、返回 data 的不同类型等。理解接口的逻辑、接口的业务关联熟悉技术方案中的接口相互关联、依赖的关系接口与接口之间的数据传递等。寻找测试点根据输入 (参数名、取值范围)、输出 (参数名、返回值范围)、关联关系进行测试点分析2、编写接口测试计划接口测试计划与功能测试计划的目标一致都是为了确认需求、确定测试环境及测试方法为设计测试用例做准备初步指定接口测试进度方案。接口测试计划包括概述、测试资源、测试功能及重点、测试策略、测试风险、测试标准。3、编写、评审、执行接口测试用例编写的接口用例评审通过后借助测试工具执行测试上报发现的问题接口数据准备4、接口自动化测试持续集成要点项目测试时接口会有变更用例也会更新需要借助工具如github来维护测试用例进行持续集成通过自动化测试实时监控项目接口运行情况。接口自动化测试持续集成主要包括以下内容流程方面。在回归阶段加强接口异常场景的覆盖并逐步向系统测试、冒烟测试阶段延伸最终达到全流程自动化。结果展示。更加丰富的结果展示、趋势分析、质量统计和分析等。问题定位。报错信息、日志更精准方便问题复现与定位。结果校验。加强自动化校验能力如数据库信息校验。代码覆盖率。不断尝试有目前的黑盒向白盒下探提高代码覆盖率。性能需求。完善性能测试体系通过自动化的手段监控接口性能指标是否正常。5、接口测试流程例子测试A借助Postman工具测试接口每天或定期将最新的接口集合文件导出到本地将最新的集合文件推送到git服务器Jenkins每次运行接口测试时先做一次文件拉取动作再通过命令行执行接口测试将测试结果通过邮件或钉钉发送给项目负责人六、各种场景下的接口测试1、单接口的测试单接口测试的重点其实就是保证该接口的正确性和健壮性。也就是说你既要保证这个接口可以按照需求正确处理传入的参数给出正确的返回也可以按照需求正确的拒绝传入非正确的参数给出正确的拒绝性返回。总结需要有足够的用例保证接口能正确处理各种正常情况和异常情况2、业务流程的接口测试多接口测试主要是保障通过多个接口的串联操作可以完成原来需求中提出的业务逻辑总结重点在于业务流程是否能跑通拓展我们更需要关心业务流和数据流的关系要完成整体业务逻辑的接口测试需要理清每个流程的数据流程而数据流程驱动了业务流处理,。并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常3、复杂场景的接口测试测试场景一被测业务操作是由多个API调用协作完成背景一个单一的前端操作可能会触发后端一系列的API调用此时API的测试用例就不再是简单的单个API调用而是一系列API的调用存在的情况存在后一个API需要使用前一个API返回结果的情况需要根据前一个API的返回结果决定后面应该调用哪个API存在问题如何高效地获取单个前端操作所触发的API调用顺序解决上述问题思路通过网络监控手段捕获单个前端操作时所触发的API调用顺序譬如Fiddler、Charles等抓包工具。也可以通过用户行为日志通过大数据手段来获取调用顺序测试场景二API 测试过程中的第三方依赖背景API 之间是存在依赖关系的比如你的被测对象是 API A但是 API A 的内部调用了 API B此时如果由于某种原因API B 在被测环境中处于不可用状态那么 API A 的测试就会受到影响。在单体架构下通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题所以还不算严重。但是在微服务架构下API 间相互耦合的依赖问题就会非常严重。解决问题的核心思路启用 Mock Server 来代替真实的 API测试场景三异步 API 的测试什么是异步API调用后会立即返回但是实际任务并没有真正完成而是需要稍后去查询或者回调Callback的 API对异步 API 的测试主要分为两个部分测试异步调用是否成功检查返回值和后台工作线程是否被创建两个方面就可以了测试异步调用的业务逻辑处理是否正确测试异步调用的业务逻辑复杂性因为异步 API 通常发生在一些比较慢的操作上比如数据库 I/O、消息队列 I/O 等此时测试往往需要去验证数据库中的值、消息队列中的值等这就需要测试代码具有访问和操作数据库或者消息队列的能力。在实际工程项目中这些能力一般会在测试框架级别提供也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等。最后感谢每一个认真阅读我文章的人礼尚往来总是要有的虽然不是什么很值钱的东西如果你用得到的话可以直接拿走这些资料对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴我走过了最艰难的路程希望也能帮助到你凡事要趁早特别是技术行业一定要提升技术功底。