qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

项目估算与计划不是一般的难(下)

计划是如何做出来的?

  一、要站在战略的高度。

  有时候我会问项目经理这样的问题:

  1、项目预算是多少?(注意前文提到的预算与估算的差别哦,预算是指公司打算花多少钱做这个项目。)
  2、合同要求在什么时候验收?
  3、验收一次进行还是分初验、终验?

  有些项目经理答不出了,他们没有去关注合同中的要点,也没有向高层取得项目的战略指示。

  一般情况下,在项目初期,你应该搞清楚这些战略层面的内容:

  1、合同价钱是多少,公司打算赚多少钱?
  2、公司为什么要做这个项目?想赚钱?想维持客户关系?想积累业务和技术?本项目是公司战略的其中一步?
  3、项目的工期要求。
  4、项目的验收办法、验收标准。
  5、项目是如何收款的,客户每次的付款条件是什么?

  你可以通过看合同,向公司高层请示,了解到这些关键信息。当然很多公司合同是保密的,你可能无法直接看到合同,但你可以直接问高层领导嘛,尽量获取上述关键信息。做项目就像打仗,秦国名将白起没有一次败仗,主要是因为他每次打仗之前,都会处在战略高度来审视国与国之间的大势。你要做好项目,先要把握项目的大势!

  二、明确计划的“输入”。

  要做好计划,你还需要了解清楚以下内容:

  1、系统的需求。通常需求是不明确的,能明确多少算多少,同时你需要有计划地去搞清楚。

  2、系统的设计。通常设计也是不明确的,你需要安排很多前期技术研究。

  3、项目组当前的能力情况。

  4、为成功完成项目,项目组还需提升哪些知识和技能。

  以上这些内容,是项目计划的“输入”,良好的输入是优质计划的基本保证。

  三、用估算来控制计划,由计划来调整估算。

  估算如果做得好,其实计划就完成大部分了,你需要利用估算来指导计划。为了说明“估算指导计划”,下面我会虚拟一个例子。

  某项目估计完工需要1000人日的工作量,其估算明细如下:

  1、项目管理150人日。
  2、需求150人日。
  3、设计150人日。
  4、编码250人日
  5、测试100人日。
  6、实施200人日。

  根据估算,你安排了详细的进度计划,进度计划中的各任务可以分为六类:项目管理、需求、设计、编码、测试、实施。请注意每一类工作量的总和,不能超过对应的估算,你需要用各子估算来控制这六类子任务。

  不少项目在安排具体进度计划时,忘记做这个检查,有时候进度计划的总工时没有超出预算,但可能编码方面的任务已经超出了编码的预算了。

  在具体计划时,往往会发现估算时遗漏考虑的内容,这时很有可能实际计划的总工时会超出估算,或者是某类别的工时超出相应的子估算。这是很正常的事情,项目组对项目的认识是逐步深入的,不太可能在估算时就100%考虑周到。遇到这样的情况,我们通常这样处理:如果仅是某类别工时超出相应的子估算,如果能从别的子估算挪一点过来“补数”,而总估算不受影响,则不需要申请估算调整;但如果总估算受到影响,则需要申请变更估算。

  前文讲述估算时提到,会因为需求不能全部明确、设计也不能全部明确,估算往往不能一次完成,这时只需要估算能估算的部分就可以了。但我们需要随着项目的开展,认识的加深,持续更新估算。估算与计划的关系是:估算指导计划,计划反过来促进估算更新。

 四、制定可执行可检查的进度计划。

  具体工作任务的制定是很讲技巧的,如何做到“可执行可检查”是关键,下面是制定进度计划的一些技巧:

  1、每个任务的时长不要超过5天。

  我们公司的项目,任务时长往往是在两三天内。

  2、任务只有完成与未完成两种状态。

  所谓任务完成90%之类的说法是不靠谱,任务应该足够细分,不要安排周期长的任务,这样能更好控制项目进展。

  3、每个任务都有可供检查的工作产物。

  不要笼统安排“研究什么什么技术点”之类的任务,必须明确工作产物,如:研究某某技术点,编写研究报告,提交演示程序。而任务完成标准就是:这些工作产物能达到期望的要求。

  4、一个任务一个人负责。

  一般不要安排类似“小甲与小乙共同完成某设计文档”之类的工作,多人同时负责一个事情,效率会很低,效果也不太好。

  尽管实际工作中有可能需要多人同时做一个事情,你可以:

  1)再次将任务分解,落实到具体的人头上,如上述任务可以分解为两个任务:小甲完成设计文档的章节1、2、3,小乙完成章节4、5、6。

  2)如果任务实在不好再分解,就只安排一个人去做。

  在我们公司,一般只有评审任务是多人参与的,别的任务都会落实到具体的人头上。

  五、细化近期计划,定下远期计划大节点。

  我曾经负责一个房地产公司的成本管理系统,当时需求还没有全部明确、技术也很不成熟,就被要求做出该项目的全部详细计划。我当时很郁闷,一个月后某一天谁干什么的事情也要计划出来吗?我只能明确近期一两周的具体工作,而远期的工作我只能定出大概,以后的事情可变因素太多,现在写出所谓具体工作,其实是毫无价值的,浪费时间。

  近期两周内的工作能明确的工作,必须按照上述第四点的要求制定详细的明确的可执行的可检查的任务,而对于将来的工作,则需要定出关键节点,如什么时候发布什么版本,什么时候验收。

  六、让项目组各成员详细计划自己的工作。

  在项目经理主持下,项目组全体共同来制定进度计划框架,明确任务的先后关系。而对于每个人的具体任务,则可以在项目经理的指导下,由每个人自己来确定。

  项目组由项目管理、需求、设计、编码、测试、实施等各专业人才组成,每个人承担起自己专业方面的管理工作,项目管理其实是项目组成员每个人的事情,不是只由项目经理一个人来负责。

  七、持续更新计划。

  计划不是死的,是活的!项目计划不是一次成型就固定不变的,项目组需要持续更新计划细化计划,要随时保证近期的任务都已经明确,而远期的任务如果能明确也应当尽量明确。任何项目组成员都可以发起计划更新,项目经理要推动大家管理好自己工作,让大家主动更新计划。

  这里要谈谈计划变更问题,谈到计划变更很多人会“闻虎色变”,我们先要看看看什么叫“计划变更”?

  “计划变更”要与“计划调整和细化”区别开来,调整和细化是指根据实际情况,不断的适时地去修改计划。任务微调是很经常和很正常的时间,某某任务稍微延长一天,某某任务比计划提早一天完成,某项目组成员请假等影响因素,都需要我们去调整计划。与此同时,我们应当不让去细化中远期的任务,至少要一直保证近期的任务都是明细化的。

  而计划变更是指,项目关键节点受到影响的重大变化,关键节点一般有:需求规格说明书通过评审的时间点、版本发布时间点、验收时间点等。这些关键节点的变化,会影响合同条款的履行,会影响公司的战略规划。通常是因为内因或外因导致计划变更,内因一般有:遗漏重要需求、软件设计出现重大失误、代码质量不过关;而外因一般有:客户的需求变更,客户未能做好项目上线准备,第三方未能及时完成相关工作(如:硬件提供商未能及时发货)。

  在我们公司,计划调整和细化只需要项目组内达成一致便可,而计划变更则需要报高层审批。


 如何跟踪计划?

  计划做出来不是用来看的,而是要执行计划!跟踪计划执行的难度和工作量比起做计划要高出好多倍。

  计划跟踪并不是对照进度计划,按时间检查每个人的任务完成情况这么简单,下面介绍一些计划跟踪的关键要点。

  1、建立便捷的项目组内沟通机制。

  很多人强调加强沟通,虽然大家的意识算是加强了,但还是收不到理想效果。程序员不善沟通的特点(理科生往往是不善沟通),不是一下子能改变的。下面一些最佳实践供大家参考:

  1)所有人的工作产品必须share!我们要求大家的文档要提交到项目网站,而代码满足提交条件的,每天都需要提交。工作产品不能几天都只存在自己电脑上,哪天你不上班了,大家就无法接手。

  2)每天站立会议。

  口头沟通是最有效的沟通办法,我在很多项目中实施了每天站立会议的做法,要求大家简要地说明工作情况及遇到的问题,需要大家提供什么支援等。每次会议,如果有决议和代办事项,我都会安排记录下来,并将会议记录公布在项目网站上。

  3)有问题即反馈!

  很多项目组成员喜欢遇到问题就闷头干活,不好意思问,也好像是怕被主管认为能力低。遇到问题有可能是任务本身有问题,也有可能是你的认识不到位,某些知识不具备等导致的。实际工作中遇到问题是很正常的事情,如果没有人提出问题,这反而是项目的最大问题。我强调任何人都可以提问题和大家讨论,任何人都可以发起项目会议讨论问题。问题如果不在产生时消除,将来必定会因此徒增很多项目工作量。

  2、建立项目组成员的自信。

  我带领过很多项目团队,很多项目组成员是新手,甚至是应届生,项目团队中新手太多是很大的挑战!在中国基本上不可能每个项目团队一开始就是最强阵容的,大部分项目团队是新老结合,中高低搭配的。我强调每个人的重要性,对于新手要给出更多的机会,更多的指导,更多的鼓励!犯错不要紧,犯错多也不要紧,只要错误不是重复的,这就是好事!只要去做事情,就有机会犯错,只要做未做过的事情,犯错机会也会更大一点,关键是总结和进步!

  3、质量投资,减少返工。

  项目时间紧,大家就会一头扎到编码中,想尽快弄出个东西来。“谋定而后动”“磨刀不负砍柴工”等大道理大家都懂,但事到临头还是明知故犯,结果往往是工作质量低、返工一大堆!

  要培养大家零缺陷意义,零缺陷意识包括零缺陷文档、零缺陷代码、零缺陷发布。我经常和大家强调,做一个事情只有两种选择,一种就是不做,一种就是认真做好!不要搞什么60分万岁,不要应付完成,任何带有缺陷的工作,会在将来带来无穷无尽的“后患”。一步一个脚印,欲速则不达。

  除了向大家灌输这种思想并要求大家这样去做,作为项目经理还需要尽早检查和指导大家的工作。比方说:我安排小甲完成某模块的设计文档,我不会等文档完成才去看,我会先要求小甲思考后找我口头说明他的思路,大致没有问题我就让他动手写文档,而且我要求项目组所有人写文档都必需在线完成,我会随时检查文档的质量。(说明:我们用SharePoint来管理项目文档,Word、Excel等文档都可以在项目网站上在线编辑。)

  绝大部分项目是分秒必争的,保证大家用正确的方法做正确的事情,才能最大限度地减少返工。不过上面提到的检查办法确实有点夸张,我一般对于新手才会这样检查,当新手已经成长起来,你对他有信心,就不需要检查得这么密了。

  4、不断思考减少工作量的办法。

  失败的项目特点,往往是无用功太多,返工太多!

  软件项目的特点是“两不明确两大限死”:需求不明确、设计不明确、工期限死、预算限死。要成功完成项目,不能光靠所谓的项目管理知识,你需要熟悉这个软件开发的方方面面,想出降低工作量的方法。

  能极大降低工作量的两个方面:

  1)需求方面:抓住本质需要,尽量简化需求,优先实现稳定的需求。

  稳定的需求是指我们基本能明确,客户将来不太可能会变化的需求,这些需求应该优先实现。

  2)设计方面:采用成熟设计,重用组件,采用能降低编码和实施工作量的设计。

  通过以上两方面降低工作量,光靠项目管理知识是办不到的,你需要在这两方面有资深的经验,你需要发动项目组全体人员的智慧,一起想出简化工作的办法。

 5、密切留意需要客户和第三方完成的工作。

  我们公司的项目在开发阶段还算比较顺利,因为一切都是自己来掌控的,但一旦涉及到客户或者第三方,问题就非常多。下面是常见的一些问题及应对办法:

  1)确认需求规格说明书,特别是一旦要求客户签字盖章,就会左推右推。我们会跟客户说明签字是表示对前面工作的确认,不代表将来不允许变更。

  2)客户不能及时准备好实施所需的软硬件环境。我们会提前很多提醒客户,并尽可能帮助可以搭建实施环境。

  3)系统上线后,客户无法及时组织人员参加培训,推动系统正式使用。我们一般会走高层路线,让客户高层推动系统上线。

  4)系统需要用到的服务器或相关硬件不能及时采购。我们会事先做好供应商选择,挑选合适的供应商。

  不要忽视客户和第三方的工作,一般需要打很大的提前量来进行预防性管理。

  优秀项目经理是怎样炼成的?

  软件项目经理往往是权力小而责任重大,软件项目的“两不明确两大限死”特点,让我们做项目犹如走钢丝,而且要高速地走钢丝!

  你的综合实力决定你能否成为优秀的项目经理!项目经理是练出来的,下面谈谈我的体会。

  1、你需要有扎实而丰富的软件工程实践经验。

  想成为优秀项目经理,从编码切入可能是最好的打基础办法。我编写VB与C#的代码都有若干年时间,编码的工作其实不只是编码的,你还需要考虑测试,你还需要思考软件是否符合需求,考虑软件如何安装部署等。只要你能坚持3年以上的编码工作,相信你一定会有软件工程的多方面经历,如需求、测试、实施,这些经历都是你宝贵的财富!如果你是从测试、实施切入,你可能难以获取软件编码、软件设计、软件技术方面的经验。

  2、学习软件开发牛人总结出来的项目管理知识。

  关于项目管理的资料书籍很多,强烈建议大家重点阅读软件开发牛人总结出来的经验。如果你还没有实际工作经验,大学中学习的软件工程知识,可能还能“忽悠”一下你。但如果你已经有实际工作经验了,建议你一边工作一边学习资深软件开发人员的著作,会让你产生极大的共鸣,让你思考如何工作得更好。我最开始看的一批项目管理书是微软资深开发人员编写的,大家找实用项目管理知识书一定要注意作者有没有多年的实际软件项目管理经验。

  3、主动承担项目管理工作。

  我刚开始的三年编码生涯,基本上是出于“无人管理”状态下完成一个技术含量较高的桌面程序。当时没有人带领我做这个软件,我完全是靠自己一边探索,一边前进,这无疑是给了我自己管理自己的锻炼机会。不要等别人来管理你,你首先应该要会自己管理自己!如果你能管好自己,你就应该主动申请带领团队完成一些工作。项目经理可以说是训练综合素质的最好职位,无论你将来升任部门经理、高层领导,甚至做老板,还是回头钻研技术,项目经理一职绝对是你以后成功的超级助力器!

  4、持续总结,不断进步。

  总结使人进步!你应该利用一切机会思考和改进。很多人不喜欢写文章,这一个很大的问题,写文章其实不需要什么文采,关键是你脑袋中有没有东西?我主要通过以下几种途径来帮助自己总结:

  1)在项目中我会编写计划、需求、设计等各种文档。

  2)我平时会整理出很多文章。

  3)我会整理出很多课程,在公司的每日培训中与大家分享。

  本文介绍了我在项目估算与计划的实践体会,希望能为大家带来有益的启发。

posted @ 2011-11-23 17:45 顺其自然EVO 阅读(307) | 评论 (0)编辑 收藏

项目估算与计划不是一般的难(中)

估算如何做出来?

  这里开始所说的估算,全部都是指项目组对项目的估算,这个估算的目的是用来指导项目的具体工作

  有很多种估算办法,大致可以分为两类:

  1、先得到软件规模,然后根据公司实际的生产率由软件规模导出工作量。

  2、直接得到工作量。

  第一类的常见方法有:功能点法、代码行法,第二类的常见方法有Delphi估算法、微软的由底而上估算法。

  什么是软件规模?我们先看看一个搬砖头的估算。

  假设有1000块砖头,它们的大小和重量一样,每名工人每天能搬100块砖头,于是我们可以估算到需要10人日来搬完。10人日的意思是1名工人需要10天完成,而10名工人只需要1天就搞定了。

  这个1000块代表了工作的规模,而生产率就是100块/日,这样就可以推算出工作量为10人日。建筑工程可以得到土石方量、混凝土量、钢筋量等代表工作规模的数据,这样就比较容易推算出完成这些工作需要的工作量。

  而软件工程估算也希望能做到类似的效果,但用什么来代表软件项目的工作规模呢?功能点和代码行是常见的两种软件规模表示方式。

  软件规模是与软件具体生产技术、项目管理办法、项目组人员水平等无关的东西,软件规模只和软件项目本身的性质相关,如果我们能找到合适的统一的标准来度量每个项目的规模,这样每个软件项目之间就可以进行横向比较了。功能点法和代码行法都希望能达致这样的效果。

  功能点法的基本思路是将复杂的软件分解为一个一个独立的粒度一致的功能点,附加一些调整系数,得到软件规模。

  我们的项目大部分是数据库四轮马车的操作(查询、增加、修改、删除),功能点法从比较高的层次对这些工作进行抽象,有一套严密的规则可以让你将需求分解成一个一个的功能点。代码行法思路也类似,不过分解的结果是代码行而已。但一般来说代码行与软件的实现技术相关度太大,大家会更加偏爱功能点法。

  功能点法和代码行法有比较长的历史,也有很多详细资料,大家可以去查阅一下。这方法理论上很理想,但实践效果很差,我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题:

  1、只适用于数据库四轮马车的操作的项目,高技术含量、创造性高的软件不适用,如游戏软件、计算机负责计算与决策软件等。

  2、我们绝大部分项目是需求不明确、设计不明确,并且工期很赶的,这两个方法都无法适应这样的现实条件。需求不明确基本上无法得到软件规模,建筑工程为什么能做到,是因为需求和设计都十分明确了。

  3、两个方法的规则都很详细,要花大量时间学习和实战才能掌握。

  4、由工作规模导出工作量这样的思考方式,难以适用于软件项目。项目组还是习惯列出具体的任务,逐条任务估计时间,而且只有这样的工作方式才能让项目组感觉更加踏实。

  Dephi估算法是比较符合大家实际工作习惯,也是比较容易掌握的估算办法。

  Delphi法的大致方法如下:

  1、找几名资深专家,一起对项目进行WBS,把项目的工作分解为十几条最多二三十条的工作项。

  2、全部专家各自估计每条工作项的工作量,并向其他专家阐述自己的理由。

  3、第一次各专家估出来的结果可能差异比较大,每位专家听取别人的意见后,重新估算。

  4、按照上述办法,各专家反复估算几次,一般次数就是2-4次,各专家估计的工作量会越来越趋近,这个时候取全部专家的平均值。

  普遍认为各专家的经验与知识水平会严重影响结果的准确性,而我的实践经验是:应该让项目组每个人自己来估算,也就是让大家来当专家,在这个基础上可以再增加一两名来自项目组外部的专家。

  有时候觉得估算这个问题搞得太复杂了,各式各样的方法是不是太夸张了?其实最简单的方法就是让负责该项工作的人自己来估计工作量,微软的由底而上的估算方法就是这样做的,可谓返璞归真啊!

微软由底而上的估算方法大致是这样的:对项目各项工作进行分解后(即俗称的wbs:work breakdown structure,工作分解结构),每个任务落实负责人,由负责人对自己的任务进行估计。这个办法有以下好处:

  1、最终该任务是由这个人来完成的,他估计多少时间才能做完,这个时间才是最接近实际的。

  2、负责该任务的人进行估算的时候,肯定需要认真思考这个任务的风险,需要做哪些具体的工作,这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间,这个人就可能不会去思考这个任务了。

  3、做这个任务的人会有被重视和尊重的感觉,他会很重视自己承诺的完成时间,并且想法设法按时间完成。这样会减少很多项目管理时间,因为每个任务负责人都会主动地跟踪好自己的工作。

  其实微软这个方法根本就没有什么特别,所有正常人都可以想到这个方法,但仍然有很多人去追求那些不太靠谱的估算方法。

  这个方法还是有这样的一些问题的:

  1、有人会估算偏小,比方他说需要5天,但往往10天还完不成。

  2、有人估算过于保守。

  3、项目的进度要求就是很紧,基本上你必须在指定时间内完成,估算显得毫无价值。

  第一个问题是比较常见的,但我们要这样想:估不准也比不估算好,估算偏差哪怕超过100%,也比不估算好,至少有个谱。

  大家是会进步的,估不准往往是对任务和自己能力认识不到位,要让大家不害怕估算,只要敢于估算,问题才会暴露出来,才能持续进步。

  第二个问题分两种情况,有些人是确实是过分保守的对自己信心不太足,项目经理可以多多来指导他的工作,看看他具体的进展,让他更加充分地了解任务,更加充分了解自己的能力,增强他的信心,这样他就能持续进步了。而另外一种情况就比较恶劣,少数人会故意增大时间,这样他平时工作不必全力以赴,可以比较悠闲,甚至可以利用工作时间干私事。如果发现这样的情况,就应该严肃处理了,不要做烂好人,这样的人在团队中存在是对团队的极大伤害。

  第三个问题往往是各项目经理心中的痛楚,他们会觉得:实在无奈啊!做项目就是在有限时间有限资源内做不可能完成的任务,在这样的情况下,你就不要跟我扯估算了!

  我们的项目大部分情况都是非常大压力的,应对这样大的压力越需要冷静。实际上大部分项目尽管是有压力,但只要发挥团队的聪明才智,还是可以高效地做好工作的,不需要加班或者少加班。本文稍后会介绍这个问题的应对办法。

  介绍了这么多种估算方法,每种都有很多问题,那到底怎样才能做好项目估算呢?

  软件项目的特点就是项目签订时,价钱是死的,工期是死的,而需求和设计是不明确的。

  我的经验告诉我,功能点法、代码行法这些方法基本上是不靠谱的,我在实际项目中会综合使用Dephi法和由底而上的估算方法,并予以改良,下面介绍一下我的一些心得体会。

  1、项目估算与其说是估出来,还不如说是做出来的。

  假设某项目是这样的情况:

  1)合同签署的金额是100万,工期是3个月。

  2)需求只是大致写了,并不明确。

  3)老板要赚50万,给你的预算只有50万。

  我们很多项目都是这样的情况,不是等你估算出比较靠谱的数字,然后才去报价签合同的,我们经常要在老板指定的预算下完成项目。

  你现在要负责这个项目,你会如何做估算呢?

你需要做好两个事情,才能保证项目实际成本控制在预算内。

  第一个事情,控制好需求。需求不明确,这既是不利因素也是有利因素,应尽量往有利的方向控制。不明确的好处就是你有控制需求的空间,抓住客户的关键需求,简化不必要的花销的需求,能极大地降低项目工作量。

  第二个事情:想尽办法降低开发工作量。不要因为进度紧就不认真思考软件的设计,应尽量采用简单的成熟的设计方案,简化工作。

  2、估算应该持续进行,持续细化。

  项目初期很难对项目做完整估算,但能估计的部分应先估计出来,并且针对不明确的部分安排计划去搞清楚。

  3、估算是项目各种工作估算的总和。

  估算并不是只是得到一个项目估算的总体数字,项目的估算总数其实是由项目各种工作的估算组成的。

  前文介绍了项目的各种工作,每一种工作都需要认真估算。如果估算发生偏差,要能定位到具体是哪部分的估算出问题了,否则估算没有指导项目工作的价值。功能点法、代码行法的估算办法,只能得到一个项目估算的总数,而不能定位到具体的哪一部分工作,这样得到的估算结果难以用来指导项目工作。

  4、估算依赖项目组的整体实力。

  如果你没有软件开发相关经验,只懂理论上的估算,你是不可能做好估算工作的。

  项目组由项目管理、软件设计、编码、测试、实施等各类专业人才组成,每个人在自己方面都是专家,每个人都是整个项目组中最有资格对自己专业方面的工作进行估算。前文列出了的项目各方面的工作,应该由相应的项目成员为主进行估算。

  5、项目组应该不断学习、总结、进步,提高整体水平。

  需求不明确、设计不确定这是项目的特点,我们需要不断地学习来提高水平,将这些不明确的因素逐步明确。

  没有什么妙方能解决这些不明确的因素,靠的还是我们的知识和能力。项目组每个人都应该通过持续估算来发现自己的不足并提高水平。

  6、公司应该定期组织项目资深人士制定估算指南并持续更新。

  我们公司有一份估算模板,里面汇集了以前的估算经验,列出了所有需要考虑的估算内容以及详细的说明。

  我们以前没有估算模板时,估算偏差会达到50%以上,总结经验发现偏差的主要原因是估漏!使用估算模板会帮助我们发现遗漏,后来我们的估算偏差基本可以控制在20%以内。

  前文的“估算要估啥”小节,我列出了项目通常要考虑的各种工作,也列出了容易估漏和估计不足的地方,大家可在此基础上根据自己公司实际情况,修改和扩充这些内容,写出自己公司的估算模板或估算指南。

  先得到项目规模,再由规模导出工作量,这是一个很美好的想法,问题就是和我们的实际情况相去甚远了。

  将工作分解,直到分解到可以估计工作量的程度,这个可能是最土最有效的方法了。但你可能会问,这样的估算方法,项目之间就无法横向比较了?

  项目估算第一目标是用来指导项目工作,如果这个目标都达不到,那么就不需要考虑项目之间的横向比较了。

  另外我要反问:为什么非要用这样的方式来作项目之间的横向比较?有什么好处?国外优秀的软件开发工作室就不会做这样无聊的事情,软件开发可能是人类最厉害的智力活动,你觉得一定能量化度量吗?

  要从本质上提升估算水平,你不太可能用几天时间去突击学习某种估算办法就能胜任项目实际的估算工作。

  提高估算能力靠你长期的积累,你的实力、你的项目团队的综合实力,还有你们公司的综合实力,决定了估算的水平!

  估算是为项目服务的,后文你会看到如何利用估算来管理项目,又如何因应项目实际情况来更新估算。

  下面开始,我们将讲述估算与计划的关系、计划及计划跟踪。 计划有什么内容?

  关于项目计划,我们要先讨论什么是正确的事情,然后再讨论如何做正确的事情,我们先来看看项目计划应该有什么内容?

  让大家做项目计划,很多人以为用Project做一份开发进度计划就完事了。而项目的开发工作只是占了项目工作的其中一部分而已,跟项目所有相关的工作,我们都需要计划。诸如开发计划、测试计划、培训计划、沟通计划、采购计划等等,这些计划的集合,我们称之为项目计划。

  项目计划应该包含以下内容:

  1、项目背景、目标、概述等。

  2、项目需要提交的工作产品,包括内部工作产品和最终工作产品。

  3、风险分析及应对措施。

  4、项目估算。

  5、项目在成本、进度、质量方面的管理目标。

  6、项目人员职责。

  7、对项目各项工作的安排,包括但不限于前文介绍的11种工作,如下:

    1)项目前期工作
    2)商务方面的工作
    3)需求调研方面的工作
    4)软件设计方面的工作
    5)编码方面的工作
    6)测试方面的工作
    7)实施方面的工作
    8)维护方面的工作
    9)项目管理方面的工作
    10)配置管理方面的工作
    11)质量保证方面的工作

  8、需客户或第三方协调的工作计划。

  9、采购计划。

  10、项目所需的各种硬件资源,包括开发环境、运行环境、测试环境等。

  一般来说项目计划有一个主计划,多个子计划。主计划总体描述项目的背景、管理目标、任务概述等总体信息,而子计划则有测试计划、实施计划、培训计划、配置管理计划等。

  下图是主计划目录示例:





下面是进度计划示例:

  该进度计划按版本来组织任务,而每个版本则按照项目管理、需求、设计、开发、测试、发布、实施来组织任务。

  也会有些公司会将所有计划集成一个大计划,计划的组织和表达方式并没有固定方式,上述示例图也只是仅供参考。

  上面讲了很多项目计划的内容,其实我们只是需要想清楚为什么要做计划,你就会知道项目计划应该有什么内容。

  项目计划的几个重要目的:

  1、明确项目人员、各人职责。(当然这可能会在立项通知书中明确。)

  2、明确完成项目所需要的各种资源。

  3、确定项目在成本、进度、质量方面的管理目标。

  4、明确项目的各种工作产品。

  5、落实各项工作安排,保证项目成功。





posted @ 2011-11-23 17:41 顺其自然EVO 阅读(139) | 评论 (0)编辑 收藏

项目估算与计划不是一般的难(上)

 摘要:

  估算、计划、计划跟踪是项目管理的主要工作,难度之高超乎你想象!光靠学习项目管理理论难以管好项目,而往往真能管好项目的都是那些在具体项目中打滚出来的实干人士。本文将会让你全面学习项目估算、计划、计划跟踪的知识,体验实际项目管理的难度,学到提高项目管理水平的一些方法。本文有点长,麻烦你慢慢阅读了!

  大纲:

  1、从建筑工程说起
  2、估算要估啥?
  3、估算如何做出来?
  4、计划有什么内容?
  5、计划是如何做出来的?
  6、如何跟踪计划?
  7、优秀项目经理是怎样炼成的?

  正文:

  从建筑工程说起

  大家都喜欢用建筑工程与软件工程做比较,但我们常常所说的建筑工程只是指建筑施工部分,而不是一个完整的建设项目。我们常常将施工项目管理与软件项目管理进行比较,这是不合适的。

  一个完整的建设项目,由甲方提出需求,设计院根据需求设计出图纸,再由造价公司进行估价,然后公开招标,最后由建筑公司承担建设。相对于软件项目,建筑工程有以下特点:

  1、从需求到竣工,经历需求、设计、估价、建设等环节,每个环节由不同专业的公司或人员完成。

  2、每个环节签署不同的合同,每个环节对应不同的乙方。而软件项目从需求到开发完成,基本上是签署一个合同,只有一个乙方。

  3、整个过程可以认为是瀑布型的,需求和设计会在前期确定,后期基本上不会变动。而软件项目就没有这么理想了,需求和设计不断在变。

  4、建筑工程只会采用最成熟的技术,可行性和设计方案要经过反复论证,你看看港珠澳大桥就论证了好多年了。而软件项目往往要采用不成熟的技术,边设计边尝试。

  5、建筑工程的估算是在需求与设计都确定的基础上估算的。而软件项目不确定的东西太多,估算无法一次成型。

  软件项目管理可能是最复杂的一种项目管理,因为软件项目具备这样的特点:

  1)需求、设计不明确。

  2)项目组需要在需求设计不明确的基础上,承担需求、设计、编码、实施等全部工作。

  如果你是这样项目的项目经理,对你来说是多么大的挑战啊!

  建筑行业发展了这么多年,整个建设工程的各个环节已经有很多专业的公司,有很多设计院、造价公司、建筑公司等。而软件行业,几乎很少见到专业的需求分析公司、软件设计公司。这既是软件行业的特点决定的,也是甲方习惯决定的。我们公司在一些项目尝试和客户签署两份合同,第一份合同只做需求的工作,而第二份合同则完成实现与编码,但客户往往不会接受。

  软件项目管理难归难,但我们还是要去面对的,我们应该如何应对软件项目的估算与计划呢?

  估算要估啥?

  很多人问如何才能做好估算?这个问题是问如何正确做事情的问题,而实际上要回答好这个问题,先要回答估算要估算什么内容的问题,也就是什么是正确的事情问题。

  对于估算要区分以下几种情况:

  1、甲方对项目的估算

  甲方想做某个系统,会根据自己对系统的估计以及自己的预算估计出一个价钱。甲方往往不能准确对项目进行估算,项目的价钱往往是来自预算,而所有甲方都是想在有限的预算内办更多的事情。很多项目需要招标,其实重要目的就是希望找出性价比最高的软件公司。

 2、乙方在投标阶段对项目的估算

  作为软件公司,要判断该项目需要多少的成本,然后稍微“放大”成本作为投标价,这样公司才能有利可图。

  然则现实情况很残酷:

  1)需求大多数是不明确的,甚至甲方对项目的期望都没有想清楚,这样软件公司无从估算。

  2)很多招标其实甲方都“隐含”一个预算价,如果软件公司的报价超出这个价钱,你就别想中标了。而这个预算价往往会小于软件公司对项目的估算,让你难以决定这项目做还是不做好!

  这个阶段的估算是最难做的,除了考虑项目实际工作量,还要考虑项目是否要赚钱、客户关系等因素。

  在我们公司,对于已经产品化的项目,估价比较容易,这其实是一个积累的过程。而对于全新的以前没有多少经验的项目,估价其实也是很难做得很好的,我们往往是由项目经验与技术经验都实力雄厚的总经理来“拍脑袋”拍出来的。所谓“拍脑袋”,其实不代表乱猜,是以雄厚的经验和强大的知识为前提的。

  3、项目组开展项目时对项目的估算

  当我们要真刀真枪开干时,项目组需要对项目的实际工作量有充分的认识,并以此为基础来做好项目工作。

  我们常常所说的项目估算问题,就是指这第三种情况,后文我们将重点讲述这种情况。

  项目估算到底要估什么呢?

  项目的成本包括:人工费、差旅费、业务费用、招待费用、采购费用。

  人工费:

  包括项目组各人的薪金,以及公司运作分摊到项目组各人头上的运作成本。公司运作成本包括非项目组人员的人工、场地设备费用、水电通讯费用、人员培训招聘费用、人员闲适成本、研究失败时的成本、商务活动的成本等。

  一般来说,项目组只需要估算出实际的项目工时就可以了,工时再乘以一个折合的人工成本单价就是项目的人工成本了。

  差旅费:项目组成员因项目出差的交通费、住宿费、通讯费、差旅补贴等。

  业务费用:公司领导、销售人员与客户进行商务谈判、联络所花费的费用,例如送礼、回扣等的费用。这笔费用往往还很大呢,不过项目组一般不需要估算这部分费用。

  招待费用:项目组成员因工作需要,和客户相关人员吃饭、娱乐的相关费用。例如:需求调研期间和客户吃饭;项目实施阶段因推动验收和客户一起加班,加班后请客户吃饭。这笔费用一般不会很大,一顿饭一般就是几十到一百多元,一个项目也不会请很多次吃饭。

  采购费用:采购项目所需的软硬费用,如数据库平台、服务器等,如果项目部分内容要外包出去,那还要包括外包的费用。有时候这笔费用会比较巨大,但这些费用都很容易估计。

  以上费用最难估计的就是人工费,人工费我们以工作量来考虑,下文开始我们重点讲解项目工作量的估算。

  如何估计项目的工作量呢?

  简单地说,我们需要将项目的所有工作进行分解,直到每个分解后的工作都能估计出具体的所需时间来。

  那项目的“所有工作”包含什么呢?回答这个问题其实就是回答“估算要估啥?”这个问题了。

  一般情况下,项目工作包括以下内容:

  1、项目前期工作。

  包括商务谈判、技术方案准备、投标准备、前期需求调研、前期技术研究等工作。当你接手项目的时候,这些工作往往已经做了,你估算项目工作量时,不要忘记这些已经花费的工作量。

2、商务方面的工作。

  从客户开始有意向做这个项目,一直到项目验收、维护,整个过程中都会贯穿商务活动。前期的商务活动有商务谈判、投标准备、合同签署等,而签订合同后的商务活动有项目请款和催款、促进验收等。某些商务活动属于灰色地带,如请客、送礼等,这些往往是花费巨大的。一般来说我们不需要估算灰色地带的商务活动,灰色地带的商务活动公司的高层会考虑的了,但我们需要对正常的商务活动进行估算。

  3、需求调研方面的工作。

  需求调研是一个“反复”的过程,一般来说能在前期确定80%已经是很了不起的成绩。

  需求调研的工作量一般由三部分组成:前期调研的工作量,后期需求细化的工作量,后期需求变更的工作量。

  前期调研的工作包括:项目组内部讨论、确认,与客户讨论、确认需求,编写需求规格说明书及组织评审等工作。

  需求细化是指对之前已确定需求的进一步具体化、优化或轻微调整,如:界面细节的确认、各业务概念的具体化等。需求细化一般是可预见可估计的。

  需求变更是指对之前已确认需求的“否定”,变更的原因主要有两种情况:一是之前需求调研工作没有能做好,理解错客户的真正意图或者是遗漏重要的需求;二是客户业务情况发生变化,与之前情况已经不同。第一种情况应该尽量避免,而第二种情况一般是难以估计的。需求变更时需重新估算,和客户签订需求变更协议。

  我们一般会充分估计前期需求调研工作量以及需求细化工作量,对于需求变更则暂不考虑,因为一旦变更我们会和客户确认需求变更的费用。但有些项目有很特殊,项目报价中预留了少量的需求变更费用,这时估算中就需要适当考虑需求变更了。

  4、软件设计方面的工作。

  不少项目为了“赶”进度,设计文档很少,然则项目真的很简单、不需要仔细考虑设计的情况是非常少的!

  软件设计工作包括:

  1)系统架构设计。

  2)技术方案选择。

  3)关键模块设计。

  4)数据库设计。

  5)用户体验设计。

  以上内容具体项目可以有所取舍,但不可能全部都不用考虑。

  另外不要忘记了以下两方面的工作:

  1)各类设计工作产品的讨论、确认、评审工作。

  2)设计细化与优化工作。设计是需要持续改进的,不要忘记这些工作。

  5、编码方面的工作。

  要注意不要遗漏代码返工、代码评审、代码调试、修复缺陷的工作量。

  需求、设计没有做好,编码质量不过关,这些会严重增加代码返工、代码调试、修复缺陷的工作量。代码首次完成的时间如果是100小时,那么后面代码调试、修复缺陷等所需要的时间可能是200小时以上,往往我们估算时只考虑了前面的100小时。

  6、测试方面的工作。

  测试工作包括测试计划、测试用例、测试文档评审、测试环境准备、测试数据准备、执行测试、回归测试等内容。

  软件测试一般要经历多轮,我们估算往往只考虑了第一轮,就好象软件只需要测试一回就不用再测试了。而测试环境准备、测试数据准备这些工作也很容易在估算时“忘记”了。

7、实施方面的工作。

  实施工作包括实施计划、实施方案的准备,编写管理员手册、用户手册,熟悉系统,搭建实施环境并进行演练,在客户现场安装、部署、调试系统,培训客户,协助系统上线,推动验收等工作。

  我们公司通常的做法是:

  1)系统在客户处部署后,会推动客户进行初步验收,初验标准是系统的所有功能跑就可以了。初验成功,客户需要支付相应的项目款项。

  2)初验后要协助客户让系统正式上线,让客户真正用上这套系统,推动最终验收。

  影响终验主要有两个因素,一个是客户在使用系统过程中会提出各式各样的问题,如果在需求范围内应该都予以满足;而另外一个影响因素是客户会因为各种各样的原因推迟使用系统,或者是使用不充分,让项目终验遥遥无期。估算时需要充分考虑这两个影响因素。

  8、维护方面的工作。

  项目终验后,一般都要提供半年到一年的维护服务,维护器后项目还会有最后一笔款项。

  维护期比较长,事情繁杂,一个不小心就很容易估算不足。

  维护的工作一般有:

  1)用户培训;

  2)协助客户录入资料;

  3)修复被破坏的数据以及数据库;

  4)修改客户或内部发现的软件缺陷;

  5)代码重构,提高部分程序的性能与可靠性;

  6)修改一些界面文字或显示风格;

  7)回答客户反馈的一些安装与操作疑难问题;

  8)提供合同中所要求的其它特殊软件维护服务。

  在维护期,往往还需要发布数个小版本来解决客户的问题。

  9、项目管理方面的工作。

  项目管理工作主要有编制项目计划、持续更新项目计划、跟踪计划执行、各种工作协调、指导项目组成员完成工作等等。

  项目管理工作量一般占整个项目工作量的10-20%,项目不明确的东西越多、项目组成员水平越不足、项目组成员之间工作磨合度越不好,管理工作量就越大。

  项目管理在项目进行整个过程都需要持续进行,一般来说前期工作量会比较大,版本发布前后阶段工作量也会比较大。项目管理前期工作抓得紧抓得好,会大大减轻后期的工作量。

 10、配置管理方面的工作。

  什么叫配置管理?简单说就是对工作产品的管理,包括对各类文档、各种记录、代码、数据库、脚本、安装程序、组件等等的管理。

  软件生产过程的工作产品可分为两类:中间产物和最终产物。

  中间产物有:

  1)工程类:需求文档、设计文档、测试方案、代码、数据库脚本、数据库、测试脚本等。

  2)管理类:开发计划、测试计划、培训计划、采购计划、实施计划等。

  3)记录类:会议记录、邮件、缺陷等。

  最终产物是指最终会交付给客户的东西,一般有:组件、安装程序、数据库、用户手册、管理员手册等。

  针对不同的工作产品应采取不同的针对性管理办法,很多公司会制定单独的配置管理计划。

  11、质量保证方面的工作。

  严格来说,质量保证是靠项目组全体来保证的,这里所说的质量保证是“狭义”的质量保证,是指:要确保项目组按照既定的规定、过程、标准来工作,需按照既定的格式要求产出相应工作产品。

  对于以上十一点,实际项目估算中往往出现这样的问题:

  1)忘记包含项目前期工作的工作量。

  2)没有考虑商务、维护、配置管理、质量保证方面的工作。

  3)需求调研、软件设计、编码、测试、实施方面的工作估计过少。

  4)项目管理方面的工作量估计不足。





posted @ 2011-11-23 17:30 顺其自然EVO 阅读(191) | 评论 (0)编辑 收藏

手机性能测试小结

 1、测试范围

关于性能测试范围的框架图

  2、性能测试项目

  2.1 模拟器测试项目

  2.1.1 时间相关项目

  2.1.1.1 长时间待机项目

  ◆ 手机在通过长时间待机后(时间范围需要讨论):手机的各个功能是否正常(各个功能包括测试规程里手机的所有功能,测试功能范围需要讨论,暂时定为只初步实现功能)(由于手机可能由于电量不足不足以完成所有功能的测试,故最好选择几台机器同时进行该项目测试)

  ◆ 手机长时间CS业务(时间范围需要讨论):手机电池是否发热;CS业务未中止前是否功能正常;CS业务中止后其他功能是否正常(其他功能范围需要讨论)

  ◆ 手机长时间PS业务(时间范围需要讨论):手机电池是否发热;PS业务未中止前是否功能正常;PS业务中止后其他功能是否正常(其他功能范围需要讨论)

  ◆ CS和PS组合测试(GPRS、CMS和通话是否能支持并发还未确定,详细参照并发功能)

  ◆ 手机长时间执行其他持续性业务(需要测试的业务包括:媒体播放器、Flash播放器、录音机、收音机、大量程序备份)同CS和PS业务测试内容类似;

  2.1.1.2 限定时间反应测试

  ◆ 手机开机时间测试:指从用户按下开机键(终端上电、系统引导、启动任务、搜索网络、完成位置更新)到终端进入待机界面,提示用户可以进行正常服务的总时间;

  ◆ 手机关机时间测试:是指从用户按下关机键(终端完成网络detach、将RAM中修改过的数据写回flash)到终端完全下电所需的总时间;

  ◆ CS业务接入时间测试:指在进行语音或视频电话时从按下拨号键到听到对方回铃声所需总时间,由于该过程需要在网络侧分配资源,所以测试结果可能会受到当前网络资源可用程度的影响(包括短信发送测试);

  ◆ PS业务接入时间测试:指在进行数据业务时从开始连接到能正常进行数据业务所需总时间。

  ◆ 本地应用的操作时间测试:指完成某些本地操作维护功能所需的时间;

    ● 查看数据库文件如:电话薄、短信、邮箱、备忘录、各种文件;存储和修改数据库,如:存储联系人、存储短信、存储邮件、存储各种文件;删除数据库文件;

    ● 打开浏览器;播放多媒体和Flash文件(包括图片);

    ● 在各个运行的进程间切换;持续性功能执行时中止操作;

    ● 程序容错所需时间测试,如:路径指向的目标文件不存在、向数据库写入非法的字符、剪切或删除已经执行的文件、写入数据库空间不足等;

    ● 目标(是否包括当前操作程序)程序无响应自动中止的时间

  ◆ 按键时间响应测试:在各个模块规程中已经体现

2.1.1.3 次数相关项目

  次数相关的性能测试是测试终端重复稳定地进行某项功能的能力,主要是对成功率的测试。重复操作包括很多对象被多次创建和释放,因此可能会发现潜在的内存泄漏等问题。

  具体测试项目在各个规程中带有可测性的项目进行选取,由于项目众多,需要重新安排优先级进行选取;

  优先级选取标准:

  ◆ 基本功能优先:主要指模块的主要功能,如:拨号盘模块就应该是拨出和呼入属于高级项目;对于拨号盘内号码的不断写入和删除则属于低级项目;

  ◆ 内存使用较大的操作优先:考虑到测试目的主要是检测内存泄漏问题,故应该选择内存使用率较大的项目进行测试,如:媒体播放器不断选择播放文件进行播放属于高级项目;写字板不断打开文本文件属于低级项目;

  2.1.1.4 并发业务

  并发测试主要是测试终端同时进行多项业务时表现出的处理能力。目前按照并发组图进行测试。

  2.1.1.5 负载测试

  系统配置不变的条件下,在一定时间内,终端在高负载情况下的性能行为表现。

  ◆ 数据极限值测试:主要测试当数据传输或写入数据库或内存接近或到达极限值时,功能是否正常;

    ● 通过GPRS下载或上传数据接近或达到GPRS极限值时,数据传输是否正常(主要是发送邮件和进行下载数据的操作)

    ● 内存高负载测试:主要测试在内存在高负荷状态下的性能行为表现。主要是将时间相关、次数相关、并发业务融合到一起进行测试,查看手机是否正常。

  2.2 真机测试项目

  2.2.1 包括模拟器测试的所有项目(如果要运用自动化测试,需要搭建环境和在真机上提供一些接口)

  2.2.2 其他可运用于真机的测试项目(需要裸机)

  2.2.2.1 抗摔性测试

  抗摔性测试是由专门的Pprt可靠性实验室来进行,0.5m的微跌落测试要做300次/面(手机有六个面)。而2m的跌落测试每个面需各做一次,还仿真人把手机抛到桌面,而手机所用的电池,也要经过最少4m的高度,单独的向着地面撞击跌落100次而不能有破裂的情况出现。

  2.2.2.2 高/低温测试

  让手机处于不同温度环境下测试手机的适应性,低温一般在零下20摄氏度,高温则在80摄氏度左右。没有温度箱的情况下,低温环境可以选择冰箱,高温环境可以在夏天的室外进行。

  2.2.2.3 高湿度测试

  用一个专门的柜子来作滴水测试,仿真人出汗的情况(水内渗入一定比例的盐分),约需进行30个小时。没有设备的情况下,可以选择蒸笼代替。

  2.2.2.4 百格测试(又称界豆腐测试)

  用H4硬度的铅笔在手机外壳上画100格子,看看手机的外壳是否会掉下油漆,有些要求更严格的手机,会在手机的外壳上再涂抹上一些“名牌”的化妆品,看看是否因有不同的化学成分而将手机的油漆产生异味或者掉漆的可能。

  2.2.2.5 按键寿命测试

  借助机器以给设定的力量对键盘击打10万次,假使用户每按键100次,就是1000天,相当于用户使用手机三年左右的时间。没有设备的话,只能手动了-_-!

  2.2.2.6 沙尘测试

  将手机放入特定的箱子内,细小的沙子被吹风机鼓吹起来,经过约三小时后,打开手机并察看手机内部是否有沙子进入。如果有,那么手机的密闭性设计不够好,其结构设计有待重新调整。

  以及其他还有很多关于成品机的测试案例,根据最终测试项目和测试环境进行筛选。

posted @ 2011-11-23 17:19 顺其自然EVO 阅读(560) | 评论 (0)编辑 收藏

黑盒测试——测试准备阶段

     摘要: 黑盒测试——测试准备阶段1、概述  1.1 黑盒测试的概念  黑盒测试(black box test)也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正...  阅读全文

posted @ 2011-11-23 17:15 顺其自然EVO 阅读(844) | 评论 (0)编辑 收藏

一个女研究生(高级测试工程师)的职业选择

 公司选择

  终于下定决心要离开,我想去的是重视测试的外企或大公司。

  我的逻辑很简单,测试在国内还未获得足够的重视,即使很多公司有测试,也是一些非常表层的测试,只有在规范的公司的测试才做得深入。在长达两个多月的面试和等待中,终于等来了我想要的机会,不过,选择摆在面前的机会,也不是一件轻松的事情。

  公司A,是一家具有一百多年历史的外企, 也是在IT行业非常有名的公司,专注于通信领域。这个公司提供给我的机会是高级软件测试工程师,主要负责软件测试,年薪比现在高50%。不过我看重的并不是这个公司提供给我的职位,也不是薪金,这些对我而言都没有太大的吸引力。吸引我的是这个公司本身完善的管理制度、规范的测试流程、先进的测试工具与测试方法、完善的培训机制以及全球共享的资源,当然,更重要的是公司的文化。

  我现在所积累的测试技术,都是自己在测试的过程中摸索出来的,没有经过规范的培训;所使用的测试工具,也是自己在业余时间学习的,也没有深入应用到测试中。虽然说积累了一些测试经验,但还不够深入、也不够专业,我希望自己能够有一个完善的培训机会,也希望自己能够系统地深入学习测试技术与测试工具。而且,在一个全球化的公司工作,不但可以增长自己的见识,也可以进一步提高自己的整体素质,还可以加强自己的英文水平。

  我对这个公司的印象很好,这源于业内对它的评价,也源于在面试过程中面试官问问题的水平以及对应聘者的态度。面试是一个双向选择,是企业在考核应聘者,也是应聘者在选择企业。在面试过程中的有一个小细节让我非常感动,hiring manager在用英文跟我交谈的过程中,有句话听不明白,重复问了她一遍,但她第二次给我复述后我还是不能马上领悟某个单词的意思,结果,她很耐心地换了一种方法问我,当我回答清楚她的问题后,自然也马上明白她所说的单词的中文含义了。

  这是一个小小的细节,但透过这个细节,可以体会到她对人的尊重,她没有因为我不明白某个单词否认了我的英文水平或我的能力,跟着这样的manager干活,是一件幸运的事情。而且,不管是hiring manager的技术面试,还是PM的项目面试,或者是后来的HR Manager的综合素质面试,他们所问的问题都非常专业,与他们的交谈也非常愉快。不过,在这样大型的外企工作,在管理层的发展机会相对较少,带领团队干活的机会相对也较少。而我,相对于单纯的技术而言,更喜欢一些沟通协调的工作。

  公司B,是一家在国内迅速发展的私企,也是在国内非常有名的公司,而且很需要人才也很珍惜人才。这个公司提供给我的机会是高级软件测试工程师,主要负责软件测试和流程改进,年薪是现在的两倍。说句心里话,这个公司最吸引我的是薪金,在那里干一年就可以有我现在两年的收入,不能不另人心动。而且,更重要的是,他们对我的赏识与信任,这样的工资水平自然是对我能力的肯定,也是希望通过薪金吸引我过去。

  在面试的交谈中,他们对我的CMMI5实施经验以及缺陷追踪经验很感兴趣,希望我能过去跟他们一起规范公司的测试与开发流程,这自然提供了我一个施展的机会。公司B的规模,与我现在公司的规模相差不大,工作环境也相差不大,也是一个给活你干让你自己去摸索自己成长的公司,这样的跳槽,在工作环境或平台上并没有太大的突破,变化的是我的报酬。我已经这样摸索了四年,我会想换一个平台,接触一些规范的管理、接触一些先进的技术,当然,也想得到一些规范的指导。

  公司C,是国内通信行业非常出名的一个国企,是大多数女孩子向往的地方。这个公司提供给我的机会是测试主管,年薪也是比现在高50%。吸引我的,是测试主管这个机会,相对于技术,我更擅长也更喜欢带领一个团队,我喜欢沟通协调多过技术,这也是我自己想发展的方向。不过,我不太喜欢国企,不喜欢里面的形式化与口号,也不喜欢里面死板的管理,更加不喜欢里面复杂的人际关系。而且,在面试时他们问的问题不够专业,我感觉他们并没有考核出我的真实水平,就这样把一个主管的机会给了我,反而让我觉得公司不够专业。

  我的大多数朋友,在选择的时候看的都是工资水平,他们建议我哪个公司给的工资高就去哪个公司,因为生活很现实,我们需要生存。也有朋友建议我去国企,因为他们觉得,在国企相对来说稳定、悠闲、福利好,对于女孩子来说,是一个很不错的选择。而我自己,在意的是在这个公司工作三年或五年或十年后,我会是怎样的一个人。

  如果在一个公司工作三年后,我还是跟现在差不多,那么三年后我肯定是失去了竞争力。现在的工资肯定是选择的一个重要因素,但我觉得目光不能停留在眼前,而是这个选择是否会让自己开心、是否能让自己增值、是否有利于长远的发展。早在一年前,我的朋友就建议我离开,因为我的工资与我的付出不合理,但我还是坚持留下,一方面是我在现在的团队中干得很开心,这是钱所不能买到的,另一方面是我觉得在现在的公司还有很多机会可以让我增值,也有很多机会让我学习让我成长。如果当初选择了离开,我就不可能有机会主导一个全新架构的系统开发,也不可能有机会参与CMMI L5的流程改进与评估,我也就可能不会成长成今天可以主动选择机会的人了。所以,我觉得,人的眼光不能只看眼前,而要放得更远一些。

  公司A是我最想去的公司,因为直觉告诉我在里面我会有一个质的改变,在那里会学习到很多先进的管理方法与测试 ,但我也会有些担心机遇不多,我想往管理方面发展的机会不多。如果没有公司B翻倍的年薪以及他们对我的赏识与信任,我会毫不犹豫地选择公司A,但翻倍的薪金是一个诱惑,他们想让我主导公司的流程改进也是一个诱惑。

  相对于公司A来说,B公司会有更多的机会让我往管理层发展。不过,公司B与我现在的工作平台差不多,自己在技术上摸索了这么长时间,一点一滴的积累,自然也让我成长了,但这样的一个积累会有一个局限性。在我的身边,我的测试水平是不错的,但是,如果跟国际水平相比,我还有很多不足的地方,还有很多需要学习的地方。而且,公司也B不会有那么完善的测试环境,也不会舍得像公司A那样投入那么多的资源在软件测试中,测试肯定不会像公司A那样专业、规范。

  而我自己,很想与别人分享自己所积累的东西,同时也希望能够以学习的姿态成长,这是A公司能给我而B公司所不能给的。如果真的用心去学、用心去做,我相信在公司A会有一个质的提高,也会在公司A会有一个更加好的发展,因为在外企,只要有能力只要肯努力,机会是公平的。我也相信,自己的能力不差,只要用心做好每一件事情,机会自然就来了。退一步说,即使没有往管理层发展的机会,从里面出来,也会很不一样。那50%的年薪,就当是继续深造的学费。毕竟,机会的选择,不能只看钱,也不能只看眼前。

posted @ 2011-11-23 17:04 顺其自然EVO 阅读(175) | 评论 (0)编辑 收藏

配置Linux服务器的网络

 服务器的系统安装好后,接下来就要在机房或内网环境中配置它的IP了,这是最重要的一个环节。下面我就以64bit Centos5.5服务器为例来说明如何通过命令或图形来配置Linux服务器的IP、网关、DNS,以及如何用命令查看Linux的进程或网络连接等。

  配置Linux服务器的网络

  1、手动修改配置网卡文件

  手动配置网卡是最直接的方式,熟练的系统管理员在平时维护系统的时候更喜欢使用这种方式,因为手动配置有如下优点:

  熟悉命令之后,手动配置更快速,并且不需要重新启动。

  能够使用配置命令的高级特性。

  更容易维护配置文件,找出系统故障。

  能更深刻地了解系统配置是如何进行的。

  那么,下面就介绍一下如何手动配置网卡文件。首先检查网卡是否正常安装,Centos5.5的驱动非常强悍,基本上市面上的服务器网卡都可以正常安装,我们可以用如下命令检查网卡是否正常安装:

  • [root@localhost ~]# lspci | grep Ether  
  • 06:07.0 Ethernet controller: Intel Corporation 
    82541GI Gigabit Ethernet Controller (rev 05)  
  • 07:08.0 Ethernet controller: Intel Corporation 
    82541GI Gigabit Ethernet Controller (rev 05) 
  • root@localhost~]# dmesg| grep error
  •   一般来说,2.4版本以后的Linux可以支持的网卡芯片组驱动已经很完备了,包括著名厂商(如Intel),以及使用广泛的RealTek、Via等网卡芯片,所以大家可以很轻松地使用它们的网卡。我们还可以用lsmod命令通过加载模块的方法来加载特殊的网卡。

      在配置Linux网络设备时,它们分别被赋予别名,该别名由一个描述性的缩略词和一个编号组成。第一个设备的编号为0,其他设备依次为1、2、3……其中,eth0、eth1是以太网卡接口,大多数的以太网卡都用此名表示,包括许多并行端口以太网卡,接下来主要讨论这种类型的网卡。与网卡相关的TCP/IP网络配置文件是/etc/sysconfig/network-scripts/ifcfg-ethx,其中x是从0开始的,第一个以太网配置文件即/etc/sysconfig/network-scripts/ifcfg-eth0。以我的公网机器举例说明如下:

  • [root@localhost ~]# vim /etc/sysconfig/network-scripts/ifcfg-eth0  
  • DEVICE=eth0 
  • BOOTPROTO=none 
  • HWADDR=00:14:22:1B:71:20  
  • IPV6INIT=yes 
  • IPV6_AUTOCONF=yes 
  • ONBOOT=yes 
  • NETMASK=255.255.255.192  
  • IPADDR=203.93.236.146  
  • GATEWAY=203.93.236.129  
  • TYPE=Ethernet 
  • PEERDNS=yes 
  • USERCTL=no 
  • NETMASK=255.255.255.192  
  • IPADDR=203.93.236.146
  •   其中:

      DEVICE=eth0表示设定网卡的名称,它要跟文件名称对应。

      BOOTPROTO=none是启动时IP取得的协议,这里是固定的(此值也可以为static),如果是动态主机的话,要改成dhcp。

      HWADDR=00:14:22:1B:71:20指网卡的MAC地址,可以用ifconfig来取值。当然了,如果我们不指定这项的话,Centos5.5也会默认指定。

      IPV6INIT=yes表示支持IPv6,no表示不支持。

      IPV6_AUTOCONF=yes表示自动配置IPv6。

      ONBOOT=yes表示在开机的时候启动网卡。这里肯定要选择yes了,如果选择no的话则网卡在系统引导时不会被分配IP地址,那就很麻烦了。

    NETMASK=255.255.255.192和IPADDR=203.93.236.146,这两个就没什么好说了,这是我们的IDC分配给公网的IP地址和子网掩码,强悍的是,顺序反了一样生效。

      GATEWAY=203.93.236.129是网关地址。

      TYPE=Ethernet表示网卡的类型为以太网型。

      PEERDNS=yes表示允许从DHCP获得的DNS覆盖本地的DNS。

    网卡和DNS配置界面

      USERCTL=no表示不允许普通用户修改配置。

      配置完成后记得保存,然后重启服务server network restart即可生效。当然了,如果嫌麻烦,可以用Centos5.5的setup工具中的“网络配置”来操作,方法很简单,如图1-23所示。这里就不浪费篇幅了。

      2、修改机器的hostname

      下面来修改机器的hostname,如下所示:

  • vim /etc/sysconfig/network  
  • NETWORKING=yes 
  • NETWORKING_IPV6=yes 
  • HOSTNAME=localhost.localdomain
  •   HOSTNAME后面紧跟的就是我们的主机名,这里是系统默认的localhost.localdomain。

      HOSTNAME的后面即可接我们要更改的主机名,重启后可以用hostname命令来查看。如果只是简单地用命令hostname,仅仅对当前生效,重启后会失效,比较好的方法是写到文件中保存。

      3、修改主机名查询静态表/etc/hosts

      Linux主机名的相关配置文件就是/etc/hosts,这个文件告诉本主机哪些域名对应哪些IP,哪些主机名对应哪些IP。下面对/etc/hosts的格式进行说明。一般/etc/hosts的内容会与下面的内容类似:

  • 127.0.0.1 localhost.localdomain localhost  
  • 192.168.21.100 webserver.cn7788.com webserver  
  • 192.168.21.111 ftp.cn7788.com ftp
  •   通常hosts文件的每行为一个主机的信息,并且每行由3部分组成,各个部分间由空格隔开,这三部分所表示的意思如下。

      第一部分:网络IP地址

      第二部分:主机名或域名

      第三部分:主机名别名

      当然每行也可以是两部分,即主机IP地址和主机名,比如:192.168.21.100 webserver.cn7788.com另外,hosts文件中以#号开头的行是说明,不会被系统解释。

      这里稍微解释一下主机名(hostname)和域名(domain)的区别:主机名通常在局域网内使用,通过hosts文件,主机名就被解析到对应的IP地址上;域名通常在Internet上使用,但如果本机不想使用Internet上的域名解析,可以更改hosts文件,加入自己的域名解析。

      目前/etc/hosts多用于集群环境或开发测试环境(以免重新架构内网DNS服务器)。

      4、配置DNS域名解析服务器

      配置DNS域名就比较简单了,只需要配置/etc/resolv.conf文件即可,如下所示:

  • vim /etc/resolv.conf  
  • nameserver 202.96.128.86  
  • nameserver 202.96.128.166
  •   resolv.conf中最重要的选项是nameserver,它给出了要使用的名字服务器的IP地址。如果你通过nameserver选项指定了几个名字服务器。那么它们会以给出的先后顺序来决定主从服务器,如果主服务器上没有对应的域名,系统会自动从DNS上寻找。因此,你首先应该给出最可靠的服务器。目前,它至多支持3个服务器名字。

    posted @ 2011-11-23 17:00 顺其自然EVO 阅读(233) | 评论 (0)编辑 收藏

    Spring MVC拦截器实现分析

    Spring MVC拦截器实现分析

     一、Servlet Filter与Spring interceptor的执行顺序

      Filter有顺序吗?我们怎么控制filter的执行顺序。通过Tomcat的代码分析,servlet在Filter执行完成后才调用,如有多个filter怎么控制执行顺序,首先会想到在web.xml配置某个参数,例如order之类的,但查找一下一番,servlet并没有这个参数。试试filter Mapping的配置的先后顺序,果然有效,原来filter的执行顺序就考filter mapping在web.xml中的顺序。

      spring interceptor也是这样的执行顺序,不过interceptor多一个配置参数order通过他也可以来实现interceptor的执行顺序。很多应用场景中,执行顺序还是重要的,比如cache和transaction interceptor的执行顺序,很显然cache应该在transaction之前,这样发现命中了就不用打开事务,如果transaction在前,每次都打开事务即使cache命中,这是一个无谓东动作。

      二、利用springMVC的interceptor实现页面性能监控(Filter亦可)

      调优第一步,找出耗时比较长的页面进行优化。利用interceptor能轻易搞定。interceptor提供了preHandle和postHandle以及afterCompletion三个方法。preHandle调用controller具体方法之前调用,postHandle完成具体方法之后调用,afterCompletion完成对页面的render以后调用,至此整个页面渲染完成。也就是说我们在preHandle记录开始的时间,在afterCompletion记录结束的时间,就可或者整个页面生成的时间。Spring自带StopWatch工具类来实现时间跟踪,关键一点interceptor不是线程安全的。我们需要借助threadlocal来实现线程安全。

  • @Override 
  •     public boolean preHandle(HttpServletRequest request, 
  •             HttpServletResponse response, Object handler) throws Exception { 
  •         if(usePerformance){ 
  •             StopWatch stopWatch = new StopWatch(handler.toString()); 
  •             stopWatchLocal.set(stopWatch); 
  •             stopWatch.start(handler.toString()); 
  •         } 
  •          
  •         return true
  •     } 
  •  @Override 
  •     public void afterCompletion(HttpServletRequest request, 
  •             HttpServletResponse response, Object handler, Exception ex) 
  •             throws Exception { 
  •         if(usePerformance){ 
  •             StopWatch stopWatch = stopWatchLocal.get(); 
  •             stopWatch.stop(); 
  •             String currentPath = request.getRequestURI(); 
  •             String queryString  = request.getQueryString(); 
  •             queryString = queryString == null ? "":"?" + queryString; 
  •             log.info("access url path:" + currentPath + queryString +  " |time:" + stopWatch.getTotalTimeMillis()); 
  •             stopWatchLocal.set(null); 
  •         } 
  •     }
  •   如果你没有使用springMVC可以使用filter来完成:

  • stopWatch.start(); 
  • doFilterChain(); 
  • stopWatch.stop();
  •   三、SpringMVC 拦截器实现分析

      SpringMVC的拦截器不同于Spring的拦截器,SpringMVC具有统一的入口DispatcherServlet,所有的请求都通过DispatcherServlet,所以只需要在DispatcherServlet上做文章即可,DispatcherServlet也没有代理,同时SpringMVC管理的Controller也不有代理。哪不难想到我们在执行controller之前做某些动作,执行完毕做某些动作,render完成做某些动作。SpringMVC的拦截器对应提供了三个preHandle,postHandle,afterCompletion方法。只需在三个方法内写我们需要的逻辑就行,多了都是废话,还是代码实在。

  • HandlerInterceptor[] interceptors = mappedHandler.getInterceptors(); 
  •                 if (interceptors != null) { 
  •                     for (int i = 0; i < interceptors.length; i++) { 
  •                         HandlerInterceptor interceptor = interceptors[i]; 
  • //ha.handle是调用具体的controller在此之前执行preHandle                      if (!interceptor.preHandle(processedRequest, response, mappedHandler.getHandler())) { 
  •                             triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, null); 
  •                             return
  •                         } 
  •                         interceptorIndex = i; 
  •                     } 
  •                 } 
  •                 // Actually invoke the handler. 
  •                 mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
  •   完成调用之后,调用render(),最后执行afterCompletion()。

  • if (interceptors != null) { 
  •                 for (int i = interceptors.length - 1; i >= 0; i--) { 
  •                     HandlerInterceptor interceptor = interceptors[i]; 
  •                     interceptor.postHandle(processedRequest, response, mappedHandler.getHandler(), mv); 
  •                 } 
  •             } 
  •         } 
  •         catch (ModelAndViewDefiningException ex) { 
  •             logger.debug("ModelAndViewDefiningException encountered", ex); 
  •             mv = ex.getModelAndView(); 
  •         } 
  •         catch (Exception ex) { 
  •             Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null); 
  •             mv = processHandlerException(processedRequest, response, handler, ex); 
  •             errorView = (mv != null); 
  •         } 
  •         // Did the handler return a view to render? 
  •         if (mv != null && !mv.wasCleared()) { 
  •             render(mv, processedRequest, response); 
  •             if (errorView) { 
  •                 WebUtils.clearErrorRequestAttributes(request); 
  •             } 
  •         } 
  •         else { 
  •             if (logger.isDebugEnabled()) { 
  •                 logger.debug("Null ModelAndView returned to DispatcherServlet with name '" + getServletName() + 
  •                         "': assuming HandlerAdapter completed request handling"); 
  •             } 
  •         } 
  •         // Trigger after-completion for successful outcome. 
  •         triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, null);
  • posted @ 2011-11-23 16:58 顺其自然EVO 阅读(8208) | 评论 (0)编辑 收藏

    C语言CGI和Apache服务器的开发环境

    今天中午在研究c语言gui时看到了cgi。之前花了些时间找c语言的gui框架,也找到了几个暂时比较满意的,但是看到了cgi后觉得也可以尝试一下。在web开发方面有点经验,或许会简单一些。Google了一下,现在讨论cgi,尤其是c语言cgi的话题已经很少了,花了些精力,总算搭建好了一个可用的开发环境,也运行出了程序。下面简单分享一下,我的实验过程。其实是很简单的事情。

      首先,需要用到的这些工具和代码:

      C语言编译器,我用了IDE(Vsiual C++ 2008 Express Edition,下面称VC2008),其他编译器(gcc、tcc等)也可;

      Apache服务器,我用的是USBWebSever中包含的Apache服务器(下载地址) ,这是个AMP服务器套装,不用安装即可使用,而本地安装的Apche服务器也可以使用;

      cgic(下载地址 ),这是用ANSI C写的一个cgi库,这里用它提供的代码来测试我们的运行环境,其他规范的c代码也是可以的;

      接着,编译C语言的cgi程序。

      在VC2008里面建一个Visual C++空项目;

      从刚才下载的cgic代码压缩包中提取cgic.h、cgic.c和cgictest.c三个文件,添加到新建的项目里面;

      打开当前项目的属性页(在解决方案资源管理器右击项目名称,选菜单中的属性),在配置属性-C/C++-预处理器中找到预处理器定义,添加WIN32;

      这时可以按F7生成解决方案,VC2008开始编译代码和链接,生成可执行文件(.exe)。报出若干警告,忽视之。这样cgi程序就做好了。

      然后,配置和启动Apache服务器。

      对于本地安装的Apache服务,需要修改配置文件httpd.conf若干内容(参考文章链接),如下:

    1. ScriptAlias /cgi-bin/ "E:/apache2/Apache2/cgi-bin/"  
    2. <Directory "E:/apache2/Apache2/cgi-bin"> 
    3. AllowOverride None  
    4. Options ExecCGI  
    5. Order allow,deny  
    6. Allow from all  
    7. </Directory> 
    8. AddHandler cgi-script .exe .pl .cgi

      其中E:/apache2/Apache2/cgi-bin/要改成你准本放cgi程序的目录。修改好httpd.conf后可能需要重启Apache服务器

      对USBWebSever,似乎不用修改httpd.conf。如果需要,应该对settings目录下的httpd.conf类比上面的内容进行修改,文中{rootdir}/cgi-bin/这类文字最好不要修改!修改好以后,双击USBWebSever.exe就可以启动Apache服务器了。

      最好把刚才生成的cgi程序(.exe文件),复制放到上文中提到的/cgi-bin/目录下,文件名最好改成index.cgi这样的形式。对于USBWebSever,cgi-bin目录应该是root目录下的cgi-bin目录(如果没有要新建一个),不是和USBWebSever在同一目录下的cgi-bin目录。我的目录结构是这样的

      打开浏览器输入http://localhost:8080/cgi-bin/index.cgi(地址取决于你自己的具体设置),就可以看到cgi程序已经运行了。

    posted @ 2011-11-23 16:55 顺其自然EVO 阅读(557) | 评论 (0)编辑 收藏

    在做性能测试之前需要知道什么

    最近群里来了很多新朋友,大都是新做测试或准备做测试工作的,见好多新手上来就问关于LoadRunner的使用上的问题。对性能测试的理解也不是太清楚。公司说让他们对系统做个性能测试,他们听说LoadRunner是做性能测试的,在网上找了点LoadRunner的使用说明就开始对系统下刀了。对于一些大公司的专业性能测试人员来说,这个很可笑,但是这种情况是存在的,我当初刚到公司时也这么干的。

      那时还真把性能测报告给整出来了,现在看来那报告没有任何意义。虽然对现在的我来说性能测试也只是只懂皮毛。但还是希望通过我这篇文章能让那些新手们对于性能测试有个入门的了解。

      ----//理发店模式

      关于理解性能,记得我那时是看了“《LoadRunner没有告诉你的》之三---理发店模式”不管你有没有看过,我这重提一下理发店模式。

      前提:

      1、一个理发店有三位理发师傅

      2、每位理发师傅理一个发需要一小时

      3、顾客都很忙,从进理发店起最多只等三小时(等待时间+理发时间),如果三小时后还没轮到自己理发,立马走人。

      思考:

      这里我们来理解“最佳用户数”和“最大用户数”。

      最佳用户数:

      理发店的最佳状态,理发店收入最多(理发师傅没有休息时间,一直在理发),顾客满意度最高(顾客随时到随时理,无需要等待)。在一个时间点来说,三个理发师傅服务于三位顾客,那么这个最佳用户数是三。

      最大用户数:

      理发店的最大承受状态,理发店收入最多(理发师傅没有休息时间,一直在理发),顾客的最大忍耐度(来的顾客等待+理发需要等上三个小时)。

      假如理发店生意非常好,早上一开门一下子来了一群顾客(很多),A、B、C三位顾客先理,D、E、F顾客需要等待一小时才能得到理发师傅的服务,G、H、I三位顾客等待了两小时才得到服务,后面排队的J、K、L.....等顾客,已经等了三小时还没得到服务,因为这已经得达到了他们等待的极限,所以后他们气愤和无奈离开。

      当然,理发店还会不断的来新的顾客,不断有等了三小时而没有得到服务的顾客离开,但对于理发店而言,他们在一个时间点上,能服务的最大用户数是九(三位正在接受服务、三位已经等待一小时,三们已经等待两小时)。

      对于最大用户数,需要注意的两点:

      1、在理发店里很大,可以容纳很多位顾客(大于9),总有一部分在这里等待了三小时而没有得到服务离开,不要把等待了三小而没有得到服务的顾客纳入最大用户数里。

      2、假如理发店很小,最多只能容纳六位顾客,当第七个顾客来时,虽然,我们知道他只需要等待两小时就可得到服务(这个时间是他可以接受的等待时间),但由于理发店容量有量,这第七个顾客只有改天再来了。

      关于理发店原理,详细请浏览http://www.51testing.com/html/58/n-10558.html

      不知道通过上面对理发店的分析,你对性能有了一些眉目。假如理发店相当于我们的系统的话,顾客就我们向服务器所发送的请求,最佳用户数和最大用户数是我们衡量一个系统的处理能力的一种方法。

     ----//要帐的模式

      注:上图是自己找来修改的,凑合着看吧!呵呵

      这个是我在给一朋友说浏览器与服务器之间交流时用到的例子,感觉比容易理解,所以拿来分享一下。

      假设:

      1)A、B、C三个人。

      2)C欠A钱(这里不考虑多少)

      3)B是专门要账

      思考:

      浏览器与服务器的信息传递次数:

      A对B说,C欠我钱,你帮我去要。B接到指令后就去找C要钱。

      B对C说,给我20块钱。

      C说,没有。

      B对C说,给我10块钱。

      C说,没有。

      B对C说,给我5块钱。

      .........

      最后,B回来对A说,哎呀妈呀,C那丫的忒抠门了,一分钱没有。

      对于A来讲,只是来说,它只是让B问C要钱,具体的B与C之间交互了几次,A是不知道的,它所知道的就是B返回给它的结果,C一分钱没有。

      浏览器与服务器传递数据的大小:

      还是上面的过程,A对B说,C欠我钱,你帮我去要。B接到指令后就去找C要钱。

      B对C说,给我20万块钱。

      C说,没问题,没支票,只有1元硬币。

      ..........

      B终于把钱拿回来给A。A很纳闷,怎么去了那么久,B委屈的说,丫的,C给我整了一堆硬币,太重了,路上走的慢,都快累死我了。

      对于A来讲,只是来说,它只是让B问C要钱,谁知道C给的是支票还是硬币。所以,B去要钱消耗的时间就很长。

      所以,要想提高浏览器对服务器的访问速度,应该减少数据传递次数与数据传递的大小。

      这样就很自然的引出了浏览器的cookie

      A在C哪里存了5毛钱。

      A对B说,我在C哪里存了5毛钱,你去拿来我看看。B跑去问C要了5毛钱回来给A看。

      过了一会,A又对B说,我在C哪里存了5毛钱,你去拿来我看看。B跑去问C要了5毛钱回来给A看。

      过了一会,A又对B说,我在C哪里存了5毛钱,你去拿来我看看。这次C烦了,对B说,你把钱放自己口袋里吧,等A要的时候,你来问我5毛的人民币有没有改版,没有改版的话,你就直接把口袋里的5毛钱给A看就行了。

      在这里A就相当于我们用户,B相当于浏览器,C是服务器。而cookie就是B的口袋,当然了cookie的用处还很多。比如我们登陆一个系统,提示我们是否保存密码(有的还有期限比如,一个星期或一个月),如果我们保存了,下次再访问登陆时,浏览器就已经帮我们填写好了账户密码或直接帮我们登陆。那这个账户密码就放在我们浏览器的cookie中。

      为什么要说上面的例子呢?因为我们大部分的一部分性能测试是基于B/S架构系统的,理解了浏览器与服务器之间的数据传递,有助于我们理解性能测试。


     ----//在开始性能测试之前,我们需要知道什么?

      当客户或老板把你叫来,对你说,去给我们系统做个性能测试,千万别傻傻的说“好!”然后,就走了,我以前这么干过(那时不懂,打肿了脸充胖子),回到座位后,不知从何下手了。

      那么,我们需要知道什么呢?

      1、性能测试的目的

      首先要知道客户的要求。

      我把性能测试按目的分以下几种

      1)客户有明确要求

      这是一个好的结果,这说明客户对性能测试有一定的了解,知道他们需要的系统要达到一个什么样的标准。如:系统要求同时满足100用户登陆,平均每个用户登陆时间不能超过5秒。这个需求很明确,当然也不排除一些不懂装懂的用户,提一些不现实的要求。

      不管怎么说,用户提要求了,这个比较容易,你可以对现系统做一次性能测试,至于,是通过优化系统还是增加硬件设备才能达到要求。就不是我们考虑的问题了。

      2)只是想知道目前系统性能(容量测试)

      可以把我们的目的就是求得最大用户数和最佳用户数。但是,这仍然是比较含糊的一个需求,我们需要对系统做出分析,找出系统的压力点。

      3)找出系统性能瓶颈

      这个同样需要分析可能对系统造成瓶颈的逻辑业务,然后才能进行性能测试。

      4)了系统在长时间的压力下性能状况(强度测试)

      这个一般验证系统的稳定性,因为系统一旦上线,就有可能会长期处在大用户的访问状态,可能以前没发现的一些问题就会暴漏出来。比较典型的就是内存溢出。

      2、性能测试的环境

      确定了我们的测试目的,当然需要测试环境。这里的环境,我们需要考虑一下几点

      1)硬件环境

      我们需要了解被测服务器硬件配置,用于加压客户端的机子配置,CPU 内存  等

      2)软件环境

      我们需要了解被测系统的架构,前端、中间件、服务器(这里指运行系统软件服务器,如tomcat)、数据库,以及他们的部署位置。

      用于加压的客户端采用什么性能测试工具进行加压。

      3)网络环境

      网络环境很重要。在上面的几个目的中,除了找出系统性能瓶颈可以在广域网进行,因为这个目的可以不用设置太多的虚拟用户,只要找出系统哪个地方影响了整个系统的性能就行。

      其他目的的测试都需要在,局域网进行,不然你压力工具所发送的请求都会卡死在网络的传输过程中。

      3、寻找系统的压力点

      我们需要对系统的哪个页面或业务进行加压。这个不是自己想出来的,需要与开发人员的沟通。系统的首页?系统的登录?还是系统的交易过程?各个业务的用户比例是多少?

      只有获得有效的性能需求,才容易寻找和定位压力点。

      获得有效的需求:http://www.51testing.com/html/68/n-10568.html

      如果上面的几点,你都很清晰了,那么打开你的性能测试工具开始录制(或编写)你的性能测试脚本吧!

      注:以上个人观点,如有错误的之处,请高手指证,以免误导别人。

    posted @ 2011-11-23 10:46 顺其自然EVO 阅读(194) | 评论 (0)编辑 收藏

    仅列出标题
    共394页: First 上一页 359 360 361 362 363 364 365 366 367 下一页 Last 
    <2025年7月>
    293012345
    6789101112
    13141516171819
    20212223242526
    272829303112
    3456789

    导航

    统计

    常用链接

    留言簿(55)

    随笔分类

    随笔档案

    文章分类

    文章档案

    搜索

    最新评论

    阅读排行榜

    评论排行榜