ios例子2 Test_MVC——理解mvc模式应用

上一篇:ios例子1 Test_main——了解简单的ios应用程序如何启动 下一篇:ios例子3 Test_xib1——使用xib布局 1.理解ios MVC机制 在iOS开发中MVC的机制被使用的淋漓尽致,充分理解iOS的MVC模式,有助于我们程序的组织合理性。 参考:http://blog.sina.com.cn/s/blog_4a3dcc3901010062.html 2. 了解view和viewController的生命周期 在接下来的例子中,继承自UIViewController的ItemViewController.m是在viewDidLoad方法中加入视图的,为了理解这一点,请先了解view和viewController... 详情

Spring mvc 模式小结

Spring mvc 模式小结 1、spring mvc简介 Spring MVC框架是一个MVC框架,通过实现Model-View-Controller模式来很好地将数据、业务与展现进行分离。从这样一个角度来说,Spring MVC和Struts、Struts2非常类似。Spring MVC的设计是围绕DispatcherServlet展开的,DispatcherServlet负责将请求派发到特定的handler。通过可配置的handler mappings、view resolution、locale以及theme resolution来处理请求并且转到对应的视图。Spring MVC请求处理的整体流程如图: ... 详情

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... 详情

linux系统一级子目录、文件个数以及文件名长度限制

本周我们一个系统新版本发布上线,其中包括修改了dump目录结构,结果在18:09分左右系统短时间内接收到700多条新发布的数据,dump目录总数达到32738个,直接超过linux系统一级子目录个数的限制,导致在dump时大量出错。而在此之前,我从来不知道原来linux上还有这样的限制,故咨询了内核组的同学并做了些调查和试验,跟大家分享一下,测试过程中大家都能多个“心眼儿”。 1、一级子目录个数: 从redhat官网可以看到这样一句话,引用一下: This is controled by these kernel include file lines: include/linux/ext2_fs.h:#define EXT2_LINK_MAX32000 i... 详情

业务格式图管理方案

一、 背景 我们在项目进展的过程中,是不是还遇到了这些问题: 1、 项目有deadline,还没开始讨论需求已经限定死了发布时间,里程碑时间点促使进度往前赶,而往往项目还没有成熟到可以推进的程度 2、 为赶进度项目成员之间的沟通会减少和不明确,每个人的理解出入就会越大,返工的隐患就出现了 3、 项目人员变更,替换的人员对项目并不是非常了解,理解成本耗费大量项目时间 4、 开发过程中的方案变更,没能及时通知到相关合作方 5、 需求方中途变更、添加需求 6、 遇到的问题,UC的载体修改起来并不是非常便捷导致大家后期不愿意维护UC 7、 新老需求纵横交错,一不小心就影响到了其他功能点 当我们疲于应对这些问题的时候,我们是不是就需要这样一个管理方式,它要满足下面几个特性:... 详情

kelude web层测试itest-webx

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

管理测试机器的使用效率

伴随着业务测试的开展,测试使用的机器逐渐增加:性能测试、全网回归、部署测试工具的机器等。当测试机器的规模逐步增加,达到上百台甚至上千台时,如何对这些机器进行有效的利用就面临着诸多挑战: 机器已申请,但长期未使用 机器处于使用状态,但资源浪费严重 部门整体的资源使用率无法估量 我们提出了机器利用率这个概念,来对机器的使用情况进行计算、统计和分类,提供直接有效的数据给各Owner,以期对机器的使用情况进行优化。 机器利用率是什么 机器的利用率是对一台机器的资源的使用情况的一个评价值。 目前,我们对机器资源的定义主要包含了以下四个百分比指标。 cpu利用率 load / (CPU核数+1) 物理内存使用率 网络流量 对以上四个指标... 详情

如何对应用做快速验证

淘宝技术体系 分层 1. 业务型应用:面向具体的业务方向和场景 2. 平台型应用:管理基础业务数据,为同类或相关业务提供公共服务 3. 中间件:负责应用间消息、数据的交换、通讯和复制,管理公共的配置 4. 核心系统:提供存储、计算、服务器等方面的基础设施服务 * 1、2类应用是面向业务的,3、4类应用提供基础服务,在下面的描述中,将1、2类应用称为上层应用,3、4类应用称为底层应用。 特点 1. 上层应用之间的依赖通常是接口、数据的依赖,上层对底层的依赖通常是服务的依赖; 2. 上层应用由于业务和需求的变化频繁,其开发测试活动具有短频快的特点;底层应用需要为上层应用提供可靠稳定的服务,因此变化小,变动较慢; 3. 上层应用的变动一般只影响自身... 详情

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

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时发现通过,... 详情

把一切监控起来

监控的重要性对于网站的运行来说至关重要,这点无需赘述,但是如何做,方法各异,这里分享下Kelude在监控方面的做法。 一、监控分类 首先要说明的是,我们以下讨论的都是系统运行过程中的监控。并不涉及开发过程。我们对系统运行过程中监控的对象做了以下分类: 用户行为:包括用户访问的URL,用户来源,用户在一个页面上点击的位置,使用的浏览器等等 应用错误、心跳、性能:应用是否存活、应用是否产生了500错误或者说是能捕获到的异常、页面响应时间是否在指定的范围内 机器硬件指标:包括CPU、Load、Mem,Disk 基础软件:主要检测提供服务的基础软件(mysql/nginx/tomcat等)是否正常运行 业务软件:这些软件都是为业务需要而开发的,比如Kelude... 详情

Kelude技术架构演进史

Kelude系统是淘宝自主研发的完整测试工作平台。这里面覆盖了产品管理、项目管理、用例管理、缺陷管理、报表分析、自动化回归体系、安全测试、性能测试、代码覆盖率、数据准备、机器管理等数几十个应用和若干自动化测试框架。有关该平台的介绍可以在淘宝产品中找到一篇11年初的介绍文章。 我有幸全程参与了在Kelude的项目管理和回归体系中的建设工作。这里面就包括刚才提到的产品、项目、用例、缺陷、报表和自动化回归。废话不多说,直接上干货。 当最开始集团内还在用QC(quality center)管理用例和缺陷时,我们就在构思这个系统。代号为Freetest(而非现在的Kelude)。在总结了现有系统的问题,收集了业务方需求,评估了业界流行的测试平台和管理平台后,我们就确立了以R... 详情

Java Web开发之一:用好的技术设计来犒赏自己

(转帖请注明http://taobaotesting.com/blogs/2359) 2012年下半年,我负责的测试平台部分业务开始采用java进行开发,10月份的时候我也加入了具体的设计开发工作中,负责用户模块的建设。对于当时的我来说,从ruby on rails转向 分布式java web一切还得从头开始:语言陌生、web框架陌生、两种框架的理念不同、以及进度压力等。后来,经过自己的不断琢磨 以及 团队的讨论,总算是如期完工了,而且结果还不错:每日构建、单元测试块覆盖率超过95%、联调时间短、遗漏BUG少等。过程中,逐渐积累了一些设计心得和实践,现总结出来分享给大家。 我所使用的技术环境是 分布式Java Web:java 6 + webx 3.0.7(阿里巴巴研发的j... 详情

我们如何做到每日发布—kelude2.0

持续集成、快速交付是每个项目团队所追求的。kelude2.0一直在努力的实践、思考。下面将针对kelude2.0如何进行每日发布这一话题进行分享。 环境管理 环境分类:本地、日常、线上; 环境一致性:本地/日常共用一个DB及静态资源,并每天从线上DB拉取数据,以确保最大程度与线上环境相同; 配置方式:利用AutoConfig工具在进行maven打包时将环境配置文件中的属性注入到程序包(jar/war). 环境配置文件统一放在代码库中的deploy/env目录下: deploy/env/local_win/k2.properties 存放windows本地开发环境的配置文件 deploy/env/local_linux/k2.properties 存... 详情

Hadoop/Hive/元数据库/Hivesql/Datax环境的搭建

入职以来本人一直在做海量数据计算建模应用的相关开发和测试工作,年前有幸全权负责一个应用的开发并将应用成功上线,从底层数据到上层应用通通走了一遍,成长良多。在工作过程中发现多部门协助内耗十分严重,由于本部门的PE同学不懂hadoop相关的环境搭建方法,而BI团队的PE又没有本部门预发线上的部署权限,由于业务和流程不熟悉,加之与多部门审核和工具使用协作等问题,使计算所依赖的运行环境准备问题,耽误了大量的时间,消耗了巨大的精力,也使本人身心饱受摧残!随着大数据应用场景越来越多,相信这种需求会越来越旺盛,不是BI部门的同学使用大数据环境的场景也越来越多,需要自己搭建环境的可能性也会越来越大,所以为了避免其他同学像我一样被蹂躏摧残,现将部署的过程总结分享如下,分享前先阐述文中几个名词含义: ... 详情