杭州软件测试培训
杭州软件测试培训,天眼教育带你遨游软件世界!
快速咨询国家电子信息产业实训基地实训中心
杭州市服务外包重点培育机构
杭州市大学生见习基地
下城区高新技术产业园定点人才培训与输送机构
杭州市下城区科技创业中心孵化企业
测试环境
1Oracle等常用数据库管理
2编程技巧及思想(Java)
3软件测试技术培训
4软件测试技术实战
5职业素质
6十年以上工作经验,有着丰富的项目经验,J2EE技术基础好,技术全面。
工作经验十年以上,曾先后在创智集团、IBM中国担任开发、设计、项目经理、高级咨询顾问工作。
淘宝全国唯一金牌服务商--绿浪视觉公司视觉总监,视觉设计讲师,拥有丰富的实战经验,为客户提供高品质视觉呈现。
WEB/H5前端开发、Android、java 讲师 五年开发经验,三年教学经验。
零首付!
学习期间不花一分钱!
学完后靠自己的能力还学费!
配套服务!
专业就业指导;入行后相关技术支持,以及终身就业!
1.软件测试的历史
2.软件测试基本概念与意义
3.软件测试过程模型
4.常用软件测试方法
5.软件测试生命周期与流程
6.软件测试计划方案编写
7.软件测试需求分解与跟踪
8.黑盒测试用例设计方法
9.白盒测试用例设计方法
10.缺陷识别与缺陷跟踪系统
11.测试评审与风险分析
12软件测试总结与过程度量
通过这课程的学习,掌握软件测试的意义与重要性,掌握软件的通用测试技术与方法,掌握软件测试各阶段工作的主要流程与方法,具备从业的基本资格。
1、开始自学的时候找一本书来入门(软件测试原版第三版很不错)-差不多要1个月左右的时间、要能看懂明白里面的知识、这个阶段主要是学习理论知识 2.....
选学校的个人角度和观念不同,发表的意见也不同,还是选择学校先选择专业,身边同事在川石教育学出来的,还不错。 .....
目前国内软件测试人才缺口已达到30万,其中在我国大中型发达城市的人才需求就突破20万,并以每年20%的速度递增。人才稀缺自然带来待遇高涨。在某软件.....
1、初级测试工程师:一般刚刚入门,熟悉基本的测试流程,入门薪资一般在5000-8000元之间。他们的工作通常是按照测试方案和流程对产品进行功能测试,检查.....
提升微服务测试效率:消费者驱动契约测试
发表于:2019-7-10 11:56 作者:yuanyi928 来源:EAWorld
软件测试技术 契约测试 概述: 在软件工程的世界里,我们经常面临变化。微服务不仅改变了软件的体系结构,而且改变了团队的组织方式和协作方式。 相对于单体式应用,微服务有其优势,同时,也有引入后所新产生的问题,测试就是问题之一。 在这篇文章中,我们想概述一下测试如何在微服务的新世界中发生变化。我们还将介绍消费者驱动的契约测试的细节和支持它的框架。 为了较为全面的阐述CDCT的概念,本文翻译、引用、和综合了多篇相关文章的内容,相关链接附后。 目录: 一、单元测试 二、端到端(系统)测试 三、集成测试 四、使用消费者驱动契约测试(CDCT) 五、总结 一、单元测试 当我们谈到微服务时,我们还应该进行单元测试吗?答案是肯定的,单元测试已经证明是一种可靠的、快速的,也不是那么昂贵的方法来测试业务逻辑的有效性。但是单元测试仅仅保证服务提供者或者服务消费者某一方的代码是有效的或者功能是正常的,而不能保证服务之间的交互是有效的。而这恰恰是微服务的核心应用场景之一。 二、端到端(系统)测试 当我们谈到微服务时,我们还应该进行端到端的测试吗?是的,进行端到端测试是很重要的,但是当我们谈到微服务时,为了执行端到端的测试,需要部署从服务消费者到服务提供者之间所有环节的相关调用,复杂程度可能会非常高。 三、集成测试 测试两个服务(提供者和消费者)之间的交互的传统方法是使用集成测试。这样做的目的是在某些集成环境中同时运行消费者服务和提供者服务,并检查它们是否按预期进行交互。这种类型的测试模拟了服务在生产环境中的行为,因此在理论上集成测试是有意义的。然而,这种方法存在一些问题。 首先,集成测试通常比较慢。它们需要设置集成环境,启动消费者和提供者服务并初始化它们的依赖关系。起初,这似乎不是一个问题,但是随着集成测试的数量开始增加,构建过程变得越来越慢。在微服务体系结构中尤其如此。在每一对交互的微服务之间进行集成测试是不合适的。 集成测试的另一个问题是它们很脆弱。有时,它们会因为与服务本身无关的原因而失败,可能存在网络问题或数据库之类的外部依赖关系。而意味着失败的集成测试并不一定意味着代码存在问题。 集成测试的另一个问题是定位困难。即使由于消费者和提供者服务之间的实际集成问题而导致集成测试失败,很难确定问题的所在:这是消费者服务的错误吗?还是提供者的服务?还是两者兼而有之? 集成测试增加了额外的团队开销。集成测试主要由QA团队执行,而不是由开发人员自己执行,这意味着在出现问题时,团队之间需要额外的开销。这也导致了一个问题:谁更适合测试两个服务之间的集成点:QA团队?还是服务的实际开发人员?在到达QA之前,清楚地知道两个服务在开发时是否正确地交互,将为我们节省大量的时间和开销。 四、使用消费者驱动契约测试(CDCT) 虽然三种方式各有利弊,但与集成测试及端到端测试相比,单元测试相对来说是健壮、可靠的,它们工作速度快,并且非常具体地告诉我们问题在哪里。如果可以更加有效的测试方法改进单元测试来验证服务间交互,肯定会改善我们的开发、测试和部署体验。 消费者驱动契约测试(Consumer-Driven Contracts Testing)背后的理念是定义每个服务消费者与提供者之间的契约,然后根据该契约对消费者和提供者进行独立测试,以验证他们是否符合契约约定的事项。 为了更好地理解,我们将使用以下示例模型来描述这一微服务测试方法背后的概念。 在上图中,我们可以看到两个微服务通过REST相互通信。第一个服务是消费者(Consumer)的角色,第二个是提供者(Provider)的角色。 当服务提供者不发生变化的情况下,比如我们通过Mock模拟服务提供者的相关反馈,相关测试是可以通过的。 但是,如果是在生产环境中,测试时模拟的服务反馈很可能跟不上服务提供者的变化,比如服务提供者更改了服务的数据格式,从“名字,姓名“到”人名“。集成测试将无法捕捉到这个问题,因为它们是针对过时版本的提供程序运行的,此时,就会发生如下的情况。 消费者驱动契约的理念是将服务消费者和提供者之间的互动正式化。服务消费者创建一个契约,它是服务消费者和提供者之间就他们之间将要发生的交互达成的协议。或者换句话说,提出服务消费者对提供者的期望。一旦提供者就契约达成协议,消费者和提供者都可以获取契约的副本,并使用测试来验证它们的相应实现没有违反契约。 消费者驱动的契约测试,通常实现方式如下: 1. 选择合适的场景,定义消费者的请求和期望的响应。 2. 使用Mock机制,为消费者提供模拟的提供者以及期望的响应。 3. 记录消费者发送的请求、提供者提供的响应以及关于场景的其它元数据,并将其记录为当前场景的契约。 4. 模拟消费者,向真正的提供者模拟发送请求。 5. 验证提供者提供的契约是否和之前记录的契约一样。 这种新的测试方法的优点是它们基本上是添加了交互条件的单元测试:它们可以在本地独立运行,而且速度快、可靠。但这其实与Mock方式模拟的好处相当,事实上,CDCT所带来的优势远非如此。 优势1:降低接口变化带来的服务消费者风险 CDCT契约的发起方是服务消费者,由服务消费者定义自己所需要的反馈信息,因此,可以保证服务消费者总是能够获得自己所需的反馈。而不论服务提供者一方发生了什么变化。以CDCT测试框架PACT为例。 服务消费者通过建立模拟提供者的Mock,可以对请求、响应和相关信息记录下来,成为一个Pact文件。这个文件就是消费者与提供者之间的契约。在这个过程中,服务提供者无需进行任何操作。 接下来,在服务提供者一端,将通过模拟消费者的Mock对Pact文件进行回放,要求服务提供者针对该契约做出正确的响应。通过这样的的过程,完成一次完整的从服务消费者向服务提供者的驱动过程。 当服务提供者需要对接口做出变更时,仍旧需要遵循契约的要求,以反馈正确的结果,这样,就可以保证服务消费者总是得到正确的信息而不论服务提供者的接口发生怎样的变化。除非消费者端主动的重新订立契约。 优势2:解耦开发团队,降低测试成本,解放生产力 当服务消费者和服务提供者以契约为中介形成解耦的时候,相关的技术团队也因此形成了解耦,而不需要一定针对一个端到端的测试场景来进行配合。 这里我们引入两个技术团队进行相关的测试。左侧的是服务消费者,需要通过ID查询用户的邮件地址,右侧的是服务提供者,负责反馈正确的邮件地址信息。 在服务消费者和提供者之间建立一个契约,我们称之为TEST,来要求服务提供者根据ID反馈正确的EMAIL。 服务消费者可以通过运行TEST测试来了解自己能否获得正确的信息,但事实上,这并没有必要,因为只有当服务提供者一方发生服务接口的变更时,才会影响契约的效力,所以正确的做法是,只需要在服务提供者一方来进行对契约的验证测试即可。 这样,服务消费者将通过契约来驱动服务提供者完成既定的功能反馈,当双方对此过程协调一致,运转正常之后,服务提供者将不再需要服务消费者来发布任何契约的变更,就可以单独的依赖契约发现代码的缺陷。而服务消费者技术团队,就可以专注于本身的事情,甚至于去支持其他的项目内容。 应用场景举例:第三方API的集成测试 在现实场景中,一方面企业内部会有诸多的遗留系统API,另一方面也同时会有很多情况需要调用外部的API,比如谷歌地图,这些情况下API并不受我们的掌控,即使提交一些反馈,相关变更也可能以数周或者数月为单位,甚至对于遗留系统来说,相关的供应商都已经不复存在。 对于应用将对这类API进行集成的场景,此时,应用是消费者端,而API是服务提供端,我们可以有三种处理方式: 1、消费者端手动检查:通过手动检查应用程序是否做了它应该做的事情以及是否使用了来自API的正确值来确保应用程序仍然工作。 2、服务者端真实调用:首先确认API被正确集成,测试的时候直接调用API来检查相关功能是否正确,这将涉及网络带来的测试速度的影响,以及调用费用的消耗,毕竟每一次调用都不是免费的。 3、记录服务端反馈,并在代码库中回放:在这种情况下,仅需要调用一次API,并将相关反馈记录为JSON文件,从而解决了网络和费用问题,但仍旧无法绕开一旦服务接口发生变化带来的影响。 引入 CDCT可以缓解这个问题。但显然我们不能将契约发布给Google Maps API或我们遗留的CRM系统,并迫使他们遵守。这些提供者可能既不关心也不具备支持CDCT的工具。因此,乍一看,为第三方API使用CDCT似乎很奇怪。 我们可以做的是在自动化测试期间,创建另一个服务,作为谷歌API的替代品。该服务将保存从实际API中定义所需字段的契约。我们称这些服务为代理。它们从不代理HTTP请求,而是在自动化测试期间充当谷歌API和应用之间的中间角色。代理将有两个目标: 1.确保API按预期响应,就像在实际调用真实的谷歌API一样。 2.向服务消费者提供契约文件,以供回放,类似于一个JSON响应文件。 让我们举个例子,我们要展示从德国斯图加特到柏林需要多长时间。使用Google距离矩阵API 我们进行如下的调用:http https://maps.googleapis.com/maps/api/ distancematrix/json \ origins==Berlin destinations==Stuttgart |
{ "destination_addresses" : [ "Berlin, Germany" ], "origin_addresses" : [ "Stuttgart, Germany" ], "rows" : [ { "elements" : [ { "distance" : { "text" : "636 km", "value" : 635736 }, "duration" : { "text" : "6 hours 18 mins", "value" : 22651 }, "status" : "OK" } ] } }, "status" : "OK" } |
org.springframework.cloud.contract.spec.Contract.make { request { method GET() url("/maps/api/distancematrix/json") { queryParameters { parameter 'origins': 'Berlin' parameter 'destinations': 'Stuttgart' } } } response { status 200 body([ rows : [[ elements: [[ duration: [ value: 22651 ] ]] ]], ]) } } |
@Test public void validate_shouldProvideDistanceBetweenTwoCities() { // when: Response response = webTarget .path("/maps/api/distancematrix/json") .queryParam("origins", "Berlin") .queryParam("destinations", "Stuttgart") .request() .method("GET"); String responseAsString = response.readEntity(String.class); // then: assertThat(response.getStatus()).isEqualTo(200); // and: DocumentContext parsedJson = JsonPath.parse(responseAsString); assertThatJson(parsedJson).array("['rows']") .array("['elements']").field("['duration']") .field("['value']").isEqualTo(22651); } |
assertThatJson(parsedJson).array("['rows']") .array("['elements']").field("['duration']") .field("['value']").matches("\\d+"); |
stubrunner: ids: 'co.hodler:scdcproxy:+:stubs' stubsMode: LOCAL ids-to-service-ids: scdcproxy: google-distance-service |
Oracle天眼,杭州下城高新区人才中心,创立于有天堂硅谷美誉的杭州,致力于中国IT人才的培养工程。成立甲骨文(浙江)运 营学习中心,为学员提供真正的原厂课程内容、认证、实训、就业一体化服务。公司总部位于杭州和平广场,目前建有和平基地、新天地基地、富阳基地 、嘉兴基地四大实训中心,并在湖南长沙成立了分公司,湖北武汉设有办事处。
甲骨文(浙江)运营学习中心是甲骨文公司在浙江指定授权IT培训中心,以“培养高素质IT精英人才、服务社会”为企业经营宗旨,依托集团公司(天演科技、绿浪视觉)强大的技术团队与丰富的客户项目资源,直接引进国际先进IT技术,结合中国本土IT企业需求,定制化培养中高级软件开发与测试人才、3G/4G人才、电商视觉设计师、UI设计师、前端开发等技术人才。
公司经市政府认定为“国家电子信息产业基地实训中心”,是“杭州市服务外包人才培训机构”。经过多年运营,公司已与杭州、浙江地市、湖南、湖北等地多所高校建立了紧密的合作,成功为Oracle、Oracle雇主联盟、美国博克软件、鸿程系统、数银在线、淘宝网、用友软件、中软安人、文思海辉、博彦科技、罗特软件、启程科技、网轩科技、绿浪视觉等中外知名IT企业培养输送了大量中高级IT人才。
基于成熟、规范的IT人才培训体系和储备过万的专业开发工程师人才库,天眼面向国际、国内IT公司提供人才推荐、人才外包、定单培训等多项IT人才服务。