本篇文章给大家谈谈mock接口测试用例,以及前端mock测试对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享mock接口测试用例的知识,其中也会对前端mock测试进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
接口自动化测试之Mock
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
最后:【可能给你带来帮助的教程】软件测试最新自学教程
什么是 Mock 测试?
作为动词,Mock 是模拟、模仿的意思。
作为名词,Mock 是能够模仿真实对象行为的模拟对象。
那么,在软件测试中,Mock 所模拟的对象是什么呢?
模拟的是 SUT(System Under Test:被测系统) 的依赖,而不是其本身。
比如,我要测试 A,但 A 依赖 B,要模拟的对象就是 B。
为什么要模拟 B 呢?
提高 A 的测试覆盖率: 通过 Mock 模拟 B 返回的正常和异常的结果,使用 A 的测试更充分。
避免 B 的因素对 A 产生影响: 当 B 因各种原因无法正常使用时,导致 A 无法测试。
提高 A 的测试效率: B 的真实行为可能很慢,但模拟可以很快。
Mock 的两大功能:
记录真实的调用信息
生成模拟的返回信息
使用 Mock 的问题是什么?
可能导致问题遗漏: 毕竟是模拟的,是理想可预见的情况,真实的情况可能更复杂。
可能导致维护成本变高: 接口变更 Mock 用例要跟着改,改错和漏改都可能出问题。
常见的 Mock 类型:
方法级别: Mock的对象是一个函数调用,例如:获取系统环境变量。
类级别: Mock 的对象是一个类,例如:一个 HTTP server。
接口级别: Mock 的对象是一个 API 接口。
服务级别: Mock 的对象是整个服务。
使用 Mock 做接口测试时,一般分二步:
1. 打桩: 创建 Mock 桩,指定 API 请求内容及其映射的响应内容。
2 . 调桩: 被测服务来请求 Mock 桩并接收 Mock 响应。
在这二步之间还有一个 Mock 桩的注入 , 啥是 Mock 注入?
Mock 的本质就是用模拟桩来替换真实的依赖。所谓 Mock 桩注入 就是 阻断被测服务与真实服务之间的链路,建立被测服务与 Mock 之间的链路过程。
如下图所示:
常见的方式包括但不限于以下五种:
API 请求构造
客户端 Mock:在被测服务 内部 工作,直接拦截被测服务的 API 请求方法,直接从方法内部返回预定义的 Mock 响应。
服务端 Mock:在被测服务 外部 工作,作为 HTTP 服务器接收被测服务发送的 API 请求,并返回预定义的 Mock 响应。
本地配置:
对于服务端 Mock,打桩之后会生成唯一的 Mock 桩地址,被测服务提供一个依赖服务地址配置项,在需要使用 Mock 时将依赖服务地址修改成 Mock 地址。
配置中心
对于服务端 Mock,为了避免修改依赖服务地址配置项导致被测服务重启,可以采用配置中心存储和管理依赖服务地址配置,或者使用注册中心记录服务与服务地址的映射关系。
反向代理
在微服务架构下,被测服务与依赖服务之间可能不是直连的,而是经过了一层反向代理,例如 API 网关。在这种情况下,被测服务是通过调用 API 网关来间接调用依赖服务的接口。
前向代理
服务端 Mock 除了作为 HTTP 服务器,还可以兼备 HTTP 代理的功能,这种架构又叫做 Mock 代理。
对比:
常用 Mock 工具:
单元测试级别:
easymock、jMock、Mockito、Unitils Mock、PowerMock、JMockit..
接口测试级别
Wiremock、Mockserver、Moco、Mock.js、RAP...
微服务接口测试之mock测试
微服务的接口测试
mock接口测试用例,一般都是使用restful接口。微服务的接口测试主要是通过调用各个服务的接口进行测试。Mock服务想要达到的目的就是:被测服务A不被其
mock接口测试用例他服务所限制
mock接口测试用例,只要被测服务A能走完流程,就可以完成这个接口测试。这个时候就需要用到mock服务,把其
mock接口测试用例他服务用mock服务来替代。
python有个关于mock服务的框架:mock框架。
初学者: https://github.com/dreamhead/moco
mock框架: https://pypi.org/project/mock/
在选择好mock框架后,需要的注意事项:
mock单元测试 mockito实践
@Rule
public MokitoRule rule = MockitoJUnit.rule();
注意这里的修饰符public,如果没有这个修饰符的话使用mock测试会报错
@Rule
public ExpectedException thrown = ExpectedException.none();
可以选择忽视抛出的异常?(我是这么理解的不知道是否正确)
这里我还没有看juint执行的逻辑,只是看了mock环境下获取注解创建mock对象,并将mock的对向注入到@Injectmocks的目标测试对象中去的逻辑。
使用的jar包版本是junit.junit.4.11,org.powermock.powermock-api-mockito.1.6.6
创建一个interface用于目标测试类的filed的type。
创建一个目标测试类,其中声明filed的type为上面的interface的type
最后创建一个测试用例对象用于测试目标测试类
我从rule对象执行的时候开始追踪,junit的运行原理略过
其中的testClass就是测试用例,MyMockTest的实例,annotationEngine是默认的注解驱动InjectingAnnotationEngine,
这个方法的内部获取测试用例的type,获取注解驱动,并判断是否是默认的注解驱动,可以自定义注解驱动?(暂时我还办不到),之后注解驱动执行
InjectingAnnotationEngine.process 内部只有两个方法,从名字和其上的注释可以知道
processIndependentAnnotations处理独立的filed,其实就是测试用例中有@mock注解的filed,这里就是a和b。processInjectMocks处理依赖于独立mock对象的filed,就是测试用例中有@InjectMocks注解的filed,依赖于mock对象的目标测试类,这里就是DoMainObject,先看processInjectMocks
入参分别为测试用例的type,和instance,方法中只有一个循环,在循环的内部处理三件事
1delegate.process(classContext, testInstance);委派对象处理@Mock,@Captor等注解,
2spyAnnotationEngine.process(classContext, testInstance);监视注解驱动处理@Spy注解
3获取测试用例的父类,赋值给原来的变量
4如果Class的type为Object,跳出循环
这个方法就是先处理自己的独立注解,然后去处理父类的独立注解,如此往复直到父类为Object源类。
这个方法参数还是Class的type和Class 的instance,
处理过程是获取instance的所有field就是所有的属性,然后循环获取filed的上的所有注解,更具注解和field尝试创建mock对象,这里最后的创建对象时使用cblib创建代理对象,最后创建一个Setter对象将创建的cglib代理对象mock对象,set进instance的field中去,即完成了一个测试用例中的属性的注入(spring的bean注解注入方式是不是也是如此呢,所有的基于注解的实现原理是否基本类似于此呢)
这里只关注两个方法createMockFor和FieldSetter(testInstance, field).set(mock)
createMockFor方法的流程比较复杂,
这个方法的内部有两个方法,
在这个方法中对annotationd的类型与已有的注解处理器对象集合进行判断是否包含,如果包含取出对应的处理器对象,如果不包含空实现一个注解处理器实现process方法返回为null。也就是说在DefaultAnnotationEngine对象的实例中只处理特定的注解生成其mock代理对象。
这个注解处理器的集合是在4中创建了deletage时创建了DefaultAnnotationEngine对象,然后在其构造方法中调用了注册注解驱动方法
private final Map, FieldAnnotationProcessor? annotationProcessorMap = new HashMap, FieldAnnotationProcessor();
根据获取的annotationProcess对象执行process方法,如果不是从map中获取的那么返回值就是null,在本测试中就是@mock的方法返回了MockAnnotationProcessor类型的注解驱动,
Mockito.mock(field.getType(), mockSettings);这个就是最后创建mock的cglib代理对象的方法,对这个方法暂时就不继续追踪了,
现在我们已经将一个@Mock注解下的测试类中的field建立好了,让我们回到5的process方法中,能看见这个步骤就是重复的执行这段逻辑:
获取field的所有注解,调用createMockFor方法,然后在此方法中和DefaultAnnotationEngine预置的FieldAnnotationProcessor 实现类型集合做匹配,满足的获取指定的注解处理器创建对应的mock对象。不满足的创建一个匿名子类,其中实现的方法指定返回null。以此将@Mock等注解和其他注解区分开来,只创建@Mock和@Captor等独立的注解。如此步骤processIndependentAnnotations.process()就完成了。
spyAnnotationEngine.process的执行类似,但是这个注解处理类是使用反射去根据类型创建一个真实的实例对象返回而不是创建一个mock的cglib对象。
现在我们完成了processIndependentAnnotations,来看看现在的测试用例instance
可以看到现在a,b使用@Mock注解的field已经存在cglib的代理对象了,使用@InjectMocks的doMainObject暂时还是null,现在来看processInjectMocks
方法内部的核心方法是injectMocks,内部的逻辑从子类到父类最后到Object处理每个继承层级的@InjectMocks注解
方法内处理
1获取测试用例的Class类型
2创建一个Field对象的set集合
3循环处理
4将class中所有InjectMocks注解的field放到mockDependentFields集合中
5将创建的mock对象添加到mocks集合中
6Class类型是Object跳出循环
7创建@InjectMock注解修饰的field
这是根据依赖创建目标测试类的mock对象。
最后方法完成的时候
可以看到目标测试类创建完成,依赖a,b也已经注入。
没有去追踪Junit和cglib只是将中间mock的注解的过程进行了追踪:
基本就是先创建mock对象,然后将根据依赖创建@InjectMocks的目标测试类对象
其中注解的区分
1@InjectMocks和其他类型不同,
2@Spy和@Mock,@Captor等注解不同
在使用的过程中Rule一定要是pulic修饰的
在使用mockito的时候还出现了mock的对象在测试的时候报空指针的问题,我追踪后发现是同类型的interface在注入@InjectMocks修饰的主目标对象的时候是有排序的,会根据测试类中的filedName进行排序依次向下注入,解决办法就是把@InjectMocks的所有field都进行mock。
python单元测试--mock
使用mock,可以将某个函数所依赖的对象或者变量mock掉,从而降低测试条件的负责度。如下所示:
上述是mock对象的简单使用方法,通过实例化一个Mock对象从而模拟掉原始函数的返回值,高级一些的用法就是通过mock.patch装饰器,装饰在类或者函数上进行模拟测试,如下在test.py文件中有两个类:
测试用例设计如下:
以上测试用例说明,通过patch装饰器模拟了 test.ProductionClass1 这个类,在 test_01 中使用 mock_class 模拟 test.ProductionClass1 。首先通过 mock_class.return_value 获取类实例(如果模拟的是函数,则不需要这一步),然后通过 obj1.pro1_method.return_value 设置方法的返回值,并进行测试。测试结果说明无论是通过 mock_class 还是 test.ProductionClass1 还是 obj1 执行方法,获取到的结果都是设置的值,并且在另一个类中调用模拟类的方法,也能成功获取到设置的 return_value 。
关于mock接口测试用例和前端mock测试的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
mock接口测试用例的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于前端mock测试、mock接口测试用例的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~