资源预览内容
第1页 / 共177页
第2页 / 共177页
第3页 / 共177页
第4页 / 共177页
第5页 / 共177页
第6页 / 共177页
第7页 / 共177页
第8页 / 共177页
第9页 / 共177页
第10页 / 共177页
亲,该文档总共177页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
上学吧(www.shangxueba.com)从大禹治水看构件与集成大禹治水 在远古的尧、舜时代,黄河流域经常发生了大水灾,洪水横流,五谷不收,家破人亡。所以尧派鲧去治水,鲧沿用了过去的传统法子,水来土挡,用土筑堤,堵塞漏洞。但由于洪水凶猛,不断冲击土墙,结果弄得堤毁墙塌,洪水反而闹得更凶了。鲧治水九年,劳民伤财,并没有把洪水制服,是一事无成。 舜接替尧后,就把鲧办罪处死,随后命鲧的儿子禹继续治水。大禹领命之后,寻找到了以前治水失败的教训,最后决定用疏导的办法来治理水患。大禹带领百姓是凿了一座又一座大山,开了一条又一条河渠,把黄河的主流加深加宽,把支流疏通与主流相接。同时,把原来的高处培修得更高,把原来的低地疏濬得更深,便自然形成了陆地和湖泽。把这些大小湖泽与大小支流连结起来,洪水就能畅通无阻地流向大海了。 相传大禹三过家门而不入,把整个身心都用在开山挖河的事业中。大禹用疏导的办法治水终于获得了成功。大禹治水,为民造福,永受华夏子孙所称颂,永为炎黄后裔所怀念。 集成与构件 “集成”是看到了信息化建设中的一个个信息孤岛,数据不能交换,资源不能共享,业务不能协同,如同洪水泛滥一样。传统的应用集成EAI是典型的“堵”法,可以说总是在事后解决问题,是头痛医头、脚痛医脚,治标不治本的办法。碰到了集成问题,才去想办法去解决,而解决眼前问题的同时又带来更多和更复杂的其它集成问题。所以,就如同鲧治水一样,鲧没有把洪水制服,EAI当然也不可能从根本上解决信息资源共享利用的问题。 因此解决信息孤岛,要学大禹治水,“疏”比“堵”更重要。“堵”是一时的、眼前的,“疏”是长远的,一劳永逸的。与集成的事到临头相比,构件就是“疏”的方法,是从源头上去堵。在构件体系下,信息资源将按标准、有层次的通过构件展开,数据是构件、展现是构件、流程是构件、服务是构件,一切皆构件。好比大禹治水,开山凿渠是构件库,主流支流是大小构件,贯通无阻是统一标准。 所以,构件可以实现信息资源的大“治”,用计算机术语来讲,就是“同构”,标准统一,架构统一,建设统一,管理统一,开发、部署、运行与维护实现同构,信息孤岛从设计源头上被消灭。 从测试角度看用户手册在软件质量中的地位 对于软件,开发者往往只注意到其功能和性能,而忽略了用户手册。其实用户手册也是衡量软件好坏的一个重要标准。好的用户手册可以帮助用户快速入门,是用户正确、充分使用软件的前提。对于开发者来说,好的用户手册可以减少培训和售后服务的费用。所以在测试中,不能忽略用户手册的重要性,应从以下多个方面考察用户手册的质量。 用户手册的完整性重点考察用户手册内容的全面性与完整性,从总体上把握用户手册的质量。这一项看似简单,但在实际测试中我们发现,很多开发商还是无法做到这一基本标准。很多软件由于开发过于仓卒,在付诸使用时,用户手册中缺少关于某些模块的说明,让用户使用起来比较困难。在测试工程师的眼里,优秀的用户手册内容应该是包括软件的所有功能模块。 用户手册的描述与软件实际功能的一致性考察用户手册与软件实际功能的一致程度。当确认用户手册基本完整后,我们还要注意用户手册与实际功能描述是否一致。这种问题往往是由用户手册跟不上软件版本的更新速度造成的。对用户来说,容易造成对描述不一致的功能的误解和苫螅?进而影响用户对软件的使用。优秀的用户手册应该根据软件的升级而及时更新,手册描述应该与软件实际功能保持一致。 用户手册的易理解性考察用户手册对关键、重要的操作有无图文说明,文字、图表,是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的,应该附以图表使说明更为直观、明了。优秀的用户手册应该是图文并举,易于理解。 用户手册提供学习操作的实例考察对主要功能和关键操作提供的应用实例是否丰富,提供的实例描述是否详细。当前大量软件的用户手册只有简单的图文说明,而无应用实例。这样的用户手册看起来就像是软件界面的简单拷贝,对于用户来说,实际上没有什么帮助。例如财务软件,用户手册就应该提供具体建帐实例及具体帐务处理的实例,这样才能使用户看完用户手册后,能够独立完成新帐套的建立并逐渐学会使用软件处理帐务信息。优秀的用户手册不仅要对主要功能和关键操作提供应用实例,而且对实例的描述应做到详细、充分,易于用户理解。 用户手册的印刷与包装质量考察用户手册包装的商品化程度,印刷质量。有些用户手册是简单打印、装订而成,过于粗糙,不易于用户保存。优秀的用户手册应提供商品化包装,并且印刷精美。软件的质量是由各个方面构成的,用户手册就是其中重要的一环。特别是在当前软件业快速增长的时期,软件开发者过于注重功能与性能而忽略用户手册,使得用户手册的质量问题尤显突出。所以对于测试人员应该充分认识到用户手册的重要性,严把用户手册的质量关,以促使软件整体质量有一个提高。 从菜鸟到大师细看程序员的五种层次软件界一个无可争议的事实是,不同程序员的效率有差别,而且差别很大。许多专家将优秀程序员和一般程序员区分地很清楚。大多数研究得出结论认为,一般程序员跟优秀程序员之间在工作效率和质量上存在10:1的关系:优秀程序员和水平较差的程序员的编码时间比例为1:20;debugging时间比为1:25;代码数量比是5:1;程序执行速度比例是10:1。而且发现,程序员的代码质量和效率跟工作经验没有关系。让我们看看一些软件大腕们是如何看待优秀程序员和一般程序员的:Randall E. Stross:无论是从软件标准、创造性、开发速度、还是设计思路或者解决问题的能力上来说,优秀程序员比差的程序员都何止好一点。Bill Gates:一个优秀的机床工值一个一般机床工的好几倍,而一个优秀程序员值一个一般程序员的10000倍。Robert C. Martin:90%的代码是由10%的程序员写出来的。程序员因此被分为五大类:1. 大师级程序员(Visionary/Artist Programmer/)大师级程序员是软件界绝对的稀有种族,他们可以创造出99.9%的程序员所创造不出来的东西。他们发明新的应用和软件模式来驱动软件产业的发展。Napster, Netscape以及World Wide Web都是大师级程序员创造的。对他们而言,软件更多的是艺术而非科学。在这个级别,速度和质量不是最重要的,他们创造出的财富才是最重要的。许多开发团队或者公司顶多也就一个大师级程序员,通常是这个公司的技术创始人或者CTO。2. 开拓者程序员(Trailblazer Programmer)开拓者程序员通常带来很好的主意和趋势。他们通常是最终产品的原型创作者,他们一天做出的事情大部分程序员需要几周甚至几个月。开拓者程序员总是在尝试新工具、新技术,不断地学习和搜寻方法来提高工作效率,并通常是其他程序员的导师和老师,而且你经常会发现当其他程序员早已离开的时候他们却依然工作到深夜。尽管这样级别的程序员工资很高,但是每个成功的公司或团队还是应该配备一两个开拓者程序员。3.骨干程序员( Workhorse Programmer)骨干程序员是一个公司或者开发团队的脊柱,这些人尽管不是很有创新性,但往往比较高效且值得信赖。给一位骨干程序员一套模板和合适的工具,他们总能以最短的时间交出错误最少的代码。4.机械程序员( Drone Programmer)许多程序员就是朝九晚五地为了填塞下自己钱包的机械程序员。他们不愿意接触新技术、避免学习新事物。许多公司或者开发团队都有许多这样的机械程序员,因为他们很便宜,但岂不知更贵的程序员才真正地更便宜。5.白痴程序员( Idiot Programmer)林子大了什么鸟都有,软件领域也不例外。编程需要抽象和逻辑思维,然而一些尚不具备此能力者由于向往着不错的薪水而加入了该领域。白痴程序员总是对最简单的算法也搞不清楚,他们总是错过软件截止日期,终日无所获。白痴程序员最好的出路就是换行。 从三十六计看软件测试之计1三十六计是根据我国古代卓越的军事思想和丰富的斗争经验总结而成的兵书,古人用兵最讲究谋略,在中国古代战争史上,精彩的谋略计策层出不穷,令人眼花缭乱,但万变不离其宗,大抵都逃不过这三十六计的范围。时至今日,“三十六计”在我们日常的工作和生活中,同样可以有很广泛的应用。我是一名软件测试工程师,并热爱软件测试这一职业,目前从事测试已有一段时间,我很愿意将自已在从事软件测试工作中积累的一些经验,以及一些心得体会,借助三十六计中的若干计谋加以说明,与诸位同行分享。总说【原文】 六六三十六,数中有术,术中有数。阴阳燮理,机在其中。机不可设,设则不中。 【解析】“兵以诈立”,多谋者胜。用兵要讲究谋略,“运筹帷幄,决胜千里之外”。同样的道理,无论从事什么样的工作,都需要讲究方式、方法。有了正确的方式方法,或者适时的运用一些小技巧,往往可以收到事半功倍的奇效。第一计瞒天过海【原文】 备周则意怠;常见则不疑。阴在阳之内,不在阳之对。太阳,太阴。 【译文】 防备周全时,更容易麻痹大意;习以为常的事,也常会失去警戒。秘密潜藏在公开的事物里,并非存在于公开暴露的事物之外。公开暴露的事物发展到极端,就形成了最隐秘的潜藏状态。 【解析】long,long ago,there is a 很厉害的程序员,名叫关羽,他是计算机专业科班出身,又拥有二十几年的编程开发经验,是当之无愧的资深软件工程师。虽然关羽的专业水平无庸置疑,但是他有一个缺点,就是自视过高,骄傲不可一世,他常常认为自己写的代码十分完美,几乎已经到了自恋的程度。他看不起测试人员,对他们提出的程序错误不仅不屑修改,甚至于不肯承认,并经常与测试人员起争执。有一年他在湖北荆州负责一个十分重要的大型系统的开发,而负责这个系统测试工作的正是关羽向来都瞧不起的吕蒙。这个吕蒙原本学历不高,只有中专文化程度,并且还不大注重学习,提高自己的能力。直到有一次被他的上司孙权教育了一顿,从此发奋图强,进步神速,技术能力迅速提高,早已不是当日的吴下阿蒙。起先吕蒙将发现的错误上报给关羽,关羽并不理会,还
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号