paulwong

#

fastweixin v1.2.5 发布,极速微信公众号开发框架

     摘要: fastweixin 发布 1.2.5 版本,版本更新内容: 修复MediaAPI中依赖spring框架工具类BUG; 重构自定义Handle接口,使用更加方便; 修复创建菜单空指针BUG,感谢bs2004提供反馈; 注释完善,便于理解; ...  阅读全文

posted @ 2014-12-04 10:25 paulwong 阅读(1033) | 评论 (0)编辑 收藏

这九大技术将在2015年或未来大行其道

摘要:企业科技正在以不可思议的速度向前发展,本文预测的9大技术或许在2015年甚至以后将会对我们产生深远影响。无论是Docker容器还是机器学习,开源都是未来的一大趋势,也是企业获得竞争优势的首选。 

【编者按】预测未来本来就是一件非常疯狂的事情,而且现在企业科技的发展速度永远超越我们的想象。infoworld主编Eric Knorr为我们预测了在2015年或是未来一段时间内9大技术将大行其道。他认为开源是企业获得竞争优势的首选,作为开发人员应该关注技术热点,并围绕核心技术构建一个类似Docker、Hadoop等的生态系统。 

以下为译文: 

1.公有云将获得成功 

今年,IaaS和PaaS的融合使得在公有云平台上更容易构建、测试和部署应用程序。随着AWS现在提供多重PaaS选项,所有主流的公有云都将提供类似集成方式。 

与此同时,私有云由于成本和复杂的企业部署以及维护整个内部堆栈将会止步不前。云计算创新是企业科技发生重大变革的领域,所以我不得不怀疑任何业务都可以跟上技术变化的速度。除了监管障碍和支付成本,为什么不简单地迁移到公有云呢?毕竟,紧随科技潮流是每个公有云厂商应该做的事。至于企业,则并非如此。当然,迁移需要时间,但像GE这样的公司已经宣布他们全力投入。 

2.疯狂的容器技术 

Docker是目前这个星球上最热门的开源项目,它使你可以打包应用程序,以便将让其运行构建在Linux内核上的容器中。之所以它如此重要是因为这意味着真正的应用程序可移植——使用轻量级包来替代一个完整的虚拟机。此外,Docker公司正在与微软Windows上创建Docker驱动的容器。很多人都在探讨使用Docker从开发到测试以及生产阶段迁移应用程序,但我相信Docker也将被用来在云中迁移生产应用程序。

将一个打包应用程序从一个容器迁移到另一个容器是很容易的,但是涉及多重容器的复杂应用程序将会变得更加困难。Docker管理和编排工具将帮助你装配和迁移复杂的App。Docker顶级项目包括Kubernetes、Mesos 、StackEngine、 Google Cloud Platform 和AWS上个月添加了他们自己的容器管理系统。 

3.微服务架构 

在当代网络和移动App开发时代,开发人员往往从服务构建应用程序,而不是从头开始编写所有程序。通常情况下,这些服务就是微服务——专用API,可获得API的App已经成为更大应用程序的构建模块。Docker通过提供一个便捷的打包和部署方式在一定程度上加快了微服务的发展趋势。 

如果你还记得十年前的SOA趋势,微服务架构可能听起来很熟悉。主要的区别在于微服务架构是从开发者的角度来看服务而不是企业架构师的角度,因此服务是细粒度的。服务之间的沟通也很简单:JSON取代XML,REST代替SOAP,另外重型中间件并不包含在内。 

4.流体计算 

InfoWorld”的主编Galen Gruman创造了“流体计算”的短语来描述ad hoc(点对点)网络在个人设备上的影响,在那里你可以在智能手机、笔记本电脑、平板电脑以及台式机之间迁移时保存状态。例如,如果你正在参加一个会议,并在平板电脑上修改了你的描述,当你回到办公室,你会发现那个描述已经提供在你的台式机前面。第一个推出这个切换特性的是OS X Yosemite和iOS 8,但微软和谷歌正在为他们的设备生态系统打造类似的功能;三星最近也宣布自己的版本。 

5.多重云管理 

云的趋势是更大、更复杂的平台。你构建在之上的平台越多,你就越依赖于其独特的特性,如果是一个公有云,你就会将自己完全锁定在一个由别人控制的平台上。很少有大型企业会把所有的鸡蛋放在同一个篮子里,而这就是多重云管理的价值所在。 

跨多重云部署工具已经出现有一段时间了,当下获得了更多的关注。CliQr,一个由谷歌风险投资公司支持多重云管理初创公司声称能够动态决定哪个云应该运行哪个工作负载。但值得关注的还有RightScale,他们声称能够让你在多重云环境下管理和优化资源以及成本。 

6.端点安全创新 

企业安全仍将处于绝望的状态,只要用户还会继续不小心下载恶意软件。尽管如此,我还是对今年出现的一些新的安全解决方案留下了深刻的印象。首先,Tanium在整个企业将创新搜索技术应用于查询端点。Tanium可以获得近实时查看成千上万的端点来检测异常情况,并且确定哪些软件缺乏最新的补丁——全部显示到仪表板视图上。 

手机上也出现了有趣的解决方案,而不仅仅是指纹阅读。一些蓝牙LE近距离解决方案使你能够用你的智能手机作为安全密钥,或作为其他移动设备的物理标记来用于近距离身份验证。最近,Android 5.0 Lollipop引入“可信任地点”技术,当你在一个区域你感觉是安全的,比如你的家或办公室,这项技术使用定位来消除密码或pincode gates。 

7.机器学习 

这差不多是人工智能的新名称。一方面,重要的是不要对近期机器学习的潜力承诺太多;另一方面,理解大数据是必需的,开源项目Mahout 和Spark / MLlib会带来帮助。正如James Kobielus在今年早些时候注意到的一样,机器学习是如此的普遍,我们甚至经常假设其存在于大数据应用程序中。IBM是这一思想的主要支持者,并且开源了 Watson APIs ,而初创公司例如Andreessen投资的 Adatao今天正在应用强大的计算能力来恢复神经网络算法。 

8.devops的回归 

这种 “开发”和“运维”的融合实际上是通过提高操作效率来实现敏捷开发。devops趋势五年前首次出现,但是供应商让其重新焕发生机。当下,其正在应用程序生命周期管理、自动化测试工具、数据库虚拟化、自动化、配置管理、应用程序性能监控、平台即服务以及相关技术领域以其原有的方式运行。 

在某些圈子里,devops被认为是一种让开发人员持续为生产中的应用程序负责的一种方式,但这并不普遍。对devops最好的理解是对现代高效配置开发和测试环境的速写,这必须延伸概念以满足更多更好应用程序几乎通用的商业需求。 

9.网络交换机的结束 

我们不会看到网络交换机在2015年消失。但虚拟网络设备、软件定义网络和强大的服务器将促使我们重新思考数据中心网络。网络的未来沦为“服务器”之间的连接正在变得愈加真实。 

Cumulus Linux将网络控制平面带到行业标准硬件和当下的服务器编排工具,同时保留线速网络运营。最近InfoBlox 推出的OpenFlow项目LINCX显示了完全软件可编程网络的潜在力量。同时,NFV(网络功能虚拟化)——利用服务器虚拟化和数据中心编排提供负载平衡、防火墙、广域网加速和其他网络功能作为服务——在服务提供商和云平台诸如OpenStack当中非常受欢迎。 

写在最后 

综上,一条主线贯穿这九大趋势就是开源。这已经成为初创公司获得竞争优势的首选,作为客户——主要是公司内部的开发人员——应该紧随新技术并提供反馈,最终把它们投入生产。与此同时,其他开发人员应该能看到哪些技术热点,围绕一个核心项目开始构建一个生态系统,就像Docker、Hadoop、OpenStack等等一样。 

原文链接:9 key enterprise tech trends for 2015 and beyond 

posted @ 2014-12-03 13:46 paulwong 阅读(429) | 评论 (0)编辑 收藏

Samza资源

【samza系列】实时计算框架Samza学习指南-前言

【Samza系列】实时计算Samza中文教程(一)背景

【Samza系列】实时计算Samza中文教程(二)——概念

【Samza系列】实时计算Samza中文教程(三)——架构

【Samza系列】实时计算Samza中文教程(四)—API概述





posted @ 2014-12-02 15:27 paulwong 阅读(290) | 评论 (0)编辑 收藏

最火爆的开源流式系统Storm vs 新星Samza

分布计算系统框架,按照数据集的特点来说,主要分为data-flow和streaming两种。data-flow主要是以数据块为数据源来处理数据,代表有:MR、Spark等,我称作它们为大数据,而streaming主要是处理单位内得到的数据,这种方式,更注重于实时性,主要包括Strom、JStorm和Samza等,我称作它们为快数据。

在这篇文章中,我主要谈论streaming相关的框架。

第一个是Storm,一个实时计算系统,它假定数据源是动态的,可以向流水一样处理数据。

它的特点是:低延迟、高性能、分布式、可扩展和容错性。

架构如下图所示。


 

Storm的具体概念可以参照:http://blog.csdn.net/hljlzc2007/article/details/12976211,这里不做具体介绍。

Storm目前算是最最稳定的开源流式处理框架,但是个人认为它有两个问题。

1. Storm虽然支持多个语言编写spout和bolt端的代码,但是它的主要技术实现是clojure,这给玩大数据、开源的朋友带来了极大的不变,因为大家会的语言不是以java和C++等大众语言为主,这样的话,变得不可控了,难以深入了解、修改其细节。

2. Storm可以支持在Yarn(Hadoop 2.0)上,可以和其他开源框架共享Hadoop集群的资源,但是性能不佳,这个有待Storm改善

当然无论如何,Storm依然是目前开源流式处理框架的王者。

第二个我想说的是JStorm,这个是阿里做的,算是Storm的另一个实现,它用的语言是Java.

特点:

1. 客户端的API与Storm基本上是一致的,如果从Storm迁移过来,不需要修改bolt和spout的代码

2. Jstrom比Strom稳定,速度更快

3. 提供了一些新的特性

大家有兴趣可以去玩玩,项目地址https://github.com/alibaba/jstorm 

第三个是Samza

Samza是由LinkedIn开源的一个技术,它是一个开源的分布式流处理系统,非常类似于Storm。不同的是它运行在Hadoop之上,并且使用了自己开发的Kafka分布式消息处理系统。

这是Linkin开发的一个小而美的项目,如何美呢?

1. 只有几千行代码,完成的功能就可以和Storm媲美,当然目前还有很多的不足

2. 和Kafka结合紧密,更方便的处理数据

3. 运行在Yarn上

之前我做过的一个项目,是Kafka + Storm + ElasticSearch,将来完全可以将Storm替换成Samza,这样的话,还可以利用Hadoop集群的资源,做一些存储、离线分析的功能。将实时处理和离线分析都运行在Hadoop上,不得不说Samza是一个伟大的项目,这样可以减少项目的增长复杂度,利于维护,还是那句话,小而美的东西,更受欢迎一些。

架构:

Samza主要包含三层,

1. 流处理层 --> Kafka

2. 执行层     --> YARN

3. 处理层    --> Samza API

Samza的流处理层和执行层都是可插拔式的,开发人员可以使用其他框架来替代,不局限于上述两种技术。

Samza提供了一个YARN ApplicationMaster,和YARN job,运行在集群之外,下图中不同颜色代表不同的主机。

Samza客户端告诉YARN的Resouce Manager,它想启动一个Samza job, YARN RM 告诉YARN Node manager,分配空间给YARN ApplicationMaster,NM指定完空间后,YARN container会运行Samza Task Runner。


Samza状态管理

流式处理数据对状态的管理是很难的,由于数据是流动的,本身没有状态,这样就需要靠历史数据来记录应用的场合,Samza提供了一个内部的key-value数据库,它是基于LevelDB,运行的JVM之外的,使用它来存储历史数据。这样的做的好处是:

1. 减少JVM的开销

2. 使用内部存储,极大提高的吞吐率

3. 减少并发操作

Samza处理流程.

下图是Samza官方给的一例子,根据Member ID分组,计算页面访问次数。入口消息分别来自Machine1、2,出口是Machine3,我们可以这样理解,消息分散在不同的消息系统中(Kafka),Samza从不同的Kafka中读取topic,在将topic进行处理后,发送到Machine3,这里不做过多分解,具体可以参照官方文档。



项目地址:https://github.com/apache/incubator-samza

官方文件:http://samza.incubator.apache.org/

以上给了我们无限遐想,Storm是否会保持领先地位,Samza能否取而代之呢,无论如何,作为开发者来说,几千行代码,我都迫不及待去要读一下了。

posted @ 2014-12-02 15:03 paulwong 阅读(422) | 评论 (0)编辑 收藏

几个实用的BOOTSTRAP插件

Bootstrap 复选框组件 Bootstrap Checkbox
http://www.oschina.net/p/bootstrap-checkbox


Bootstrap 子菜单插件 Bootstrap Sub-Menu
http://www.oschina.net/p/bootstrap+sub-menu


jQuery 日历插件 Bootstrap Calendar
http://www.oschina.net/p/bootstrap-calendar


vsn4ik
https://github.com/vsn4ik?tab=repositories



posted @ 2014-12-01 21:51 paulwong 阅读(313) | 评论 (0)编辑 收藏

Jspxcms 5.2发布,国内开源的Java CMS

Jspxcms-5.2.0-release今天正式发布。

 

更新列表:

1、增加广告管理的标签

2、描述去除空格。

3、tag增加栏目参数。

4、InfoList标签中加上模型参数。

5、select字段支持key、value。

6、支持可查询字段。

7、文档管理左边栏及列表页显示所属模型。

8、栏目管理左边栏及列表页显示所属模型。

9、修复会员投稿上传获取图片目录问题。

10、修复IE8下视频无法播放。

11、更新新浪采集规则,适用采集改版后的新浪网。

12、后台默认给予欢迎页权限。

13、默认的新浪采集报错(内容没有图片)的内容报错。

14、投稿编辑器改为ueditor。

15、投稿更新时,栏目是否允许投稿判读有误。

16、采集是否提交没有默认值。

17、新闻模型默认增加标题图字段。

18、增加默认专题模型。

19、专题管理上传控件改为swfupload。

20、彻底删除文章后,评论没有删除。

21、会员投稿报错。

22、全局自定义表邮件数据有重复数据及无效数据。

23、文章翻页第二页标题缺失。

 

 

可独立管理的站群:

支持多组织、多站点、独立管理的网站群,各个站点可以有独立的管理员,对本站用户、组织、模型、栏目等信息进行独立管理,互不干扰。

 

无侵入式二次开发:

支持无侵入式插件和二次开发,无需修改系统原有代码,即可无缝整合Entity、Service、Controller、功能菜单、权限、标签、国际化等功能。查看教程

 

高并发:

jspxcms有近乎完美的性能表现,在没有做特殊优化、纯动态页下,支持高并发访问。

对 http://demo.jspxcms.com/ 测试结果简要描述:5000次请求,500次并发,全部成功,总耗时31.124秒,每秒处理160.65个请求,每个请求耗时6.225毫秒。

对 http://demo.jspxcms.com/node/40.jspx 测试结果简要描述:5000次请求,500次并发,全部成功,总耗时11.969秒,每秒处理417.73个请求,每个请求耗时2.394毫秒。

详细测试报告http://bbs.jspxcms.com/thread-35-1-1.html

 

百万级数据支持:

很多cms在小数据量下可以运行的不错,但在日积月累的数据量增加,会让这些cms运行缓慢、不堪重负。

jspxcms在不需要任何特殊处理和优化的情况下,轻松支持百万级数据量,且在纯动态页访问的情况下,一样快速如飞。

 

全站静态化:

可以对所有的栏目页、文档页做静态化处理,在数据量大的情况下,可以设置前n页静态化,后面n页为动态页。

 

下载及演示:

下载地址:http://www.jspxcms.com

演示站:http://demo.jspxcms.com 后台:http://demo.jspxcms.com/cmscp/index.do

 

主要技术:SpringMVC3.2、Spring3.2、JPA2.0、JSP2.0、Freemarker2.3、Spring Data JPA,QueryDSL、Shiro、Lucene等。

 

技术亮点:JPA、Spring Data JPA、QueryDSL组成的无比简洁高效的持久化技术;Shiro安全框架;Lucene近实时检索;Freemarker模板技术;仿Gmail验证码等。

 

功能列表:

1、文档。(新闻、图集、下载、视频、作品、文库、招聘等)

2、栏目。(无限级数栏目管理)

3、文件。(zip上传自解压、zip打包下载、模板、图片、js、css)

4、生成。(全文检索、页面静态化、定时任务、任务管理)

5、模块。(文档属性管理、专题类别管理、专题管理、TAG管理、评论管理、敏感词管理、评分组管理、附件管理)

6、扩展。(友情链接类型管理、友情链接管理、留言板类型管理、留言板管理、广告版位管理、广告管理、投票管理)

7、插件。(简历管理、数据库备份)

8、统计。(流量分析、受访访问、访问日志)

9、用户。(用户管理、角色管理、会员组管理、组织管理、全局用户管理、全局组织管理)

10、系统。(网站设置、系统设置、站点管理、模型管理、文档属性、工作流组、工作流、发布点、操作日志)

 

前台模板:

 

 



 

 

 

后台界面:

 



 

 

posted @ 2014-12-01 21:00 paulwong 阅读(451) | 评论 (0)编辑 收藏

我眼中的开发和测试

摘要:在IT行业,开发和测试之间的关系一直是一个大家津津乐道的话题。那在周兆熊眼中,开发和测试是什么样的?他进行了细致的说明,并就两者的关系给出了一些建议。 
在IT行业,开发和测试之间的关系一直是一个大家津津乐道的话题。在整个软件产品的生命周期中,开发和测试人员所做的工作分别对应不同的阶段,如图1所示。 


图1 开发和测试人员的分工

工作内容 

从图1可以看出,开发和测试是一个上下游的关系。 

具体而言,开发人员主要做这几件事情: 

第一,对软件需求说明书进行详细评审,弄清楚要开发一个什么样的软件。 

第二,编写软件详细设计、单元测试和集成测试规程文档。软件详细设计文档是最重要的文档,在里面,要写清楚自己程序的流程、函数设计、异常保护考虑等。在动手写程序之前,一定要将软件详细设计文档写好,等评审通过了再写代码。 

第三,编写代码,用程序实现软件的功能。很多人认为的软件开发就是写代码,其实这是一种很狭隘的理解,写代码在整个开发流程中,只占了很小的部分。 

第四,程序写好之后,开发人员要对它进行单元测试和集成测试也叫(自测),确保程序的正确性。这里就出现了“测试”二字,但与软件测试所做的“测试”是不同的,他们做的是“系统测试”。等自测通过之后,并且相关文档也写好之后,就可以提交程序版本,供测试人员进行测试了。 

相对开发,测试人员主要做这几件事情: 

第一,参与软件需求说明书的评审,对软件要实现的功能有一个大致的了解。 

第二,搭建测试环境。这个是很重要的,也是比较难的事情。什么是“测试环境”呢?就是说,不管什么软件,都有个运行的条件,如操作系统类型、参数设置及配套软硬件设施等,这些统称为“环境”。为了保证程序功能的正确性,要在软件发布之前,尽量模拟软件实际的运行环境,这就是搭建测试环境时要做的事情。很多软件在正式商用之后出问题,就是测试的时候没有还原现场环境所致。 

第三,对软件进行系统测试并输出测试报告。所谓系统测试,就是指将配套的所有软件都运行起来,看一下所有的功能是否正常。当出现问题的时候,要及时和开发人员联系,以修正软件缺陷。 

第四,指导现场人员安装软件程序,并在必要的时候亲自出差到现场去安装软件。因此,测试人员也可能会经常出差的。 

“三足鼎立” 

开发人员的主要任务是用程序完成软件需求,而测试人员的主要任务则是保证程序功能的正确性,他们做事的依据都是需求开发工程师编写的需求说明书。 

在实际的软件开发项目中,需求开发工程师、软件开发工程师和软件测试工程师之间的交流是很频繁的,如图2所示。 


图2 三类角色的“三足鼎立”

就像“三国时期”的魏蜀吴“三足鼎立”一样,需求开发工程师、软件开发工程师和软件测试工程师所站的立场不同,对软件的认识也不同。大家需要相互讨论、协商,挑选出一套最佳的软件实现方案。 

一些建议 

在完成软件研发的过程中,开发和测试之间的关系非常的“微妙”,时而合作如亲人,时而争论如敌人。我认为,为了做出高质量的软件产品来,开发和测试需要做到: 

第一,共同参与软件需求文档的评审,对程序要实现的功能有一个清晰的认识。如果对需求有疑问,一定要当面提出来。 

第二,在对需求达成共识之后,软件开发人员严格按照软件需求文档上的描述来编写程序,如果在程序实现上有困难,要提出来和大家讨论。软件测试人员严格按照需求的描述来验证程序的功能,如果发现程序实现与需求不符,要及时与软件开发人员联系,大家共同将程序问题解决掉。 

第三,如果开发时间紧张、人手不足,那么在开发人员编写程序的时候,测试人员可以帮忙把测试环境搭建好。等程序编写好之后,开发人员便可以立即进行单元测试和集成测试。 

第四,不管是需求有问题,还是程序有缺陷,大家都可以指出来。但注意要就事论事,不可将软件问题上升为对特定个人的人身攻击。 

第五,虽然是各司其职,也许还身处不同的部门,但大家的共同目标是一致的:做出让客户满意的、高质量的软件产品。开发和测试人员要为了这个目标,一起努力。 

结束语 

一个软件产品的成功需要从各个环节上去把握,因此用人的左手和右手的关系来比喻开发和测试之间的关系更为恰当。好的软件产品需要开发和测两手抓,两手都要硬。 

posted @ 2014-12-01 20:55 paulwong 阅读(312) | 评论 (0)编辑 收藏

聊聊架构

什么是系统架构?

从字面上理解,系统架构是系统的框架结构,是系统进行抽象之后的一个草图。它包含了系统中各个抽象组件的协作方式。


为什么需要架构?

好的架构能够降低系统的创造和维护成本,特别是维护成本。一个系统的创造成本低,而维护的成本大,特别是互联网应用,一般情况下把一个系统搞上线只需要一个月,但是有的系统搞下线缺需要几个月,而维护则需要数年。好的设计师不会在系统上线后对系统进行大的修改,从而减少系统的维护成本。

如果区分创造和维护两个阶段的话,架构师分为系统架构师和维护架构师,架构新的系统的是系统架构师,而维护老系统的则是维护架构师,程序员大多数愿意做新系统不愿意维护老系统,因为感觉没什么技术含量,但是维护老的系统反而更难,因为老系统的重构和改进更加复杂,维护架构师不仅需要读懂老系统架构设计,还要在不影响老系统功能的情况下,进行功能新增和重构。我的一位同事在对一个旧的系统进行重构之前,读了几个星期的代码,然后才开始设计改进方案。

架构设计的目标

设计的目标围绕着降低成本这个需求进行。设计的目标非常多,不同的系统架构目标也不一致,但是我觉得比较重要的架构目标有以下几个,可扩展性,灵活性和可插入性。

可扩展性,新的功能容易加入到系统里,降低创造成本。
灵活性,一处修改不会波及其他的地方,降低维护成本。
可插入性,同样的功能可方便的替换,降低创造和维护成本。
那么如何实现这三个目标

提高可扩展性:把不易变的抽象出来。抽象层要比实现层要更稳定,抽象层的变化要少。把变化的集中起来,比如把容易变化的功能放在单独一个系统或者一个模块里。
灵活性:模块化,每个模块相互独立,减少模块之间的藕合度,修改不会互相传递。
提高可插入性:模块化,服务化。
如何开始架构

当一块新业务放在你面前时,如何进行系统架构?我觉得需要进行以下几个步骤的思考:

业务分析:输出业务架构图,这个系统里有多少个业务模块,从前台用户到底层一共有多少层。
系统划分:根据业务架构图输出系统架构图,需要思考的是这块业务划分成多少个系统,可能一个系统能支持多个业务。基于什么原则将一个系统拆分成多个系统?又基于什么原则将两个系统合并成一个系统?
系统分层:系统是几层架构,基于什么原则将一个系统进行分层,分成多少层?
模块化:系统里有多少个模块,哪些需要模块化?基于什么原则将一类代码变成一个模块。

posted @ 2014-11-28 23:06 paulwong 阅读(339) | 评论 (0)编辑 收藏

单元测试、集成测试和系统测试的不同之处[转]



首先,他们的测试方法不同:

单元测试属于白盒测试;

集成测试属于灰盒测试的范畴;


系统测试属于黑盒测试。





其次,他们的考察范围不同,也就是他们测试的重点不同:

单元测试主要测试单元内部的数据结构、逻辑控制、异常处理等等;

集成测试主要测试模块之间的接口和接口数据传递的关系,以及模块组合后的整体功能;

系统测试主要测试整个系统相对于需求的符合度。




再次,他们的基准不同:

单元测试评估的主要是逻辑覆盖率;

集成测试评估的主要是接口覆盖率;

系统测试评估的是测试用例对需求规格的覆盖率。

posted @ 2014-11-21 09:09 paulwong 阅读(371) | 评论 (0)编辑 收藏

SPRING-SESSION

     摘要: HTTP SESSION的管理通常是由容器来做,但如果是在PAAS环境下,服务器不能做变更,则需要由WEB应用来做处理HTTP SESSION。同样,如果是分布式的环境下,SESSION的管理也会带来性能问题。SPRING推出了处理SESSION的框架:SPRING-SESSION。 SPRING会重写HTTP SESSION的那一套,使用SESSION也同样还是用 Code ...  阅读全文

posted @ 2014-11-19 18:23 paulwong 阅读(6390) | 评论 (1)编辑 收藏

仅列出标题
共115页: First 上一页 42 43 44 45 46 47 48 49 50 下一页 Last