总是很难忘记生活的点点滴滴, 脑海中总是闪过好多的曾经, 美好的回忆, 但成长中却让我们失去了很多, 很想在忙碌的生活中淡淡忘记; 不曾放低的东西却始终让我忘记不了, 但我还要在忙碌的生活中继续生活!

发布新日志

  • IT职场里的某些人感悟(转)

    2008-08-18 17:36:57

    IT职场里的某些人感悟(转)
    1.一个企业,80%的价值是由20%的人创造的,其他80%的人只创造了20%的价值,而他们最大的作用就是刺激这20%的人创造出 80%的价值,而能获得企业肯定和好处,也仅仅是这20%的人,所以,想要站的稳,爬的高,就只有成为这20%中的一员,这是千古不变的真理,所谓的团队,说粗俗点就是拉帮结派,兄弟,现实一点,人的社会就是这样,看看历史如此,现在如此,将来还是如此,不管职场,管场,都是如此,呵呵,一点浅见。
    2.过人的头脑比技术更重要!有了技术你可以独当一面,可是懂了权术,你就可以独挡八面了!钱花花的来了,多看看书,厚黑学,鬼谷子之类的,保证有好处,揣测别人的心理啊!
    3.人本来就是复杂的,世界上没有绝对的好人,也没有绝对的坏蛋,好与坏只是一念之差。人人都可以做好人,有时候,人人也都可以成为坏蛋,这个世界上,没有永远的敌人,也没有永久的朋友,只有永恒不变的利益。但是你不能欺骗自己的兄弟!
    4.等咸鱼翻身的时候,也就是这锅汤煮熟的时候了!做好人有什么用?人善被人欺,马善被人骑,他妈的,一代天子一朝臣,这是自古不变的道理。谁不想将重权交给忠于自己的人来掌握!
    5.智,谋天下。勇,争天下。这个世界上,没有什么东西是得不到的,只有抓不住而从掌心中悄然流走的。做人要讲究城府,在你未成为三军统帅之前,不要暴露自己,等你成为将军了,大刀阔斧的给杀!但是要记住:先纳新,后吐故!如果先吐故,势必完蛋!康熙用此法一统朝政!
    6.不管他是谁,不管他的为人如何,只要对我们有利,就应该想办法让他为我们做事!不是不报时候未到!
    7.自己要懂技术,还要学会驾驭权术。
    8.鄙人最近看了小说《无以言退》,里面经典话很多,对你这种情况,可以录几句:“走很容易,留下来才是修行”,“不要说别人卑鄙狡诈,只能说自己无知愚蠢” ,“可以忍受物质的匮乏,但要学会在新时代下竞争的残酷。”
    9. 我说的这个高管,我来这个公司,就是他把我从另一家当地比较有规模的企业里生生的挖过去的,因为他知道我们这里另一家通过了cmmi L3级的企业就是我负责EPG里非常重要的工作,而且是已经获得SEI认证的cmmi定级评估员,所以他死活要把我挖过去,我过去后,由于cmmi当时是这个公司里的一项很重要的工作,所以我的工作是直接像他汇报。同时,我过来也不是什么很基层的员工,是质量管理部经理,所以对他汇报也符合汇报机制,不存在越级,所以他对我的工作是很了解的,不过由于这个公司里的软件部门从技术到工程管理简直垃圾的不是一般,一个项目经理基本没有听说过什么WBS是什么,连V模型都不知道是怎么回事。给他们一个瀑布模型的计划日程,他们都看不出来是什么生命周期,像什么配置管理,集成构建,需求管理,需求开发,分析设计,测试,等等等等,更是做得一踏糊涂。我来之后名称是一个部门经理,但是下大力气作了大量的一线工作,很多事情是一手一手教,就连个接口记录和管理这样的事情,我要给技术人员手把手的教,如何规划设计,如何识别接口(这里不是说的Java等语言里的接口类型定义),如何记录和管理,以及发展对接口的设计等等。不然他们在需求里说,“XX系统和XX子系统需要接口”,在概要设计里还是这句话,到了详细设计里,还是这样一句话。这种事情多得数不胜数。在项目管理方面就更不要说了,教项目经理写项目计划和做日程安排的时候,简直是我说一句,他们就往计划里写一句,同时我还要解释为什么这么写,日程的安排如何去符合生命周期,任务的分配和进度控制如何管理,配置管理如何设计符合生命周期的配置结构,等等等等,还有测试,我兼任测试部门负责人,对测试人员作了的培训,手把手的教他们如何设计测试用例。 所以,我的所有工作他是看得到的,企业由于我的存在发生的变化也是有目共睹的。但是,我过来大概半年后,这个高管就调任其他部门做管理了,新来的软件部经理来了之后,倒是对我的没有怎么着,因为当时cmmi还处于非常紧张的工作阶段,他当时不能动我,但在这期间,软件部有4个下属部门经理,他赶走了另外2个,到了 cmmi通过了,我就是成了第三个,他容不下不属于自己人的有能力的人。你说得不错,这就是政治斗争,一朝天子一朝臣,但是拿我们这些做实事有没有什么野心的人来做他政治斗争的牺牲品,我觉得很郁闷,觉得这个圈子里很肮脏。
    10.公司越大越不会要高手。你看看世界500强,有哪个高手进去了?世界500强的技术,大部分都是吞并小公司得来的。公司越大人事关系越复杂。你要知道你不是直接跟老板打交道的,你的表现在中层向上层回报的时候就全变样了。但大公司的收入高。所以,如果给人打工,最好不要露出你的本事太强。特别是在大公司。当然小公司露本事了,不会有好处,收入不会高了。但太大的坏处也没有。
    11. 有时候,程序员应该心胸开阔点,不要觉得有人比自己技术强,就觉得不舒服,不服气。没有这一点很难站在领导岗位上,换个角度想想,不是这个社会怎么着了,而往往是自己的心胸变的狭窄了,你无法左右这个社会,但是你可以左右你自己。勇于认可别人是一种美德,也是受到别人尊重的基础!
    12.人在屋檐下,不得不低头,要学会夹起尾巴做人。 必要的时候,反咬一口才是真的。伯乐不是那么好当的,如果你威胁到了他的利益,你说他会让你好过吗?开国皇帝杀重臣的是普遍现象,反倒是稀里糊涂的人能长寿。
    13.看《明朝那些事儿》感觉到,真正有发展的都是既能干又能混的。
    14.管理需要跟人打好关系,上头〉下级〉平级。如果你不想升迁,想做个普通的技术人员,你得私下跟你的新上司说,丑话就是表忠心。男人三件事:入对行,跟对人,做对事。好好琢磨吧。
    15. 对于CMM,我觉得对实际工作没什么用。我在2003年的时候,在某个世界顶级的通讯设备生产商的某个部门里参加了该部门的CMM流程制定工作,在一帮老印下面工作了一段时间。后来因为该部门持续亏损,公司决定退出这个领域,把整个部门给卖了,所以我跳槽到另外一家公司,属于该领域的上游厂商,接触了很多这个领域里小的公司,看到其中有些公司从10几个人开始发展,最后2000人,6000人,分拆,上市,茁壮成长。而以前那个部门被出售以后,还在不停的亏损。我觉得CMM那些鬼东西是其中的一个原因。这些流程极大的拉长了开发周期。在你做了需求分析,概要分析,详细设计,单元测试计划,集成测试计划,开了无数的review meeting,总结出了一堆的matrix,虽然你投入的人力是别人的两三倍,虽然你还迭代开发,来缩短周期,但是你的产品周期还是别人的四五倍。这不是夸张,的确是四到五倍。CMM只适合那些几乎完全垄断,没有竞争压力下生存的企业。印度人CMM搞得很好,但是他们还是只能做做代工,而且我接触过的印度人的代码,质量极其低下,完全没有保障。我现在在另一家公司,它倒是很庞大,在这个领域很垄断,但是没有CMM,甚至连像样的 schedule都没有,给一个大致的项目日程,几个重要的milestone,工程师自己的schedule,自己看着办,开始的时候让我很瞠目。
    16.cmm/cmmi 只是一套模型,就像其他的很多行业,如:银行业、建筑业、汽车工业、或者航空业,需要一套衡量其技术和管理水平的标尺一样,它只是一把衡量软件业管理和技术水平的标尺,当然,为了使决定采用cmm/cmmi的企业更好的实施cmm/cmmi所提出的目标,SEI将软件研发生产领域的诸多方面作了逐级的解释和有机的结合,形成了从cmm到cmmi的不断演化完善的各种版本,提出研发cmm/cmmi需求的人和研发cmm/cmmi的人,他们无非是希望软件 -----这个相对较新的技术产业,也能够逐步的成熟起来,能够适应软件应用相关行业对软件日益提高的各种要求。
        cmm/cmmi是在经历了软件危机之后,在大量的业内企业和专家在为了克服软件危机而做了大量的理论研究和实践之后,系统的总结的一种软件的方法论,不同的地域,不同的企业,不同的商业目标,不同的技术类型,不同的应用要求,这导致cmm/cmmi不可能非常具体的为我们提供某种直接的方法,因为它面向全世界所有的软件企业和他们研发的所有项目,所以,cmm/cmmi是一个高度抽象的模型,它所提出的目标和实践要求,也是在非常高度的抽象上的,换句话说,它为我们指出了目标,给我们说了要做什么,但是,怎么做,这就是企业自身去实例话这写目标和实践的东西了。我的意思就是说,在同一个cmm/cmmi目标下,不同的企业,有的成功,有的失败,这完全是自己的做法不同,这很正常,如果失败了就在cmm/cmmi上找原因,那么你看看人家成功的呢?是不是人家的成功和cmm /cmmi一点关系没有??所以,要客观公正的看待cmm/cmmi。 这里我要再谈谈软件危机,什么是软件危机?如果项目预算准确,产品质量可靠,成本控制到位,客户笑容满面,一派和谐祥和的大家发财的局面,这叫软件危机???而很多人提到软件业的困难的时候就会说,这是我们中国的国情,我们这里项目紧,周期短,开发人员技术不怎么样,还经常无能控制得住成本,客户的需求变更很多很无理。言下之意,就我们中国是这样,在国外一切都不是这样,国外的软件开发人员日子都很好过,诚然,现在放眼世界,发达国家的软件行业各方各面都要优于我们目前的状况,但是这是人家与生俱来的吗??难道“软件危机”一词的出现不是在60年代的西方,而是在今天的中国吗???4-5十千,人家同样经历着我们现在经历的一切,这,就是软件危机。如果说现在还有人cmm/cmmi 只适合那些市场环境良好,企业素质优秀的地方玩,那就是大错特错了,cmm/cmmi就是为了解决60年代后的软件危机而诞生的,换句话说,就是用在我们现在这样的行业环境下的东西,当然,实践有成功,有失败,经验和教训并存,如果没有失败的实践者去当炮灰,也就换不来后来人吸取教训必然无谓的失败,唯有这样,我们的行业环境也才能像欧美发达国家的IT业一样,经历阵痛,涅磐重生。
    17.做技术的人,能努力干活了,好技术留着以后自己创业的时候再用。要多用心思在跟人斗上。因为你要知道你是在打工,不是在给自己干。特别在500强的大公司更是如此。有人捣鬼,你就要捣更大的鬼。特别是大公司,每个人都有自己的算盘。他们都不是从公司利益出发的。这些话都是肺腑之言,你要好好体会。别人不会告诉你这些,只有你载跟斗了才能体会到。
    18.根据个人经历观察,高层才会重视CMMI,下面一线研发人员包括PM都比较抵触,特别是任务紧时最怕弄些繁文缛节。可能根本原因还是QA部门与项目规划没沟通好吧,让coder们又要马儿跑又要马儿不吃草。
    19.这个世界从来就没有公平过。我原来也以为只要把事情做好就可以了。可现实环境中,总会存在很多因素阻止你把事情做好!这个时候,就不光是修炼自己的内功了,还要学习很多的策略,和别人相处的方式。只有这样才能把事情做好。也就是外圆内方,但自己内心需要坚持的东西还要坚持。在任何时候都要保持虚心,多做事,少说话,特别是抱怨是没有用的,反而让你自己迷失了自己。将每一次挫折都看作一种成长!相信你总会实现自己的理想!
    20. 关于CMM,有一点很想说的。 本人曾经亲身参与过一个500人规模的软件公司CMM4级的评估,自己的项目也作为参评项目并且得到认可,不过我个人对于CMM并不看好,原因如下: 1,CMM的来源其实是美国军方,为了能够对军方超大规模的项目研发进行控制以及评估,而设计的一个模型,由卡耐基梅隆的软件工程研究所完成。这个模型的初衷就是要不计成本的完善软件质量,因为军方的很多软件项目(比如航天飞机的控制软件)不允许出现错误的。至于说CMM模型是否能够应用到民用项目中来,还有待探讨,最关键是CMM产生的成本很高,不仅仅是时间的问题,还有培训、实施等一系列的问题。我个人的观点除了大规模量产的产品(比如手机)中应用CMM会比较适合,其他类型的项目应用这个模型会得不偿失,毕竟软件项目做到最后还是利润摆在第一位的。 2,至于说能力太强,我觉得每个人的能力就像是那个“木桶原理”一样,由最短的那根木头决定,这么多人不认可你肯定有你自己的原因在里面,不要总是看到别人的不是。“让别人认可你”也是一种很重要的能力,如果你真的能力那么强,雇用你能够给公司带来大笔的收入,哪个老板会不愿意给你付薪水呢?而且要是真那么有本事,找投资商自己开公司也不是什么很难的事情。
    21.狼生活再战场,狗生活在职场。能力最强,也要低调。
    22.事业靠利用人力,不是靠朋友。人和人就是互相利用,在一个单位里同行就没什么朋友,都等看你笑话呐! 生存靠手段而不是技术,他过河拆桥,你不会釜底抽薪么?显然企业的领导目光也有点短浅。 如果不知道该干什么就开培训机构,弄不好你的学生会替你出口气~~
    23. 其实,中国就是这么一个社会,经历了那么长久的封建社会,权术这个东西还是在后代人的脑袋里扎了根.只要一遇到似乎可以威胁到自己地位的东西,就会用尽一切办法来把这些东西排除。 其实,我并不是说我们的祖国不是一个好的国家,只是我觉得现状是这个样子的,中国人只有到了山穷水尽的地步才会懂得团结,只有被别的国家侵略的无路可退才会奋起反抗.说的好是我们中国人大度不和别人挣,说的不好,就是没有血性!  我个人觉得,中国的IT事业处于一个急速发展的阶段,就像一个土富豪,拥有巨大的财富,却不知道自己该做些什么.现在中国的IT企业几乎上都是引进别人的先进技术,而大多IT人才都觉得IT这个行业很挣钱才会来投身IT事业,但是有几个人想过,要想自己赚钱安安稳稳只有等中国的IT行业成熟了,才会有可能吗?总觉得现在人,只顾自己赚钱,忽略了太多东西了.一个人的生活过的好不好,并不代表一个国家。 以前总觉得网络游戏很好玩,很新颖.但到现在人长大了,才发现自己所玩的游戏竟然没有一个是自己国家出的.都是韩国,美国的.现在看着中国人玩的不是自己国家出品的游戏, 总觉得很心酸.。现在的企业,为的不就是赚钱吗?谁不想赚钱,是人都想赚钱,都想让自己的生活过的很好,但是有时候自己的行为有可能会影响到别人的利益. 只要有利益冲突,就会有斗争,"忍"这是一个很好的办法,想要赚钱,并不是有很强的职业技术就可以的,左右逢源很重要,也不是要你缩着头,性格是这样,也不要去强制的改变什么,那样不是失了工作又是了真诚了吗? 我觉得做人要厚道是对的,但是遇什么人做什么事.看清楚自己在的什么位置上,做好本分的事情, 不要强出头... 如果你想生活的好,就请收敛你一身的光芒做人,如果你想做一个真实,对的起自己的人,就请你按自己的性格,思想去做所有的事情..
  • 软件测试之软件的安全可靠性(转)

    2008-08-15 17:43:40

    软件测试之软件的安全可靠性(转)

    软件的安全可靠性是衡量软件好坏的一个重要标准。安全性指与防止对程序及数据的非授权的故意或意外访问的能力有关的软件属性;可靠性指与在规定的一段时间和条件下,软件能维持其性能水平能力有关的一组属性。具体我们可以从以下几个方面来判断:

      用户权限限制 软件是否按功能模块划分用户权限,权限划分是否合理,考察超级用户对各个用户的权限管理是否合理,包括修改用户的登录资料等。

      用户名和密码封闭性 软件对用户名和密码有无校验,有无保护措施,尤其对密码有无屏蔽功能。

      系统对用户错误登录的次数限制 软件对用户错误登录有无次数限制,一般做法是连续三次登录失败就退出系统。

      留痕功能 软件是否提供操作日志,比如某用户登录的时间,查询、修改或删除的动作以及离开的时间等。

      屏蔽用户操作错误 考察对用户常见的误操作的提示和屏蔽情况,例如可否有效避免日期的录入错误或写入无效的日期

      错误提示的准确性 当用户操作错误或软件发生错误时,能否有准确清晰的提示,使用户知道造成错误的原因。例如,当用户未输入完有效信息时存盘,系统应当给出关于未输入项的提示。

      错误是否导致系统异常退出 考察软件运行的稳定性,当软件发生一般错误或严重错误时,软件是否会自动退出。

      数据备份与恢复手段 主要针对有数据存储需要的软件,有的软件依靠数据库操作系统本身的备份与恢复机制,这需要用户具备一定的操作知识;好的软件会提供备份与恢复的操作,不需要用户直接对数据库系统进行操作。

      输入数据有效性检查 当用户输入的数据有错时,软件应能判断数据的有效性,避免无效数据的生成。

      异常情况的影响 在程序运行过程中进行掉电等试验,考查数据和系统的受影响程度;若受损,是否提供补救工具,补救的情况如何。

      网络故障对系统的影响 当网络中断连接时,是否会造成数据的丢失。

      以上一些方面是中国软件评测中心在大量的软件测试实践中提炼出来的比较有共性的项目,对于不同类型的软件,在安全可靠性方面还有更多的评测指标,并且依据实际情况侧重点有所不同。
  • 在IT行业中,你应该知道的10个小秘密

    2008-08-15 17:35:16

    (IT)这个行当里你应该知道的10个小秘密
    如果你正准备投身到IT这行,或者你还是个IT新手,下面列出的很多”小秘密”也许会让你惊讶不已,因为我们通常不会大声的讨论它们。 如果你是个IT老手,这些所说的估计你大部分都遇到过,而且很有可能还有自己的心得 —当然,非常欢迎你花几秒钟的时间把你的所知道的其它小秘密添加到本文的讨论中。 大部分的这些秘密是针对网管,IT经理,以及桌面支持人员的。它们不是针对开发人员和编程人员 —这些人有他们自己的一套小秘密 — 但我说的这些其实也可以放到他们身上。

    10.) 做IT的相对于其它行业薪水较高,但正是因为待遇好,公司就会认为可以把你当奴隶般的使用

    尽管不像2001-2002年间的点com风暴和IT大潮里那么夸张,现在的做IT的人仍然要比其它很多行业的人挣的多(至少那些只需要大专或本科学历的职位里是这样的)。 各种证据显示在未来的十年里社会对IT人才仍然会保持大量的需求,因为科技在企业和社会里扮演的角色越来越重要。然而,正因为IT职业人员是如此的昂贵,很多公司对待IT员工就像是对待包身工。如果因为某些人会工作的很晚导致你晚上9点你还要必须回答技术支持问题,你会听到老板说,”这就是你的工作。“ 如果你在周末还需要加班6小时去部署一个软件更新包,以确保工作时间不宕机,你会得到,”因为既然你是带薪休假,就不会再有补休时间。这就是我们花大价钱雇你的原因!“

    9.) 用户出的荒唐可笑的错误的责任在你身上

    有些用户在工作时受到挫折后会愤怒的向你咆哮。他们会大叫,“怎么又出问题了?”或者“这个电脑又不工作了!”或者(我个人常遇到),“你对我的计算机究竟做了什么?”可实际原因是他们不小心把IE浏览器的图标从桌面上删除了,或者脚不小心把鼠标的插头从机器上踢掉了,或者把咖啡撒在了键盘上。

    8.) 每天你都会从替罪羊变成英雄,而后又变成替罪羊,而后又变成英雄的反复好几次

    当你奇迹般的修复了一个问题,而这个问题已经让好几个员工被迫停工10分钟了 — 他们不知道修复这个问题是如此的简单 — 此时你就成了英雄,成了的大家最喜爱的员工。 但是一个小时后,由于网络堵塞不能打印时,他们会轻易的忘掉你的英雄事迹 — 此时你将会成为大家的头号敌人。 但是当这一天快要结束时,如果你告诉用户一些使用微软Outlook的小窍门,那么你的英雄的身份又回来了。

    7.) 证书并不总能使人成为一个更好的技术专家,但却能帮助人找到一份更好的工作或者更高的薪酬

    猎头公司和人资部门喜欢IT证书。 通过证书他们很容易能给空缺的职位找到相匹配的候选人。 同样,HR也可以简单的通过证书来排除一些候选人。你也许听到了很多IT老手诉苦,抱怨那些凭证证书进入公司却没有工作能力的人。 他们说的基本上是对的。 这种现象很多地方都有。但实际上证书能够打开你职业生涯的大门。 它体现了你对自己的人生有计划,有抱负,有求知受教育和扩展自己的技能的愿望。如果你是一个有经验的IT从业人员,而且有各种证书来证明你的阅历,那么你会发现自己职场非常的受欢迎。技术证书只是用来证明你基本技能很简单的方式,它可以给你做职业上的宣传。 然而,大部分的证书并不能用来证明你可以如此的胜任你的工作。

    6.) 你的非技术专业的同事会把你当作他们的家庭电脑的私人技术支持顾问

    你的同事(也包括你的朋友,家人和邻居)会把你当作他们的个人技术顾问,让你解决他们的家用电脑和家庭网络上的问题。他们会给你发邮件,打电话,或者路过你的办公室时侯问你如何对付他们的家用电脑里的病毒,如何搞定上次停电后就不工作了的无线路由器,以及如何把照片和视频传到网上让远在衣阿华州的爷爷能看到。 有些人甚至会提出把电脑搬到你的办公室让你来修。客气的人会提出给你报酬,但很多人只是希望你给他们提供义务性的帮助。帮助这些家伙们可能会有很多好处,但你必须要小心什么事情能帮,什么事情应该拒绝。 看一看TechRepublic的 “Ten ways to decline a request for free tech support.”会对你有些帮助。

    5.) 当事情干的漂亮时,供应商和顾问们会把所有的赞扬都拿走,而当事情搞砸时,你成了罪人

    跟IT顾问打交道是我们工作中非常重要的一部分,也是一项非常有挑战性的事情。顾问会提供合适的专家支持帮助你部署很专业的系统,当所有的事情正确运行时,你和顾问们的关系就是良好的合作伙伴。 但你要小心了。当事情出了问题时,有些顾问会试图把责任都推给你,责备你,说他们的方案在其他案例里都工作的很好,一定是你本地的IT架构有问题。相反,当项目非常成功时,就会站出来一些顾问身份的人把所有的荣誉都拿走,却无视你为定制和实现这个方案所做的实实在在的工作。

    4.) 你需要花上大量的时间去维护老的技术架构,而事实上做个新的会更省事

    在IT这个行当中,一提到“我们将会采用最新最前沿的技术”,无疑会成为对大家最有吸引力的事情之一。然而,在大部分的IT工作中通常却不是这样。 实际情况是IT工作者典型的任务是花更多的时间去维护,料理,照看已经建成的系统,而不是实现新系统。甚至那些一直研究最前沿最强大的技术方案的IT顾问们也仍然倾向于主要使用已建成的已证实技术解决方案。

    3.) IT老员工经常会成为使用新技术的反对者

    有很多公司实际上应该采用更多更前沿的技术。 如果升级或者替换掉他们的软件或基础架构可以省下大量的时间和金钱,而且提高生产率和利润。然而,通常却是这样的一种情况,迁移到新的技术上的阻力不是预算上的限制,也不是管理层的反对,而是IT部门的资深老员工。一旦系统建立起来,能跑能用,他们就拒绝去改变它。这可以认为是真确的,因为他们的任务就是让那些基础架构稳定运行,但这也同样成了一种借口,从而拒绝接受新的东西,拒绝在新的技术领域里扩展自己的能力。他们变的懒惰,自满,自鸣得意。

    2.) 一些IT专家采用某种技术的目的是为了巩固自己的势力,而不是出于对企业有帮助。

    另外一种很隐蔽的但是值得批评一下的事情是,有些IT工程师选择和使用的技术依赖于技术人员对这种技术的掌握情况,而不是这种技术是否是真的最适合这个业务。 例如,IT工程师会选择某个需要特殊技能才能维护的技术路线,而不是选择一种很现成的解决方案。或者,由于IT经理有过Linux/UNIX的背景经历,所以就会采用Linux-based的方案,反对基于Window的方案,即使采用window 平台的方案会更有利于项目。(或者,举个例子,一个Windows管理员很可能会把那些Linux-based的方案置之一边。)他们会有很多的借口和理由为他们的行为做解释,但很多都是不坦白的。

    1.)IT工程师不停的用一些专业术语来忽悠那些不懂技术的业务经理,以此掩盖他们把事情搞才一团糟的事实

    所有的IT人员 — 即使是最棒的员工 — 偶尔的也会把事情办遭. 这种事情一般会发生在很紧急的关头,而且要面对的系统是被搞的无比复杂而且很难入手。 然而,并不是所有的IT职员都擅长承认他们犯下的错误。大部分人都会利用业务经理(甚至是高层技术经理们)不是很清楚具体技术细节的事实,当系统出问题或宕机时拿一些专业术语去忽悠他们(掩盖事实的真相)。例如,向业务经理介绍为什么财务系统会宕机了3小时,技术人员会说,“我们在系统使用的SQL Server服务器上遇到了蓝屏。该死的微软!”技术人员没有说出的真实情况是由于没有先在工作站服务器上测试就进行驱动更新导致了这次蓝屏。

     

  • 转自--卖烧烤的鱼(网站安全测试)

    2008-08-13 15:31:20

    在网站测试中如何做好安全性测试?
     软件测试每周一问:随着网络发展的趋势,对于网站的安全性的要求也越来越高,很多网站都存在被黑客攻击的漏洞,你在网站测试中有做到安全性测试吗?你觉得安全测试应该从哪些方面来检查?欢迎大家讨论交流!

      会员卖烧烤的鱼的精彩回答:

      安全性测试(security testing)是有关验证应用程序的安全服务和识别潜在安全性缺陷的过程。

      注意:安全性测试并不最终证明应用程序是安全的,而是用于验证所设立策略的有效性,这些对策是基于威胁分析阶段所做的假设而选择的。

      以下是我读<<软件评测试教程>>中的Web安全性测试章节内容,并进行修改的笔记,前面看了好多朋友写的,不过不是很全,希望对大家有所帮助,建议大家还是买本<<软件评测试教程>>此书绝对物超所值^_^

    WEB安全性测试
      一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。
    1.        安全体系测试
    1)        部署与基础结构
      网络是否提供了安全的通信
      部署拓扑结构是否包括内部的防火墙
      部署拓扑结构中是否包括远程应用程序服务器
      基础结构安全性需求的限制是什么
      目标环境支持怎样的信任级别
    2)        输入验证
    l        如何验证输入
    A.        是否清楚入口点
    B.        是否清楚信任边界
    C.        是否验证Web页输入
    D.        是否对传递到组件或Web服务的参数进行验证
    E.        是否验证从数据库中检索的数据
    F.        是否将方法集中起来
    G.        是否依赖客户端的验证
    H.       应用程序是否易受SQL注入攻击
    I.        应用程序是否易受XSS攻击
    l        如何处理输入
    3)        身份验证
      是否区分公共访问和受限访问
      是否明确服务帐户要求
      如何验证调用者身份
      如何验证数据库的身份
      是否强制试用帐户管理措施
    4)        授权
      如何向最终用户授权
      如何在数据库中授权应用程序
      如何将访问限定于系统级资源
    5)        配置管理
      是否支持远程管理
      是否保证配置存储的安全
      是否隔离管理员特权
    6)        敏感数据
      是否存储机密信息
      如何存储敏感数据
      是否在网络中传递敏感数据
      是否记录敏感数据
    7)        会话管理
      如何交换会话标识符
      是否限制会话生存期
      如何确保会话存储状态的安全
    8)        加密
      为何使用特定的算法
      如何确保加密密钥的安全性
    9)        参数操作
      是否验证所有的输入参数
      是否在参数过程中传递敏感数据
      是否为了安全问题而使用HTTP头数据
    10)        异常管理
      是否使用结构化的异常处理
      是否向客户端公开了太多的信息
    11)        审核和日志记录
      是否明确了要审核的活动
      是否考虑如何流动原始调用这身份
    2.        应用及传输安全
      WEB应用系统的安全性从使用角度可以分为应用级的安全与传输级的安全,安全性测试也可以从这两方面入手。
      应用级的安全测试的主要目的是查找Web系统自身程序设计中存在的安全隐患,主要测试区域如下。
      注册与登陆:现在的Web应用系统基本采用先注册,后登录的方式。
    A.        必须测试有效和无效的用户名和密码
    B.        要注意是否存在大小写敏感,
    C.        可以尝试多少次的限制
    D.        是否可以不登录而直接浏览某个页面等。
      在线超时:Web应用系统是否有超时的限制,也就是说,用户登陆一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。
      操作留痕:为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进入了日志文件,是否可追踪。
      备份与恢复:为了防范系统的意外崩溃造成的数据丢失,备份与恢复手段是一个Web系统的必备功能。备份与恢复根据Web系统对安全性的要求可以采用多种手段,如数据库增量备份、数据库完全备份、系统完全备份等。出于更高的安全性要求,某些实时系统经常会采用双机热备或多级热备。除了对于这些备份与恢复方式进行验证测试以外,还要评估这种备份与恢复方式是否满足Web系统的安全性需求。
      传输级的安全测试是考虑到Web系统的传输的特殊性,重点测试数据经客户端传送到服务器端可能存在的安全漏洞,以及服务器防范非法访问的能力。一般测试项目包括以下几个方面。
      HTTPS和SSL测试:默认的情况下,安全HTTP(Soure HTTP)通过安全套接字SSL(Source Socket Layer)协议在端口443上使用普通的HTTP。HTTPS使用的公共密钥的加密长度决定的HTTPS的安全级别,但从某种意义上来说,安全性的保证是以损失性能为代价的。除了还要测试加密是否正确,检查信息的完整性和确认HTTPS的安全级别外,还要注意在此安全级别下,其性能是否达到要求。
      服务器端的脚本漏洞检查:存在于服务器端的脚本常常构成安全漏洞,这些漏洞又往往被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。
      防火墙测试:防火墙是一种主要用于防护非法访问的路由器,在Web系统中是很常用的一种安全系统。防火墙测试是一个很大很专业的课题。这里所涉及的只是对防火墙功能、设置进行测试,以判断本Web系统的安全需求。

    另推荐安全性测试工具:
      Watchfire AppScan:商业网页漏洞扫描器(此工具好像被IBM收购了,所以推荐在第一位)
      AppScan按照应用程序开发生命周期进行安全测试,早在开发阶段就进行单元测试和安全保证。Appscan能够扫描多种常见漏洞,例如跨网站脚本、HTTP应答切开、参数篡改、隐藏值篡改、后门/调试选项和缓冲区溢出等等。


      Acunetix Web Vulnerability Scanner:商业漏洞扫描器(目前用的比较多,不过这东东N占内存)
    Acunetix WVS自动检查您的网页程序漏洞,例如SQL注入、跨网站脚本和验证页面弱密码破解。Acunetix WVS有着非常友好的用户界面,还可以生成个性化的网站安全评估报告。

      另附我以前在51testing上发过“Yeepay网站安全测试漏洞之跨站脚本注入”
    http://bbs.51testing.com/thread-113784-1-1.html
      Sql注入和跨站脚本这种漏洞比较常见,另在支付宝网站注册页面也存在跨站脚本情况,希望能早点发现^_^

  • 5种方法快速定位对方IP

    2008-08-13 15:25:50

    5种方法快速定位对方IP
    与好友在网络上相互传输资料时,有时先要知道对方计算机的IP地址,才能与对方建立信息传输通道。
     
      那么对方的IP地址该如何搜查得到呢?这样的问题你也许会嗤之以鼻,的确,查询对方计算机的IP地址,实在简单得不值得一提;可是,要让你列举出多种IP地址搜查方法时,你可能就感到勉为其难了。下面,本文就对如何快速、准确地搜查出对方好友的计算机IP地址,提出如下几种方法,相信能对大家 有所帮助!
     
      1、邮件查询法
     
      使用这种方法查询对方计算机的IP地址时,首先要求对方先给你发一封电子邮件,然后你可以通过查看该邮件属性的方法,来获得邮件发送者所在计算机的IP地址;下面就是该方法的具体实施步骤:
     
      首先运行OutLook express程序,并单击工具栏中的“接受全部邮件”按钮,将朋友发送的邮件接受下来,再打开收件箱页面,找到朋友发送过来的邮件,并用鼠标右键单击之,从弹出的右键菜单中,执行“属性”命令;
     
      在其后打开的属性设置窗口中,单击“详细资料”标签,并在打开的标签页面中,你将看到“Received: from xiecaiwen (unknown [11.111.45.25])”这样的信息,其中的“11.111.45.25”就是对方好友的IP地址;当然,要是对方好友通过Internet中的 WEB信箱给你发送电子邮件的话,那么你在这里看到的IP地址其实并不是他所在工作站的真实IP地址,而是WEB信箱所在网站的IP地址。
     
      当然,如果你使用的是其他邮件客户端程序的话,查看发件人IP地址的方法可能与上面不一样;例如要是你使用foxmail来接受好友邮件的话,那么你可以在收件箱中,选中目标邮件,再单击菜单栏中的“邮件”选项,从弹出的下拉菜单中选中“原始信息”命令,就能在其后的界面中看到对方好友的IP地址了。
     
      2、日志查询法
     
      这种方法是通过防火墙来对QQ聊天记录进行实时监控,然后打开防火墙的日志记录,找到对方好友的IP地址。为方便叙述,本文就以KV2004防火墙为例,来向大家介绍一下如何搜查对方好友的IP地址:
     
      考虑到与好友进行QQ聊天是通过UDP协议进行的,因此你首先要设置好KV防火墙,让其自动监控UDP端口,一旦发现有数据从UDP端口进入的话,就将它自动记录下来。在设置KV2004防火墙时,先单击防火墙界面中的“规则设置”按钮,然后单击“新建规则”按钮,弹出设置窗口;
     
      在该窗口的“名称”文本框中输入“搜查IP地址”,在“说明”文本框中也输入“搜查IP地址”;再在“网络条件”设置项处,选中“接受数据包”复选框,同时将“对方IP地址”设置为“任何地址”,而在“本地IP地址”设置项处不需要进行任何设置;
     
      下面再单击“UDP”标签,并在该标签页面下的“本地端口”设置项处,选中“端口范围”选项,然后在起始框中输入“0”,在结束框中输入“65535”;同样地,在“对方端口”设置项处,也选中“端口范围”选项,然后在起始框中输入“0”,在结束框中输入“65535”。
     
      接着在“当所有条件满足时”设置项处,选中“通行”选项,同时将“其他处理”处的“记录”选项选中,而“规则对象”设置项不需要进行任何设置;完成了上面的所有设置后,单击“确定”按钮,返回到防火墙的主界面;再在主界面中选中刚刚创建好的“搜查IP地址”规则,同时单击“保存”按钮,将前面的设置保存下来。
     
      完成好上面的设置后,KV防火墙将自动对QQ聊天记录进行全程监控,一旦对方好友给你发来QQ信息时,那么对方好友的IP地址信息就会自动出现在防火墙的日志 。

      3、工具查询法。
     
      这种方法是通过专业的IP地址查询工具,来快速搜查到对方计算机的IP地址。例如,借助一款名为whereIsIP的搜查工具,你可以轻松根据对方好友的 Web网站地址,搜查得到对方好友的IP地址,甚至还能搜查到对方好友所在的物理位置。在用whereIsIP程序搜查对方IP地址时,首先启动该程序打开搜查界面,然后单击该界面的“Web site”按钮,在其后的窗口中输入对方好友的Web地址,再单击“next”按钮,这样该程序就能自动与Internet中的Domain Name Whois数据库联系,然后从该数据库中搜查到与该Web网站地址对应的IP地址了。当然,除了可以知道IP地址外,你还能知道对方好友所在的具体物理位置。
     
      倘若要想查看局域网中某个工作站的IP地址时,可以使用“网络刺客II”之类的工具来帮忙;只要你运行该工具进入到它的主界面,然后执行工具栏中的“IP地址<->主机名”命令,在其后打开的对话框中,输入对方好友的计算机名称,再单击“转换成IP”按钮,就能获得对方好友所在计算机的IP地址了。
     
      如果你使用Oicqsniffer工具的话,那么查询QQ好友的IP地址就更简单了。只要你单击该程序界面中的“追踪”按钮,然后向对方好友发送一条QQ消息,那么Oicqsniffer工具就会自动将对方好友的IP地址以及端口号显示出来了。除此之外,还有许多可以查找IP地址的专业工具可以选择,例如IPsniper软件。
     
      4、命令查询法
     
      这种方法是通过Windows系统内置的网络命令“netstat”,来查出对方好友的IP地址,不过该方法需要你先想办法将对方好友邀请到QQ的“二人世界”中说上几句话才可以。下面就是该方法的具体实现步骤:。
     
      首先单击“开始”/“运行”命令,在弹出的系统运行对话框中,输入“cmd”命令,单击“确定”按钮后,将屏幕切换到MS-DOS工作状态;然后在DOS命令行中执行“netstat -n”命令,在弹出的界面中,你就能看到当前究竟有哪些地址已经和你的计算机建立了连接(如果对应某个连接的状态为“Established”,就表明你的计算机和对方计算机之间的连接是成功的);。
     
      其次打开QQ程序,邀请对方好友加入“二人世界”,并在其中与朋友聊上几句,这样你的计算机就会与对方好友的计算机之间建立好了TCP连接;此时,再在DOS命令行中执行“netstat -n”命令,看看现在又增加了哪个tcp连接,那个新增加的连接其实就是对方好友与你之间的UDP连接,查看对应连接中的“Foreign Address”就能知道对方好友的IP地址了。
     
      5、ping检查法
     
      这种方法就是利用“ping”命令,来检查当前计算机是否能与对方好友的网站连通,在检查的过程中该地址能自动获得对方网站的IP地址。比方说,要是你想搜查天极网站的IP地址时,可以先打开系统的运行对话框,然后在其中输入“pingwww.pconline.com.cn”字符串命令,再单击“确定”按钮,在弹出的窗口中,就能知道网站的IP地址了。同样地,你也可以搜查其他网站的IP地址。

  • Web系统有多少安全漏洞

    2008-08-13 15:17:20

    Web系统有多少安全漏洞

    Internet的开放性使得Web系统面临入侵攻击的威胁,而建立一个安全的Web系统一直是人们的目标。一个实用的方法是,建立比较容易实现的相对安全的系统,同时按照一定的安全策略建立相应的安全辅助系统,漏洞扫描器就是这样一类安全辅助系统。

      漏洞扫描就是对计算机系统或者其他网络设备进行安全相关的检测,以找出安全隐患和可被黑客利用的漏洞。作为一种保证Web信息系统和网络安全必不可少的手段,我们有必要仔细研究利用。值得注意的是,漏洞扫描软件是把双刃剑,黑客利用它入侵系统,而系统管理员掌握它以后又可以有效的防范黑客入侵。

      四种漏洞扫描技术

      漏洞扫描通常采用两种策略,第一种是被动式策略,第二种是主动式策略。所谓被动式策略就是基于主机之上,对系统中不合适的设置、脆弱的口令以及其他与安全规则抵触的对象进行检查;而主动式策略是基于网络的,它通过执行一些脚本文件模拟对系统进行攻击的行为并记录系统的反应,从而发现其中的漏洞。利用被动式策略的扫描称为系统安全扫描,利用主动式的策略扫描称为网络安全扫描。

      漏洞扫描有以下四种检测技术:

      1.基于应用的检测技术。它采用被动的、非破坏性的办法检查应用软件包的设置,发现安全漏洞。

      2.基于主机的检测技术。它采用被动的、非破坏性的办法对系统进行检测。通常,它涉及到系统的内核、文件的属性、操作系统的补丁等。这种技术还包括口令解密、把一些简单的口令剔除。因此,这种技术可以非常准确地定位系统的问题,发现系统的漏洞。它的缺点是与平台相关,升级复杂。

      3.基于目标的漏洞检测技术。它采用被动的、非破坏性的办法检查系统属性和文件属性,如数据库、注册号等。通过消息文摘算法,对文件的加密数进行检验。这种技术的实现是运行在一个闭环上,不断地处理文件、系统目标、系统目标属性,然后产生检验数,把这些检验数同原来的检验数相比较。一旦发现改变就通知管理员。

      4.基于网络的检测技术。它采用积极的、非破坏性的办法来检验系统是否有可能被攻击崩溃。它利用了一系列的脚本模拟对系统进行攻击的行为,然后对结果进行分析。它还针对已知的网络漏洞进行检验。网络检测技术常被用来进行穿透实验和安全审记。这种技术可以发现一系列平台的漏洞,也容易安装。但是,它可能会影响网络的性能。

      网络漏洞扫描

      在上述四种方式当中,网络漏洞扫描最为适合我们的Web信息系统的风险评估工作,其扫描原理和工作原理为:通过远程检测目标主机TCP/IP不同端口的服务,记录目标的回答。通过这种方法,可以搜集到很多目标主机的各种信息(例如:是否能用匿名登录,是否有可写的FTP目录,是否能用Telnet,httpd是否是用root在运行)。

      在获得目标主机TCP/IP端口和其对应的网络访问服务的相关信息后,与网络漏洞扫描系统提供的漏洞库进行匹配,如果满足匹配条件,则视为漏洞存在。此外,通过模拟黑客的进攻手法,对目标主机系统进行攻击性的安全漏洞扫描,如测试弱势口令等,也是扫描模块的实现方法之一。如果模拟攻击成功,则视为漏洞存在。

      在匹配原理上,网络漏洞扫描器采用的是基于规则的匹配技术,即根据安全专家对网络系统安全漏洞、黑客攻击案例的分析和系统管理员关于网络系统安全配置的实际经验,形成一套标准的系统漏洞库,然后再在此基础之上构成相应的匹配规则,由程序自动进行系统漏洞扫描的分析工作。

      所谓基于规则是基于一套由专家经验事先定义的规则的匹配系统。例如,在对TCP80端口的扫描中,如果发现/cgi-bin/phf/cgi-bin/Count.cgi,根据专家经验以及CGI程序的共享性和标准化,可以推知该WWW服务存在两个CGI漏洞。同时应当说明的是,基于规则的匹配系统有其局限性,因为作为这类系统的基础的推理规则一般都是根据已知的安全漏洞进行安排和策划的,而对网络系统的很多危险的威胁是来自未知的安全漏洞,这一点和PC杀毒很相似。

      这种漏洞扫描器是基于浏览器/服务器(B/S)结构。它的工作原理是:当用户通过控制平台发出了扫描命令之后,控制平台即向扫描模块发出相应的扫描请求,扫描模块在接到请求之后立即启动相应的子功能模块,对被扫描主机进行扫描。通过分析被扫描主机返回的信息进行判断,扫描模块将扫描结果返回给控制平台,再由控制平台最终呈现给用户。

      另一种结构的扫描器是采用插件程序结构。可以针对某一具体漏洞,编写对应的外部测试脚本。通过调用服务检测插件,检测目标主机TCP/IP不同端口的服务,并将结果保存在信息库中,然后调用相应的插件程序,向远程主机发送构造好的数据,检测结果同样保存于信息库,以给其他的脚本运行提供所需的信息,这样可提高检测效率。如,在针对某FTP服务的攻击中,可以首先查看服务检测插件的返回结果,只有在确认目标主机服务器开启FTP服务时,对应的针对某FTP服务的攻击脚本才能被执行。采用这种插件结构的扫描器,可以让任何人构造自己的攻击测试脚本,而不用去了解太多扫描器的原理。这种扫描器也可以用做模拟黑客攻击的平台。采用这种结构的扫描器具有很强的生命力,如著名的Nessus就是采用这种结构。这种网络漏洞扫描器的结构如图2所示,它是基于客户端/服务器(C/S)结构,其中客户端主要设置服务器端的扫描参数及收集扫描信息。具体扫描工作由服务器来完成。漏洞扫描器的发展趋势

      值得我们注意的是漏洞扫描软件从最初的专门为UNIX系统编写的一些只具有简单功能的小程序,发展到现在,已经出现了多个运行在各种操作系统平台上的、具有复杂功能的商业程序。今后的发展趋势主要有以下几点,我们可以根据实际Web信息系统风险评估的需求进行选用:

      1.使用插件或者叫做功能模块技术。每个插件都封装一个或者多个漏洞的测试手段,主扫描程序通过调用插件的方法来执行扫描。仅仅是添加新的插件就可以使软件增加新功能,扫描更多漏洞。在插件编写规范公布的情况下,用户或者第三方公司甚至可以自己编写插件来扩充软件的功能。同时这种技术使软件的升级维护都变得相对简单,并具有非常强的扩展性。

      2.使用专用脚本语言。这其实就是一种更高级的插件技术,用户可以使用专用脚本语言来扩充软件功能。这些脚本语言语法通常比较简单易学,往往用十几行代码就可以定制一个简单的测试,为软件添加新的测试项。脚本语言的使用,简化了编写新插件的编程工作,使扩充软件功能的工作变得更加容易,也更加有趣。

      3.由漏洞扫描程序到安全评估专家系统。最早的漏洞扫描程序只是简单地把各个扫描测试项的执行结果罗列出来,直接提供给测试者而不对信息进行任何分析处理。而当前较成熟的扫描系统都能够将对单个主机的扫描结果整理,形成报表,能够并对具体漏洞提出一些解决方法。不足之处是对网络的状况缺乏一个整体的评估,对网络安全没有系统的解决方案。未来的安全扫描系统,应该不但能够扫描安全漏洞,还能够智能化地协助网络信息系统管理人员评估本网络的安全状况,给出安全建议,成为一个安全评估专家系统。

      Web系统的风险等级评估

      在实现了对Web信息系统的安全扫描后,便可根据扫描结果,对Web信息系统的安全性能进行评估,从而给出Web信息系统的风险状况。这里,风险评估的依据是根据扫描结果,根据Web信息系统所具有的漏洞数目及漏洞的危害程度,将Web信息系统的安全状态进行分级。

      划分的风险评估级别如下:

      l.A级:扫描结果显示没有漏洞,但这并不表明系统没有漏洞,因为有许多漏洞是尚未发现的,我们只能针对已知的漏洞进行测试。

      2.B级:具有一些泄漏服务器版本信息之类的不是很重要内容的漏洞,或者提供容易造成被攻击的服务,如允许匿名登录,这种服务可能会造成许多其它漏洞。

      3.C级:具有危害级别较小的一些漏洞,如可以验证某账号的存在,可以造成列出一些页面目录、文件目录等,不会造成严重后果的漏洞。

      4.D级:具有一般的危害程度的漏洞。如拒绝服务漏洞,造成Web信息系统不能正常工作;可以让黑客获得重要文件的访问权的漏洞等。

      5.E级:具有严重危害程度的漏洞。如存在缓冲区溢出漏洞,存在木马后门,存在可以让黑客获得根用户权限或根用户的shell漏洞,根目录被设置一般用户可写等一些后果非常严重的漏洞。

      另外,我们需要强调的是:漏洞的产生主要源于Web信息系统的不正当配置以及其提供的服务自身的弱点。前面我们详细介绍了如何使用漏洞扫描来进行风险评估。其实还有一个非常重要的问题我们不能忽略,那就是需要检测Web信息系统到底提供了哪些服务,因为它直接关系到系统的漏洞的产生以及危害。一方面,Web信息系统为用户提供了多种优质的网络服务,包括Http、Ftp、Smtp、Pop3等;另一方面,服务的增多意味着更多的风险。每种服务本身都必然存在着某些缺陷,而这些缺陷很有可能被高明的黑客利用来对系统进行攻击。所以,提供特定服务的服务器应该尽可能开放提供服务必不可少的端口,而将与服务器服务无关的服务关闭,比如:一台作为www和ftp服务器的机器,应该只开放80和25端口,而将其他无关的服务如关掉,以减少系统漏洞。

      因此,我们需要针对Web系统的实际用途使用相关的工具来对系统开放的网络服务及其端口等进行有效地检测和适时的处理,以及时关闭那些不必需要的服务和端口,以免为黑客和不法用户利用,从而侵入信息系统。显然,这是一项非常艰巨和长期的工作,管理者们需要在技术和管理两个层面上投入相当的物力和财力,从而保证Web信息系统的安全性

  • 软件测试管理常见问题及其回答

    2008-08-13 10:19:55

    软件测试管理常见问题及其回答
    1、测试负责人要进行严格的测试进度跟踪吗?
    很多时候,由于人力资源的不足,测试项目负责人都是在执行测试,这样就使整个项目缺乏控制,一些问题(例如:有些成员的缺陷质量不够合格;开发人员修改不及时,系统某些功能发生严重问题导致部分功能无法测试。)得不到解决,耽误了进度。所以测试负责任必须全程监控项目,尽可能多的掌握信息。通常,测试负责人需要完成下面这些内容的管理工作:
    测试用例执行情况;
    每个测试员提交的缺陷情况;
    测试中是否发生突发问题。

    2、 测试也有版本控制吗?
    这里的版本主要是指测试对象的版本控制,也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下,测试小组进行版本控制十分重要,要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定,可以各自指定专门的测试版本负责人,制定提交原则,对提交情况进行详细的记录,这样基本避免了版本失控导致的测试失误或无效。

    3、如何处理测试人员的流动问题?
    人员流动不仅仅是测试部门,这是IT行业的普遍现象。从管理者角度,主管需要多多和团队内成员进行沟通,建立一个融洽的团队环境,及时掌握情况,可以早些进行相应的调整。但是只有企业建立好的用人制度,给员工提高广阔的发展空间和好的培训学习机会,才能从根本上解决这一问题。
    加强项目管理,强化文档管理并保证文档的有效性,可以大大减少由于人员流失带来的损失。同时,测试部门要建立培训机制,使新到员工接受直接或者间接的培训,快速适应工作。

    4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差?
    我们经常听开发人员说:“这不是缺陷!”,“这个缺陷没有,因为我的系统上运行正常!”。测试工程师本身就是做质量工作的,提交的成果本身就应该质量高些,为什么还会有这种现象?
    提交的缺陷引起争议是一种正常的现象,例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试,交叉测试是提高测试质量的一个有效手段,当然交叉测试会增加一定的测试成本投入。在测试任务完成后,测试工程师之间互相验证彼此提交的缺陷,就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题,从而大大降低了回归测试以及交流的成本,因而这种投入也是值得的,实际开发人员在单元测试阶段也会进行交叉测试,来提高开发质量。
    另外,测试人员一定要按照规范描述测试中发现的缺陷,一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容,缺陷管理参考第八章的内容。

    5、“让那些新手来做测试,反正他们也不会什么”正确吗?
    在实际项目开发中,我们常常看到有些单位忽视测试团队存在的意义,当要实施测试时,往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性,但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作,这常常导致测试效率低下,测试人员对测试工作索然无味。
    根据笔者的经验,测试团队应首先聘请一名资深的测试领域专家,他应具有极为丰富的同类项目软件测试经验,对软件开发过程中常见的缺陷或错误了然于胸;此外,他还具有较好的亲和力和人格魅力。其次,项目测试团队还具有很多具备一技之长的成员,如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。
    另外,测试团队还应聘请一些兼职成员,如验证测试实施过程中,同行评审是最常使用的一种形式,这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手,这部分人可以安排去从事交付验证或黑盒测试之类的

    6、测试同化现象是什么?
    同化现象是指随着时间的推移,开发人员会逐渐影响测试人员的思维和对缺陷的判断能力,尤其是针对同一产品,同一组开发人员和同一组测试人员共同配合了很长时间,很多本来是缺陷的问题,由于测试人员对软件“习惯成自然”的使用,会不被当成缺陷,尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始:测试人员会帮着开发人员解释一个个缺陷的合理性,一轮有一轮的测试都不会发现问题。
    招聘新的人员,不同的测试项目组轮换去测试不同的产品,就可以避免。同时建议产品可以发布测试版,更多的人对其进行测试,就可以发现更多的问题。

    7、测试工程师如何避免定位效应?
    社会心理学家曾作过一个试验:在召集会议时先让人们自由选择位子,之后到室外休息片刻再进入室内入座,如此五至六次,发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应,说明人们习惯上凡是自己认定的,人们大都不想轻易改变它。
    定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能,经常进行代码移植,这种复制的“功能”,由于上一次经过调试,在新的地方往往不会认真调试,这些代码往往会带来共享变量冲突等许多种类型的缺陷。
    定位效应体现在测试人员身上就是测试过的功能不再进行认真测试:在回归测试时,之前由于进行过认真的测试,往往会认为某些功能是可靠,只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出,因为回归测试中很多功能都会进行多次反复测试。众所周知,开发人员在修改缺陷时往往会引入新的缺陷,测试人员的疏于防范就会把这些缺陷带到用户这里。
    解决这种问题的方案一般有两个:
    (1)完整的执行测试用例:这种方法投入较大,但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。
    (2)交叉测试:测试人员交叉测试,就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务,反复测试某一功能的机会大大减少,从而也就不会“主观的”人员某些功能没有缺陷。
    通常上面的两个方法都是结合使用的,既要进行交叉测试,又要全面执行测试用例,测试覆盖面要尽可能的广泛。

    8、测试人员忽然辞职怎么办?
    目前IT行业人员流动较大已经成为一种不争的事实,员工的辞职大多数都会给组织带来一定的影响,而这种影响基本是不可能避免的。在测试领域,员工忽然辞职也会带来很大的负面影响,尤其测试队伍规模较小时。面对这种情况,我们所能做的,就是如何最大限度的降低这种影响。
    根据作者的经验,主要有两种方法:第一种是在测试人员内部建立一个良好的学习环境,大家互相学习,这样某些特有技术不会被某一个人所掌握,而互相学习和提高自身,也是大多数成员愿意做的;第二种就是在组织中进行知识管理,把技术作为知识沉淀下来,这样新的员工在接手工作时容易上手,通过学习快速适应环境。
    此外,日常还要注意工作规范化,例如形成尽可能多的文档,都可以降低员工离职带来的损失。

    9、测试人员工作发生问题测试经理应该如何做?
    测试人员工作发生问题是测试经理经常要面对的问题,作为测试部门的领导,首先要做的是指出测试人员所犯的错误,使其尽快改正错误。
    唯一不能做的就是盯着下属的错误不放。总盯着下属的失误,是一个领导者的最大失误。英国行为学家波特说:当遭受许多批评时,下级往往只记住开头的一些,其余就不听了,因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导,最大限度的调动每个人员的积极性来参加工作。

    10、不深入到具体测试工作时,测试经理如何考核员工?
    这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话,这样可以尽早发现和解决很多问题。
    最为一个测试经理,主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告,以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。
    测试经理和每个员工重点是谈谈目前的工作,例如大家在工作中的问题或意见;是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验,如果不能安排时间和员工进行每周的谈话,员工会来打扰测试经理的工作,因为员工很多问题还要要来找测试经理商议。
    同时对待员工要用他们能接受的方式,而不是我们自己可以接受的方式。“己之不予,勿施于人”,这条黄金法则可能会对许多生活中的纯粹的社交因素有效,但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。

    总之,只有尽可能多的和员工接触,才能更精确的进行考核。
    11、测试经理如何面对加班问题?
    大多数情况下,作者是不主张加班的。当员工每周工作超过40个小时的时候,他们开始在工作的时候关心自己的事。他们花钱,会给很久没有联系的人打电话,因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作,这是因为他们在工作时不能关心自己,这种情况下通常效率很低。
    测试管理工作的重要任务之一就是要创造一个环境,让员工在工作时间内完成工作,同时还要鼓励他们每周不要超过40小时,甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力,从而会逐渐提高效率。
    测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试,如果在疲劳状态下,很有可能精力不集中,略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序,这种情况更需要较好的状态来工作。

    12、测试管理者如何面对自己的错误?
    每个人都会犯错。我们可能会因为忘记开会而使客户发怒,承认自己犯错是一件尴尬的事情,尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错,承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议,然后为此向同事或者客户道歉,其他的人会理解我们的。
    不管做了什么,不要否认或故意忽略自己的失误。故意忽略不会让错误消失,这只会让错误成长为怪物。

    13、为什么计划定期的培训?
    测试工作和开发工作一样,不但要面对日新月异的新技术,还要学习相关系统的领域知识。只有在不断的学习中,才能做好工作,跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工,就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术,通常采用下面几种方法:
    (1)测试部门内自由交流方式的培训。这种培训的交流比较随意,可以在周五的例会上进行交流,也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”,让每个组员讨论一个特定的领域,这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目,这会有助于每个人了解你小组所有的工程。
    (2)跨部门的互相学习。测试工作需要很多领域以及技术知识,这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法,大家在工作中可以在技术等各个方面互相得到提高。
    (3)外部培训。外部培训尽管投入较高,但也是值得的。这些专家一般在自己的领域非常精通,可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训,这种方式可以降低成本。
    培训是构造学习型组织的基本条件,也是提高员工水平的重要方法。经常的定期培训,可以增强组织凝聚力,使员工更加愿意长期留在组织中发展。做为测试负责人,定期的进行培训是十分必要的。

    14、时间上不允许进行全部测试,测试负责人应该如何做?
    这个问题也许十分可笑,可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试,而是指测试负责人制定的测试计划包含的全部测试内容。
    通常,不管是开发产品还是做具体的项目,都会发生耽误进度的情况。一旦整体进度不能向后延迟,项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况下,这种现象更为突出。
    担负着质量重任的测试经理,如何来解决这个问题呢?比较好的做法是按照下面的步骤逐步来完成和改进工作:
    (1)按照测试任务的轻重缓急,尽最大努力完成测试任务。在时间不足的情况下,我们应该对测试任务按照优先级来划分,重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作,其目的就是尽最大努力来提高质量。因此,面对这种情况,测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。
    (2)在实际工作中和开发人员共同配合,逐步改进工作。只有整个团队的软件开发能力提高了,才能从根源上解决问题。因此,测试负责人要带领团队和开发小组共同寻找适合自己的开发模式,从而使项目规划的更加合理,进而按照预定计划来开展测试工作。
    总之,在任何情况下,测试负责人都不应该抱怨。只有积极的面对问题,才能更好的解决问题。

    15、公司不重视测试,测试负责人如何开展测试工作?
    目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试,但是在具体工作中,往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下,测试负责人仍要对软件质量负主要责任。在这种环境下,测试负责人应该如何开展工作呢?
    首先,要主动去配合开发人员完成工作。尤其是不能抱怨环境,在任何情况下抱怨是不能解决问题的,只能加重矛盾的激化。在此基础上,逐渐显出测试工作的重要性,然后再逐步健全测试体系。
    其次,用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来,人们才会真正的注意到测试的重要性。因此,测试负责人从点滴开始做起,才能逐步做好测试工作。
    要想做好软件,把开发的软件产品形成商品,测试工作必须和开发一样重视。否则,质量不好的产品,很快会被市场淘汰的。现代的软件规模越来越大,测试工作也会越来越重要,因此测试负责人只要坚持做好工作,可发挥作用的空间会越来越大。
    最后要说的是,如果真的是在一个没有希望的团队里,测试负责人可以考虑辞职。辞职也是一个不错的选择,到新的环境去发挥自己的能力,要比长时间的怀着“郁闷”的心情去工作好的多。

    16、测试管理者需要是技术专家吗?
    测试管理者在测试项目中的主要任务是制定测试策略,管理测试计划的落实情况,并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性,对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。
    但是在实际工作中,由于测试人员的短缺,测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队,测试管理者的日常工作通常以具体的测试执行工作为主,这个时候更需要测试管理者有较好的背景知识。
    总体说来,技术方面的背景知识对测试管理者是十分有益的。例如:分配工作任务、做进度预算,以及一些具体的执行工作,都需要一定的背景知识。当然,做为一个测试管理者,没有必要精通所有的技术,那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作,并且提供最好的完成工作的环境就可以了。

     
     

  • 不同测试类型的形象比喻

    2008-08-12 15:37:56

    不同测试类型的形象比喻

    功能测试: 圆珠笔按下是否能正常写字,写字太重会不回缩回去,继续按会不会弹回去

    性能测试:圆珠心弹出弹回的快慢

    负载测试:一直按,弹簧能接受多少次的升缩

    兼容性测试:换其他的笔芯能不能行

    强度测试:用力过度会怎样

    可恢复性测试:如果弹簧压久了,是否可恢复等等

    GUI测试:笔的外观,拿笔的舒适性

    安全性:考虑对笔芯的保护,是否对使用者造成危害等等

  • 获取负面测试用例的技术

    2008-08-12 15:22:25

    获取负面测试用例的技术
    http://www.51testing.com/?action_viewnews_itemid_71451.html(转自)

    1.负面测试的目的

    负面测试在BS7925-1中的英国标准定义是采用Beizer的定义,其定义负面测试为“旨在说明软件不能工作的测试”(原文:Testing aimed at showing software does not work)。它可以带出一系列补充性的和竞争性的目的。

    发现导致重大失效、崩溃、破坏和安全漏洞的故障

    观察和度量系统对外界问题的响应

    揭露软件的弱点和开发的潜力

    虽然有个一个公正的定义,但是它离被普遍接受还差的很远。负面测试是一个紧跟着被重新定义的术语,有时甚至是各小组的。一个常见的方法,其实践和英国标准定义不同的是它包括旨在使用专门对付失效的功能的测试。

    输入验证,拒绝和重新请求的功能(人工输入和外界系统)

    内部数据验证和拒绝

    应付缺乏的,缓慢的或坏掉的外界资源

    错误处理功能,例如消息,日志,监视功能

    恢复功能,例如故障恢复,回滚和恢复

    2.获取测试用例的技术

    负面测试不是一种测试设计技术,说是一种方法或分类更加合适。使用许多正式的测试设计技术来获取那些能够被划分为‘负面测试’的测试是很有可能。这一节详述了各种各样的知名技术的应用。

    边界值分析和等价类划分Boundary Value Analysis and Equivalence Class Partitioning

    状态转换测试State Transitiontesting

    逆着已知的约束测试Test against known constraints

    故障模式和结果分析Failure Mode and Effects analysis

    并发Concurrency

    用例和误用的用例Use cases and mis-usecases

    2.1.边界值分析和等价类划分

    有两种基于输入和输出数据和系统行为期望的技术。

    边界值分析(BVA:Boundary Value Analysis)利用关于预知系统行为转换位置的边界的需求和设计来检查那些能够带出一连贯范围数值的数据元素。

    这个方法用于产生三个数值-一个就是边界本身,另外两个在前者的两边(尽可能的和数字相接近)。如果边界在有效和无效范围之间,使用无效数值的测试用例将成为一个负面测试用例。例如,使用66在只接受从18~65数值的年龄字段。

    等价类划分(ECP:Equivalence Class Partitioning)着眼于边界之间的范围。给出的等价类中的每个成员应该在一个已知测试的环境里,使系统做同样的事情-这样测试员不必要测试在等价类中每一个数值。无效输入数据的范围可以被看成为负面测试-例如,一个年龄字段可能被期望用相同的方法拒绝所有的负数。

    ECP一般被延伸到包括非连续数值的集合,胜于连续的数值范围。要注意一些输入可能看上去等价,但是实际上出现很多不同的行为。例如,一个简单web的表单的输入是为空或者太长时可能会被拒绝,但是控制字符的正确组合可能危害潜在web服务器的安全。

    2.2.状态转换测试

    假设有一个状态转换图或者一个与其等价的理解,那么就很容易获得可以明确地检查不可到达的状态是否真的不可到达的测试用例。与这种方法相同的变种称为n-switch测试,在一套已知的转换之后,那些不可到达的状态仍然是不可到达吗?图形工具,例如Compendium-TA[4]能够帮助你获得这样的测试。

    2.3.逆着已知的约束测试

    大多数的系统有明确的和含蓄的限制和约束。如同需求一样对待这些约束(参加Robinson+Robinson,[5]))就可以得到各种负面测试。例如:

    “The site is designed to be viewed with Internet Explorer4.5 or later”–负面测试可以使用IE3.0或Netscape.

    “No more than five users will use the system at the same time”–负面测试可以尝试6个,然后8。

    概括来说,测试包括度量和观察系统的行为胜于直接逆着期望结果测试。这只能在系统的操作参数之外工作时被使用,并且这种观察可能导致对系统的进一步了解。

    2.4.故障模式和结果分析

    从对潜在的技术,实现和已知故障的分析来预见系统特有的故障是很有可能的。这种分析是观察在故障条件下系统行为的测试基础。捕获和文档化这种信息是非常重要的-特别是如果他们允许诊断数据和环境。对于那些监视他们系统并且拥有在系统被使用时(例如银行,电话公司)可以采取行动的技术专家的组织而言,这些文档通常是测试的必要输出。另一方面,对于更广泛的分布式软件包来说,这些信息也可以成为FAQ或故障诊断指南的一部分。

    这些测试可能不可能在没有一个有效的测试工具或应用驱动下执行。这样的工具通常是自定制的,并且可能需要在代码的已提交版本里运行。

    然而,象CannedHEAT和Holodeck(都出自the Florida Institute of Technology,[6])这样的工具允许将普通性故障引入到运行在Windows的软件中。

    6.4.1.故障家族

    有很多来源可以帮助你开发故障模式的家族。既有故障的根本原因分析,系统设计文档,基础设施特有问题的知识能够帮助识别故障模式,并且因此为获取测试提供来源。

    以下列表虽不详尽,但或许可以帮助引发更多的关于可能的故障想法。

    外部资源:反应迟钝或缓慢的,莫明其妙或不恰当的反应。

    协处理器故障:独特的间断处理器,多任务和递归

    并发使用:资源锁定,请求已拒绝的锁定,死锁,锁定响应延迟

    牺牲处理器Sacrificialprocesses:允许失败的处理器并且用可控方式恢复

    文件系统:文件不能被找到,打开,读,写,权限变更,文件系统识别介质错误,介质移除,介质装满

    网络:网络中断,网络忙碌/缓慢,传输段丢失、损坏、无序,处理器之间的对话被中断

    内存:不足以给请求的分配,碎片

    已达到的限制:排队,licences,线程,连接,数组大小,资源分配

    2.5.并发

    测试对资源的并发使用可以是一个非常富有成效的找bug方法。初始分析包括鉴别也许会尝试同时使用的数据,数据库条目,文件、连接和超过一个处理器的硬件。通过允许测试者在系统之前利用资源,简单,定制的工具可能有些帮助,并且在他们选择的时候发布它。测试也应该检查第二个请求者最终得到了资源。更加复杂的测试将着眼于二个以上的请求,排队,超时和死锁。

    2.6.用例和误用的用例

    用例,在实践中趋向于处理系统的‘happypath’。各种错误输入的覆盖,拒绝的循环和部分转换通常是很稀少的。‘误用的用例’术语,虽然不是偏僻的标准,但是能够帮助明确地识别和区分他们。执行这些路径地用例可以通过图解期望结果正常范围外的用户的活动来帮助提高设计,并且允许一个正式的方法来测试选择和覆盖.

  • WEB性能测试用例设计

    2008-08-12 15:18:09

    WEB性能测试用例设计 

    性能测试用例主要分为预期目标用户测试,用户并发测试,疲劳强度与大数据量测试,网络性能测试,服务器性能测试五大部分,具体编写测试用例时要根据实际情况进行裁减,在项目应用中遵守低成本,策略为中心,裁减,完善模型,具体化等原则;

    一、WEB 全面性能测试模型
     Web 性能测试模型提出的主要依据是:一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试,这些类型的性能测试的实施是有着相似之处的;

    1.       预期指标的性能测试:
    系统在需求分析和设计阶段都会提出一些性能指标,完成这些指标的相关的测试是性能测试的首要工作之一,这些指标主要诸于“系统可以支持并发用户200个;”系统响应时间不得超过20秒等,对这种预先承诺的性能要求,需要首先进行测试验证; 

    2.       独立业务性能测试;
         独立业务实际是指一些核心业务模块对应的业务,这些模块通常具有功能比较复杂,使用比较频繁,属于核心业务等特点。

    用户并发测试是核心业务模块的重点测试内容,并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能,并且持续一段时间。对相同的功能进行并发测试分为两种类型,一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。

    3.       组合业务性能测试;
    通常不会所有的用户只使用一个或者几个核心业务模块,一个应用系统的每个功能模块都可能被使用到;所以WEB性能测试既要模拟多用户的相同操作,又要模拟多用户的不同操作;组合业务性能测试是最接近用户实际使用情况的测试,也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况;组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来,在通过工具模拟用户操作的同时,还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。

    用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发,每组的用户比例要根据实际情况来匹配;

    4.       疲劳强度性能测试;
    疲劳强度测试是指在系统稳定运行的情况下,以一定的负载压力来长时间运行系统的测试,其主要目的是确定系统长时间处理较大业务量时的性能,通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定;

    5.       大数据量性能测试;
    一种是针对某些系统存储,传输,统计查询等业务进行大数据量时的性能测试,主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试;

    第二种是极限状态下的数据测试,主要是指系统数据量达到一定程度时,通过性能测试来评估系统的响应情况,测试的对象也是某些核心业务或者常用的组合业务。

    第三种大数据量测试结合了前面两种的测试,两种测试同时运行产生较大数据量的系统性能测试;

    大数据量测试通常在投产环境下进行,并独立出来和疲劳强度测试放在一起,在整个性能测试的后期进行;大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试;

    6.       网络性能测试;
         主要是为了准确展示带宽,延迟,负载和端口的变化是如何影响用户的响应时间的,在实际的软件项目中

    主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成;

    7.       服务器(操作系统,WEB服务器,数据库服务器)性能测试;
    初级服务器性能测试主要是指在业务系统工作或者进行前面其他种类性能测试的时候,监控服务器的一些计数器信息,通过这些计数器对服务器进行综合性能分析,为调优或提高系统性能提供依据;

    高级服务器性能测试一般由专门的系统管理员来进行如数据库服务器由专门的DBA来进行测试和调优;

    8.       一些特殊的测试;
      主要是指配置测试,内存泄露测试的一些特殊的WEB性能测试;

    二、WEB 性能测试策略
    性能测试策略一般从需求设计阶段开始讨论如何定制,它决定着性能测试工作要投入多少资源,什么时间开始实施等后续工作的安排;其制定的主要依据是软件自身的特点和用户对性能的关注程度,其中软件自身的特点起决定性的作用;

    软件按照用途的不同可以分为两大类,系统类软件和应用类软件。系统类软件通常对性能要求较高,因此性能测试应该尽早介入;应用类软件分为特殊类应用和一般类应用,特殊类应用主要有银行,电信,电力,保险,医疗,安全等领域软件,这类软件使用频繁,用户较多,也需要较早进行性能测试;一般类主要是指一些普通类应用如OA,MIS 等一般类软件根据实际情况制定性能测试策略,受用户因素影响较大;

    1.       系统类软件;
     从设计阶段就开始针对系统架构,数据库设计等方面进行讨论,从根源来提高性能,系统类软件一般从单元测试阶段开始性能测试实施工作,主要是测试一些和性能相关的算法和模块;

    2.       应用类软件;
    特殊应用:从设计阶段就开始针对系统架构,数据库设计等方面进行讨论,从根源来提高性能,系统类软件一般从单元测试阶段开始性能测试实施工作,主要是测试一些和性能相关的算法和模块;

    一般应用:与使用用户的重视程度有关,用户高度重视时 ,设计阶段开始进行一些讨论工作,主要在系统测试阶段开始进行性能测试实施;用户一般重视时,可以在系统测试阶段的功能测试结束后进行性能测试;用户不怎么重视时,可以在软件发布前进行性能测试,提交测试报告即可;

    三、WEB性能测试用例设计模型
    性能测试用例设计通常不会一次设计到位,是一个不断迭代完善的过程,即使在使用过程中,也不是完全按照设计好的测试用例来执行,需要根据需求的变化进行调整和修改; WEB性能测试用例设计模型是一个内容全面比较容易组织和调整的模型架构。

    3.       预期性能指标测试用例;
    指一些十分明确的,在系统需求设计阶段预先提出的,期望系统达到的,或者向用户保证的性能指标,针对每个指标都要编写一个或者多个测试用例来验证系统是否达到要求,预期性能指标测试用例主要参考需求和设计文档,把里面十分明确的性能要求提取出来,指标中通常以单用户为主;

    如:对于普通的客户端,系统上传5MB以内的文件,速度不低于2MB/S;

    输入动作:选择1-5 MB的文件并上传,用秒表计时;

    期望的性能:上传的时间小于等于2.5S

    实际性能: 上传的时间2.29秒;

    这类用例通常以手工的方式执行;

    4.       用户并发性能测试用例;
         用户并发测试主要通过逐渐增加用户数量来加重系统负担,并通过测试工具对应用系统,各种服务器资源进

    监控,用户并发测试可以是正常数量用户和特殊数量用户进行并发, 用户并发测试是系统性能测试的核心部分,涉及压力测试,负载测试,强度测试等多方面的内容.独立业务性能测试实际就是核心业务模块的某一业务的并发性能测试,可以理解为单元性能测试;组合业务的性能测试是一个或者多个模块的多个业务同时进行并发性能测试,可以理解为集成性能测试,单元性能测试和集成性能测试两者紧密相连合并称为用户并发性能测试;用户并发测试要求选择有代表性的关键的业务来设计测试用例,以便更有效的评测系统性能;其测试用例设计文档的基本的编写思想是按照系统的体系结构进行编写.

    1.       独立核心模块用户并发性能的测试用例设计

     完全一样功能的并发测试:主要检查系统的健壮性,从技术角度讲就是检查程序对同一时刻并发操作的处理.

     完全一样操作的并发测试:基本要求是在同一时刻进行完全一样的操作,这类测试的目的是验证核心模块在

    大量用户使用同一功能时是否正常工作;

    相同/不同功能的子功能并发:每个不同的子功能都模拟一定的用户数量,通过工具来控制并发情况;

    如发送与接收邮件模块的一个测试用例,

    功能:当在线用户达到高峰时,发送和接收普通邮件正常,保证2000个以内用户可以同时访问邮件系统,能够正常发送和接收邮件;

    目的:测试系统2000个以内的用户同时在线时能否正常发送邮件;

    方法:采用LOADRUNNER的录制工具录制一个邮件发送过程测试,要监视数据库服务器和WEB服务器的性能,其中发送的邮件为普通邮件,附件大小不超过1MB.

    并发用户数与事务执行情况:并发用户数,事务平均响应时间,事务最大响应时间,平均每秒处理事务数,事务成功率,每秒点击率,平均流量;

    并发用户数与数据库主机:并发用户数,CPU利用率,MEM利用率,磁盘I/O参数,DB参数;

    并发用户数与应用服务器的关系表:并发用户数,CPU利用率,MEM利用率,磁盘I/O参数;

    2.       组合模块用户并发性能测试的用例设计

    组合模块的性能测试是最能反映用户实际使用情况的测试,它把前面系统中具有耦合关系的模块组合起来进行测试,可以理解为集成性能测试,组合模块并发测试可以真实反映用户使用系统的情况,可以从需求,设计文档;现场调查,系统采集数据获取用户场景;

    具有耦合关系的核心模块进行组合并发测试:主要测试在多用户并发条件下,一些存在耦合关系或者数据接口的模块是否正常运行;

    彼此独立的,内部具有耦合关系的核心模块组的并发测试:这类测试的对象是多个模块组,每个组相关的模块具有一定的耦合关系,组与组之间关系相互独立,主要站在用户的角度考虑问题;

    基于用户场景的并发测试:选择用户的一些典型场景进行测试,测试对象不限制于核心模块或非核心模块;

    组合模块用户并发性能测试的前两种类型仍然是针对核心模块的同时也关注用户场景,这样做的原因是大多数的性能问题都是由用户经常使用的核心模块一起的;可以看出,组合模块的用户并发性能测试既关注功能测试,也关注性能测试,通过发现一些接口和综合性能方面的问题,使系统更加稳定的运行。

    如下某OA系统组合模块的一个测试用例:

    功能:在线用户数达到高峰时,用户可以正常使用系统,目标是满足500个以内用户同时在线使用系统;

    目的:测试500个以内用户同时在线时能否使用比较常见的模块:公文系统,电子公告,网上论坛;

    方法:采用LOADRUNNER 的录制工具录制三项业务;业务1,在公文系统内进行打开,修改等操作;业务2,在电子公告系统内,察看发布公告; 业务3 ,在网上论坛系统内发布帖子,查看文章;每项业务分配一定数量的用户,利用LOADRUNNER来完成;

    并发用户数与事务执行情况:业务1,业务2,业务3事务平均响应时间;业务1,业务2,业务3事务最大响应时间;业务1,业务2,业务3平均每秒事务数;业务1,业务2,业务3平均成功率;每秒点击率;平均流量;

    并发用户数与数据库主机:CPU利用率;MEM利用率;磁盘I/O情况;DB参数;

    并发用户数与应用服务器的关系:CPU利用率,MEM利用率;磁盘I/O情况;

    5.       疲劳强度与大数据量测试;
    疲劳强度测试:主要特点是长时间对目标测试系统加压,目的是测试系统的稳定性,持续时间一般在1小时以上;疲劳强度测试属于用户并发测试的延续,因此核心内容仍然是核心模块用户并发和组合模块用户并发,在编写测试用例时需要编写不同参数或者负载条件下的多个测试用例,可以参考用户并发性能测试用例的设计内容,通常修改相应的参数就可实现所需要的测试场景;如下疲劳强度测试用例:

    极限名称:200个用户同时使用系统的3个模块;

    前提条件:测试客户端要有足够的资源;

    运行时间:连续运行16小时;

    测试方法:采用LOADRUNNER录制3个任务,然后开始对系统加压;

    输入动作:任务1,任务2,任务3 ;持续时间, 任务20小时, 任务2,21小时,任务3,16小时;用户数量;现象;

    大数据量测试:主要针对对数据库有特殊要求的系统进行的测试,如电信业务系统的手机短信业务;可以分为实时大数据量,主要目的是测试用户较多或者某些业务产生较大数据量时,系统能否稳定运行;极限状态下的测试,测试系统使用一段时间即系统累计一点量的数据时能否正常的运行业务;前面两种的结合,测试系统已经累计了较大数据量时,一些实时产生较大数据量的模块能否稳定工作;如下大数量测试用例:

    功能:数据库中的短信息表可以保存所有不能及时发送的短信息,用户上线后又能及时发送已经保存的信息;

    目的:

    方法:

    并发用户数与事务执行情况:输入说明; 事务平均响应时间;事务最大响应时间;平均每秒处理事务数,事务成功率;每秒点击率;平均流量;

    6.       网络性能测试;
         基于硬件的测试:主要是通过各种软件工具,仪器等测试整个系统的网络运行环境,一般由系统集成人员负责 ;

         基于应用系统的测试:主要测试用户数目与网络带宽的关系,通过测试工具准确展示带宽,延迟,负载和端口的变化是如何影响用户响应时间的;

    网络性能测试的用例设计主要针对后一种类型,可以独立进行测试,也可以和用户并发性能测试,疲劳强度与大数据量测试结合起来,在原有的基础上采用工具来调整网络设置,从而达到监视网络性能的目的;如下网络性能测试用例;

    目的: 测试系统运行在不同网络带宽条件下的性能情况,以及与并发用户数量的关系;

    方法:在不同的广域网带宽下使用LOADRUNNNER录制邮件系统得相关事务操作脚本,然后以不同的带宽和并发用户数进行压力测试,并记录在各种用户条件下各种事务的响应情况,同时记录路由器端口的流量和其他数据;

    运行时间:

    并发用户数与事务响应时间:

    7.       服务器性能测试;
    服务器性能测试主要是对数据库,WEB服务器,操作系统的测试,目的是通过性能测试找出服务器的瓶颈,为系统扩展,优化提供相关的依据;分为:

    高级服务器性能测试:在特定的硬件条件下,由数据库,WEB服务器,操作系统相应领域的专家进行的性能测试;

    初级服务器性能测试:在系统运行前面的性能测试时,通过测试工具对数据库,WEB服务器,操作系统的使用情况进行监控,然后进行综合分析,找出系统瓶颈;性能测试的主要目的是在软件功能良好的前提下,发现系统瓶颈并解决,而软件和服务器是产生瓶颈的两大来源,因此服务器测试一定要和前面的测试结合起来进行;在进行用户并发性能测试,疲劳强度与大数据量性能测试时,可以完成对服务器的监控并对服务器性能进行评估;这类部分的测试用例一般不必单独编写;

    四、WEB性能测试用例设计
    WEB 性能测试用例设计模型是设计性能测试用例的一个框架,在实际项目中,需要对其进行适当的剪裁,从而确定性能测试用例的范围和类别,裁减的依据是性能测试策略和测试范围;在测试用例主要框架确定后,接下来就要如何设计各类性能测试用例中具体数据。

    基于用户的测试多在用户现场进行,而为了测试目的而进行的测试多在开发环境即开发团队的内部进行;为了测试目的而设计的测试用例场景主要根据测试设计人员的经验来进行,但是仍要参考用户的实际场景,用户实际使用场景是设计所有测试用例的依据,性能测试用例设计首先要分析出用户现实中的典型场景,然后参照典型场景进行设计。比较常见的用户场景有如下三种:一天内不同时段的使用场景;系统运行不同时期的场景;不同业务模式下的场景;各类测试用例设计的细节:

    1.       确定用户使用系统情况的方法;
    确定用户对系统的使用情况是设计用例具体数据的基础,后面并发用户数据设计,疲劳强度设计以及各种场景设计都要依赖对用户使用系统情况的分析,分析用户使用情况经常采用现场调查和分析系统日志两种方法;

    用户现场调查:通过和用户进行沟通,可以确定用户的人员组成情况;这类方法适用于用户群体固定且目标测试系统没有投产前的情况;

    分析系统日志:当用户比较分散,现场调查比较困难时,可以采用对系统日志进行分析的方法,作为对用户现场调查的补充;

    2.       并发用户数量设计;
         设计并发用户数量前,首先要了解确定系统最大并发用户数量的方法;可以根据系统的最大使用人数或者最大在线数量来评估最大并发用户数量的方法;

         极限法:取最大在线用户数作为最大并发数,这种方法适用于系统已经投产目标用户群体不确定的门户网站,可以通过分析日志来进行测试;也可以使用系统已经注册的用户数量作为系统的用户数量,按照经验公式来估算最大用户数量;

         用户趋势分析:对软件生存周期内的用户未来走势进行分析,预测系统可能达到的最大使用用户数目,从而估算系统的最大并发用户数目,这种方法多用于用户数目逐渐增多的情况;

        经验评估法:多用于系统的使用用户数目相对稳定而且比较明确的系统;

    并发用户数量的设计基本是按照最大并发用户的数量的百分比来设计的,对于某一特定的用例,需要注意:

    一按照各类用户同时递增的方式来设计用户数量,是为了按照由浅入深的方法来发现系统的瓶颈;二并发用户的最大值一般不会超过前面计算的最大并发用户数量的20% ,除非是为了测试系统能支持的最大并发用户数量;三设计用户数量时要考虑成本,因为每组用户数都意味着至少执行一次测试;

    3.       系统不同时间段场景的设计;
    不同时间段的场景更接近用户使用情况,它也是设计核心模块和组合模块并发性能测试用例的基础,不同时间段场景分析的数据主要是前面的需求分析和日志分析结果;不同时间段场景的设计基本原则有两个:一是选择典型的场景进行测试;尤其要选择场景中并发用户数目较大的场景;二是要覆盖全面,设计出的用例要覆盖到压力可能较大的时间段;用户场景的设计一般与后面的业务模式结合起来进行;

    4.       业务模式的设计;
         业务模式的设计是不同时间段场景设计的特例,也是设计核心模块和组合模块并发性能测试用例的基础,设计业务模式的目的是专注于某些功能模块的组合,按时间段来设计场景通常会涉及很多模块,如果系统存在的由应用软件引起的瓶颈则很难定位,所以才抽象一些特定的业务模式来进行用例的设计;

    按照业务模式和时间段的场景来设计性能测试用例时,会涉及到如何设计每个模块并发用户数目的问题,通常会取各个相关模块在24小时内最大的并发用户数目进行组合;

    5.       大数据量测试用例的设计;
    历史数据相关的大数据量测试设计与并发用户的测试设计很类似,首先要确定系统数据的最长迁移周期,确定了系统的最大数据量后,接下来选择一些前面的核心模块或者组合模块的并发用户测试用例作为其主要内容即可;

    运行时大数据量测试主要根据模拟系统运行时可能产生的大数据量来进行测试,这类测试用例通常根据实际情况去分析设计;

    6.       一些特定测试用例的设计;
    疲劳强度测试,最大用户测试,容量测试等一些特殊的测试用例设计,根据用户的需求进行,这类用例的相关要求通常十分明确;

    性能测试用例最重要的是注意用例间的关系,孤立的设计各类用例只能增加测试成本,浪费人力。性能测试用例设计人员应该追求设计既能覆盖性能测试需求,又能以较低的成本来执行测试用例;

    五、WEB性能测试用例设计总结
    1.       测试用例可用性总结
    对于一个比较完善的性能测试项目,经常会有一些测试用例不能执行,,因此测试完成后应该分析哪些用例不能执行以及不能执行的原因,这样可以为下次测试打好基础。

    2.       用例执行效果分析
    通过对用例执行效果进行分析,可以为升级或者开发新的性能测试用例提供有利的参考,不是所有的用例都能导致系统瓶颈的出现,因此应该分析哪些用例能够发现系统问题,哪些用例执行时没有太大效果。分析那些设计好的用例不但有助于以后设计用例,还可以为再次执行提供参考:当下次测试进度压力较大时可以先执行重要的用例,跳过那些尝试性的,不容易发现问题的用例;

    3.       用例执行时间分析;
    分析用例的执行时间是为下次规划性能测试提供参考,由于很多用例执行时间不是特别确定,导致性能测试计划也具有一定的不确定性。通过分析用例的执行时间可以为以后的制定测试计划提供参考;

     

    总之,性能测试用例的设计是需要通过不断分析总结才能做好,不但要分析性能测试用例的可用性,执行效果,执行时间,还应该分析用例的设计方法,设计思路等。

  • Web性能测试术语

    2008-08-12 15:05:23

    Web性能测试术语

    在软件系统日益复杂的今天,性能已经成为软件质量的重要衡量标准之一,这一点尤其体现在和WEB相关的系统上。接下来介绍一些WEB性能测试中的术语,这些术语都是WEB性能测试中出现频繁的比较高的词汇,只有掌握这些基础的性能知识才可以进一步开展测试工作。这些术语主要有并发用户,并发用户数量,请求响应时间,事务响应时间,吞吐量,吞吐率,TPS,点击率,资源利用率等。

    并发用户:并发一般分为2种情况。一种是严格意义上的并发,即所有的用户在同一时刻做同一件事情或者操作,这种操作一般指做同一类型的业务。比如在信用卡审批业务中,一定数目的拥护在同一时刻对已经完成的审批业务进行提交;还有一种特例,即所有用户进行完全一样的操作,例如在信用卡审批业务中,所有的用户可以一起申请业务,或者修改同一条记录。

    另外一种并发是广义范围的并发。这种并发与前一种并发的区别是,尽管多个用户对系统发出了请求或者进行了操作,但是这些请求或者操作可以是相同的,也可以是不同的。对整个系统而言,仍然是有很多用户同时对系统进行操作,因此也属于并发的范畴。

    可以看出,后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况,因此对于大多数的系统,只有数量很少的用户进行“严格意义上的并发”。对于WEB性能测试而言,这2种并发情况一般都需要进行测试,通常做法是先进行严格意义上的并发测试。严格意义上的用户并发一般发生在使用比较频繁的模块中,尽管发生的概率不是很大,但是一旦发生性能问题,后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来,因为并发功能遇到异常通常都是程序问题,这种测试也是健壮性和稳定性测试的一部分。

    用户并发数量:关于用户并发的数量,有2种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的全部用户的数量,理由是这些用户可能同时使用系统;还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户发生并发,例如正在浏览网页的用户,对服务器没有任何影响,但是,在线用户数量是计算并发用户数量的主要依据之一。

    请求响应时间:指的是客户端发出请求到得到响应的整个过程的时间。在某些工具中,请求响应时间通常会被成为"TLLB",即"Time to last byte",意思是从发起一个请求开始,到客户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位一般为"秒"或者"毫秒".

    事务响应时间:事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念,是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数.

    吞吐量:指的是在一次性能测试过程中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.

    TPS:每秒钟系统能够处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.

    点击率:每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位.如果把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求.

    资源利用率:指的是对不同的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,因此是WEB性能测试工作的重点。

    资源利用率主要针对WEB服务器,操作系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考。在WEB性能测试中,更根据需要采集相应的参数进行分析。

  • 程序员面试之葵花宝典(下)

    2008-08-08 09:21:02

    程序员面试之葵花宝典(下)

    81、如何设定的weblogic的热启动模式(开发模式)与产品发布模式?

    可以在管理控制台中修改对应服务器的启动模式为开发或产品模式之一。或者修改服务的启动文件或者commenv文件,增加set PRODUCTION_MODE=true。

    82、如何启动时不需输入用户名与密码?

    修改服务启动文件,增加 WLS_USER和WLS_PW项。也可以在boot.properties文件中增加加密过的用户名和密码.

    83、在weblogic管理制台中对一个应用域(或者说是一个网站,Domain)进行jms及ejb或连接池等相关信息进行配置后,实际保存在什么文件中?

    保存在此Domain的config.xml文件中,它是服务器的核心配置文件。

    84、说说weblogic中一个Domain的缺省目录结构?比如要将一个简单的helloWorld.jsp放入何目录下,然的在浏览器上就可打入http://主机:端口号//helloword.jsp就可以看到运行结果了? 又比如这其中用到了一个自己写的javaBean该如何办?

    Domain目录\服务器目录\applications,将应用目录放在此目录下将可以作为应用访问,如果是Web应用,应用目录需要满足Web应用目录要求,jsp文件可以直接放在应用目录中,Javabean需要放在应用目录的WEB-INF目录的classes目录中,设置服务器的缺省应用将可以实现在浏览器上无需输入应用名。
    ygahgjxx (2006-7-01 09:18:54)
    85、在weblogic中发布ejb需涉及到哪些配置文件

    不同类型的EJB涉及的配置文件不同,都涉及到的配置文件包括ejb-jar.xml,weblogic-ejb-jar.xmlCMP实体Bean一般还需要weblogic-cmp-rdbms-jar.xml

    86、如何在weblogic中进行ssl配置与客户端的认证配置或说说j2ee(标准)进行ssl的配置

    缺省安装中使用DemoIdentity.jks和DemoTrust.jks KeyStore实现SSL,需要配置服务器使用Enable SSL,配置其端口,在产品模式下需要从CA获取私有密钥和数字证书,创建identity和trust keystore,装载获得的密钥和数字证书。可以配置此SSL连接是单向还是双向的。

    87、如何查看在weblogic中已经发布的EJB?

    可以使用管理控制台,在它的Deployment中可以查看所有已发布的EJB

    88、CORBA是什么?用途是什么?

    CORBA 标准是公共对象请求代理结构(Common Object Request Broker Architecture),由对象管理组织 (Object Management Group,缩写为 OMG)标准化。它的组成是接口定义语言(IDL), 语言绑定(binding:也译为联编)和允许应用程序间互操作的协议。其目的为:用不同的程序设计语言书写在不同的进程中运行,为不同的操作系统开发。

    89、说说你所熟悉或听说过的j2ee中的几种常用模式?及对设计模式的一些看法

    Session Facade Pattern:使用SessionBean访问EntityBean;Message Facade Pattern:实现异步调用;EJB Command Pattern:使用Command JavaBeans取代SessionBean,实现轻量级访问;Data Transfer Object Factory:通过DTO Factory简化EntityBean数据提供特性;Generic Attribute Access:通过AttibuteAccess接口简化EntityBean数据提供特性;Business Interface:通过远程(本地)接口和Bean类实现相同接口规范业务逻辑一致性;EJB架构的设计好坏将直接影响系统的性能、可扩展性、可维护性、组件可重用性及开发效率。项目越复杂,项目队伍越庞大则越能体现良好设计的重要性。

    90、说说在weblogic中开发消息Bean时的persistent与non-persisten的差别

    persistent方式的MDB可以保证消息传递的可靠性,也就是如果EJB容器出现问题而JMS服务器依然会将消息在此MDB可用的时候发送过来,而non-persistent方式的消息将被丢弃。

    91、Servlet执行时一般实现哪几个方法?

    public void init(ServletConfig config);public ServletConfig getServletConfig();public String getServletInfo();public void service(ServletRequest request,ServletResponse response);public void destroy()

    92、常用的设计模式?说明工厂模式。

    Java中的23种设计模式:Factory(工厂模式),Builder(建造模式), Factory Method(工厂方法模式),Prototype(原始模型模式),Singleton(单例模式), Facade(门面模式),Adapter(适配器模式), Bridge(桥梁模式), Composite(合成模式),Decorator(装饰模式), Flyweight(享元模式), Proxy(代理模式),Command(命令模式), Interpreter(解释器模式), Visitor(访问者模式),Iterator(迭代子模式), Mediator(调停者模式), Memento(备忘录模式),Observer(观察者模式),State(状态模式),Strategy(策略模式),Template Method(模板方法模式), Chain Of Responsibleity(责任链模式)。工厂模式:工厂模式是一种经常被使用到的模式,根据工厂模式实现的类可以根据提供的数据生成一组类中某一个类的实例,通常这一组类有一个公共的抽象父类并且实现了相同的方法,但是这些方法针对不同的数据进行了不同的操作。首先需要定义一个基类,该类的子类通过不同的方法实现了基类中的方法。然后需要定义一个工厂类,工厂类可以根据条件生成不同的子类实例。当得到子类的实例后,开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。

     

  • 程序员面试之葵花宝典(中)

    2008-08-08 09:18:15

    程序员面试之葵花宝典(中)

    41、是否可以继承String类?

    String类是final类故不可以继承。

    42、swtich是否能作用在byte上,是否能作用在long上,是否能作用在String上?

    switch(expr1)中,expr1是一个整数表达式。因此传递给 switch 和 case 语句的参数应该是 int、 short、 char 或者 byte。long,string 都不能作用于swtich

    43、try {}里有一个return语句,那么紧跟在这个try后的finally {}里的code会不会被执行,什么时候被执行,在return前还是后?

    会执行,在return前执行。

    44、编程题: 用最有效率的方法算出2乘以8等於几?

    2 << 3
    在VC++中运行这个就可得到16,最好的方法
    #include<stdio.h>
    void main(){
    printf("%d",2<<3);
    }
    2<<3移位,也可在JAVA足正确的运行

    45、两个对象值相同(x.equals(y) == true),但却可有不同的hash code,这句话对不对?

    不对,有相同的hash code。
    如果两个值相等,那么equals()方法相等,表示两个方法的对像相等,这表示,引用的对像的地址相等,这样就有相同的hashcode

    46、当一个对象被当作参数传递到一个方法后,此方法可改变这个对象的属性,并可返回变化后的结果,那么这里到底是值传递还是引用传递?

    是值传递。Java 编程语言只有值传递参数。当一个对象实例作为一个参数被传递到方法中时,参数的值就是对该对象的引用。对象的内容可以在被调用的方法中改变,但对象的引用是永远不会改变的。

    47、当一个线程进入一个对象的一个synchronized()方法后,其它线程是否可进入此对象的其它方法?

    不能,一个对象的一个synchronized方法只能由一个线程访问。

    48、编程题: 写一个Singleton出来。

    Singleton模式主要作用是保证在Java应用程序中,一个类Class只有一个实例存在。一般Singleton模式通常有几种种形式:
    第一种形式: 定义一个类,它的构造函数为private的,它有一个static的private的该类变量,
    在类初始化时实例话 通过一个public的getInstance方法获取对它的引用 ,继而调用其中的方法
    public class Singleton
    {
    private Singleton(){}
    private static Singleton instance = new Singleton();
    public static Singleton getInstance()
    {
    return instance;   }
    }

    第二种形式:
    public class Singleton {
    private static Singleton instance = null;
    public static synchronized Singleton getInstance() { 
    if (instance==null) 
    instance=new Singleton();
    return instance;   
    }
    }
    其他形式: 定义一个类,它的构造函数为private的,所有方法为static的。一般认为第一种形式要更加安全些

    49、Java的接口和C++的虚类的相同和不同处。

    C++的纯虚类
    由于Java不支持多继承,而有可能某个类或对象要使用分别在几个类或对象里面的方法或属性,现有的单继承机制就不能满足要求。与继承相比,接口有更高的灵活性,因为接口中没有任何实现代码。当一个类实现了接口以后,该类要实现接口里面所有的方法和属性,并且接口里面的属性在默认状态下面都是public static,所有方法默认情况下是public.一个类可以实现多个接口。

    C++的虚类,纯虚类
    纯虚类就像是接口,可以多重继承
    虚类只是声明

    #include
    //father class
    class Virtualbase
    {
    public:
    virtual void Demon()= 0;
    virtual void Base() {cout<<"this is farther class"<};
    }

    //sub class
    class SubVirtual : public Virtualbase
    {
    public:
    void Demon() { cout<<" this is SubVirtual!"< }
    void Base() {
    cout<<"this is subclass Base"<};

    void main()
    {
    Virtualbase* inst = new SubVirtual(); //multstate pointer
    inst->Demon();
    inst->Base();
    // inst = new Virtualbase();
    // inst->Base()
    return ;
    }

    51、垃圾回收的优点和原理。并考虑2种回收机制

    Java语言中一个显著的特点就是引入了垃圾回收机制,使c++程序员最头疼的内存管理的问题迎刃而解,它使得Java程序员在编写程序的时候不再需要考虑内存管理。由于有个垃圾回收机制,Java中的对象不再有“作用域”的概念,只有对象的引用才有“作用域”。垃圾回收可以有效的防止内存泄露,有效的使用可以使用的内存。垃圾回收器通常是作为一个单独的低级别的线程运行,不可预知的情况下对内存堆中已经死亡的或者长时间没有使用的对象进行清楚和回收,程序员不能实时的调用垃圾回收器对某个对象或所有对象进行垃圾回收。回收机制有分代复制垃圾回收和标记垃圾回收,增量垃圾回收

    52、请说出你所知道的线程同步的方法。

    wait():使一个线程处于等待状态,并且释放所持有的对象的lock。sleep():使一个正在运行的线程处于睡眠状态,是一个静态方法,调用此方法要捕捉InterruptedException异常。notify():唤醒一个处于等待状态的线程,注意的是在调用此方法的时候,并不能确切的唤醒某一个等待状态的线程,而是由JVM确定唤醒哪个线程,而且不是按优先级。Allnotity():唤醒所有处入等待状态的线程,注意并不是给所有唤醒线程一个对象的锁,而是让它们竞争。

    53、你所知道的集合类都有哪些?主要方法?

    最常用的集合类是 List 和 Map。 List 的具体实现包括 ArrayList 和 Vector,它们是可变大小的列表,比较适合构建、存储和操作任何类型对象的元素列表。 List 适用于按数值索引访问元素的情形。 Map 提供了一个更通用的元素存储方法。 Map 集合类用于存储元素对(称作“键”和“值”),其中每个键映射到一个值。

    54、描述一下JVM加载class文件的原理机制?

    JVM中类的装载是由ClassLoader和它的子类来实现的,Java ClassLoader 是一个重要的Java运行时系统组件。它负责在运行时查找和装入类文件的类.

    55、char型变量中能不能存贮一个中文汉字?为什么?

    能够定义成为一个中文的,因为java中以unicode编码,一个char占16个字节,所以放一个中文是没问题的
    可能的解释为一个中文占16位,两个字节

    56、多线程有几种实现方法,都是什么?同步有几种实现方法,都是什么?

    多线程有两种实现方法,分别是继承Thread类与实现Runnable接口 ,同步的实现方面有两种,分别是synchronized,wait与notify

    57、JSP的内置对象及方法

    applicaton 表示一个javax.servle.ServletContext对象。这有助于查找有关servlet引擎和servlet环境的信息
    pageContext 表示一个javax.servlet.jsp.PageContext对象。它是用于方便存取髦址段У拿?挚占洹?ervlet相关的对象的API,并且包装了通用的servlet相关功能的方法
    page表示从该页面产生的一个servlet实例
    config表示一个javax.servlet.ServletConfig对象。该对象用于存取servlet实例的初始化参数

    request表示HttpServletRequest对象。它包含了有关浏览器请求的信息,并且提供了几个用于获取cookie, header, 和session数据的有用的方法response
    response表示HttpServletResponse对象,并提供了几个用于设置送回浏览器的响应的方法(如cookies,头信息等)
    out对象是javax.jsp.JspWriter的一个实例,并提供了几个方法使你能用于向浏览器回送输出结果
    session表示一个请求的javax.servlet.http.HttpSession对象。Session可以存贮用户的状态信息

    58、线程的基本概念、线程的基本状态以及状态之间的关系

    线程指在程序执行过程中,能够执行程序代码的一个执行单位,每个程序至少都有一个线程,也就是程序本身。Java中的线程有四种状态分别是:就绪,运行、、挂起、结束。

    59、JSP的常用指令

    <%@page language=”java” contenType=”text/html;charset=gb2312” session=”true” buffer=”64kb” autoFlush=”true” isThreadSafe=”true” info=”text” errorPage=”error.jsp” isErrorPage=”true” isELIgnored=”true” pageEncoding=”gb2312” import=”java.sql.*”%>isErrorPage(是否能使用Exception对象),isELIgnored(是否忽略表达式) <%@include file=”filename”%><%@taglib prefix=”c”uri=”http://……”%>

    60、什么情况下调用doGet()和doPost()?

    Jsp页面中的form标签里的method属性为get时调用doGet(),为post时调用doPost()。

    61、servlet的生命周期

    web容器加载servlet,生命周期开始。通过调用servlet的init()方法进行servlet的初始化。通过调用service()方法实现,根据请求的不同调用不同的do***()方法。结束服务,web容器调用servlet的destroy()方法。

    62、如何现实servlet的单线程模式

    <%@ page isThreadSafe=”false”%>

    63、页面间对象传递的方法

    request,session,application,cookie等

    64、JSP和Servlet有哪些相同点和不同点,他们之间的联系是什么?

    JSP是Servlet技术的扩展,本质上是Servlet的简易方式,更强调应用的外表表达。JSP编译后是"类servlet"。Servlet和JSP最主要的不同点在于,Servlet的应用逻辑是在Java文件中,并且完全从表示层中的HTML里分离开来。而JSP的情况是Java和HTML可以组合成一个扩展名为.jsp的文件。JSP侧重于视图,Servlet主要用于控制逻辑。

    65、四种会话跟踪技术

    cookie,url重写,session,隐藏域

    65,jsp的四种范围

    page代表与一个页面相关的对象和属性。一个页面由一个编译好的 Java servlet 类(可以带有任何的 include 指令,但是没有 include 动作)表示。这既包括 servlet 又包括被编译成 servlet 的 JSP 页面
    request是是代表与 Web 客户机发出的一个请求相关的对象和属性。一个请求可能跨越多个页面,涉及多个 Web 组件(由于 forward 指令和 include 动作的关系)
    session是是代表与用于某个 Web 客户机的一个用户体验相关的对象和属性。一个 Web 会话可以也经常会跨越多个客户机请求
    application是是代表与整个 Web 应用程序相关的对象和属性。这实质上是跨越整个 Web 应用程序,包括多个页面、请求和会话的一个全局作用域

    66、Request对象的主要方法:

    setAttribute(String name,Object):设置名字为name的request的参数值
    getAttribute(String name):返回由name指定的属性值
    getAttributeNames():返回request对象所有属性的名字集合,结果是一个枚举的实例
    getCookies():返回客户端的所有Cookie对象,结果是一个Cookie数组
    getCharacterEncoding():返回请求中的字符编码方式
    getContentLength():返回请求的Body的长度
    getHeader(String name):获得HTTP协议定义的文件头信息
    getHeaders(String name):返回指定名字的request Header的所有值,结果是一个枚举的实例
    getHeaderNames():返回所以request Header的名字,结果是一个枚举的实例
    getInputStream():返回请求的输入流,用于获得请求中的数据
    getMethod():获得客户端向服务器端传送数据的方法
    getParameter(String name):获得客户端传送给服务器端的有name指定的参数值
    getParameterNames():获得客户端传送给服务器端的所有参数的名字,结果是一个枚举的实例
    getParameterValues(String name):获得有name指定的参数的所有值
    getProtocol():获取客户端向服务器端传送数据所依据的协议名称
    getQueryString():获得查询字符串
    getRequestURI():获取发出请求字符串的客户端地址
    getRemoteAddr():获取客户端的IP地址
    getRemoteHost():获取客户端的名字
    getSession([Boolean create]):返回和请求相关Session
    getServerName():获取服务器的名字
    getServletPath():获取客户端所请求的脚本文件的路径
    getServerPort():获取服务器的端口号
    removeAttribute(String name):删除请求中的一个属性
    ygahgjxx (2006-7-01 09:18:33)
    67、J2EE是技术还是平台还是框架?

    J2EE本身是一个标准,一个为企业分布式应用的开发提供的标准平台。
    J2EE也是一个框架,包括JDBC、JNDI、RMI、JMS、EJB、JTA等技术。

    68、我们在web应用开发过程中经常遇到输出某种编码的字符,如iso8859-1等,如何输出一个某种编码的字符串?

    Public String translate (String str) { String tempStr = ""; try { tempStr = new String(str.getBytes("ISO-8859-1"), "GBK"); tempStr = tempStr.trim(); } catch (Exception e) { System.err.println(e.getMessage()); } return tempStr; }

    69、简述逻辑操作(&,|,^)与条件操作(&&,||)的区别。

    区别主要答两点:a.条件操作只能操作布尔型的,而逻辑操作不仅可以操作布尔型,而且可以操作数值型b.逻辑操作不会产生短路

    70、XML文档定义有几种形式?它们之间有何本质区别?解析XML文档有哪几种方式?

    a: 两种形式 dtd schema,
    b: 本质区别:schema本身是xml的,可以被XML解析器解析(这也是从DTD上发展schema的根本目的)
    c:有DOM,SAX,STAX等 DOM:处理大型文件时其性能下降的非常厉害。这个问题是由DOM的树结构所造成的,
    这种结构占用的内存较多,而且DOM必须在解析文件之前把整个文档装入内存,适合对XML的随机访问
    SAX:不现于DOM,SAX是事件驱动型的XML解析方式。它顺序读取XML文件,不需要一次全部装载整个文件。
    当遇到像文件开头,文档结束,或者标签开头与标签结束时,它会触发一个事件.
    用户通过在其回调事件中写入处理代码来处理XML文件,适合对XML的顺序访问 STAX:Streaming API for XML (StAX)

    71、简述synchronized和java.util.concurrent.locks.Lock的异同?

    主要相同点:Lock能完成synchronized所实现的所有功能主要不同点:Lock有比synchronized更精确的线程语义和更好的性能。synchronized会自动释放锁,而Lock一定要求程序员手工释放,并且必须在finally从句中释放。

    72、EJB的角色和三个对象

    一个完整的基于EJB的分布式计算结构由六个角色组成,这六个角色可以由不同的开发商提供,每个角色所作的工作必须遵循Sun公司提供的EJB规范,以保证彼此之间的兼容性。这六个角色分别是EJB组件开发者(Enterprise Bean Provider) 、应用组合者(Application Assembler)、部署者(Deployer)、EJB 服务器提供者(EJB Server Provider)、EJB 容器提供者(EJB Container Provider)、系统管理员(System Administrator)三个对象是Remote(Local)接口、Home(LocalHome)接口,Bean类

    73、EJB容器提供的服务

    主要提供声明周期管理、代码产生、持续性管理、安全、事务管理、锁和并发行管理等服务。

    74、EJB规范规定EJB中禁止的操作有哪些?

    1.不能操作线程和线程API(线程API指非线程对象的方法如notify,wait等),2.不能操作awt,3.不能实现服务器功能,4.不能对静态属生存取,5.不能使用IO操作直接存取文件系统,6.不能加载本地库.,7.不能将this作为变量和返回,8.不能循环调用。
    ygahgjxx (2006-7-01 09:18:43)
    75、remote接口和home接口主要作用

    remote接口定义了业务方法,用于EJB客户端调用业务方法。home接口是EJB工厂用于创建和移除查找EJB实例

    76、bean 实例的生命周期

    对于Stateless Session Bean、Entity Bean、Message Driven Bean一般存在缓冲池管理,而对于Entity Bean和Statefull Session Bean存在Cache管理,通常包含创建实例,设置上下文、创建EJB Object(create)、业务方法调用、remove等过程
    对于存在缓冲池管理的Bean,在create之后实例并不从内存清除,而是采用缓冲池调度机制不断重用实例,而对于存在Cache管理的Bean则通过激活和去激活机制保持Bean的状态并限制内存中实例数量。


    77、EJB的激活机制

    以Stateful Session Bean 为例:其Cache大小决定了内存中可以同时存在的Bean实例的数量,根据MRU或NRU算法,实例在激活和去激活状态之间迁移,激活机制是当客户端调用某个EJB实例业务方法时,如果对应EJB Object发现自己没有绑定对应的Bean实例则从其去激活Bean存储中(通过序列化机制存储实例)回复(激活)此实例。状态变迁前会调用对应的ejbActive和ejbPassivate方法。

    78、EJB的几种类型

    会话(Session)Bean ,实体(Entity)Bean 消息驱动的(Message Driven)Bean ;会话Bean又可分为有状态(Stateful)和无状态(Stateless)两种;实体Bean可分为Bean管理的持续性(BMP)和容器管理的持续性(CMP)两种

    79、客服端调用EJB对象的几个基本步骤

    设置JNDI服务工厂以及JNDI服务地址系统属性,查找Home接口,从Home接口调用Create方法创建Remote接口,通过Remote接口调用其业务方法。

    80、如何给weblogic指定大小的内存?

    在启动Weblogic的脚本中(位于所在Domian对应服务器目录下的startServerName),增加set MEM_ARGS=-Xms32m -Xmx200m,可以调整最小内存为32M,最大200M

     

  • 程序员面试之葵花宝典(上)

    2008-08-08 09:15:35

    程序员面试之葵花宝典(上)

    1、面向对象的特征有哪些方面?

    1. 抽象:抽象就是忽略一个主题中与当前目标无关的那些方面,以便更充分地注意与当前目标有关的方面。抽象并不打算了解全部问题,而只是选择其中的一部分,暂时不用部分细节。抽象包括两个方面,一是过程抽象,二是数据抽象。

    2. 继承:继承是一种联结类的层次模型,并且允许和鼓励类的重用,它提供了一种明确表述共性的方法。对象的一个新类可以从现有的类中派生,这个过程称为类继承。新类继承了原始类的特性,新类称为原始类的派生类(子类),而原始类称为新类的基类(父类)。派生类可以从它的基类那里继承方法和实例变量,并且类可以修改或增加新的方法使之更适合特殊的需要。

    3. 封装:封装是把过程和数据包围起来,对数据的访问只能通过已定义的界面。面向对象计算始于这个基本概念,即现实世界可以被描绘成一系列完全自治、封装的对象,这些对象通过一个受保护的接口访问其他对象。

    4. 多态性:多态性是指允许不同类的对象对同一消息作出响应。多态性包括参数化多态性和包含多态性。多态性语言具有灵活、抽象、行为共享、代码共享的优势,很好的解决了应用程序函数同名问题。

    2、String是最基本的数据类型吗?

    基本数据类型包括byte、int、char、long、float、double、boolean和short。
    java.lang.String类是final类型的,因此不可以继承这个类、不能修改这个类。为了提高效率节省空间,我们应该用StringBuffer类。

    3、int 和 Integer 有什么区别。

    Java 提供两种不同的类型:引用类型和原始类型(或内置类型)。Int是java的原始数据类型,Integer是java为int提供的封装类。Java为每个原始类型提供了封装类。
    原始类型封装类booleanBoolean charCharacter byteByte shortShort intInteger longLong floatFloat doubleDouble
    引用类型和原始类型的行为完全不同,并且它们具有不同的语义。引用类型和原始类型具有不同的特征和用法,它们包括:大小和速度问题,这种类型以哪种类型的数据结构存储,当引用类型和原始类型用作某个类的实例数据时所指定的缺省值。对象引用实例变量的缺省值为 null,而原始类型实例变量的缺省值与它们的类型有关。

    4、String 和StringBuffer的区别。

    JAVA平台提供了两个类:String和StringBuffer,它们可以储存和操作字符串,即包含多个字符的字符数据。这个String类提供了数值不可改变的字符串。而这个StringBuffer类提供的字符串进行修改。当你知道字符数据要改变的时候你就可以使用StringBuffer。典型地,你可以使用StringBuffers来动态构造字符数据。

    5、运行时异常与一般异常有何异同?

    异常表示程序运行过程中可能出现的非正常状态,运行时异常表示虚拟机的通常操作中可能遇到的异常,是一种常见运行错误。java编译器要求方法必须声明抛出可能发生的非运行时异常,但是并不要求必须声明抛出未被捕获的运行时异常。

    6、说出Servlet的生命周期,并说出Servlet和CGI的区别。

    Servlet被服务器实例化后,容器运行其init方法,请求到达时运行其service方法,service方法自动派遣运行与请求对应的doXXX方法(doGet,doPost)等,当服务器决定将实例销毁的时候调用其destroy方法。
    与cgi的区别在于servlet处于服务器进程中,它通过多线程方式运行其service方法,一个实例可以服务于多个请求,并且其实例一般不会销毁,而CGI对每个请求都产生新的进程,服务完成后就销毁,所以效率上低于servlet。

    7、说出ArrayList,Vector, LinkedList的存储性能和特性。

    ArrayList和Vector都是使用数组方式存储数据,此数组元素数大于实际存储的数据以便增加和插入元素,它们都允许直接按序号索引元素,但是插入元素要涉及数组元素移动等内存操作,所以索引数据快而插入数据慢,Vector由于使用了synchronized方法(线程安全),通常性能上较ArrayList差,而LinkedList使用双向链表实现存储,按序号索引数据需要进行前向或后向遍历,但是插入数据时只需要记录本项的前后项即可,所以插入速度较快。

    8、EJB是基于哪些技术实现的?并说出SessionBean和EntityBean的区别,StatefulBean和Stateles我白痴ean的区别。

    EJB包括Session Bean、Entity Bean、Message Driven Bean,基于JNDI、RMI、JAT等技术实现。
    SessionBean在J2EE应用程序中被用来完成一些服务器端的业务操作,例如访问数据库、调用其他EJB组件。EntityBean被用来代表应用系统中用到的数据。
    对于客户机,SessionBean是一种非持久性对象,它实现某些在服务器上运行的业务逻辑。
    对于客户机,EntityBean是一种持久性对象,它代表一个存储在持久性存储器中的实体的对象视图,或是一个由现有企业应用程序实现的实体。
    Session Bean 还可以再细分为 Stateful Session Bean 与 Stateless Session Bean ,这两种的 Session Bean都可以将系统逻辑放在 method之中执行,不同的是 Stateful Session Bean 可以记录呼叫者的状态,因此通常来说,一个使用者会有一个相对应的 Stateful Session Bean 的实体。Stateless Session Bean 虽然也是逻辑组件,但是他却不负责记录使用者状态,也就是说当使用者呼叫 Stateless Session Bean 的时候,EJB Container 并不会找寻特定的 Stateless Session Bean 的实体来执行这个 method。换言之,很可能数个使用者在执行某个 Stateless Session Bean 的 methods 时,会是同一个 Bean 的 Instance 在执行。从内存方面来看, Stateful Session Bean 与 Stateless Session Bean 比较, Stateful Session Bean 会消耗 J2EE Server 较多的内存,然而 Stateful Session Bean 的优势却在于他可以维持使用者的状态。

    9、Collection 和 Collections的区别。 Collection是集合类的上级接口,继承与他的接口主要有Set 和List.

    Collections是针对集合类的一个帮助类,他提供一系列静态方法实现对各种集合的搜索、排序、线程安全化等操作。

    10、&和&&的区别。

    &是位运算符,表示按位与运算,&&是逻辑运算符,表示逻辑与(and)。

    11、HashMap和Hashtable的区别。

    HashMap是Hashtable的轻量级实现(非线程安全的实现),他们都完成了Map接口,主要区别在于HashMap允许空(null)键值(key),由于非线程安全,效率上可能高于Hashtable。
    HashMap允许将null作为一个entry的key或者value,而Hashtable不允许。
    HashMap把Hashtable的contains方法去掉了,改成containsvalue和containsKey。因为contains方法容易让人引起误解。 Hashtable继承自Dictionary类,而HashMap是Java1.2引进的Map interface的一个实现。
    最大的不同是,Hashtable的方法是Synchronize的,而HashMap不是,在多个线程访问Hashtable时,不需要自己为它的方法实现同步,而HashMap 就必须为之提供外同步。
    Hashtable和HashMap采用的hash/rehash算法都大概一样,所以性能不会有很大的差异。

    12、final, finally, finalize的区别。

    final 用于声明属性,方法和类,分别表示属性不可变,方法不可覆盖,类不可继承。finally是异常处理语句结构的一部分,表示总是执行。finalize是Object类的一个方法,在垃圾收集器执行的时候会调用被回收对象的此方法,可以覆盖此方法提供垃圾收集时的其他资源回收,例如关闭文件等。

    13、sleep() 和 wait() 有什么区别?

    sleep是线程类(Thread)的方法,导致此线程暂停执行指定时间,给执行机会给其他线程,但是监控状态依然保持,到时后会自动恢复。调用sleep不会释放对象锁。wait是Object类的方法,对此对象调用wait方法导致本线程放弃对象锁,进入等待此对象的等待锁定池,只有针对此对象发出notify方法(或notifyAll)后本线程才进入对象锁定池准备获得对象锁进入运行状态。

    14、Overload和Override的区别。Overloaded的方法是否可以改变返回值的类型?

    方法的重写Overriding和重载Overloading是Java多态性的不同表现。重写Overriding是父类与子类之间多态性的一种表现,重载Overloading是一个类中多态性的一种表现。如果在子类中定义某方法与其父类有相同的名称和参数,我们说该方法被重写 (Overriding)。子类的对象使用这个方法时,将调用子类中的定义,对它而言,父类中的定义如同被“屏蔽”了。如果在一个类中定义了多个同名的方法,它们或有不同的参数个数或有不同的参数类型,则称为方法的重载(Overloading)。Overloaded的方法是可以改变返回值的类型。

    15、error和exception有什么区别?

    error 表示恢复不是不可能但很困难的情况下的一种严重问题。比如说内存溢出。不可能指望程序能处理这样的情况。
    exception 表示一种设计或实现问题。也就是说,它表示如果程序运行正常,从不会发生的情况。

    16、同步和异步有何异同,在什么情况下分别使用他们?举例说明。

    如果数据将在线程间共享。例如正在写的数据以后可能被另一个线程读到,或者正在读的数据可能已经被另一个线程写过了,那么这些数据就是共享数据,必须进行同步存取。当应用程序在对象上调用了一个需要花费很长时间来执行的方法,并且不希望让程序等待方法的返回时,就应该使用异步编程,在很多情况下采用异步途径往往更有效率。

    17、abstract class和interface有什么区别?

    声明方法的存在而不去实现它的类被叫做抽象类(abstract class),它用于要创建一个体现某些基本行为的类,并为该类声明方法,但不能在该类中实现该类的情况。不能创建abstract 类的实例。然而可以创建一个变量,其类型是一个抽象类,并让它指向具体子类的一个实例。不能有抽象构造函数或抽象静态方法。Abstract 类的子类为它们父类中的所有抽象方法提供实现,否则它们也是抽象类为。取而代之,在子类中实现该方法。知道其行为的其它类可以在类中实现这些方法。接口(interface)是抽象类的变体。
    在接口中,所有方法都是抽象的。多继承性可通过实现这样的接口而获得。接口中的所有方法都是抽象的,没有一个有程序体。接口只可以定义static final成员变量。接口的实现与子类相似,除了该实现类不能从接口定义中继承行为。当类实现特殊接口时,它定义(即将程序体给予)所有这种接口的方法。然后,它可以在实现了该接口的类的任何对象上调用接口的方法。由于有抽象类,它允许使用接口名作为引用变量的类型。通常的动态联编将生效。引用可以转换到接口类型或从接口类型转换,instanceof 运算符可以用来决定某对象的类是否实现了接口。

    18、heap和stack有什么区别。

    栈是一种线形集合,其添加和删除元素的操作应在同一段完成。栈按照后进先出的方式进行处理。堆是栈的一个组成元素。

    19、forward 和redirect的区别。

    forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来,然后把这些内容再发给浏览器,浏览器根本不知道服务器发送的内容是从哪儿来的,所以它的地址栏中还是原来的地址。 redirect就是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址,一般来说浏览器会用刚才请求的所有参数重新请求,所以session,request参数都可以获取。

    20、EJB与JAVA BEAN的区别?

    Java Bean 是可复用的组件,对Java Bean并没有严格的规范,理论上讲,任何一个Java类都可以是一个Bean。但通常情况下,由于Java Bean是被容器所创建(如Tomcat)的,所以Java Bean应具有一个无参的构造器,另外,通常Java Bean还要实现Serializable接口用于实现Bean的持久性。Java Bean实际上相当于微软COM模型中的本地进程内COM组件,它是不能被跨进程访问的。Enterprise Java Bean 相当于DCOM,即分布式组件。它是基于Java的远程方法调用(RMI)技术的,所以EJB可以被远程访问(跨进程、跨计算机)。但EJB必须被布署在诸如Webspere、WebLogic这样的容器中,EJB客户从不直接访问真正的EJB组件,而是通过其容器访问。EJB容器是EJB组件的代理,EJB组件由容器所创建和管理。客户通过容器来访问真正的EJB组件。

    21、Static Nested Class 和 Inner Class的不同。

    Static Nested Class是被声明为静态(static)的内部类,它可以不依赖于外部类实例被实例化。而通常的内部类需要在外部类实例化后才能实例化。

    22、JSP中动态INCLUDE与静态INCLUDE的区别?

    动态INCLUDE用jsp:include动作实现 <jsp:include page="included.jsp" flush="true" />它总是会检查所含文件中的变化,适合用于包含动态页面,并且可以带参数。静态INCLUDE用include伪码实现,定不会检查所含文件的变化,适用于包含静态页面<%@ include file="included.htm" %>
    23、什么时候用assert。

    assertion(断言)在软件开发中是一种常用的调试方式,很多开发语言中都支持这种机制。在实现中,assertion就是在程序中的一条语句,它对一个boolean表达式进行检查,一个正确程序必须保证这个boolean表达式的值为true;如果该值为false,说明程序已经处于不正确的状态下,系统将给出警告或退出。一般来说,assertion用于保证程序最基本、关键的正确性。assertion检查通常在开发和测试时开启。为了提高性能,在软件发布后,assertion检查通常是关闭的。

    24、GC是什么? 为什么要有GC?

    GC是垃圾收集的意思(Gabage Collection),内存处理是编程人员容易出现问题的地方,忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃,Java提供的GC功能可以自动监测对象是否超过作用域从而达到自动回收内存的目的,Java语言没有提供释放已分配内存的显示操作方法。

    25、short s1 = 1; s1 = s1 + 1;有什么错? short s1 = 1; s1 += 1;有什么错?

    short s1 = 1; s1 = s1 + 1; (s1+1运算结果是int型,需要强制转换类型,这样子才可以正确的编译) short s1 = 1; s1 += 1;(可以正确编译)

    26、Math.round(11.5)等於多少? Math.round(-11.5)等於多少?

    Math.round(11.5)==12 Math.round(-11.5)==-11 round方法返回与参数最接近的长整数,参数加1/2后求其floor.

    27、String s = new String("xyz");创建了几个String Object?

    两个
    一个是”xyz”,一个是s对”xyz”的引用

    28、设计4个线程,其中两个线程每次对j增加1,另外两个线程对j每次减少1。写出程序。

    以下程序使用内部类实现线程,对j增减的时候没有考虑顺序问题。
    public class ThreadTest1 {
    private int j;
    public static void main(String args[])
    {
    ThreadTest1 tt=new ThreadTest1();
    Inc inc=tt.new Inc();
    Dec dec=tt.new Dec();

    for(int i=0;i<2;i++){
    Thread t=new Thread(inc);
    t.start();
    t=new Thread(dec);
    t.start(); } }

    private synchronized void inc(){ j++; System.out.println(Thread.currentThread().getName()+"-inc:"+j); }
    private synchronized void dec(){ j--; System.out.println(Thread.currentThread().getName()+"-dec:"+j); }

    class Inc implements Runnable{
    public void run(){
    for(int i=0;i<100;i++){
    inc(); }
    }
    }
    class Dec implements Runnable{public void run(){ for(int i=0;i<100;i++){ dec(); }
    }
    }
    }

    29、Java有没有goto?

    java中的保留字,现在没有在java中使用。

    30、启动一个线程是用run()还是start()?

    启动一个线程是调用start()方法,使线程所代表的虚拟处理机处于可运行状态,这意味着它可以由JVM调度并执行。这并不意味着线程就会立即运行。run()方法可以产生必须退出的标志来停止一个线程。
    ygahgjxx (2006-7-01 09:17:23)
    31、EJB包括(SessionBean,EntityBean)说出他们的生命周期,及如何管理事务的?

    SessionBean:Stateless Session Bean 的生命周期是由容器决定的,当客户机发出请求要建立一个Bean的实例时,EJB容器不一定要创建一个新的Bean的实例供客户机调用,而是随便找一个现有的实例提供给客户机。当客户机第一次调用一个Stateful Session Bean 时,容器必须立即在服务器中创建一个新的Bean实例,并关联到客户机上,以后此客户机调用Stateful Session Bean 的方法时容器会把调用分派到与此客户机相关联的Bean实例
    EntityBean:Entity Beans能存活相对较长的时间,并且状态是持续的。只要数据库中的数据存在,Entity beans就一直存活。而不是按照应用程序或者服务进程来说的。即使EJB容器崩溃了,Entity beans也是存活的。Entity Beans生命周期能够被容器或者 Beans自己管理。EJB通过以下技术管理实务:对象管理组织(OMG)的对象实务服务(OTS),Sun Microsystems的Transaction Service(JTS)、Java Transaction API(JTA),开发组(X/Open)的XA接口。
    32、应用服务器有那些?

    BEA WebLogic Server,IBM WebSphere Application Server,Oracle9i Application Server,jBoss,Tomcat
    ygahgjxx (2006-7-01 09:17:44)
    34、接口是否可继承接口? 抽象类是否可实现(implements)接口? 抽象类是否可继承实体类(concrete class)?

    接口可以继承接口。抽象类可以实现(implements)接口,抽象类是否可继承实体类,但前提是实体类必须有明确的构造函数。

    35、List, Set, Map是否继承自Collection接口?

    List,Set是,Map不是

    36、说出数据连接池的工作机制是什么?

    J2EE服务器启动时会建立一定数量的池连接,并一直维持不少于此数目的池连接。客户端程序需要连接时
    池驱动程序会返回一个未使用的池连接并将其表记为忙。如果当前没有空闲连接,池驱动程序就新建一定数量的连接,新建连接的数量有配置参数决定。
    当使用的池连接调用完成后,池驱动程序将此连接表记为空闲,其他调用就可以使用这个连接。

    37、abstract的method是否可同时是static,是否可同时是native,是否可同时是synchronized?

    都不能
    native:这个修饰符修饰的类或者方法,表示里边的代码不是用纯JAVA编写,有可能用C或者C++,这些方法及类可以调用,但JAVA中看不到代码.

    38.数组有没有length()这个方法? String有没有length()这个方法?

    数组没有length()这个方法,有length的属性。String有length()这个方法

    39、Set里的元素是不能重复的,那么用什么方法来区分重复与否呢? 是用==还是equals()? 它们有何区别?

    Set里的元素是不能重复的,那么用iterator()方法来区分重复与否。equals()是判读两个Set是否相等。equals()和==方法决定引用值是否指向同一对象equals()在类中被覆盖,为的是当两个分离的对象的内容和类型相配的话,返回真值。

    40、构造器Constructor是否可被override?

    构造器Constructor不能被继承,因此不能重写Overriding,但可以被重载Overloading。

     

  • 很全面的界面测试总结(转载)

    2008-08-06 12:13:49

    [转] 界面测试总结

        界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够,直到最近网页制作的兴起,才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。

      目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。

    一。易用性:

      按钮名称应该易懂,用词准确,屏弃没楞两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

        易用性细则:

        1) 完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。

        2) 完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。

        3) 按功能将界面划分区域块,用Frame框括起来,并要有功能说明或标题。

        4) 界面要支持键盘自动浏览按钮功能,即按Tab键、回車鍵的自动切换功能。

        5) 界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。

        6) 同一界面上的控件数最好不要超过10个,多于10个时可以考虑使用分页界面显示。

        7) 分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab

        8) 默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作。

        9) 可写控件检测到非法输入后应给出说明并能自动获得焦点。

        10) Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式。

        11) 复选框和选项框按选择几率的高底而先后排列。

        12) 复选框和选项框要有默认选项,并支持Tab选择。

        13) 选项数相同时多用选项框而不用下拉列表框。

        14) 界面空间较小时使用下拉框而不用选项框。

        15) 选项数叫少时使用选项框,相反使用下拉列表框。

        16) 专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词眼。

    二。规范性:

        通常界面设计都按Windows界面的规范来设计,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工具厢。

        规范性细则:

        1) 常用菜单要有命令快捷方式。

        2) 完成相同或相近功能的菜单用横线隔开放在同一位置。

        3) 菜单前的图标能直观的代表要完成的操作。

        4) 菜单深度一般要求最多控制在三层以内。

        5) 工具栏要求可以根据用户的要求自己选择定制。

        6) 相同或相近功能的工具栏放在一起。

        7) 工具栏中的每一个按钮要有及时提示信息。

        8) 一条工具栏的长度最长不能超出屏幕宽度。

        9) 工具栏的图标能直观的代表要完成的操作。

        10) 系统常用的工具栏设置默认放置位置。

        11) 工具栏太多时可以考虑使用工具箱。

        12) 工具箱要具有可增减性,由用户自己根据需求定制。

        13) 工具箱的默认总宽度不要超过屏幕宽度的1/5。

        14) 状态条要能显示用户切实需要的信息,常用的有:目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,如果某一操作需要的时间较长,还应该显示进度条和进程提示。

        15) 滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。

        16) 状态条的高度以放置五好字为宜,滚动条的宽度比状态条的略窄。

        17) 菜单和工具条要有清楚的界限;菜单要求凸出显示,这样在移走工具条时仍有立体感。

        18) 菜单和状态条中通常使用5号字体。工具条一般比菜单要宽,但不要宽的太多,否则看起来很不协调。

        19) 右键快捷菜单采用与菜单相同的准则。

    三。帮助

      系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。

        帮助设施细则:

        1) 帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明,让人困惑)。

        2) 打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。

        3) 操作时要提供及时调用系统帮助的功能。常用F1。

        4) 在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。

        5) 最好提供目前流行的联机帮助格式或HTML帮助格式。

        6) 用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。

        7) 如果没有提供书面的帮助文档的话,最好有打印帮助的功能。

        8) 在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。

    四。合理性:

        屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。

        合理性细则:

        1) 父窗体或主窗体的中心位置应该在对角线焦点附近。

        2) 子窗体位置应该在主窗体的左上角或正中。

        3) 多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。

        4) 重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。

        5) 错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。

        6) 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。

        7) 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。

        8) 非法的输入或操作应有足够的提示说明。

        9) 对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。

        10) 提示、警告、或错误说明应该清楚、明了、恰当。

    五。美观与协调性:

        界面应该大小适合美学观点,感觉协调舒适,能在有效的范围内吸引用户的注意力。

        美观与协调性细则:

        1) 长宽接近黄金点比例,切忌长宽比例失调、或宽度超过长度。

        2) 布局要合理,不宜过于密集,也不能过于空旷,合理的利用空间。

        3) 按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置。

        4) 按钮的大小要与界面的大小和空间要协调。

        5) 避免空旷的界面上放置很大的按钮。

        6) 放置完控件后界面不应有很大的空缺位置。

        7) 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观,很少使用超过12号的字体。

        8) 前景与背景色搭配合理协调,反差不宜太大,最好少用深色,如大红、大绿等。常用色考虑使用Windows界面色调。

        9) 如果使用其他颜色,主色调要柔和,具有亲和力与磁力,坚决杜绝刺目的颜色。

        10) 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。

        11) 界面风格要保持一致,字的大小、颜色、字体要相同,除非是需要艺术处理或有特殊要求的地方。

        12) 如果窗体支持最小化和最大化或放大时,窗体上的控件也要随着窗体而缩放;切忌只放大窗体而忽略控件的缩放。

        13) 对于含有按钮的界面一般不应该支持缩放,即右上角只有关闭功能。

        14) 通常父窗体支持缩放时,子窗体没有必要缩放。

        15) 如果能给用户提供自定义界面风格则更好,由用户自己选择颜色、字体等。

    六。菜单位置:

        菜单是界面上最重要的元素,菜单位置按照按功能来组织。

        菜单测试细则:

        1) 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列,符合流行的Windows风格。

        2) 常用的有“文件”、“編輯”,“查看”等,幾乎每個系統都有這些選項,當然要根據不同的系統有所取捨。

        3) 下拉菜单要根据菜单选项的含义进行分组,並且按照一定的规则进行排列,用横线隔开。

        4) 一组菜单的使用有先后要求或有向导作用时,应该按先后次序排列。

        5) 没有顺序要求的菜单项按使用频率和重要性排列,常用的放在开头, 不常用的靠后放置;重要的放在开头,次要的放在后边。

        6) 如果菜单选项较多,应该采用加长菜单的长度而减少深度的原则排列。

        7) 菜单深度一般要求最多控制在三层以内。

        8) 对常用的菜单要有快捷命令方式,组合原则见8。

        9) 对与进行的操作无关的菜单要用屏蔽的方式加以处理,如果采用动态加载方式——即只有需要的菜单才显示——最好。

        10) 菜单前的图标不宜太大,与字高保持一直最好。

        11) 主菜单的宽度要接近,字数不应多于四个,每个菜单的字数能相同最好。

        12) 主菜单数目不应太多,最好为单排布置。

        13) 菜单条是否显示在合适的语境中?

        14) 应用程序的菜单条是否显示系统相关的特性(如时钟显示)?

        15) 下拉式操作能正确工作吗?

        16) 菜单、调色板和工具条是否工作正确?

        17) 是否适当地列出了所有的菜单功能和下拉式子功能?

        18) 是否可能通过鼠标访问所有的菜单功能?

        19) 相同功能按钮的图标和文字是否一致?

        20) 是否能够用其他的文本命令激活每个菜单功能?

        21) 菜单功能是否随当前的窗口操作加亮或变灰?

        22) 菜单功能是否正确执行?

        23) 菜单功能的名字是否具有自解释性?

        24) 菜单项是否有帮助,是否语境相关?

        25) 在整个交互式语境中,是否可以识别鼠标操作?

        26) 如果要求多次点击鼠标,是否能够在语境正确识别?

        27) 如果鼠标有多个按钮,是否能够在语境中正确识别?

        28) 光标、处理指示器和识别指针是否随操作恰当地改变? 

          

    七。独特性:

        如果一味的遵循业界的界面标准,则会丧失自己的个性.在框架符合以上规范的情况下,设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。

    测试细则:

        1) 安装界面上应有单位介绍或产品介绍,并有自己的图标。

        2) 主界面,最好是大多数界面上要有公司图标。

        3) 登录界面上要有本产品的标志,同时包含公司图标。

        4) 帮助菜单的“关于”中应有版权和产品信息。

        5) 公司的系列产品要保持一直的界面风格,如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

    八。快捷方式的组合

        在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。

    菜单中:

        1) 面向事务的组合有: Ctrl-D 删除 ;Ctrl-F 寻找 ;Ctrl –H替换;Ctrl-I 插入 ;Ctrl-N 新记录 ;Ctrl-S 保存 Ctrl-O 打开。

        2) 列表: Ctrl-R ,Ctrl-G定位;Ctrl-Tab下一分页窗口或反序浏览同一页面控件。

        3) 编辑:Ctrl-A全选;Ctrl-C 拷贝;Ctrl-V 粘贴;Ctrl-X 剪切;Ctrl-Z撤消操作;Ctrl-Y恢复操作。

        4) 文件操作:Ctrl-P 打印;Ctrl-W 关闭。

        5) 系统菜单Alt-A文件;Alt-E编辑;Alt-T工具;Alt-W窗口;Alt-H帮助。

        6) MS Windows保留键:Ctrl-Esc 任务列表 ;Ctrl-F4 关闭窗口; Alt-F4 结束应用;Alt-Tab 下一应用 ;Enter 缺省按钮/确认操作 ;Esc 取消按钮/取消操作;Shift-F1 上下文相关帮助。按钮中:可以根据系统需要而调节,以下只是常用的组合。Alt-Y确定(是);Alt-C取消;Alt-N 否;Alt-D删除;Alt-Q退出;Alt-A添加;Alt-E编辑;Alt-B浏览;Alt-R读;Alt-W写。

        这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

    九。安全性:

        在界面上通过下列方式来控制出错几率,会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

        安全性细则:

        1) 最重要的是排除可能会使应用非正常中止的错误。

        2) 应当注意尽可能避免用户无意录入无效的数据。

        3) 采用相关控件限制用户输入值的种类。

        4) 当用户作出选择的可能性只有两个时,可以采用单选框。

        5) 当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。

        6) 当选项特别多时,可以采用列表框,下拉式列表框。

        7) 在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。

        8) 对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。

        9) 对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。

        10) 对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。

        11) 对错误操作最好支持可逆性处理,如取消系列操作。

        12) 在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。

        13) 对可能造成等待时间较长的操作应该提供取消功能。

        14) 特殊字符常有;;’”><,`‘:“[”{、\|}]+=)-(_*&&^%$#@!,.。?/还有空格。

        15) 与系统采用的保留字符冲突的要加以限制。

        16) 在读入用户所输入的信息时,根据需要选择是否去掉前后空格。

        17) 有些读入数据库的字段不支持中间有空格,但用户切实需要输入中间空格,这时要在程序中加以处理。

    十。多窗口的应用与系统资源:

        设计良好的软件不仅要有完备的功能,而且要尽可能的占用最底限度的资源。

        1) 在多窗口系统中,有些界面要求必须保持在最顶层,避免用户在打开多个窗口时,不停的切换甚至最小化其他窗口来显示该窗口。

        2) 在主界面载入完毕后自动卸出内存,让出所占用的WINDOWS系统资源。

        3) 关闭所有窗体,系统退出后要释放所占的所有系统资源 ,除非是需要后台运行的系统。

        4) 尽量防止对系统的独占使用。

        5) 窗口能否基于相关的输入或菜单命令适当地打开?

        6) 窗口能否改变大小、移动和滚动?

        7) 窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问?

        8) 当被覆盖并重调用后,窗口能否正确地再生?

        9) 需要时能否使用所有窗口相关的功能?

        10) 所有窗口相关的功能是可操作的吗?

        11) 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用,并适当地显示?

        12) 显示多个窗口时,窗口的名称是否被适当地表示?

        13) 活动窗口是否被适当地加亮?

        14) 如果使用多任务,是否所有的窗口被实时更新?

        15) 多次或不正确按鼠标是否会导致无法预料的副作用?

        16) 窗口的声音和颜色提示和窗口的操作顺序是否符合需求?

        17) 窗口是否正确地关闭?

  • 测试少少积累(积累是一点一点的)20080804

    2008-08-04 15:41:27

    一.遇到的奇怪问题:
    1.在开发人员环境中模拟不到该问题;
    2.将升级包拿到另一个测试环境中可以模拟该问题;
    3.将相同的升级包放到自己的测试环境中也不能模拟该问题;
    结论:该升级包没有问题,只是环境配置没有和开发人员的环境一样,重新安装tomcat和JDK,问题得以解决;

    二.菜单没有显示出来,
    将升级包放到任何一个环境中都看不到该菜单节点,经过自己想到升级之前,是不是哪个文件没有和开发人员更换,
    原来只是配置文件NewArches有个菜单上是否显示出来的区别;(要留心开发人员的升级包是否一致)

    三.数据过滤问题:
    1.条件不满足;
    2.数据过滤出来的信息太多;
    3.数据过滤出来的信息太少;
    4.数据过滤有重复的数据;
    5.参考没有参考数据;
    6.数据唯一性问题;
    7.数据丢失;
    8.数据锁定;(期间结账,财务结账)
    9.删除数据能否再恢复数据;


    三.界面展示问题:
    1.是否用户需要这样的界面;
    2.客户习惯性操作;
    3.逆向思维;(不同的操作,可能引起不同的错误);穷举是不切实际的,只能想好的用例,按照用例来测试;
    4.多层页面操作比较难控制,建议尽量少用;
    5.网络延时;(网络速度慢,页面响应不过来,页面出现错误没有提示,内存或代码溢出;)
    6.缺少字段导致页面出现错误;
    7.页面多一些字段和少一些字段都会信息不完整性;
    8.节点越多分支,测试越困难,出现的错误也越大;
    9.页面显示的信息不对;(刷新问题,程序出错,页面没有跳转)

    四.速度问题:
    1.存储过程引起的速度慢问题;
    2.SQL语句没有优化引起的速度问题;
    3.界面加载的数据量太大,导致速度慢;
    4.另外用户操作出现错误,程序没有处理,导致另外一个用户速度慢;
    5.网络速度慢,数据库优化,电脑配置问题;


    五.错误:
    1.经常出现代码错误,但不影响操作;
    2.错误不可重现,多数原因:环境没有满足得到;
    3.经常出现错误,暂不能解决,会导致用户对软件没有信心;
    4.错误跟踪:最好知道产生该错误的原因,可以在下次操作时想到更好的用例;
    5.给出的错误提示信息不对;
    6.令用户不能再进行操作,只能退出系统重新进入
    7.在同一个测试点,运用不同的测试方法,会发现更多的错误;
    8.要传递的值没有传送到页面上;
    9.输入框没有阻止非法的操作信息;
    10.业务逻辑思维不能满足用户操作;(入库日期大于出库日期,出库数量多于入库数量,
    仓库有数量,但不能录入系统中来,可设置调整单;
    11.内存溢出错误;
    12.自动退出系统;
    13重新进入系统,加载的信息是否正确;
    14.数据库错误,不能连接数据库;
    15.树节点错误,列表错误,


    六.操作:
    1.删除记录,参考是否可以再带出来;
    2.作废单据,系统是怎样操作;
    3.确定,取消操作;
    4.退格键;
    5.价格版本是否执行正确的价格来更新产品价格;
    6.功能是否满足以后扩展;
    7.是否用户方便查询数据,关联报表,关联列表,关联单据明细,生产单号的关联问题;
    8.单据序号的唯一性和连续性;
    9.单据编号的唯一性;客户的单据编号要通用性和可索引性,最好有一定规律;
    10.用户更改或删除基础资料,能否导致业务数据丢失,数据更改,没有逻辑性?
    11.不同用户或工作组,可根据自己的权限,看到自己的数据信息,并且没有冲突和错乱;
    12.报表打印样式是否正确;
    13.IE的常用工具栏和快捷方式,不同IE的测试;
    14.环境配置和测试;
    15.多用户操作,并发操作,性能测试;
    16.每个用户账号对应一个网卡地址;

     

     

     

     

     

  • 测试人员容易遗漏一些隐藏的缺陷

    2008-08-04 14:14:32

    测试人员容易遗漏一些隐藏的缺陷
     
    通常软件测试会暴露软件中的缺陷,经过修正后可以保证软件系统的功能满足需求并正确运行。但是,在系统测试和确认测试中,测试人员容易遗漏一些隐藏的缺陷。众所周知,软件测试不可能发现所有的缺陷,而软件开发周期各个阶段仍然存在注入缺陷的可能,但是,有一些缺陷是测试中容易忽略的,也就是说,通过测试方法和用例可以充分暴露这些缺陷,遗憾的是,它们往往被忽略或者某种原因忘记测试了,这就给软件留下了隐患或者危机。这些容易被忽略的缺陷包括:
      1、安装缺陷

      通常项目组完成代码后,发布时候安装打包是最后一个环节,而软件测试人员通常在测试的时候,没有仔细的测试这一部分,而把用例集中在其他功能上。安装时候的缺陷通常通过拷贝而不是运行安装程序方式给测试人员安装软件,结果正式安装时候出现问题,引起例如控件没有注册,注册表没有导入等。删除时候没有注意安装文件夹是否存在用户文件,造成数据丢失;使用绝对路径;安装顺序没有说明书。

      2、配置文件

      有些文件在ini等配置文件中写出了管理员口令密码等信息,而且是明文的!这是一个安全隐患。另外,有些安装文件的 XML 文件,为了方便在数据库和中间层连接文件中写入了Admin 口令和密码。作为一个合格的软件测试人员,必须检查这些可以用记事本打开的文件。因为,一个稍有常识而且喜欢探索的用户,可能从中获取信息而成为不自觉的黑客。所以,配置文件可能成为软件安全方面的一个缺陷。

      3、网页安全缺陷

      现在网站开发已经注意到:登陆网站进入其内部网页后,直接拷贝网址,然后粘贴到另一IE 窗口输入,可以绕过登陆直接访问。也许商业网站很关注这个问题,但是很多行业软件却很容易忽略。

      网页安全缺陷还可能存在于 IE 弹出的子窗口。有些设计不严格的软件,在主页面关闭的时候子页面还可以运行,这是一个明显的漏洞,而且还大大增加了错误发生的几率。

      4、判断顺序/逻辑缺陷

      对界面进行多个输入判断的时候,非常容易出现这种问题。例如判断年月顺序,判断长度,判断非空等。假如操作员仅仅满足单个条件,保存不能成功;而按界面从上之下顺序一一满足条件之后,保存是没有问题的。但是,改变一下输入的次序,校验失效。例如,一一满足条件之后,不保存,倒过来将上面的输入改成非法输入,然后保存,结果居然也能成功,这是因为原先的判断由于发生过,或者根据语句顺序只检查最后一个判断,所以没有报错。这种错误尤其在 Java scrīpt 脚本的页面中要注意。能够保存不能保证数据正确,有可能引起系统崩溃或者后续数据错误。所以,在测试的时候,不要按照正常的顺序输入,而是要打乱步骤,看看代码是否强健,是否在判断逻辑上没有错误。良好的代码应该经得起折腾,至少保存时会再此全部进行判断,而不只是简简单单走到判断的最后一行。

      5、调试语句和冗余信息

      维护项目和升级改造的推广系统最容易潜伏这类缺陷。典型表现在没有删除或者屏蔽调试语句。弹出一个界面不友好的提示信息,会使不明真相的用户产生误以为系统发生了严重故障,从而引起对软件的不信任感。页面中某个角落存在当前客户不需要的冗余按钮和功能也是一种缺陷。多余的功能会使用户以为是额外附加部分而去使用,其结果可想而知;而多余的按钮会误导好奇心强的用户操作,产生不必要的错误。

      同样值得关注的还有参数设置,由于没有实际数据,开发人员在调试或者单元测试的时候,习惯性的进行自我设定而忘了删除,软件测试人员可能会忽略掉了这部分测试,也可能导致在客户现场发生错误而影响系统发布和验收。

      6、不可重现的故障

      新参加软件测试的人员或者新来的开发人员总是要问,不可重现的缺陷是否需要记录,有必要吗?回答是肯定的。测试必须如实的记录发生的问题,也许不能重现,或者使非软件系统本身问题,但是,可能这些偶然性背后是有规律的,不记录这些,就不可能发现这些规律。

      7、多节点的逆向流转缺陷

      当前软件不少喜欢使用工作流来驱动。工作流的问题,就是可能出现多个流向分支。测试容易忽略的部分,就是工作流多节点的逆向流转。例如,通过不通过涉及两个分支,但是流程逆转的时候,有可能不是回到上一节点而是平级的另一个节点去了。软件测试要格外注意这类用例的设计。另外,有些时候默认分支在向前的时候是有默认值的,例如默认通过,那么保存的时候要提示用户是否通过,否则可能由于操作疲劳而走错了节点,引起回退。

      8、输入框缺陷

      试过往输入框粘贴数据而不是直接输入吗?可能这里会出现问题。按 Ctrl+V 的时候,输入框会根据长度大小自动截断输入长度。但是用鼠标,截断可能会失效。有一次测试人员就是用这种方法把一篇 Word 文档输入进去了,保存的时候,数据库崩溃。有些网站登陆的口令****可以拷贝下来的,只要放在剪贴板里面马上明文显示。

      输入框可以说是问题最多的部分,能够引起的麻烦也很多。日期、数字、文本等等,都需要耐心的测试一下。

      9、界面布局缺陷

      曾经有一次,项目经理回来向测试部反映一个问题,客户对界面不满意。原因很简单,因为界面上删除按钮和保存按钮挨得很近。结果有些操作不熟练的业务人员,很容易误按。这个问题是测试人员没有意料到的,因此注意关闭、删除、退出按钮与保存、下一步等按钮的距离。类似的按钮应按此规则排列分布。

      界面布局还可能发生在窗口最大化和最小化上,有可能窗口缩小的时候没有下拉框或不匹配分辨率,对用户来讲,这个错误实在很低级。有些用户由于操作习惯,非常不喜欢腾出手使用鼠标,尤其是大量输入的界面,因此,要注意设置键盘的快捷方式。还有,按 Tab定位到下一焦点时要注意顺序,避免跳转太灵活而让操作人员感到无从适应,在界面进行维护或者修改的时候,不要忘了软件测试开发人员是否无意改变了这些快捷方式和跳转顺序。

      10、版本和补丁包的环境问题

      理论上讲,这属于兼容性测试应该覆盖的问题。有些客户很喜欢更新最新的软件版本或者微软时不时打些补丁包,问题就出现了。有时候升级不一定是好事。这些问题最好在测试的时候增加几个用例,多用不同软件版本的机器跑一跑。软件测试有个定律是:你没跑过的地方,就一定会出事。经常听到开发人员抱怨,怎么我的机器没问题,你的机器就有事了呢?这不能完全靠配置管理员解决问题,环境配置项是大家最容易忽略的。

      11、用户管理缺陷

      用户管理的角色和授权需要好好研究一下,作过测试的人员都知道,有时候为了测试的方便,测试用户都是具有超级权限的用户。而且,比较容易忽略用户管理这一部分的测试。往往发往客户的时候,很多测试用户都没有删除。

      另外,有些接口的用户和口令,到软件使用寿命结束都没有更改过。在一次测试中,软件测试人员发现,给一个用户授超级用户权限,之后更改这个用户为受限权限。使用中发现,用户居然没有真正回收权限,用户管理界面上没有任何不对。及早准备用户管理用例,不要等到测试快结束时候才想起。

      12、常识缺陷

      从逻辑或者统计学上讲,计算机是允许如此处理的,但是从常识上来讲,这些情况不可能发生。例如电话号码不可能出现小数点,终止时间不能大于开始时间等等。除此之外,常识还要结合业务特点来进行判断,因此,开发和测试人员要格外注意对自己知识的培养以及增加对需求细节的了解。不能因为一味追求进度而采用最简单的代码来实现,对用户来说,这些错误可能是很荒谬的。

      尽管我们不可能完美的测试一个软件,但是我们仍然可以改进我们的软件测试。每次测试结束,及时总结测试中的不足,进一步完善用例。思考一下那些容易忽略的软件缺陷,能提高对软件测试的认识,提高所在组织软件的质量。

  • 转> EPR和SAP的一些名词解释

    2008-08-04 14:11:19

    转> EPR和SAP的一些名词解释

    1.企业资源计划
    企业资源计划(Enterprise Resources Planning,ERP),可以从三个层次进行定义:
    管理思想:ERP是由美国著名的计算机技术咨询和评估集团Gartner Group Inc.提出了一整套企业管理系统体系标准,其实质是在MRPII(Manufacturing Resources Planning,“制造资源计划” )基础上进一步发展而成的面向供应链(Supply Chain)的管理思想;
    软件产品:是综合应用了客户机/服务器体系、关系数据库结构、面向对象技术、图形用户界面、第四代语言(4GL)、网络通讯等信息产业成果,以ERP管理思想为灵魂的软件产品;
    管理系统:是整合了企业管理理念、业务流程、基础数据、人力物力、计算机硬件和软件于一体的企业资源管理系统。
    2.物料需求计划
    物料需求计划(Material Requirement Planning,MRP) 指企业的信息管理系统对产品构成进行管理,借助计算机的运算能力及系统对客户订单,在库物料,产品构成的管理能力,实现依据客户订单,按照产品结构清单展开并计算物料需求计划。实现减少库存,优化库存的管理目标。
    3.制造资源计划II
    制造资源计划II(Manufacturing Resources Planning II,MRP II) 指在企业技术、管理和经济上有效地建立起来的一个过程,贯穿于市场经销、产品设计、制造工艺、生产计划、物资供应、生产作业与控制、仓储管理和财务成本等环节。
    4.供应链管理
    供应链管理(Supply Chain Management,SCM) 指从原材料采购直到产成品销售,供应链管理设计、计划、控制可能因素并同时协调与优化物流、资金流、信息流,着重供应商、制造商、批发零售商以及服务供应商和客户之间的协调处理。
    5.BPR业务流程重组
    业务流程重组(Business Process Reengineer,BPR) 指运用信息技术和人力资源管理手段大幅度改善业务流程绩效的革命性方法。
    6.绩效管理体系
    绩效管理体系(Key Performance Indicator,KPI) 指一个循环往复的过程,包括“目标设定”、“跟踪汇报”、“分析调整”和“考核激励”四个主要的管理环节。
    7.系统应用产品
    系统应用产品(System Applications Products ,SAP) 指德国的一家ERP软件公司开发的ERP应用软件,是英文System Applications Products in Data Processing的缩写,翻译为数据处理中的系统、应用和产品。
    8.SAP R/3
    SAP R/3 指一个基于客户/服务器结构和开放系统的、集成的企业资源计划系统;其功能覆盖企业的财务、后勤(工程设计、采购、库存、生产销售和质量等)和人力资源管理等各个方面。
    二、SAP模块名称
    1.财务会计
    财务会计(Financial Accounting,FI) 指必须能够按有关规定向股东、债权人、劳工组织以及社会公众披露并提供所需的信息,而有效的公司管理会计必须包括控制和转移的功能。财务会计模块由总分类帐、应收帐款和应付帐款、固定资产、法定合并以及特殊统计会计功能组成。
    2.管理会计
    管理会计(Controlling,CO) 指提供企业内部管理控制及内部考核评价所需要的各种信息,通过与销售模块、采购模块、财务会计的集成功能,将生产经营中的各种信息在CO中进行分析和比较,由一般费用成本核算、生产成本核算和获利能力分析等子模块组成。
    3.销售和分销
    销售和分销(Sales and Distribution,SD) 指SAP系统中一个用于解决销售过程中相关业务操作的高度集成的模块,通过与财务模块的集成,所有信息可以实时反映到帐务系统。主要由销售订单的管理、信用额度的控制、发货管理、发票管理等功能组成。
    4.物料管理
    物料管理(Material Management,MM) 指R3后勤系统的一个组成部分;此模块所提供的功能基于物料的物流管理操作:获取、采购、需求计划、库存管理、物理仓储管理以及票据管理。
    5.仓库管理
    仓库管理(Warehouse Management,WM) 指MM模块中的一个子模块,利用WM系统, 可以对公司中复杂的库存结构进行管理。这种结构可包括不同的仓库中的区域(即存储类型),如在高架位闲置的存储、可用存储、冻结存储和固定的仓位提取区域等,以及生产供应、发货和收货区域等。利用WM系统,可以同时对具有随机组织结构和具有固定仓位的仓库进行管理。
    6.生产计划
    生产计划(Production Planning,PP) 指后勤系统中负责计划、控制、管理生产的模块,提供完善的满足各种制造模式的处理,如重复生产、按订单生产、按订单装配、流程式生产、批量生产和面向库存生产。集成化供应链如MRPII、电子看板、计划估化器、车间控制器、流程控制系统、PDM等。
    7.工厂维护
    工厂维护(Plant Maintenance,PM) 指负责复杂的工厂控制系统维护;支持对工厂的图形化表达,可和地理信息系统相连,包括详细的工厂图表;对设备可进行预防性维护计划、缺损保修、检修、备品备件管理等。
    8.人力资源
    人力资源(Human Resources,HR) 指SAP系统中的人力资源模块,是管理人事档案、人员工资及培训和差旅费用的,最终产生的财务信息会集成到会计模块中。
    9.物流集成
    物流集成(Material Repair Operation,MRO) 指对备品备件、原料、产成品等物资的采购、供应、库存、销售等状态的管理。
    10.石油行业解决方案
    石油行业解决方案(Industry Solution- OIL,IS-OIL) 指一个专门针对石油和天然气开发出来的行业解决方案,SAP公司与其众多的战略合作伙伴共同建立了石油天然气行业全球理事会,目标是支持SAP石油天然气行业产品及SAP油气企业用户的互动发展。该理事会定期召开会议,工作重点主要围绕着制定石油天然气行业的管理标准及相应SAP产品的开发策略,以满足石油天然气行业不断变化的管理需求。经SAP公司及其战略合作伙伴二十余年来的潜心研究,反映当今一流石油企业生产与管理经验的“最佳业务实践”被预置在 SAP的系统中。这些最佳业务实践基本涵盖了大多数石油企业在生产与管理上的各类需求,同时也可为各石油企业进行组织机构、管理流程的改革提供有益的参考与专家式的帮助。
    11.高级计划优化器
    高级计划优化器(Advanced Planning Optimizer,APO) 指SAP供应链管理的一部分,可优化供应链管理,通过高级计划优化器可提供一套更好的采购方案给企业,通过APO与ERP集成可尽快尽好并最低成本的得到供应商原料从而使得公司的产品更快速地交付给客户。
    12.数据仓库
    数据仓库(Business Information Warehouse,BW) 指在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。与其他数据库应用不同的是,数据仓库更像一种过程,对分布在企业内部各处的业务数据的整合、加工和分析的过程。
    13.企业战略管理
    企业战略管理(Strategic Enterprise Management,SEM) 指提供一种手段和途径(如通过与历史同期的比较或对未来某一时期的合理预期),使企业的战略决策不断地由设想转变为现实。

    14.主生产计划
    主生产计划(Master Production Schedule ,MPS) 是预先建立的一份计划,由主生产计划员负责维护。主生产计划是驱动MRP的一整套计划数据,它反映出企业打算生产什么,什么时候生产以及生产多少。主生产计划必须考虑客户订单和预测、未完成订单、可用物料的数量、现有能力、管理方针和目标等等。
    三、SAP实施
    1.SAP实施方法: 快速实施SAP
    快速实施SAP (Accelerated SAP ,ASAP) 指SAP提供的执行解决方案。Accelerated SAP集成了几个组件,这几个组件联合工作以支持R/3 系统的快速有效的执行。
    2.Change Management变革管理
    变革管理(Change Management) 指对用现行的计划和概念将企业转换成新的状况的渐进和不断变化的过程的管理。
    3.关键流程演示
    关键流程演示(Conference Room Pilot,CRP) 指SAP实施过程中,对关键业务流程在系统上进行实现演示,从而得到实施单位对实施SAP的初步认可。
    四、SAP系统设置
    1.集团
    集团(Client) 指SAP系统中最高等级的组织单位,是由一个主数据库和建立一个完全集成系统所必须的所有表格组成的。
    2.公司代码
    公司代码(Company Code) 指一个独立的会计实体,拥有完整的会计帐套。是对外报送法定资产负债表和损益表的最小单位。
    五、SAP开发工具
    1.高级业务应用程序
    高级业务应用程序(Advanced Business Application Programming,ABAP) 指SAP公司开发的用于Reports、Screens、Interfaces、Data conversions等多种应用程序设计的一种编程语言。R/3的所有应用程序甚至其BASIS系统的部分组件都是由ABAP开发的。它是图形化第四代编程语言。因此常被称为ABAP/4。
    六、系统应用
    1.关键用户
    关键用户(Key User) 指在ERP实施过程中,代表实施方提出业务需求,全程参与整个项目实施,负责对最终用户进行培训,及实施后的系统维护的人员。
    2.最终用户
    最终用户(End user) 指在ERP实施后,在ERP系统中进行凭证输入、报表查询等日常业务操作的系统使用人员。
    3.角色
    角色(Role) 指按照一定的权限执行相应的操作的个体。
    SAP APO = Advanced Plan optimization, 做资源优化的
    SCM = Supply chain management 供应链管理
    ECC = ERP Central Component
    SRM = mySAP供应商关系管理(SRM)套件
    CRM = CRM Solutions for customer relationship management 客户关系管理
    BW = Business Information Warehouse,商务信息仓库

    SAP各模块:

    FI 应收、应付、总帐、合并、投资、基金、现金等;

    CO 利润及成本中心,产品成本、项目会计、获利分析等;

    AM 固定资产、技术资产、投资控制等;

    SD 销售计划、询价报价、定单管理、运输发货、发票等;

    MM 采购、库房管理、库存管理、MRP、供应商评价等;

    PP 工厂数据、生产计划、MRP、能力计划、成本核算等;

    QM 质量计划、质量检测、质量控制、质量文档等;

    PM 维护及检测计划、单据处理、历史数据、报告分析等;

    HR 薪资、差旅、工时、招聘、发展计划、人事成本等;

    PS 项目计划、预算、能力计划、资源管理、结果分析等;

    WF 工作定义、流程管理、电子邮件、信息传送自动化等;

    IS 针对不同行业提供特殊应用。

  • 软件开发过程系统常见的错误及处理机制

    2008-08-02 10:43:53

    软件开发过程系统常见的错误及处理机制
            在软件开发过程中,经常会遇到各种各样的错误,那么怎么尽可能的避免错误的产生呢?
            下面就是系统开发过程中常见的错误类型和处理机制。

    一、常见错误类型

    1、用户输入错误
            用户输入的非法的数据或不完整的数据时,输出相应的告警信息,并返回用户输入的初始页;

    2、用户错误操作
            用户进行错误的操作时,输出相应的告警信息,并返回用户输入的初始页;

    3、系统异常错误
            系统异常错误包括数据连接失败、网络连接失败、因开发与运行平台的固有原因而产生的异常错误等,处理系统异常错误时,将输出错误报警信息,并终止当前程序的运行。

    4、程序给黑客留的漏洞
            程序员常犯的一个错误就是对接收的数据进行盲目引用,而不进行适当的处理,这样就很容易得给黑客留下了一个进入我们系统的入口。

    二、错误处理机制
    1、程序编写时充分考虑到用户的错误或非法输入,用户的错误操作等情况,并针对相应情况分别进行错误处理;

    2、程序编写时需要充分考虑到系统可能会遇到的各种异常情况,并针对这些情况做出相应的错误处理;

    3、为了防止数据丢失,系统中应当提供相关接口进行数据库内容的备份、还原和导出;

    注1:数据库的备份和还原需要数据库服务器与应用服务器位于同一个物理服务器上,同时数据库正在使用的过程中数据库将不能被还原;

    注2:数据库内容的导出是指的将一个指定的查询、视图、存储过程的返回结果导出一个Excel文件,并存储在磁盘上;

    4、为了尽量减少程序的漏洞,对接收的数据要进行适当的处理,比如过滤掉一些特殊的字符,如单撇、双撇、空格等等,必要时在注册时就禁止一些特殊字符

     

  • 一个工作6年的软件工程师对该职业的总结(转)

    2008-08-01 16:17:34

    一个工作6年的软件工程师对该职业的总结(转)
    1、 分享第一条经验:“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要:“重要的道理明白太晚将抱憾终生!”所以放在每一条,让刚刚毕业的朋友们早点看到哈!
    2、 一定要确定自己的发展方向,并为此目的制定可行的计划。不要说什么,“我刚毕业,还不知道将来可能做什么?”,“跟着感觉走,先做做看”。因为,这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术,将来成为专家级人物?向管理方向走,成为职业经理人?先熟悉行业和领域,将来自立门户?还是先在行业里面混混,过几年转行做点别的?这很重要,它将决定你近几年、十年内“做什么事情才是在做正确的事情!”。


    3、 软件开发团队中,技术不是万能的,但没有技术是万万不能的!在技术型团队中,技术与人品同等重要,当然长相也比较重要哈,尤其在MM比较多的团队中。在软件项目团队中,技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码,还是产品管理、测试、文档、实施、维护,多少你都要有技术基础。算我孤陋寡闻,我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目,哪怕就一个,也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目,项目交付的第二天,项目组成员扔下一句“再也受不了啦!”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。


    4、 详细制定自己软件开发专业知识学习计划,并注意及时修正和调整(软件开发技术变化实在太快)。请牢记:“如果一个软件开发人员在1、2年内都没有更新过自己的知识,那么,其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们:另外的那8小时如何使用将决定你的人生成败!本人自毕业以来,平均每天实际学习时间超过2小时。


    5、书籍是人类进步的阶梯,对软件开发人员尤其如此。书籍是学习知识的最有效途径,不要过多地指望在工作中能遇到“世外高人”,并不厌其烦地教你。对于花钱买书,我个人经验是:千万别买国内那帮人出的书!我买的那些家伙出的书,100%全部后悔了,无一本例外。更气愤的是,这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识;拥有知识并不表示拥有技能;拥有技能并不表示拥有文化;拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧,才算是真正拥有了它。


    6、不要仅局限于对某项技术的表面使用上,哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发Windows应用程序,看看Windows程序的设计、加载、执行原理,分析一下PE文件格式,试试用SDK开发从头开发一个Windows应用程序;用VC++、Delphi、Java、.Net开发应用程序,花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码;除了会用J2EE、JBoss、Spring、Hibernate等等优秀的开源产品或者框架,抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做,你以后的工作将会少遇到一些让你不明就里、一头雾水的问题,因为,很多东西你“知其然且知其所以然”!

    7、在一种语言上编程,但别为其束缚了思想。“代码大全”中说:“深入一门语言编程,不要浮于表面”。深入一门语言开发还远远不足,任何编程语言的存在都有其自身的理由,所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是:用面对对象工具开发某些关键模块时,为什么不可以借鉴C、C51、汇编的模块化封装方式?用传统的桌面开发工具(目前主要有VC++、Delphi)进行系统体统结构设计时,为什么不可以参考来自Java社区的IoC、AOP设计思想,甚至借鉴像Spring、Hibernate、JBoss等等优秀的开源框架?在进行类似于实时通信、数据采集等功能的设计、实现时,为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式?为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题???“他山之石、可以攻玉”。

    8、 养成总结与反思的习惯,并有意识地提炼日常工作成果,形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知,对软件开发人员而言,有、无经验的一个显著区别是:无经验者完成任何任务时都从头开始,而有经验者往往通过重组自己的可复用模块、类库来解决问题(其实这个结论不应该被局限在软件开发领域、可以延伸到很多方面)。这并不是说,所有可复用的东西都必须自己实现,别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是,最好还是自己实现,这样没有知识产权、版权等问题,关键是自己实现后能真正掌握这个知识点,拥有这个技能。

    9、 理论与实践并重,内外双修。工程师的内涵是:以工程师的眼光观察、分析事物和世界。一个合格的软件工程师,是真正理解了软件产品的本质及软件产品研发的思想精髓的人(个人观点、欢迎探讨)。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作,但从软件工程师这个角度来看,这只是外在的东西,并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论,并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题,才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题,并在具体实践中验证和修正这些思想与方式,最终形成自己的理论体系和实用方法论。

    10、心态有多开放,视野就有多开阔。不要抱着自己的技术和成果,等到它们都已经过时变成垃圾了,才拿出来丢人现眼。请及时发布自己的研究成果:开发的产品、有创意的设计或代码,公布出来让大家交流或者使用,你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具,5、6年之后的今天,还是那个样子,今天流行的好多Windows系统工具都比自己的晚,但进化得很好,且有那么多用户在使用。并且,不要保守自己的技术和思想,尽可能地与人交流与分享,或者传授给开发团队的成员。“与人交换苹果之后,每个人还是只有一个苹果;但交换思想之后,每个人都拥有两种思想”,道理大家都懂,但有多少人真正能做到呢?
    11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品,千万不要因为没有钱赚而不做。网络早已不再只是“虚拟世界”,网上有很多的开源项目、合作开发项目、外包项目,这都是涉猎工作以外的知识的绝好机会,并且能够结识更广的人缘。不要因为工作是做ERP,就不去学习和了解嵌入式、实时、通信、网络等方面的技术,反过来也是一样。如果当他别人拿着合同找你合作,你却这也不会,那也不熟时,你将后悔莫及。
    12、书到用时方恨少,不要将自己的知识面仅仅局限于技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明: “对于一个有一定基础的人来说,他只要真正肯下功夫,在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果,故命名为西蒙学习法。可见,掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识,有空花时间看看,韬光养晦、未雨绸缪。
    13、本文的总结与反思:
    A:不要去做技术上的高手,除非你的目标如此。虽然本文是关于提高软件开发知识的建议,做技术的高手是我一向都不赞同的。你可以提高自己的专业知识,但能胜任工作即止。

    B:提高软件知识和技术只是问题的表面,本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理,可以很容易地延伸、应用到生活的其它方面。

    C:在能胜任工作的基础上,立即去涉猎其它领域的专业知识,丰富自己的知识体系、提高自己的综合素质,尤其是那些目标不在技术方面的朋友

Open Toolbar