发布新日志

  • 庆祝51Testing软件测试网成立五周年

    2009-05-14 11:05:21

          曾经51Testing的学子,现在51Testing的孩子。

          愿母校越办越好,优秀的人才越来越多,对社会的贡献越来越大。

          51Testing软件测试网:http://www.51testing.com

  • 怎样做一个人见人爱的软件测试经理?

    2008-12-14 14:10:42

    1.具有较好的人格魅力和亲和力:

    真正来说做到这一点非常难。这不仅要求测试经理有宽广的胸怀,良好的沟通能力和语言表达能力,还要求测试经理具有较强的应对能力。向上能把工作汇报的让领导满意,令领导信任。能把工作任务轻松, 无异意的下发给下属, 并让他们饱含工作热情共同协作去完成测试任务。如果您能够把扭转下属的思想,把“要我测试,变成我要测试”,我想你一定很强了。如果陌生的人一见到你,通过谈话就觉的你很强,都愿意和你交朋友,那你的人格魅力一定不错了,呵呵。

    2.最好具备较强的测试技术水平:

    一般来说,作为测试经理,在一个测试技术性的团队里,如果你有很强的技术,并且你的技术是最棒的,下属不能够搞定的问题,你都能够做的很好,即时有时候你凶了点,团队里的成员心底里都还是很敬佩你。如果你有技术,但是技术不高,你组内的技术高手一定是你的亲密战友,这个时候唯一的出路就是凝聚团队的力量,取长补短,也能够取得较高的效率。还有一点值得注意:在分派工作的时候,找一下组内的骨干,看看是否有新的或者好的处理办法,这样一来,避免在开会的时候遇到分工或者技术上的尴尬局面。但有的测试经理具备了很强的技术,整天对团队的成员都板副面孔,那你也很难做到人见人爱。唯有为人处事比较圆滑,待人真诚中肯、随和亲切,整天都是笑脸相迎,那呆在这样的团队里工作,一定很开心。所以要做到人见人爱的测试经理,较强的测试技术水平不能够忽视。

    3.乐意处理下属在项目中碰到的困难:

    在带领一个团队开展测试工作的时候,当你的下属碰到困难的时候,你更多的是给下属鼓励和安慰,帮助下属分析出现问题的原因。比如说一下:“幸苦了”!“干得不错”!“慢慢来,没关系的”!下属听了也很开心的,并且以后干活可能会很卖命,因为他的工作得到了领导的认可。或许该问题你也不一定解决得了,这时候你一定要挺身而出,协调测试团队的资源尽力帮他解决问题,久而久之,你的威信就树立起来了,之后就好办事了。

    4.勇于承担责任,把功劳推给测试团队:

    软件测试经理,作为一个中层经理。管理者一定要想管好下属,必须“身先士卒”、“以身作则”,事事为先、严格要求自己,处处起到表率作用。示范的力量是惊人的,一旦通过表率在团队中树立起在员工中的威望。将会上下同心,大大提高团队的整体战斗力。常言到:“得人心者得天下”,做下属敬佩的领导,将使管理事半功倍。如果下属在测试项目中出现问题,上级领导怪罪下来,自己勇于承担,多检讨自己,少怪罪他人。始终用平和语气与下属沟通,最后一定要找出出现问题的真正原因。让出现问题的下属,自己过意不去,从心底里佩服你,想法补偿你。项目得到喜讯,比如:某个测试项目做的很好,领导表扬的时候,把功劳推给大家,很多时候,容易让人感动,让人佩服得“五体头地”哈哈。

    5.对下属多一些宽容和生活关心:

    特别是对下属不懂,自己懂得很精的地方,下属问的时候,一定要有耐心,给下属详细讲解。切忌:看不起下属。如果真是这样,你这个经理就很失败了。反正对下属,在很多地方,要多一些理解和包容,最好能和下属打成一片,当下属不认为你是领导的时候,你就真是领导了。如果做领导做到别人都当你是朋友,那你真的就成功了。
    还有一点就是要察言观色,随时发现和了解下属的困难,不管是工作方面,还是私人方面,都要关心。比如说:某个下属买了房子,准备装修,那他一定很关心装修方面的东西。如果你懂得很多,那和他交谈时,多一些这方面的话题,他也会很开心,觉的你这个人相当热心,并且也会觉的大家有共同语言,以后当你碰到问题的时候,他一定会鼎立帮助你,因为他认为你是他最信任的知己。也可以多在生活上关心下属。比如有项目要加班什么的,有时候陪陪下属加班呀,吃个午饭宵夜呀,聊点家常呀什么的,自己买单后,公司报销,效果真的不错哟!

    6.力争多给下属争取福利

    在公司条件允许的条件下,多给下属争取福利!但是做这件事的时候,一定要在公司利益和员工利益之前要平衡。若过分的给员工争取福利,会造成公司对你有意见,同样,过分的以公司利益为重,员工对你也会意见大!总之,每种情况都要有度,力所能及的事,一定不能放过。很多时候,为员工申请比较多的福利,即时没有成功或者工资变化不大,但是下属都看在眼里,还是很感激你的,因为他知道你已经尽力了,觉的你很够哥们,为你工作很值。

    7.多给下属锻炼机会,培养下属能力:

    作为测试经理不可能向测试工程师那样什么事情都自己做,并且事事都自己做也不现实。可以在不同的测试项目中,安排测试主管。然后对测试工作进行协调,参与测试中发现重大问题的讨论。这就要求测试经理懂得用人,懂得计划。在制定详细的测试计划的同时,自己把握测试项目中的关键点和时间表,给下属更多的实践机会,让下属做事更具有责任心和成就感。测试主管在做好测试项目的同时,又减少了测试经理的工作量,学到了不少东西,能力变强了,开心了,达到了上下级和谐共处的双丰收。

    8.多给下属精神鼓励,奖惩公私分明:

    很多时候,部门周例会上偶尔的一个口头表扬,更会让下属铭记于心,因为他觉的很有面子,很体面,也许他会再接再厉,给自己创造机会,争取后面再受表扬。下属也乐开了,工作也更加努力、拼命了,效果相当明显。并且奖赏要公私分明,不能有所偏袒,更不能让部门的人觉得你搞私人关系,力争做到一视同仁,对事不对人,也许你就成功了一半。但是,对于工作做的比较差的下属,也要私下单独谈心,帮助找出原因,给他打气,并鼓励他继续努力工作。

    9.知人善用,用人之长,合理分工:

    现在很多公司的测试工程师,都是网上外招的,分别来自不同的行业和不同的工作岗位,他们有着不同的专业知识和行业、业务背景。这就要求测试经理,对每个人的长处非常了解,将合适的人安排到合适的工作岗位上,用人之长,避人之短,合理分工,争取达到双赢。

    10.较强的行业和业务知识背景:

    测试经理作为一个部门的Leader必须对相关的产品和行业的知识背景了如指掌,要不然下属做了什么,怎么做的,正确与否,你都没法判断。一般来说,在某个行业待3年左右,做了几年的测试,那你对这个行业就非常了解。即使你不参加项目的测试,你问很多的问题,下属也不敢乱讲,毕竟你了解很多。再比如说:某些税务的项目,很多的业务知识,你不是很了解,那也没法做,还有一些隐含的行业需求,没有3、5年的行业背景,更是没法发掘出来,到了客户缺陷才被发现,你就太被动了。当然,如果时间允许的话,你也可以介入部分模块的测试,这样虽然你测试不是很多,往往会发现很多问题,检验检验下属测试成果。

    11.多给下属讲解一些职业发展方面的东西:

    从我带过的团队成员来说,一般干了3、4年测试的测试工程师,大部分的测试工程师,对自己的职业生涯都很迷茫,没有完整的规划。由于大部分都是做黑盒测试,技术含量较低,抱怨时常是有的。尤其在这个关键的节骨眼上,对他们的心里辅导和安慰非常必要。多给他们展望一些测试的前景,经常组织测试职业发展的方向类似的讨论会,让大家有一个稳定的心,认真干活,而不是时时刻刻在寻找机会,想立马跳槽。

                                                                           sun_910

  • VOA Special English

    2008-10-28 09:27:53

        最近对英语听力的提高是非常迫切的,因为客户马上就要到中国来访,原来邮件联系还没有问题,但是真的面对面,确实有些抵触。

        所以,从今天开始,坚持每天听一篇,练习一篇VOA的慢速英语,希望能小有成效。

        第一篇:WORDS AND THEIR STORIES - What Does the Average Joe Think?——10.27

        尽管目前看来,难度确实很大,因为需要花费的时间可能不止是1个小时。但是,但是,坚持,坚持。

  • 飞蛾扑火

    2008-10-21 11:39:04

     “飞蛾会扑火,飞蛾错了?火错了?都没有,是老天爷错了,最好的办法就是不要让飞蛾见到火。”

      这是曾经陪我走过一段人生路的男人在E-mail中突然写到的一句话。起初看到,心中不免有些凉意,但是细细研磨,确是实情,不过更直白的表达。

      我思忖前后,不知如何回复,自觉地这句的潜台词——冲动是魔鬼。

      也许,许多年后,我们都沉浸在各自幸福的家庭生活中的时候,再来看这句话,会觉得幼稚,但是今天却真的在提醒彼此,有所为,有所不为。

      生活的无奈在于,每天面对的选择,只要选择了,就一定会后悔,谁让贪念在作祟。生活的残酷又在于,无论怎样的结果,你都必须去面对,因为无所谓改变。

      最近没有在QQ空间更新,也没有在大家都知道的blog更新,因为我想写的更随意一些,更真实一些。有时候感叹:人能真正的淡定真好。

  • 能高兴,真好!

    2008-10-06 15:56:39

    十一长假“转瞬即是”。

    连续几日的“赶路”,很是疲惫,真的很想“自然醒”,偶尔一两日清晨起来较晚,还觉得心中有事,不能踏实。

    则么才能“如释重负”?活的“轻松”!整日思考,不得而解。

    生活在“心脏”,确实负荷很大,身体和心灵。

    从来没有过的想法:“不能再一个人活下去了!”好累!

    今天又开始了周而复始的工作,知道又开始那样的生活。

    走在路上的感觉...

  • 婚礼进行曲

    2008-09-16 12:48:45

    这个应该是我的技术搏客,可是还是不忍“晒”点私人小秘密。

    他十月一也要结婚了,嗬嗬!似乎这是我的宿命。

    刚通完电话,我还是笑着对他说了:“新婚快乐”。

    一直这样坚强没有什么不好,就是有点受伤。很疼......

    本就不该把自己的喜怒哀乐无形的加于别人的头上,一直觉得“己所不欲,勿施于人”......

    可在别人眼里,女人太过于“坚强”,往往失去了别人的关心,因为你“无敌”,什么都能抗。

    始终还是不能接受这个现实,虽然我知道这离我很近.

  • 38周日记

    2008-09-09 09:36:37

    09.08 周一

    和往常一样平静而又紧张的周一。新的任务,新的开始。但是,晚上的一场大雨却“冲垮”了我的家,昨夜我无法入睡,今夜我无家可归。

    09.09 周二

    生日。早上来了就收到了一大束花!满心欣喜,心满意足。但是还是不能被胜利冲昏了头脑,开始背单词。预计目标:“Z”.(今天09.18才把手中字典里11个Z开头的单词背完)

    zenith; zest; zeal; zealous; zip; zigzag; zoom; zoology; zinc; zone; zebra.

    09.10

    新的任务开始了,今天加班到晚上12点,回到家里,居然躺下2个小时才开始慢慢入睡。

    09.11

    Deadline,晚上又到了9点,有点疲惫不堪了!

    09.12

    今天是三天长假的前一天,大家都比较放松。下午3点就离开了公司。

  • 一个软件如何确定测试结束点呢?

    2008-09-08 15:38:44

    在软件消亡之前,如果没有测试的结束点,那么软件测试就永无休止,永远不可能结束。软件测试的结束点,要依据自己公司具体情况来制定,不能一概而论!个人认为测试结束点由以下几个条件决定::

    1.基于“测试阶段”的原则:

    每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段,我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后,再进行后面一个阶段的测试。举个例子来说:单元测试,我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准,当然也是如此。

    2.基于“测试用例”的原则:

      测试设计人员设计测试用例,并请项目组成员参与评审,测试用例一旦评审通过,后面测试时,就可以作为测试结束的一个参考标准。比如说在测试过程中,如果发现测试用例通过率太低,可以拒绝继续测试,待开发人员修复后再继续。在功能测试用例通过率达到100%,非功能性测试用例达到95%以上,允许正常结束测试。但是使用该原则作为测试结束点时,把握好测试用例的质量,非常关键。

    3.基于“缺陷收敛趋势”的原则:

      软件测试的生命周期中随着测试时间的推移,测试发现的缺陷图线,首先成逐渐上升趋势,然后测试到一定阶段,缺陷又成下降趋势,直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向,来定测试是否可以结束,这也是一个判定标准。

    4.基于“缺陷修复率”的原则:

      软件缺陷在测试生命周期中我们分成几个严重等级,它们分别是:严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时,严重错误和主要错误的缺陷修复率必须达到100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上,允许存在少量功能缺陷,后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题,可以暂时不用修改。

    5.基于“验收测试”的原则:

    很多公司都是做项目软件,如果这种要确定测试结束点,最好测试到一定阶段,达到或接近测试部门指定的标准后,就递交用户做验收测试。如果通过用户的测试验收,就可以立即终止测试部门的测试;如果客户验收测试时,发现了部分缺陷,就可以针对性的修改缺陷后,验证通过后递交客户,相应测试也可以结束。

    6.基于“覆盖率”的原则:

    对于测试“覆盖率”的原则,个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求,包括行业隐性需求、功能需求和性能需求等等,只要测试用例执行的覆盖率达到100%,基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心,非得要看看测试用例的执行效果,检查是否有用例被漏执行的情况,可以对常用的功能进行“抽样测试”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试,每个阶段都不能忽略。

    7.基于“项目计划”的原则:

    大多数情况下,每个项目从开始就要编写开发和测试的Schedule,相应的在测试计划中也会对应每个里程碑,对测试进度和测试结束点做一个限制,一般来说都要和项目组成员(开发,管理,测试,市场,销售人员)达成共识,团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了,测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成,就可以作为一个结束点。很多不规范的软件公司,都是把项目计划作为一个测试结束点,但是如果把它作为一个结束点,测试风险较大,软件质量很难得到保证。

    8.基于“缺陷度量”的原则:

    这个原则也许大家用的不是很多,了解比较少。我们可以对已经发现的缺陷,运用常用的缺陷分析技术和缺陷分析工具,用图表统计出来,方便查阅,分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题,我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然,最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说:一万行代码最多允许存在多少个什么严重等级的错误,这样比较好量化,比较好实施,成为测试缺陷度量的主流。

    9.基于“质量成本”的原则:

    一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是:人命关天的航天航空软件,那还是质量重要些,就算多花点钱、推迟一下进度,也要测试能保证较高质量以后才能终止测试,发布版本。如果是一般的常用软件,由于利益和市场的原因,哪怕有bug,也必须得先推出产品,没办法呀。一般来说,最主要的参考依据是:“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候,可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”,同时保证公司利益最大化。如果找到bug的成本比,用户发现bug的成本还高,也可以终止测试。

    10.基于“测试行业经验”的原则:

    很多情况下,测试行业的一些经验,也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度,测试人员的工作能力,测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中,每个人都没有项目行业经验数据积累,拿到一个新的项目,自然是一头雾水,不知道从何处开始,测试质量自然不会很高。因此通过测试者的经验,对确认测试执行和结束点也会起到关键性的作用。
     
    转载自:http://bbs.51testing.com/thread-124864-1-1.html
  • 大多数软件测试员应具备的素质

    2008-08-27 16:36:08

    大多数软件测试员应具备的素质:

      1. 探索精神:软件测试员不会害怕进入陌生环境。 有较强的学习能力,可以用最快的速度成为一个新的行业的专家。

      2. 故障排除能手:软件测试员善于发现问题的症结,喜欢猜谜。可以迅速的通过事物的表面现象发现事物的本质,能够从琐碎的现象中发现内部的联系和规律。

      3. 不懈努力:软件测试员总是不停尝试。他们可能会碰到转瞬即逝或者难以重建的软件缺陷;他们不会心存侥幸,而是尽一切可能去寻找。只要出现过的缺陷,就说明一定是存在的,找不到只能说明没有能够真的重新当时的环境和全部的操作细节。测试人员要能够敏感的察觉到细微的变化,并立即开始在大脑中努力重现之前的整个场景。把残存的瞬间记忆整理在纸上,通过分析,把这些碎片整理起来,最终找到缺陷重现的场景和规律。牢记:在做这样的事情之前给自己制定一个规则,例如只花费N多时间来努力重现这个缺陷,如果超过这个时限还没有找到,那么就把当前的工作整理成一份文档保留下来,然后去按计划继续进行下面的工作,直到再次“偶遇”这个缺陷。

      4. 创造性:测试显而易见的事实,那不是软件测试员;他们的工作是想出富有创意甚至超常的手段来寻找软件缺陷。虽然创造性是必需的,但是还是更建议把大多数时间放在熟悉真实用户的工作上,测试的基础是现实中已经存在的场景,在冥思苦想新的场景的时候,先同用户沟通一下,试图发现一些新的场景效率会更高一些。有很多事实并不是那么显而易见。

      5. 追求完美:他们力求完美,但是知道某些无法企及时,不去苛求,而是尽力接近目标。 做任何事情都应当有一个策略,分配给每项任务一个指标或者一部分资源(也就是说如果这件事情成功,那么它带来的收益值得我们付出的最大成本),当这部分资源耗尽时,就停止这项任务。

      6. 判断准确:软件测试员要决定测试内容、测试时间,以及看到的问题是否算作真正的缺陷。 要不断的提高自己的专业素养,除了行业知识、测试专业知识以外,还要尽可能的去学习一些软件行业的基础知识,例如操作系统数据库、程序设计开发、计算机网络等。

      7. 老练稳重:软件测试员不害怕坏消息。 其实做任何工作、任何事情都一样,人生就是一个不断的发现问题和解决问题的过程,没什么好怕的。

      8. 说服力:软件测试员要善于表达观点,表明软件缺陷为何必须修复,并通过实际演示力陈观点。 测试工作开展的好坏,很大程度上就靠沟通能力和展示自己工作的能力了。

      9. 在编程方面受过教育。 一个有过开发经历的测试人员,对系统的领悟能力和学习速度同没有开发经历的测试人员是截然不同的。

    转载自:http://www.51testing.com/html/200808/n91250.html

  • 笑傲测试

    2007-09-22 23:53:24

      《笑傲测试》——魏伟

       首先,谢谢他让我找到了今天写作的灵感。

       其次,感谢他,因为这个题目,那些还在测试边缘徘徊的人可能给我增加点击量(待查)。

       最后,感谢他,我对测试有了一个新的认识,测试是有创造力的!

       姑且,不对书中的内容做任何评价,本人也没有那个实力说三道四什么!但就测试的理解而言,作者的工作经验可能已经说明了一切!前辈,晚辈这厢有理了!
    许,这个行业永远也不可能在中国这个领土上有什么太大的发展,远不如网上吹嘘的那样,因为国情不一样。但是那些曾经为其执着的前辈们,现在为其倾注全部的我们,还有那些即将放开一搏的后来者们,却都坚信着这个概念——质量。他们,我们,还有他们都将为中国的软件质量奋斗不息,耕耘不止!

       目前为止,这个行当倍受争议,似乎地位也不是很受人尊重,反倒有些被鄙视的意思,可是事实是无法掩盖的,成功的脚印也是无法磨灭的,我的热情也是无法阻止的。
    认识测试,学习测试,从事测试,终身为测试而奋斗......

       谨此献给那些战斗在测试第一线的同志们,你们辛苦了......

  • 看《越狱》体会项目管理

    2007-09-15 23:41:46

        因为越狱具备了项目所需要的独特性,临时性和明确目标的所有特征,完全可以将Michael策划的越狱作为一个项目来看待,而要想成功越狱则必须关注项目管理中所需要关注的所有要素。沉着,冷静,机智和敏锐的Michael使他具备了领导这个项目的最重要的资质,但每一个项目要素同样至关重要

    1.计划
    一次重大的行动必须要有周密的计划,在计划中要考虑导所有应该考虑的要素,以保证项目的成功。911恐怖分子为了当天的几小时行动往往要花上几年的时间来计划和策划。而为了这次越狱,Michael同样花上半年多时间进行计划,让我们来看下需要计划的内容
    项目目标:第一目标是Brother死刑前越狱成功,第二是逃避掉追捕并消声匿迹。
    项目假设:假设能够关到同Brother一样的Fox River监狱
    假设狱友能够协助
    假设能够说服AbruzziWestmoreland入伙
    假设过程中的每个子步骤都能够成功
    项目约束:最重要的约束就是刑期的约束,过了刑期一切将毫无意义
    其次是受到的资源,环境的约束
    能够协助自己开展行动工具约束。
    经过了三次改造的Fox Revier监狱的地下水道真跟迷宫一样,因此Michael身上的纹身是最重要的一个准备,甚至细化到了狱室洗手台螺钉的型号。然后是打听到Sara的背景资料和座右铭以获取Sara的好感和帮助
    越狱成功后需要快速的出境因此需要Abruzzi黑帮老大飞机帮助
    越狱后需要大量的资金因此需要说服Westmoreland入伙。到第二季还可以看到为越狱成功后准备的衣服,装备和车辆
    为模拟坠车山崖实现准备的各种道具。可以说是事先能够想到的全部想到和做到了。但计划仍然无法保证万无一失,假设中的任何一项都可能给项目带来风险,同时还存在更多的事先根本无法预料到的未知因素,任何一个环节出现都将导致失败和功亏一篑。
    没有完美和万无一失的计划,最重要的是要懂得随时根据环境的变化来调整我们的计划,在出现问题和不利因素时候要保持清醒的头脑。
    里程碑1:进入Fox RiverBrother汇合上,拉狱友Suore入伙,探清道路。
    里程碑2:AbruzziWestmoreland入伙,打通仓库到储物室再到医务室的道路。
    里程碑3:在合适的时间准备越狱,逃出Fox River监狱
    里程碑4:找到Westmoreland留下的500万,并消声匿迹
    2.资源
    日益负责的社会环境和严密的监狱监控,像肖申克那种只靠个人力量越狱成功已经成为历史。你必须依靠一组人,形成一个团队来共同达到目标,每个人在这个团队中都会有明确的作用或任务。所有可以看到的必不可少的人力资源只有Abruzzi,Westmoreland,Suore。但根据剧情的发展或需要加入了其他的人员,每个人员加入都合情合理,并且可以为越狱行动贡献力量。
    人力资源外的就是硬件资源如各种工具,精确计时的手表,逃跑需要预先准备好的飞机,从草坪长椅上搞到的螺钉,为了假装糖尿病需要获得的药丸,探路需要的狱警服,还有藏在自己胳膊里面的致病药丸等,每一种工具或资源都将发挥重要的作用。
    整个Fox River的地图是最重要的资源,放在哪里都不可靠。因此Michael选择了旁人难以看懂的纹身放在了自己的身上。任何你觉得万无一失的都可能出现变故,就像背上的纹身会因为探路被烫掉而引起了根据曲折的故事情节。
    3.风险
    任何假设都可能成为风险,只有分析清楚了所有了风险并对关键风险进行应对才可以保证更大的胜算。从了解Sara的背景资料,了解WestmorelandAbruzzi的性格特征,藏药丸我胳膊里面无一不是在为了降低风险概率,减小风险的影响。
    但我们看到整个第一季中对风险的分析仍然显得不充分,最明显的就是出现了很多应急的场面或者说根本没有预料到的问题。如果说Brother为了拖延时间而冒犯预警被关入静闭室还算突发事件的话,那没有实现预计到储物室到医务室的天窗可能被加固则是风险分析的重要遗留,类似的还有地道被发现,地下室到储物室事先灌满的水流失掉,医务室到围墙的电缆出现问题等,这些都是必须要考虑到的风险并要考虑针对风险进行因对。
    4.时间
    从整个剧情中,Michael的一次次的看秒表,我们可以看到时间在整个越狱过程中的重要性,有时需要精确到的秒的地步。狱警要定时的巡查,所以每次去探路用的时间必须精确计算,同样给地下管道放水一幕事先需要计算管道的尺寸,大小和水流量,保证水能够在精确时间放满到合适的位置。越狱过程中每一个环节也要精确计算,保证没有延迟。第一次越狱虽然没有成功,但为了和Brother在医务室碰头,也需要精确计算出各自采取行动的时间。
    5.解决问题
    没有一成不变的事物,我们也没有以不变应万变的境界。因此当出现突发事件后最需要的还是面对问题并解决问题,而不是去相互争吵,扯皮或去探讨是谁的责任。而沉着,冷静,睿智和高智商的Michael就具备了解决问题的所有条件,虽然我们看到的是他一次次的遇到各种问题,但通过自己的冷静的思考和分析,最终都得到了解决,而解决问题依赖的不是灵感或神助,而是自己的知识积累和联想分析能力。
    Sara怀疑Michael无病->需要阻止胰岛素吸收->联系CNotes买药
    Brother越狱前意外被关禁闭->医务室汇合->Brother需要得病->装病药丸->带药丸给Brother的人->神父
     
     
  • 啥是TD?

    2007-09-12 21:10:29

      TestDirector 是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理,测试计划,测试执行以及错误跟踪等功能,TestDirector极大地加速了测试过程。
    D M6\-i ap:m ?!~13247151Testing软件测试网 Ag*i,q`O#cX:oh
      电子商务正影响着许多公司制定计划和建立自己的IT系统。很快,一个Web应用软件就能被创建,开发并立即展现在您的客户、供应商或合作伙伴的面前。然而,由于紧凑的开发计划和复杂的系统基构,Web应用软件的测试经常是被忽视的。为了与新经济同步, 您必须开发经过系统测试的高品质的网络应用软件。51Testing软件测试网H6t-b&m"prd
    51Testing软件测试网#YdOaa m2B
      您需要设立一个中央点来管理测试过程。一套基于Web的测试管理系统提供了一个协同合作的环境和一个中央数据仓库。由于测试人员分布在各地,您需要一个集中的测试管理系统能让测试人员不管在何时何地都能参与整个测试过程。IT部门增长地会非常快,人员也会不断流动。您必须以最快的速度培训新的测试人员,教会他们所有与测试有关的知识技术。重点在于管理复杂的开发和测试过程,改善部门间的沟通,加速您测试的成功。
    Of tR?13247151Testing软件测试网1vt4GKT E7ShuU'W] l
      TestDirector能消除组织机构间、地域间的障碍。它能让测试人员、开发人员或其它的IT人员通过一个中央数据仓库,在不同地方就能交互测试信息。TestDirector将测试过程流水化——从测试需求管理,到测试计划,测试日程安排,测试执行到出错后的错误跟踪——仅在一个基于浏览器的应用中便可完成,而不需要每个客户端都安装一套客户端程序。
    -~4S3t o(}3P13247151Testing软件测试网 }6wN;v!oG,yp7Q
      需求管理
    %AUJSA#X"AV132471
    c#V H\Z]8ve132471  程序的需求驱动整个测试过程。TestDirector 的Web 界面简化了这些需求管理过程,以此您可以验证应用软件的每一个特性或功能是否正常。通过提供一个比较直观的机制将需求和测试用例、测试结果和报告的错误联系起来,从而确保能达到最高的测试覆盖率。
    6mj8n8z;U}9P,D132471
    f~l2u'S[132471  一般有2 种方式可将需求和测试联系起来。其一,TestDirector 捕获并跟踪所有首次发生的的应用需求。您可以在这些需求基础上生成一份测试计划,并将测试计划(?)对应与您的需求。例如,您或许有25 个测试计划(?)可对应同一个应用需求。您一定能方便地管理需求和测试计划(?)之间可能存在的一种多配多的关系,确保每一个需求都经过测试。其二,由于Web 应用是不断更新和变化的,需求管理允许测试人员加减或修改需求,并确定目前的应用需求已拥有了一定的测试覆盖率。它们帮助决定一个应用软件的哪些部分需要测试,哪些测试需要开发,是否完成的应用软件满足了用户的要求。对于任何动态地改变Web 应用,必须审阅您的测试计划是否准确,确保其符合最当前的应用要求。
    $|D5wy9E3t132471
    b p%qlKb7H132471  计划测试 51Testing软件测试网|V5ejj }P L
    51Testing软件测试网KE#N,D#H k:N]8Q
      测试计划的制定是测试过程中至关重要的环节。它为整个测试提供了一个结构框架。TestDirector的Test Plan Manager 在测试计划期尖,为测试小组提供一个关键要点和Web 界面来协调团队间的沟通。
    b&cD.S(w\fh&j132471
    giY6M B_|W132471  Test Plan Manager 指导测试人员如何将应用需求转化为具体的测试计划。这种直观的结构能帮助您定义如何测试您的应用软件,从而您能组织起明确的任务和责任。Test Plan Manager提供了多种方式来建立完整的测试计划。您可以从草图上建立一份计划,或根据您用Require-ments Manager所定义下的应用需求,通过Test Plan Wizard 快捷地生成一份测试计划。如果您已经将计划信息以文字处理文件形式,如Microsoft Word 方式储存,您可以再利用这些信息,并将它导入到Test Plan Manager。它把各种类型的测试汇总在一个可折叠式目录树内,您可以在一个目录下查询到所有的测试计划(?)。例如,你可以将人工和自动测试,如功能性的,还原和负载测试方案结合在同一位置。 51Testing软件测试网h|k2\6W`"u

    ;ph~:jis132471  Test Plan Manager 还能进一步的帮助您完善测试设计和以文件形式描述每一个测试步骤,包括对每一项测试,用户反应的顺序,检查点和预期的结果TestDirector 还能为每一项测试连加附属文件,如Word ,Excel ,HTML ,用于更详尽的记录每次测试计划。 51Testing软件测试网9m2QL lep

    o5C/Q2l+y0Z{132471  Web 网络应用日新月异,您的应用需求也随之不断改变。您需要相应地更新您的测试计划,优化测试内容。即使频繁的更新,TestDirector 仍能简单地将应用需求与相关的测试对应起来。TestDirector 还可支持不同的测试方式来适应您公司特殊的测试流程。 51Testing软件测试网2v4Li`6t"G7i&A

    6P[QpN132471  多数的测试项目需要一个有人工与自动测试的结合,包括健全,还原和系统测试。但即使符合自动测试要求的工具,在大部分情况下也需要人工的操作。启用一个演变性的而非革新性的自动化切换机制,能让测试人员决定哪些重复的人工测试可转变为自动脚本以提高测试速度。
    )o{[3@E9C-Y%v13247151Testing软件测试网%T~*E v]
      TestDirector 还能简化将人工测试切换到自动测试脚本的转化,并可立即启动测试设计过程

  • Alpha和Beta测试——定义和区别

    2007-09-01 18:32:34


       大型通用软件,在正式发布前,通常需要执行Alpha和Beta测试,目的是从实际终端用户的使用角度,对软件的功能和性能进行测试,以发现可能只有最终用户才能发现的错误。

       Alpha测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。

       Beta测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。因而,Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中,由用户记下遇到的所有问题,包括真实的以及主管认定的,定期向开发者报告,开发者在综合用户的报告后,做出修改,最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理。

       由于Alpha和Beta测试的组织难度大,测试费用高,测试的随机性强、测试周期跨度较长,测试质量和测试效率难于保证,所以,很多专业软件可能不再进行Beta测试。随着测试技术的提高,以及专业测试服务机构的大量涌现,很多软件的Beta测试外包给这些专业测试机构进行测试。
  • 号外——国产3G测试10月底完成

    2007-08-23 00:19:04

         日前,在上半年业绩报告发布会上,中国移动董事长王建宙表示,移动在8个奥运城市建设的TD-SCDMA网络将在10月铺设完毕,届时将公布测试结果,而奥运会能否提供3G服务,“须先待母公司完成TD-SCDMA测试才有具体公布”。

         王建宙表示,中国移动的母公司于8个奥运城市进行的TD-SCDMA网络建设,预计于10月底完成,届时会公布测试结果,现时仍未收到任何3G牌照发放或电信业重组的任何官方消息,

         “具体的TD测试正在进行中,10月底会完成初步建网,作为奥运唯一的合作伙伴,中移动已做好充足的准备,包括制定奥运会的手机专用网页、铺设完备的覆盖等。”

          问及TD会否就是中移动在北京奥运所提供的3G技术时,王建宙重点提出,将在2G服务上作充分准备。他以早前上海举办一级方程式赛车(F1),在同一场地服务超过10万名用户为例,证明中移动有能力在奥运提供完备的服务。

         王建宙称,“中国移动将紧守移动信息专家的战略定位,2007年下半年将继续全面开拓农村市场、拓展增值业务以及优化网络。”他表示,公司重视产品创新,并密切关注新经营模式的发展,公司最重要的目标将会维持不变。

  • 测试过程小节

    2007-08-20 00:36:11

        单元测试:单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此,单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

        集成测试:集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

        系统测试:系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的先知者问题。因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。

        验收测试:验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

        回归测试:回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。(这里强调,回归测试不属于测试过程的一部分)

  • The testing of mobile

    2007-08-13 20:45:21

       时间真的是很快,转眼来到51已经三周了,理论是第一阶段的主题,由于没有基础,学到的东西都还满新鲜的!

       随着时间的蔓延,老师总在讲自己一定要有个方向,女孩子的特性,我觉得自己该在手机方向努力了,有志向相同的XDJM一起交流吧!

      

  • 我来到了51testing

    2007-07-25 21:51:28

     

        2007年7月24日,一个值得纪念的日子,我来到了51testing,认识这里的老师,这里的同学,开始了自己梦想之旅(无论是噩梦还是美梦),我自己的梦!

Open Toolbar