分类:接口测试

支付宝--平台技术部--质量技术部--工具平台研发团队招聘

蚂蚁金服--平台技术部--质量技术部--工具平台研发团队邀请您一起打造AQC 全力打造蚂蚁金服全站产品质量管控、资损防控、风险防控、测试管控、回归体系、效率工具、无线测试等平台,见http://aqc.alipay.net 全站回归体系建设,见详情;无线测试平台建设,见详情;线下工具平台建设实践,见详情 工作年限:五年以上 学历要求:本科或硕士 岗位级别:P6+、P7、P8 待遇面谈:Base + 年终奖+ 红包 + 股权激励 岗位描述: 1. 负责测试平台研发、持续集成平台或回归体系建设、自动化测试框架研发、移动应用开发(andriod或ios); 2. 带领组员进行项目研发和关键技术攻关; 3. 要带头写代码,尤其是技术攻关,要能够落地,不单单只是方... 详情

代码测试(CodeTest)

代码测试(Code Test): 1.什么是代码测试?与传统的功能和接口测试有什么不同? 代码测试的立足点是Code,是基于代码基础之上的,而传统的功能测试和接口测试是基于应用的,必须对应的测试系统是在运行中的。 代码测试不会特别注重接口测试的可持续性集成。 代码测试的特点是快捷高效准确的完成测试工作,快速推进产品的迭代。 2.Code Test 的方法: (1)代码走读和review 适合场景:逻辑相对简单,有较多的边界值。 方法介绍:直接查看和阅读代码,检验逻辑是否正确。 (2)代码debug与代码运行中测试 适合场景:数据构造比较困难,特殊的场景覆盖。 方法介绍:1.直接在debug代码过程中查看数据流走向,校验逻辑。 2.在debug过程... 详情

Java基本类型与对象类型的区别导致的Bug剖析

本文中所提到的基本类型是指类似 int,long等,而对象类型是指Integer,Long等。 基本类型和对象类型第一个最大的不同在于初始化的值不同。int 初始化为0,Integer 为null。在一个线上产品故障的排查过程中发现根本原因在于开发同学把数据库DO对象的一个字段从int 改成了Integer引起的,因为int 类型可以正常的初始化,而Integer 对象的时候不能正常插入,导致了线上产品故障。 正是由于初始化的值的不同,也导致了在进行逻辑比较的时候,对象类型很容易出现空指针异常: 基本类型可以直接进行逻辑判断: int num; if( num >0 ){ //todo } 这样的代码不会有空指针的异常,但是如果是如下代码: Integer nu... 详情

调试全网回归脚本小结

我们在完成接口测试之后,需要先通过mvn test本地运行全部的脚本通过,然后放到全网回归的实验室进行回归。尽管在Eclipse里面全部的脚本通过,但是无论在本地还是在全网回归的机器上面,都很可能会因为各种原因,而无法运行全部的测试脚本;原因有很多很多,很可能每次调都会遇到不一样的问题,最近调全网回归的时候,又遇到了问题1、2,在此小结一下。 A、整个运行透传两个脚本时,总是第二个失败;而单独运行的校验都是通过的; 排查过程: a、观察第一次运行总是第二失败,debug发现返回结果同第一个; b、调整两个脚本的顺序,再次运行发现位置在后面的运行失败,返回的结果同第一个; 猜测:同时运行两个用例,返回的结果,可能网络层相应慢一步,而用例这边的线程已经往后面跑,拿结果的 ... 详情

国际事业部持续集成案例分享之一

国际事业部,持续集成已运作快2年了,一直以来都比较低调,自给自足,以服务好国际事业部为核心运作。自从听了ADC的分享之后,挺激动,也想分享下我们的实践、我们的想法。有种不甘示弱的赶脚,觉得我们做的还挺靠谱。ADC,你给了我们分享的信心。 非常简单的描述下,我们持续集成的核心思想。 打通SCM系统,自动获取项目相关信息(新建、修改、删除)。 1、自动创建单元测试任务,并且构建任务,返回构建结果给项目成员。 2、自动根据项目信息,关联自动化测试代码。(目前有9种不同自动化类型) 2.1、自动搭建项目环境应用,反馈项目内环境绑定。 2.2、根据项目绑定,自动运行基于应用环境的测试代码,运行结果反馈项目成员。 主干变更升级同样自动持续运作。 附上简易图示: ... 详情

容错测试2-hsf mock方案

问题描述: 前文中描述了基于aop的容错测试解决方法, 我们可以结合具体的业务,使用场景来编写脚本进行测试.但是实际工作中,随着业务复杂度的不断提高,系统间的相互依赖更加复杂,完全依赖测试人员一个个编写针对性的容错测试脚本来保证系统的容错能力,会越来越困难.我们需要一个更”自动化”的解决方案. 再仔细分析一下淘宝的实际使用场景,淘宝的应用这件的依赖关系类似下图: 一个淘宝的应用,依赖几十个其他应用提供的服务是很正常的现象。依赖系统之间使用HSF服务(淘宝内部的分布式的服务框架,RPC解决方案)来进行相互调用,在调用方进行如下的配置,就可以调用远程的hsf服务. 应用提供的服务如果有异常,对于服务的使用方来说就是调用HSF时抛异常,比如在hsf服务调用超时,在使... 详情

容错测试1-aop实现

背景介绍: 今年我们产品线对我们去年线上的遗留bug做了分析,发现线上的遗留问题基本上是一些无法测试到的异常流程或者依赖的其他应用有异常引起的,普通的正常功能测试已经很难发现那些问题,于是我们今年提出了一个容错测试的目标,希望能够解决这类问题的测试瓶颈. 我们的目标: ² 测试各种错误异常情况下系统的反应 ² 通过自动化的手段运行 为了说明后面的内容,先看一个简单的例子,有下面的被测代码: 接口: public interface IHello { public int hello(); } 实现: public class Hello implements IHello { @Override public int hello() { ... 详情

接口测试数据准备的扩展

问题描述: 在使用淘宝的itest(http://kelude.taobao.org/itest/zh/Overview)接口测试框架时,可以使用@ITestDataSet(value={"xxx.xls"})来进行数据准备.在脚本执行前会把excel中的内容自动插入数据库,执行完成后又会自动清理.功能很强大. 但是在我们实际使用过程中遇到了一个问题: ² 我负责的应用A,需要依赖于应用B提供的服务Service_B1. ² Service_B1的数据依赖于Table1.于是在我们针对A写的脚本中作了针对Table1的数据准备. ² 实际上Service_B1的服务还依赖于Table2,Table2如果没有数据光有Table1的数据, Service_B1回报错 ² 一天应... 详情

依赖配置问题的解决

问题描述: 先描述具体问题,在我们使用itest进行接口测试的时候,经常会遇到一个问题,开发的bean配置经常会调整,比如把bean name从bean1改成bean2,特别是一些间接依赖的bean,调整后测试脚本就会报错,而且排查起来比较麻烦. 在前面的文章中,说到过可以通过直接引用开发的配置文件来解决问题,这样只要开发的配置文件名不变,修改开发的配置文件不会引起测试脚本的问题. 但是使用过程中又遇到了新的问题,因为淘宝的很多配置都是基于auto-config的,(对auto-config不熟悉的同学,可以参考一下webx的auto-config帮助: http://openwebx.org/docs/autoconfig.html,这里不详细介绍了)直接通过引用会报Could... 详情

Nginx单元测试自动化浅析之二-Test::More用法

Nginx单元测试自动化浅析之二-Test::More用法 Perl 提供测试的基础模块是Test::More ,该包能提供测试用例的执行以及测试的断言。Test::Unit测试框架以及Test::Nginx测试框架都是基于该模块创建的。接下来介绍该模块常用的使用。 1.导入包的方式 use Test::More; 同时Test::More需要事先申明需要测试的 testcase 的个数,声明方式如下: use Test::More tests => 2; 这表示在该模块中有两个测试用例被执行。 有时候,你不知道有多少测试用例会被执行,可以用这个方法: use Test::More; # see done_testing() …… 执行测试用例 …... 详情

AutomanX框架原理-JUnit4测试方法断言失败后重试Demo

上文讲到JUnit4如何支持测试方法断言失败后重试,觉得有必要分享下怎么使用。还是上代码: 这里Runner的名字就是自己扩展的BlockJUnit4ClassRunner,如果你使用的是AutomanX的话,直接继承基类就好了,不需要考虑Runner的问题。由于测试基类上加了@Retry注解,那么所有继承BaseTestCase的测试类的测试方法都会默认断言失败后再重试两次(共执行三次)。 上面的测试方法test_1中断言静态变量i为3,直接执行肯定会报错(不贴图废话了),显然要重试执行到第三遍才会为真,出现我们期待的绿条条。由于我们继承的BaseTestCase,刚好会重试三次。看结果: BeforeClass和AfterClass各执行了一遍,... 详情

AutomanX框架原理-JUnit4如何支持测试方法断言失败后重试

前两天在AutomanX群里看到这样一个需求:断言失败用例自动重试运行,以消除WebUI自动化中常见的虚假失败,TestNG或JUnit38想要满足这个需求很容易,这里不做讨论。由于JUnit4是基于Runner执行的,不再那么容易扩展以实现本功能。利用周末的时间,又读了一遍JUnit底层Runner这部分源码,感觉实现起来也不是不可能,忍不到周一了,遂动手实现了一把,果然功夫不负有心人。这里分享下思路和实现代码,这部分功能后续应该会集成进AutomanX,有需求的同学也可以先用为快。闲话少说,上干货: JUnit4的扩展主要是自己实现一个Runner继承BlockJUnit4ClassRunner,重写部分关键方法,达到实现新功能的目的,automanx、itest、feed4... 详情

kelude web层测试itest-webx

kelude向java,webx转型的几个模块(用户、产品、项目、应用,机器),biz层和dal层使用itest进行接口测试,覆盖率基本达到了80%。开始思考如何对web层做自动化测试,需要达到以下几个目标: 用例编写简单 用例稳定,不会出现假摔现象,一旦失败,就是代码问题或是脚本问题,不存在框架问题或环境问题 用例维护简单 无缝接入到部署流程中 运行速度快 最后,我选定了淘宝的itest-webx, 把itest-webx抽象为接口测试,调用http请求相当于调用接口,数据的检验为检查context返回的数据或数据库创建的数据。这样来看,可以 发现写用例是不难的。但是itest-webx也有其难点。下面分析一下itest-webx的优缺点: ... 详情

法政先锋项目-测试技术问题小节

v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} 法政先锋项目是淘宝服务线为了应对客服量减半目标而进行的项目,项目测试过程中遇到了一些问题,也尝试了一些新的测试手段,下面进行了总结,供大家参考. 1 问题,hsf服务不稳定: 现象:调用hsf服务时发现在eclipse中有时会报错,提示: 定位过程: 检查相关的hsf服务是否存在,如果不存在则属于服务问题,检查结果,确实存在 1. debug脚本,debug时发现通过,... 详情

【GBA】2012Q3-商品规则校验代码漏洞

Bug标题 规则使用or及and条件,当校验条件有before,而校验动作为发布时,整个规则被忽略 发现阶段:1-PRD评审前2-PRD评审时3-PRD评审后UC评审前4-UC评审时5-UC评审后测试执行前6-测试执行期间7-预发期间8-发布后9-daily回归10-测试用例评审时11-发布前遗留原因定位:1-需求2-设计3-后端编码4-前端与交互5-环境深度:1-很容易发现2-正常发现3-很难发现 Bug影响 商品发布规则限制条件在启用(校验DB商品场景+and和or关系都包含+发布动作)下,整个规则会被放过,导致该场景下商品发布限制规则会失效。 Bug发现过程 1.前期review规则后台代码,发现简单规则(只包含一个条件的规则)与多个条件的规则走的是不同的规则... 详情

返回首页 博客 技术交流 产品 期刊下载 关于我们 意见反馈 无障碍

浙ICP备09109183号-14 Copyright © 2003-2015 TaobaoTesting.com 版权所有