java 单机接口限流处理方案
305
2023-01-25
本文目录一览:
接口 :外部系统与本系统之间以及系统内部的各个子系统间,以约定标准提供的服务,包括对外提供的接口/对内提供的接口。
在这块实际接口自动化测试我们举一个比较生活化的例子,实际接口自动化测试我们平常使用的笔记本,在笔记本的两端有很多小插口,最常见的就是USB插口,我们可以把鼠标连接在USB插口上,也可以把键盘、U盘连接在USB插口上,为什么同一个USB接口可以连接这么多设备呢,其实这个接口,实际接口自动化测试他就有一个统一对外的连接标准。
在我们开发当中,也有一个对外暴露的接口,因为他们服务的协议都是统一的,最常见的就是hhtp协议,我们规定好一种格式,让客户端来调用我们。
这里面键盘鼠标属于调用方,插到笔记本的USB上,就可以连接设备,就可以进行操作了。对外暴露的一个统一的一个规范,这样去理解接口,更形象一些。
在了解完什么是接口之后,我们来说一下什么是接口测试。
接口测试 测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等,保证对外提供接口的正确性和健壮性。
我们在具体测试过程中,我们不用关心接口调用方和接收方的实现逻辑,我们只需要知道传入什么数据,返回什么的结果是否达到我们的预期。接口测试其实也是黑盒测试,他与UI测试的区别就是没有界面交互,是不可视化的。
测试前置 :我们不能等到整个系统全部开发完成才能进行测试,我们可以通过调用接口来进行测试,把问题拦截在前期,降低问题修复成本。
Bug更容易定位 :因为我们按接口进行测试,出现问题后在被测接口中排查就可以了,它比系统集成之后,发现问题更容易定位,系统集成之后有各种模块的调用,出现bug之后再排查,排查的链路非常的长。另外从机制上更接近出问题的地方更容易命中问题。
前后端分离结构 :现在很多系统都采用前后端分离架构,各服务之间更多的是通过接口来实现信息互通,对接口进行直接测试,可以更全面的覆盖各类测试场景。
自动化测试落地性价比高 :比UI自动化测试更稳定,我们上面已经说了UI层的元素时常发生变化,有时改一个简单的元素,都有可能导致我们的自动化测试走不下去,写一套自动化测试脚本比较容易的,但是维护起来,会耗费很大的时间精力,相对来说,接口就比较稳定,一个项目没有大的改造,入参和出参就是固定的,变化的概率比较小,这样维护起来也比较方便。
减少安全隐患 :比如我们在平常的测试过程中,测试用户名和密码,密码格式要求不能输入特殊字符,前端做了校验,而后端没有处理,这样我们只测试页面,这条case就默认通过了,但一些黑客可能通过抓包的方式进行登录,这样安全隐患就比较大了。我们对接口进行安全测试,可以避免安全隐患。
借助工具 : Postman、Jmeter、jsf平台、jsf测试工具、easytest
编写测试脚本 :Java+TestNG
请关注下一篇如何使用Java+TestNG进行接口自动化测试
Mock介绍
1.找到要替换的对象:我们需要测试的是visit_ustack这个函数,那么我们需要替换掉send_request这个函数。
2.实例化Mock类得到一个mock对象,并且设置这个mock对象的行为。在成功测试中,我们设置mock对象的返回值为字符串“200”,在失败测试中,我们设置mock对象的返回值为字符串"404"。
3.使用这个mock对象替换掉我们想替换的对象。我们替换掉了client.send_request
4.写测试代码。我们调用client.visit_ustack(),并且期望它的返回值和我们预设的一样。
上面这个就是使用mock对象的基本步骤了。在上面的例子中我们替换了自己写的模块的对象,其实也可以替换标准库和第三方模块的对象,方法是一样的:先import进来,然后替换掉指定的对象就可以了。
Mockrunner用在J2EE环境中进行应用程序的模拟测试。它不仅支持Struts actions,servlets,过滤器和标签类,还包括一个JDBC和一个JMS测试框架,可以用于测试基于EJB的应用程序。
Mockrunner扩展了JUnit并模拟了必要的行为,而无需调用实际的基础结构。它不需要正在运行的应用程序服务器或数据库。此外,它不会调用web容器或Struts ActionServlet。它非常快速,使用户可以在测试的所有步骤中操纵所有涉及的类和模拟对象。它可以用于为基于J2EE的应用程序编写非常复杂的单元测试,而不会产生任何开销。Mockrunner不支持任何类型的容器内测试。
Mockrunner不会读取任何配置文件,例如web.xml或struts-config.xml。您可以使用Mockrunner API指定所有参数。因此,可以将servlet,过滤器,标签和Struts动作作为可重用组件进行测试,而不管您在一个或另一个应用程序中使用的设置如何。无法测试配置文件中的定义。如果要这样做,可以将StrutsTestCase用于基于Struts的应用程序或Cactus。
Mockrunner支持Java版本从1.3到1.6以及J2EE 1.3,J2EE 1.4和JavaEE5。尚不支持EJB 3.0。Mockrunner支持Struts版本1.1、1.2和1.3。
下载地址:Mockrunner download | SourceForge.net
最后:【可能给你带来帮助的教程】软件测试最新自学教程
下面从以下几个方面来进行总结实际接口自动化测试:
1.设置环境
2.设置变量
3.自定义脚本写法
4.python脚本调用
在界面实际接口自动化测试的右上角实际接口自动化测试,是 环境管理 的入口实际接口自动化测试,选择管理环境后进入。
可以在左侧新建或删除环境实际接口自动化测试,右侧可以对某个环境进行编辑。
如果在系统测试时需要多个系统来测试,可以在添加默认服务的基础上,再添加其他系统的URL,在编写对应的接口时,手动选择对应服务信息。
根据需要,可以在页面右上角,快速切换为你所需要的环境。
打开环境管理(软件右上角设置形状的按钮),选择全局变量 tab。
1.添加一个名为my_variable的变量,将本地值设置值为hello,点击保存。
2.打开一个接口,在运行 tab (或接口用例)的参数值里输入{{my_variable}}即可引用该变量。
3.点击运行按钮,发送请求,实际运行的时候系统会将{{my_variable}}替换为hello,然后发出请求。
本地值和远程值的区别:
1.所有使用到变量的地方,实际运行的时候都是读写本地值,而不会读写远程值。
2.本地值仅存放在本地,不会同步到云端,团队成员之间也不会相互同步,适合存放token、账号、密码之类的敏感数据。
3.远程值会同步到云端,主要用来团队成员之间共享数据值。
4.注意:由于本地值仅存放在本地,使用一些清理软件清理 Apifox 文件缓存会导致本地值被清空,请务必注意。
变量类型:
1.环境变量是最常用的变量,同一个变量可以在不同的环境设置不同的值,变量值会跟随环境切换而改变。环境变量在环境管理模块设置
2.全局变量 使用方法类环境变量类似,但全局变量不会跟随环境切换而改变。
3.临时变量 仅在单次运行接口用例或测试管理里的测试用例或测试套件过程中有效,不会持久化保存。
使用方式:
以下两个环节可添加脚本:
在将请求发送到服务器之前,使用前置脚本。
收到响应后,使用 后置脚本(断言测试)。
接口请求的执行流程如下:
[全局前置脚本] - [分组前置脚本] - [接口前置脚本] - [发送接口请求] - [返回接口结果] - [全局后置脚本] - [分组后置脚本] - [接口后置脚本]
调试脚本:
调试脚本可以在 前置脚本 和 后置脚本里编写,使用console.log('hello')方式将调试信息写入控制台,打开 控制台 即可查看。
使用python进行前置脚本编写:
第三步:python环境变量配置完成后重启电脑和apifox
第四步:前置脚本编写
接口测试实际接口自动化测试的目实际接口自动化测试的是为了增加测试覆盖度、深入度 实际接口自动化测试,对接口的各个参数做实际场景中很难遇到的异常场景的测试实际接口自动化测试,保证接口的稳定性。如果在这个前提下接口测试还是没有发现 bug,那么可以 review 下历次迭代中是不是业务测试发现的所有 bug 都是前端的。如果是,那么说明你们的后端开发工程师能力实在很强,应该恭喜你们遇到了这么给力的队友。在测试压力很大的情况下就可以酌情考虑不做接口测试,前端测试完成就上线了。
如果不是那就应该 review 你们的接口测试用例了。是不是用例设计的还不如业务测试全面实际接口自动化测试?是不是用例设计的时候默认按照正常的取值范围?按照正常的业务逻辑进行的用例设计导致用例的覆盖还不如业务直接黑盒测出来的覆盖全。
自动化测试的主要目的不是发现多少 bug ,而是为了快速对接口做回归、做线上监控等,避免接口出现了低级问题、阻碍问题但是大家不能第一时间知道,等过了很长时间线上出了强反馈或者在错误接口的基础上又做了很多开发才被大家发现。当然,在接口自动化的基础上再做压力测试、稳定性测试等也会更方便。在这个前提下再评估接口自动化测试是否有必要,思路就会清楚一些。
整体上测试是为了保证业务中的 bug 能够在有限的资源下最大量、最快速的发现,业务实际情况不同、测试团队规模不同、测试与业务的合作模式、测试团队成员的技术能力等等都会影响测试方案的制定。
个人觉得如果团队有专人做接口测试,这种情况下接口测试定位到用来发现更多 bug 是没有问题的,如果没有发现 bug 那就需要仔细找找接口测试用例设计的问题。接口测试的目的不是取代业务测试,而是减少业务测试遇到阻碍问题的概率以及减轻业务测试模拟异常场景的工作量。接口自动化测试的目的是在回归场景节约业务测试的工作量,在新业务测试中实际反倒会占用更多的测试资源。
以上是作者拉拉肥对接口测试以及接口自动化测试的理解。你怎么看?欢迎点击 原文链接 在原帖共同讨论。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~