发布新日志

  • (上)专访微软测试经理:软件测试的未来在哪里

    2007-07-09 16:40:53

     

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿

            通过上一篇关于微软测试工程师李和恒的采访,我们大概了解了软件测试工程在工作中思考问题的方式。每个人都寻求能在一个公司做出更多的成绩,争取晋升的机会。但想得到晋升的机会,我们需要思考问题能力和方式的提升和一些转变。于是我们走访了微软测试经理Francis Zhou,请他来谈谈从测试经理角度是如何看待软件测试工作。

            Francis Zhou 毕业于加州大学系统圣克鲁斯分校。他于2000年加入微软,曾在总部先后担任软件开发测试工程师及测试组长等职务,参与了Windows XP及Windows Presentation Foundation的开发。2005年初他正式加入微软亚洲工程院并先后参与了TTS, Microsoft Speech Server, ActiveSync, GamesUX等项目的开发及测试。他现任测试经理,主管游戏平台及移动平台多媒体软件的测试开发。

            Bug还没出现以前就将其杜绝,这才是软件测试的未来

            机遇总是光临有准备的头脑,Francis走上测试之路虽然有些偶然,但他在解决问题的特质才是真正的关键。他是从大学一毕业就加入微软做了一名软件开发测试工程师(SDET),最初做这行是测试这行选中了他,然后他回过头来又选中了测试。在大学时对软件工业的认识很薄浅,以为除了开发工程师就是管理人员。后来微软来他们学校招聘,他第一次听到还有SDET这么个职位,是荐于纯开发与纯测试之间的。当时没怎么在意,后来到微软面试时才知道面的是SDET。因为一直很向往加入微软,所以不管三七二十一就答应了。加入微软之后他有一次偶然碰到了那位到他们学校招聘的人力咨询师,就问她为什么推荐自己做SDET,才知道是自己回答她问题的时候很注重对细节的描述,而且喜欢把问题拆开来了解决,而这些都是一个SDET的基础素质,所以说最初是测试选中了自己。进入微软后做了一段时间后有很多其他的职位可以选择,但在测试行业中总是有着解决不完的难题。软件工程本身就是一个很新的课题,而软件测试工程则是近十几年才开始被重视的,里面有很多需要完善解决的东西。

            Francis说:“我觉得在这个领域有很好的发展前景。现在软件测试大多数还只是停留在找bug阶段,而如果真的要做好产品的话要在bug还没出现以前就将其杜绝,这才是软件测试的未来。因为我对软件测试这个行业很看好,就留了下来,所以可以说我回过头来又选中了测试。”

            至今没有碰到新的理念能完全否定以前的认识

            每个人对事物的认识都不是不断变化的,通过学习知识和项目经验的积累。有些时候人们会产生一些顿悟,对一个事物有了全新的理解。谈到是否在软件测试方面有过这样的顿悟,Francis认为至今还没有碰到一个新的理念能完全否定以前对测试理念的认识,因为他对测试的认识是慢慢积累而后拓展到新的领域的。

            刚进微软不久,Francis从一位资深工程师那里学到了自动化测试的几种常用模式,使自己写的自动化测试程序更加规范化。它可以在一个框架中重复利用,更有效率地组建自动化测试案例,这个认识在以后诸多产品测试计划中都起到了很重要的作用。第二个认识是在听了一个演讲后领悟的。那次演讲的主题是怎么样提高测试的效率,如何从找缺陷转换到防止缺陷的产生,使Francis对测试团队的作用提高到了一个新的层面,从单单在产品里找bug,到了如何与开发团队合作把整个团队的工程质量水平提高上来,也就是做到从Bug detection到Bug prevention的转变。

            Francis说:“从那以后,我开始更加强调测试团队在产品设计以及开发初期的介入,使很多bug还在设计期间就被找出来并且该掉,不仅提高了测试的效率同时也提高了产品的质量。”

            9个月测试了近1500个游戏,总部测试组都无法做出的成绩

            想要成为测试经理,我们必须要先了解一下测试经理主要的职责是什么。在微软一个测试经理主要负责制定一个产品或者一组重要功能的测试计划,然后按照计划带领一个测试团队去完成对该产品的测试任务。测试计划里除了要规划哪些功能要测、哪些不要测之外,还要详细解释各种测试方法在该产品测试中的应用方法,以及设置其优先级。制定测试计划也就是对该产品从测试角度进行分析,然后根据现状做出取舍,以便在有限的时间和资源内对产品质量做出最有效的评估的一个战略规划。而后在计划实施阶段,测试经理也要帮助建立起一些必要的工程流程,以保证计划的实施。然后在一个产品最终阶段,测试经理通常会担当质量把门人的角色,保证严重的缺陷都能够得到修复。

            从一个测试工程师到测试经理,Francis作过了很多项目。谈到说他觉得最满意的项目,Francis说:“这个比较难说,因为每个项目都有它做得好的和可以改进的地方。如果一定要举个例子,那么我会选择Windows Vista里对Games Explorer的测试。我们是在Vista发布前九个月时从总部那边把这个项目接手过来的。做过测试的人都知道,一个项目的结尾阶段是对测试组最具考验的时候。我们接手该产品的测试任务以后,只花了1个多月的时间就把所有事都接管过来了,而且做得比以前更好、更有效。而后的几个月中我们又找到并修改了Games Explorer中以前没有找的很多缺陷,而且测试了近1500个游戏在Vista上的兼容性。自豪地说,我们组在这9个月里做出了总部测试组都无法做出的成绩。能在这么短的时间内取得这样的成绩,除了归功于他们在先进自动化技术上的投入,主要还是靠着我们建立的过硬的队伍。”

            最近,Francis主要在做下一版Windows Mobile里的几个核心组件,以及一个在桌面平台上与Xbox Live有关的用户端软件。这两个项目对于Windows Mobile和Xbox Live平台都是至关重要的,期待会有更出色的成绩。

  • 黑盒测试方法揭密

    2007-07-06 11:30:05




    作者:陈樵 2002年04月08日 本文选自:中国计算机报

    一、黑盒测试在快速应用开发(rad)环境中的重要作用

      软件测试方法一般分为两种:白盒测试与黑盒测试。其中,白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试,着重于程序的内部结构及算法,通常不关心功能与性能指标。黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试,实际上是站在最终用户的立场上,检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。

      随着rad环境的发展,软件工程面临新的挑战,其中包括:

      ●应用系统的规模越来越庞大,结构越来越复杂;

      ●开发团队人员越来越多,分工越来越细;

      ●项目投资日益提高,导致投资风险增大。

      在这样一种背景下,软件质量面临着更大的危机,而解决问题的关键正是黑盒测试,可是由于传统的黑盒测试往往局限于手工测试,凭借工程人员的经验自发地进行,缺乏严格的测试管理机制,因而效果并不明显。

      在分发一个应用系统之前,若没有经过科学、周密的黑盒测试,就相当于将大量隐含的缺陷(defect)交付到最终用户手中,这对于开发团队自身、项目投资方及最终用户来说都是不负责任的表现,也将严重损害三方的利益。

      今天,软件的质量要求越来越受到重视,在对软件的质量监督中,黑盒测试起着重要的、不可替代的作用;而随着软件开发平台及软件设计思想的进步和发展,特别是rad技术的发展,对黑盒测试提出了更明确的要求,人们发现,必须遵循一定的测试理论,依赖于优秀的测试工具,才能进行科学、完备的测试。

      二、黑盒测试的操作步骤

      在传统的软件开发生命周期当中,测试工作往往被搁置到整个开发过程的后期进行,也就是说,当应用程序的编码工作已经基本完成,才开始进行测试,这样做的缺点在于:

      a)由于应用程序庞大而复杂,测试工作千头万绪,测试人员难以组织科学、全面的测试用例,从而大幅度提高了测试成本,并严重影响测试的全面性和有效性;

      b)由于缺陷所涉及的模块从开发到测试之间的时间间隔较长,使得程序员的修改和维护工作要付出更大的代价;

      c)由于受到分发日期的限制,测试工作往往是在忙碌中结束的,而将大量的缺陷遗留给最终用户,也就是说,真正的测试工作实际上是由最终用户来完成的。

      因此,为了保证测试工作科学、精确、全面、有序地进行,应该采取一边开发一边测试的策略,使得开发工作与测试工作平行进行,这也就是俗话所说的“越早测试越好”的概念。

      一套完整的测试应该由五个阶段组成:

      1.测试计划

      首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应的测试需求报告,即制订黑盒测试的最高标准,以后所有的测试工作都将围绕着测试需求来进行,符合测试需求的应用程序即是合格的,反之即是不合格的;同时,还要适当选择测试内容,合理安排测试人员、测试时间及测试资源等。

      2.测试设计

      将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并为每个测试过程选择适当的测试用例(测试用例选择的好坏将直接影响到测试结果的有效性)。

      3.测试开发

      建立可重复使用的自动测试过程。

      4.测试执行

      执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成,测试人员应本着科学负责的态度,一步一个脚印地进行测试。

      5.测试评估

      结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。

      显然,黑盒测试只有严格按照步骤进行,才可能对应用程序的质量进行把关。然而,如果没有一种优秀的测试工具的帮助,单纯凭借手工测试,不但将耗费大量的人力、物力和财力,而且有很多测试工作是难以实现甚至是无法实现的。

      三、手工测试与自动测试的比较

      手工测试无法保证黑盒测试的科学性与严密性,这是因为:

      ●测试人员要负责大量文档、报表的制订和整理工作,会变得力不从心;

      ●受软件分发日期、开发成本及人员、资源等诸多方面因素的限制,难以进行全面的测试;

      ●如果修正缺陷所花费的时间相当长,回归测试将变得异常困难;

      ●对测试过程中发现的大量缺陷缺乏科学、有效的管理手段,责任变得含混不清,没有人能向决策层提供精确的数据以度量当前的工作进度及工作效率;

      ●反复测试带来的倦怠情绪及其他人为因素使得测试标准前后不一,测试花费的时间越长,测试的严格性也就越低;

      ●难以对不可视对象或对象的不可视属性进行测试。

      因此,自动测试成为最佳的解决方案。所谓自动测试,实际上是将大量的重复性工作交给计算机去完成,一个优秀的自动测试工具,不但可以满足科学测试的基本要求,而且可以节约大量的时间、成本、人员和资源,并且测试脚本可以被重复利用(包括被不同的项目所利用)。
  • 面试必成5大原则

    2007-05-22 15:00:13

      尼克。柯考迪罗斯,一位专门替大公司物色高级职员的猎头专家,多年来,他从设在加州硅谷的公司引荐过大量精英给许多大公司,如施乐公司、IBM公司、通用电气公司等。以下是他向准备参加面试的求职者提出"求职必成6原则“。但请求职者注意的是:面试成不成功,最更本的决定因素还是你本身具不具备你所去面试的公司所需的素质或潜质。

       履历表用途不大

       专业位大公司物色人才的专家都知道,公司是否雇用某个人,决不会只根据这个人的履历。履历表只是列出你过去的经历,对求职可以说没有什么帮助,因为不能证明你可以胜任你想得到的那份工作。柯考迪罗斯说:履历表的作用是供雇主参考,根据他来推测你是否对他们有用。只靠履历表某直觉不可能成功。"他忆起一句促销格言:赠送货样给顾客,可让顾客找到理由多买一些。他建议你也这样做:向雇主举例说明你能为他们做些什么。“在履历表中增加一栏,称之为'能为贵公司带来的利益‘。用两句话来说明你能为未来雇主带来什么好处。例如,我会整顿运输部,节省营运成本。"内容要具体,想你去求职的每一家公司应提交不同的履历表。

       不要理会人力资源部

       只要可能,猎头专家总是设法绕过人力资源部。"大多数人力资源部其实都是以处理文件为主的部门,“柯考迪罗斯说,"他们把你的求职函、履历表等文件装包、编组、归档、分类。然后,如果你的文件有幸没在混乱中给弄丢,他们可能把你的文件送交一位真正知道公司需要什么人才的经理。可是,在你等待人力资源部约你去面试的时候,猎头公司的人已在打电话、走后门去和负责雇用职员的经理接触了。”所以,你求职也应采取同样的策略:直接向有最终决定权的人求职。

       面试以前必须查明一切

       猎头公司只会推荐显然符合资格的求职者去面世。你找工作时,也应先设法了解自己是否能胜任那个职位。去面试前要先查明该职位的工作范围,研究该公司,摸清他的企业文化和目标,以及有什么竞争对手。

       要了解某家公司,最好的方法就是去找该公司的雇员谈谈。罗切斯特大学电机工程学及光学博士班学生肯登。格林毕业前去求职,就采用了这种方法:"我会去找一篇在我感兴趣的那家公司工作的某同行所写的论文,然后打电话给他要求跟他谈谈,向他查询我是否达到受雇条件,并且讨论公司的需求。我这样做了之后,结果通常是:我获邀请去面试,要不然就是总算知道这家公司并不适合我。“

       调查可能加入的那家公司之后,你往往会发觉那家公司其实并不适合你。"那可是好事,“柯考迪罗斯说,"到你最终找到一家真正适合你的公司时,你就会满怀信心地去面试,并且认定该公司时你愿意效力的。”

       记住,雇主真的想雇用你

    "公司举行面试是为了要找到最佳人选,“柯考迪罗斯说,"如果你获录用,经理会欣喜若狂,因为他或她再也不用主持面试,可以去做自己的工作了。”

       所以你要调整一下自己的心态。"如果你确信经理会录用你,面试时自然充满信心、挥洒自如,而经理就可能因此对你产生好感。“

       视面试为第一天上班

       大多数人视面试为讯问:雇主提出问题,他们答话。猎头专家认为需避免让这种局面出现。柯考迪罗斯说:"你应该当自己已是雇员,正在那里讨论一项新计划,而不应视自己为渴望获录用的求职者,并因而表现的卑躬屈膝、唯唯诺诺。“

       且看柯考迪罗斯如何指点想去美国电报电话公司填补空缺的盖利。查高斯基。主持面试的副总裁告诉查高斯基,面试不会超过20分钟。查高斯基走到副总裁旁边的记事板前,扼要地写下该公司正面临的考验,以及他相信可为公司增加利润的措施。15分针后,查高斯基写下他估计的最终利润,同时抬起头来朝副总裁看了一眼。

    "那副总裁嘴巴张得老大,“柯考迪罗斯说,"他告诉查高斯基,面试可以继续下去。”然后副总裁去把他自己部门的人都叫了进来,大家开会开了两个小时。

       查高斯基如此把面试转为工作会议,不但让对方看得出他了解并能胜任他所应征的职位,也让对方明白他能为公司带来什么益处。

       如获录用,先参观公司

       雇主如果决定聘用你,他除了给你提供一个职位和相应的薪金福利,还放弃了部分对雇用程序的控制权。"面试开始的时候,雇主对是否录用你掌握全部决定权,“柯考迪罗斯说,"但一旦告诉你他要聘用你,他就把决定权让给了你。身处这种情况的人只有极少数知道自己拥有此权力。你一旦知道了自己已获录用,就应该去研究是否要更改聘用条件以助你达成目标,也应到该公司去彻底参观一次。”

       去参观你将要加入的那个部门,要求和那部门的人见面,看看由那些资源归你支配。要求把薪酬提高—先决条件是你认为自己值得拿较高的薪酬。不必担心雇主可能不满。"只要你提出要求的时候有技巧,所提要求也合理,“柯考迪罗斯说,"公司时会考虑的。”

       他指出,一旦你获得录用,"你就有权决定是否加入那家公司,是否应该要求更好的薪酬和福利。"

  • 35岁前必须做好十件事

    2007-05-22 14:59:14

    第一,学会本行业所需要的一切知识并有所发展。已故零件大王布鲁丹在他35岁时,已经成为零件行业的领袖,并且组建了年收入达千万美元的海湾与西部工业公司。每个人在年轻时都可能有过彻夜不眠、刻苦攻读,这在20岁甚或30岁都没有问题,但到了35岁,就不应该再为学习基本技能而大伤脑筋了。35岁之前是一个人从事原始积累的阶段,35岁之后就应该勃发了。

      第二,养成个人风格。在35岁以前,找出你所喜欢的,不论是衣着或是爱好,哪怕是与众不同的小习惯也好。20岁、30岁时你可以不断尝试、不断改变,但是到了35岁,你便要明确地建立个人风格。一位男士或女士在事业中途改变自己的形象,就会让人觉得很不可靠。你喜欢穿西装吗?好!就把西装当作你的商标吧!办公桌上摆些鲜花会令你工作更有效率吗?那就每天都摆些鲜花吧!

      第三,在感情生活方面平和安定。在攀登事业的高峰时,如果私人生活不愉快,陷入感情危机,对你会产生很大的干扰,甚至会逐渐令你对别的事物失去兴趣。那些在35岁之前私人生活已经平和安定的人,一般都比生活动荡不安的人有更大的机会获得成功。因此,如果你想结束一段没有结果的恋情,或者你想和女友结婚,那就赶快行动吧,免得把问题拖到生命的第35个春秋。在35岁以后,你应该专注地看着你对事业的投资开始获利。

      第四,明白自己的短处。承认有些事情你的确做不好,或者不愿做。如果你讨厌数字而喜欢创作,那就不要因为待遇高或顺从别人的期望而强迫自己做数字工作。在 35岁之前,一定要投入你所喜爱、所擅长的那种工作。否则,35岁之后必然会有一段郁郁不乐的日子。而且,真正的成功可能因为活力的消退而丧失。

      第五,知道自己的长处。你应该知道自己擅长什么,并且清楚你所喜欢做而又做得比别人好的事情。不管你目前担任什么样的角色,知道自己的长处对成功都很重要。

      第六,储备辞职另谋生路的钱。在这个多变的职业世界里,你也许不会永远在一个地方工作,或者永远在一个位置上淋漓尽致地发挥自己,当你感到无法施展时,你很可能会想到辞职,或者开辟第二职业,如果你事先储蓄了足够的钱,你便有了一个安全的后盾。

      第七,建立人际关系网。如果到了35岁你仍未建立起牢固的人际关系网,那你就有麻烦了。这个人际关系网包括你的朋友、亲人,最低限度包括所有可以互相帮助的人。这些人有的是你的同事,有的受过你的恩惠,有的你倾听过他们的问题,有的你和他有着相同的爱好。人际关系网不是一朝一夕就能建立起来的,它需要几年甚至十几年的培养。一个人在事业上、生活上的成功其实如同一个政党的成功,你要有许多人散布在适当的地方,你可以依赖他们,他们也可以依赖你。

      第八,学会授权他人。许多人不肯或不能这样做,因此始终被钉在从属的职位上。授权他人是成功的一半,一个事无巨细,不能将工作授权别人的人,注定会遇到极大的障碍。到了35岁,你最好已成为这方面的专家。换言之,你懂得挑选合适的人并信任他们。

      第九,学会在什么时候三缄其口。因说话不小心而自毁前程的人,比因为任何其他原因丧失成功的人都多。要学会保持沉默而且看起来机智 别人自然以为你知道的比实际还多。别讲别人的闲话,别谈论你自己的大计,守口如瓶所赢得的声誉,远比讲人闲话所带来的东西更加珍贵。你在事业上越成功,这一点就越重要。

      第十,对人要忠诚。如果你到了35岁仍未能建立起坚如磐石的忠诚信誉,这一缺点将会困扰你一生。不忠诚的恶名必然会使你在事业上到处不受欢迎。你不能靠暗箭伤人爬到事业的顶峰,而要靠在早期树立起来的真诚刚直和不可动摇的声誉。35岁以前,忠诚只是投资;35岁以后,你会作为一个可以信赖的人收到忠诚的回报。

  • 测试生命周期-SQA测试过程

    2007-05-22 14:05:36

    测试生命周期

    测试计划 → 测试设计 → 测试开发 → 测试执行 → 测试评估   

    测试计划就是定义一个测试项目的过程,以便能够正确的度量和控制测试。

    第一部分:测试计划
    测试计划的问题:
      1、测试计划经常是等到开发周期后期才开始实行,使得没有时间有效的执行计划;
      2、测试计划的组织者可能缺乏Client/Server测试经验;
      3、测试的量度和复杂性可能太大,没有自动化工具,很难计划和控制。
    测试策略:
      测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试(单元测试、集成测试、系统测试)以及每个阶段内在进行的测试种类(功能测试、性能测试、压力测试等)。
      测试策略包括
      1、要使用的测试技术和工具;
      2、测试完成标准;
      3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。
      测试计划最关键的一步就是将软件分解成单元,写成测试需求。
      测试需求有很多分类方法,最普通的一种就是按照商业功能分类。把软件分解成单元元件有几个好处:
      1、测试需求是测试设计和开发测试用例的基础,分成单元可以更好地进行设计;
      2、详细的测试需求是用来衡量测试覆盖率的重要指标;
      3、测试需求包括各种测试实际和开发以及所需资源。
    怎样估计测试工作量:
      1、效率假设:即测试队伍的工作效率。对于功能测试,这主要依赖于应用的复杂度,窗口的个数,每个窗口中的动作数目。对容量测试,主要依赖于建立测试所需数据的工作量大小。
      2、测试假设:为了验证一个测试需求所需测试动作数目。
      3、应用的维数:应用的复杂度指标。例如要加入一个记录,测试需求的维数就是这个记录中域的数目。
      4、所处测试周期的阶段:有些阶段主要工作都在设计,有些阶段主要是测试执行。
    测试资源:
      1、人力资源
      测试经理
      为测试项目提供总体方向。开发测试计划、征集并监督测试人员、申请系统资源、监视并汇报工作进程、测试评估、测试需求的分解。
      测试工程师 ---- 设计和开发
      设计:对被测软件的详细了解、分解测试需求的技能、选择在C/S环境下用来验证测试需求的技术。
      开发:熟悉SQA、VB、和脚本语言。
      测试工程师 ---- 执行
      负责测试执行和记录结果。需要能够安装系统,网络知识,初始化数据库和其他初始条件。重要的是诊断能力。
      测试系统管理者
      每个测试项目必须指定一个专人负责管理SQA Suite。包括在服务器上安装存储库,安装打印机连接,执行备份,以及其他维护工作。管理者必须高度熟悉SQA,网络工作经验。
      2、系统资源
      安装SQA Suite的硬件和软件环境
      数据库服务器
      该服务器必须专用于 测试工作,能够重置某些初始值,包括系统日期和时间等。
    写测试计划的步骤:
      1、确定工程
      收集下列信息
    文档 已创建(是/否) 版本/日期 需求详述     功能详述     项目计划     设计详述     原型     用户手册      定义新的工程,Adminà New Project。
      确定软件的结构,用Assetsà Software Structure选项定义软件结构。
      2、定义测试策略
    测试策略项 例子 测试阶段 系统测试 测试类型 功能测试 测试技术 75%用SQA Suite自动测试,25%手工测试 完成标准 95%测试用例通过并且最高级缺陷全部解决 特殊考虑 测试必须在上午进行  3、分解软件,写测试需求
      分析各种信息
      反复检查并理解各种信息,和用户交流,理解他们的要求。可以按照以下步骤执行:
      1、确定软件提供的主要商业任务
      2、对每个商业任务,确定完成该任务所要进行的交易。
      3、确定从数据库信息引出的计算结果。
      4、对于对时间有要求的交易,确定所要的时间和条件。这些条件包括数据库大小、机器配置、交易量、以及网络拥挤情况。

     5、确定会产生重大意外的压力测试,包括:内存、硬盘空间、高的交易率
      6、确定应用需要处理的数据量。
      7、确定需要的软件和硬件配置。通常情况下,不可能对所有可能的配置都测试到,因此要选择最有可能产生问题的情况进行测试,包括:最低性能的硬件、几个有兼容性问题的软件并存、客户端机器通过最慢的LAN/WANF连接访问服务器。
      8、确定其他与应用软件没有直接关系的商业交易。包括:
        管理功能,如启动和推出程序
        配置功能,如设置打印机
        操作员的爱好,如字体、颜色
        应用功能,如访问email或者显示时间和日期。
      9、确定安装过程,包括定置从哪安装、定制安装、升级安装。
      10、确定没有隐含在功能测试中的户界面要求。大多界面都在功能测试时被测试到。还有写没有测到,如:操作与显示的一致性,如使用快捷键等;界面遵从合理标准,如按钮大小,标签等。
      把需求组织成层次图
      4、估计测试工作量
      ∑(每个测试的时间*每个需求的测试的数目*测试需求的的数目)
      (测试设计、开发、….)
      5、确定资源
      人力资源
    职位 姓名 特殊责任/说明 测试经理     测试工程师
    设计/开发(可以多人)     测试工程师
    测试执行(可以多人)     测试系统管理员      系统资源
    系统 名称/类型 数据库服务器 网络/子网
    服务器名称
    数据库名称
            SQA 测试存储库 网络/子网
    服务器名称
          客户测试机 包括专门的配置需求
    列表   测试开发的PC机 列表  6、创建工程调度表
    任务 相关工作量(天) 整个SQA过程 38 测试计划 12 确定项目 1 定义测试策略   决定测试需求   估计工作量   确定资源   调度测试活动   生成测试计划文档   测试设计 7 分析测试需求   指定测试过程   指定测试用例   查看测试需求的覆盖率   测试开发 12 建立测试开发环境   录制和回放原型过程   开发测试过程   测试和调试测试过程   修改测试过程   建立外部数据集合   重新测试并调试测试过程   测试执行 6 设置测试系统   执行测试   验证测试结果   调查突发结果(unexpected result)   生成缺陷日记   测试评估 1 回顾测试日记   评估测试需求的覆盖率   评估缺陷   决定是否达到测试完成的标准    7、书写测试计划
      1、介绍
        目的
        背景
        测试范围
        项目文件列表
      2、测试需求
      3、测试策略
        测试类型
        1、功能测试
        2、用户界面测试
        3、性能测试
        4、压力测试
        5、容量测试
        6、配置测试
        7、安装测试
        工具
      4、资源
        人力资源
        系统资源
      5、调度
      6、文档
        软件元件
        测试特性(Assets)
        测试日记
        缺陷报告
    第二部分:测试设计
    测试设计的问题
      1、不做测试设计,测试过程也是胡乱建立的。
      2、测试设计不详细,不是基于可量度的测试策略,例如测试计划覆盖一个集合或者测试需求的一个子集。
      3、测试过程没有采用最好的技术来检验Windows C/S结构的测试需求
    测试用例的选择规则
      1、选择与测试需求的实质部分最相关的测试用例。
      2、选择的测试用例应该不容易应用程序的改变的影响。
      下面是选择测试用例的几点具体规则:
      1、商业函数
      商业函数一般与数据库有关,要测试数据库的变化,有几种方法:
      1、如果数据库的的改变会反映在一个列表框中,那么就要选择验证列表框内容的测试用例。
      2、还可以检查交易完成后的确认对话框。可以检查对话框的标题。图象比较也可以检查确认对话框,但图象比较容易受其他因素影响。
      3、修改脚本,SQA Basic提供了强大的数据库支持。
      2、域的验证

      各种不同的域选择相应的测试用例。
      3、用户界面测试
      对象状态测试用例
      4、性能标准
      等待状态测试用例
      5、压力下的操作
      6、访问控制
      Object state test case
      7、配置测试
      不能选择图象测试用例(也分辨率有关)和文件测试用例(与驱动器有关)
      8、安装选项和验证
      对象状态用例和窗口存在用例,文件存在用例。
    书写测试设计的步骤
        生成测试需求报告
           ↓
         指定测试过程
           ↓
       指定测试用例(可选)
           ↓
        回顾测试覆盖率
    第三部分:测试开发
    输入:被测软件、基于测试需求的测试设计
    输出:测试过程和测试用例
    目标:
      1、创建可以重用的测试过程和测试用例
      2、维护测试过程、测试用例与相关测试需求的一一对应。
    测试开发的问题:
      1、测试开发很乱,与测试需求或测试策略没有对应性
      2、测试过程不可重复或不可重用
      3、测试过程被作为一个编程任务来执行,导致脚本太长,不能满足软件移植性的要求。
    错误处理
      当测试过程发生错误时,有几种解决办法:
      1、跳转到别的测试过程
      2、调用一个能够清除错误的过程
      3、退出过程,启动另一个
      4、退出过程和应用程序,重新启动启动Windows,在失败的地方重新开始测试
    测试开发的步骤
      1、设立开发环境
        SQA Suite
        连接到SQA存储库
        启动SQA Baisc或VB
        被测软件
        等等
      2、录制和回放原型过程
      原型过程指出所有未知窗口控制,使得他们都能象标准窗口那样动作或者没有特别的动作,把他们都划归为Generic类型。通过这个过程,SQA Robot就知道该怎样处理应用中的特殊控制。
      1、把recording option 中的Define Unknown Object as Type Generic选项设置为off
      2、使用的过程标识符要可以被覆盖,或者能被删掉。因为这只是个原型,用来教SQA Robot 录制的过程
      3、录制测试过程和测试用例
      1、录制模块测试过程和与测试需求最低层对应的测试用例;
      2、录制初始化过程;
      3、录制导航过程,把前面的过程串起来;
      4、测试和调试测试过程
      5、修改测试过程(可选)
      6、建立外部数据集合
      如果测试过程是用来循环一套输入和输出数据,就需要建立数据集合。
      7、重复测试和调试测试过程,回到4
    第四部分:测试执行
    测试执行的问题
      1、自动化测试没有有效的利用,使得手工测试太多。
      2、测试结果的捕获没有系统性,而且没有查看或调查
      3、缺陷报告必须用手工加入缺陷跟踪系统
    错误分类
      1、测试用例失败
        正常错误
      2、脚本命令失败
        当测试过程不能不能执行录制过程中的某个功能时,回产生这种错误,如鼠标单击按钮或选择菜单项等。它也能指示是缺陷还是测试过程的设计问题。
      3、致命错误
        导致测试停止,这种情况最好重起Windows。
    具体步骤:
      1、建立测试系统
      2、准备测试过程
      3、运行初始化过程
      4、执行测试
      5、从终止的测试恢复
      6、验证预期结果
      7、调查突发结果
      8、记录缺陷日记
    第五部分:测试评估
    测试评估的目标
      1、量化测试进程
      2、生成缺陷和测试覆盖率的总结报告
    测试评估的问题
      1、没有把测试覆盖率作为报告测试进程的根据,使得不知测试是否结束;
      2、没有做缺陷评估,缺陷评估是量度软件可行性的重要指标;
      3、不使用专门的软件工具进行数据输入任务和相应的评估活动,使得这些任务变得繁重累人。
    测试覆盖率
      评估测试完成多少的标准
    缺陷评估
      评估软件质量的重要指标,通常评估模型假设缺陷的发现是呈泊松分布的;严格的缺陷评估要考察在测试过程中发现缺陷的间隔时间长短。评估要估计软件当前的可靠性并预测随着测试的继续进行,软件可靠性会怎样提高。

      SQA Suite 提供四种形式进行缺陷评估:
      1、缺陷分布报告可以生成缺陷数量与缺陷属性的函数。如测试需求和状态。
      2、缺陷趋势报告可以看出缺陷增长和减少的趋势;
      3、缺陷年龄报告展示一个缺陷处于某种状态的时间长短
      4、测试结果进度报告展示测试过程在被测应用的几个版本中的执行结果以及测试周期。
    具体步骤
      1、回顾测试日记
      2、评估测试需求的覆盖率
      3、分析缺陷
      4、决定是否达到完成测试的标准,没有满足标准时
        1、再测试
        2、降低标准
        3、确定软件的一个满足标准的子集,看是否可以发布。

  • 如何制定成功的测试计划

    2007-05-22 13:55:00

       “工欲善其事,必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的,但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括:产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。

       产品基本情况调研:

      这部分应包括产品的一些基本情况介绍,例如:产品的运行平台和应用的领域,产品的特点和主要的功能模块,产品的特点等。对于大的测试项目,还要包括测试的目的和侧重点。

      具体的要点有:

      目的:重点描述如何使测试建立在客观的基础上,定义测试的策略,测试的配置, 粗略的估计测试大致需要的周期和最终测试报告递交的时间。

      变更:说明有可能会导致测试计划变更的事件。包括测试工具改进了,测试的环境改变了,或者是添加了新的功能。

      技术结构:可以借助画图,将要测试的软件划分成几个组成部分,规划成一个适用于测试的完整的系统,包括数据是如何存储的,如何传递的(数据流图),每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求,比如运行平台、需要什么样的数据库等等。

      产品规格:就是制造商和产品版本号的说明。

      测试范围:简单的描述如何搭建测试平台以及测试的潜在的风险。

      项目信息:说明要测试的项目的相关资料,如:用户文档,产品描述,主要功能的举例说明。

      测试需求说明:

      这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题,你应该很高兴你有这个记录在案的文档,可以证明你测了什么没测什么。具体要点有:

      功能的测试:理论上是测试是要覆盖所有的功能项,例如:在数据库中添加、编辑、删除记录等等,这会是一个浩大的工程,但是有利于测试的完整性。

      设计的测试:对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

      整体考虑:这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

      测试的策略和记录:

      这是整个测试计划的重点所在,要描述如何公正客观地开展测试,要考虑:模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节,越详细越好,并制作测试记录文档的模板,为即将开始的测试做准备,测试记录重要包括的部分具体说明如下:

      公正性声明:要对测试的公正性、遵照的标准做一个说明,证明测试是客观的,整体上,软件功能要满足需求,实现正确,和用户文档的描述保持一致。

      测试案例:描述测试案例是什么样的,采用了什么工具,工具的来源是什么,如何执行的,用了什么样的数据。测试的记录中要为将来的回归测试留有余地,当然,也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

      特殊考虑:有的时候,针对一些外界环境的影响,要对软件进行一些特殊方面的测试。

      经验判断:对以往的测试中,经常出现的问题加以考虑。

      设想:采取一些发散性的思维,往往能帮助你找的测试的新途径。

      测试资源配置:

      项目资源计划:制定一个项目资源计划,包含的是每一个阶段的任务、所需要的资源,当发生类似到了使用期限或者资源共享的事情的时候,要更新这个计划。

      计划表:

      测试的计划表可以做成一个多个项目通用的形式,根据大致的时间估计来制作,操作流程要以软件测试的常规周期作为参考,也可以是根据什么时候应该测试哪一个模块来制定。

      问题跟踪报告:

      在测试的计划阶段,我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质,问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的,以及明确问题产生时的测试环境。

      问题描述尽可能是定量的,分门别类的列举,问题有几种:

      1、严重问题:严重问题意味着功能不可用,或者是权限限制方面的失误等等,也可能是某个地方的改变造成了别的地方的问题。

      2、一般问题:功能没有按设计要求实现或者是一些界面交互的实现不正确。

      3、建议问题:功能运行得不象要求的那么快,或者不符合某些约定俗成的习惯,但不影响系统的性能,界面先是错误,格式不对,含义模糊混淆的提示信息等等。

      测试计划的评审:

      又叫测试规范的评审,在测试真正实施开展之前必须要认真负责的检查一遍,获得整个测试部门人员的认同,包括部门的负责人的同意和签字。

      结果:

      计划并不是到这里就结束了,在最后测试结果的评审中,必须要严格验证计划和实际的执行是不是有偏差,体现在最终报告的内容是否和测试的计划保持一致,然后,就可以开始着手制作下一个测试计划了。

  • 如何才能做好测试自动化(TA)?

    2007-05-22 10:33:50

    在自动化测试引入和应用中,我们清楚一些基本的原则:

    -选择好工具,最流行的工具不一定适合自己,真正适合自己的工具才是最好的。如Robot不一定是最好的,但它的多机交互协作能力是其它工具没有的

    -根据客户端、Web和服务器的不同特点可选择不同的测试工具,如Web的链接、UI变化快和复杂的逻辑,工具的录制功能要强、稳定,适应不同的平台(Windows, Linux, Mac OS)和浏览器(IE, ForeFox, NS, ...)。而服务器一般不存在UI界面,主要是对不同协议的支持。

    -负载、性能自动化测试比较容易实现,但功能性测试更困难

    -软件测试自动化(TA)虽然具有很多优点,但只是对手工测试的一种补充,TA绝不能代替手工测试。在系统功能逻辑测试、验收测试、适用性测试、涉及物理交互性测试时,多采用黑盒测试的手工测试方法; 单元测试、集成测试、系统负载或性能、稳定性、可靠性测试等比较适合采用TA。

    - 工具本身并没有想象力和灵活性,自动测试只能发现15-30%的缺陷,而手工测试可以发现70-85%的缺陷;TA工具在进行功能测试时,其准确的含义是回归测试工具,因为工具不能发现更多的新问题,但可以保证对已经测试过部分进行测试的准确性和客观性 

     -找准测试自动化的切入点,一般从长期的新产品开始、同步进行,并选用一些相对容易进行自动化处理的、手工测试较繁的模块着手,如大量API调用、邮件模板处理等;

     -把测试开发纳入整个软件开发体系,是必要的,系统不具有可测试性,再好的工具也无能为力。而且测试自动化前期投入大,这样软件开发的前期分配的时间要多些,测试执行的时间可短些;人力分配也不同,进行资源的合理调度。
     

    -测试自动化依赖测试流程和测试用例。没有好的测试流程或者没有设计有效的测试用例,测试工具会事倍功半。
     软件测试自动化的投入较大
     

    但有一个问题困扰着我们,即采用下面哪种模式更好?

    1。专门的TA团队,负责自动化模块开发,开发完后交给进行功能测试的队伍。人为增加了一个交接工作、沟通层次,但TA团队全心再Scipting, 开发效率高,而且有利于留住TA engineer

    2. 将产品的部分模块承包给TA团队,TA开发好了,他们手工测试就少了,让TA团队自己Drive自己,效果应该不错,但开发效率可能会低,或TA团队感觉压力太大,或不喜欢手工测试,容易被逼走去做开发。

    Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=779294

  • LoadRunner函数小全

    2007-05-22 10:03:27

    LR函数:
    lr_start_transaction

    为性能分析标记事务的开始

    lr_end_transaction

    为性能分析标记事务的结束

    lr_rendezvous

    在 Vuser 脚本中设置集合点

    lr_think_time

    暂停 Vuser 脚本中命令之间的执行 

    lr_end_sub_transaction

    标记子事务的结束以便进行性能分析

    lr_end_transaction

    标记 LoadRunner 事务的结束

    Lr_end_transaction("trans1",Lr_auto);

    lr_end_transaction_instance

    标记事务实例的结束以便进行性能分析

    lr_fail_trans_with_error

    将打开事务的状态设置为 LR_FAIL 并发送错误消息

    lr_get_trans_instance_duration

    获取事务实例的持续时间(由它的句柄指定)

    lr_get_trans_instance_wasted_time

    获取事务实例浪费的时间(由它的句柄指定)

    lr_get_transaction_duration

    获取事务的持续时间(按事务的名称)

    lr_get_transaction_think_time

    获取事务的思考时间(按事务的名称)

    lr_get_transaction_wasted_time

    获取事务浪费的时间(按事务的名称)

    lr_resume_transaction

    继续收集事务数据以便进行性能分析

    lr_resume_transaction_instance

    继续收集事务实例数据以便进行性能分析

    lr_set_transaction_instance_status

    设置事务实例的状态

    lr_set_transaction_status

    设置打开事务的状态

    lr_set_transaction_status_by_name

    设置事务的状态

    lr_start_sub_transaction

    标记子事务的开始

    lr_start_transaction

    标记事务的开始

    Lr_start_transaction("trans1");

    lr_start_transaction_instance

    启动嵌套事务(由它的父事务的句柄指定)

    lr_stop_transaction

    停止事务数据的收集

    lr_stop_transaction_instance

    停止事务(由它的句柄指定)数据的收集

    lr_wasted_time

     消除所有打开事务浪费的时间

    lr_get_attrib_double

    检索脚本命令行中使用的 double 类型变量

    lr_get_attrib_long

    检索脚本命令行中使用的 long 类型变量

    lr_get_attrib_string

    检索脚本命令行中使用的字符串

    lr_user_data_point

    记录用户定义的数据示例

    lr_whoami

    将有关 Vuser 脚本的信息返回给 Vuser 脚本

    lr_get_host_name

    返回执行 Vuser 脚本的主机名

    lr_get_master_host_name

    返回运行 LoadRunner Controller 的计算机名

    lr_eval_string

    用参数的当前值替换参数

    lr_save_string

    将以 NULL 结尾的字符串保存到参数中

    lr_save_var

    将变长字符串保存到参数中

    lr_save_datetime

    将当前日期和时间保存到参数中

    lr _advance_param

    前进到下一个可用参数

    lr _decrypt

    解密已编码的字符串

    lr_eval_string_ext

    检索指向包含参数数据的缓冲区的指针

    lr_eval_string_ext_free

    释放由 lr_eval_string_ext 分配的指针

    lr_save_searched_string

    在缓冲区中搜索字符串实例,并相对于该字符串实例,将该缓冲区的一部分保存到参数中

    lr_debug_message

    将调试信息发送到输出窗口

    lr_error_message

    将错误消息发送到输出窗口

    lr_get_debug_message

    检索当前消息类

    lr_log_message

    将消息发送到日志文件

    lr_output_message

    将消息发送到输出窗口

    lr_set_debug_message

    设置调试消息类

    lr_vuser_status_message

    生成带格式的输出,并将其写到 ControllerVuser 状态区域

    lr_message

    将消息发送到 Vuser 日志和输出窗口

    lr_load_dll

    加载外部 DLL

    lr_peek_events

    指明可以暂停 Vuser 脚本执行的位置

    lr_think_time

    暂停脚本的执行,以模拟思考时间(实际用户在操作之间暂停以进行思考的时间)

    lr_continue_on_error

    指定处理错误的方法

    lr_continue_on_error (0);lr_continue_on_error (1);

    lr_rendezvous

     在 Vuser 脚本中设置集合点

    TE_wait_cursor

    等待光标出现在终端窗口的指定位置

    TE_wait_silent

    等待客户端应用程序在指定秒数内处于静默状态

    TE_wait_sync

    等待系统从 X-SYSTEM 或输入禁止模式返回

    TE_wait_text

    等待字符串出现在指定位置

    TE_wait_sync_transaction

    记录系统在最近的 X SYSTEM 模式下保持的时间

     

    WEB函数列表:

    web_custom_request

    允许您使用 HTTP 支持的任何方法来创建自定义 HTTP 请求

    web_image

    在定义的图像上模拟鼠标单击

    web_link

    在定义的文本链接上模拟鼠标单击

    web_submit_data

    执行“无条件”或“无上下文”的表单

    web_submit_form

    模拟表单的提交

    web_url

    加载由“URL”属性指定的 URL

    web_set_certificate

    使 Vuser 使用在 Internet Explorer 注册表中列出的特定证书

    web_set_certificate_ex

    指定证书和密钥文件的位置和格式信息

    web_set_user

    指定 Web 服务器的登录字符串和密码,用于 Web 服务器上已验证用户身份的区域

    web_cache_cleanup

    清除缓存模拟程序的内容

    web_find

    在 HTML 页内搜索指定的文本字符串

    web_global_verification

    在所有后面的 HTTP 请求中搜索文本字符串

    web_image_check

    验证指定的图像是否存在于 HTML页内

    web_reg_find

    在后面的 HTTP 请求中注册对 HTML源或原始缓冲区中文本字符串的搜索

    web_disable_keep_alive

    禁用 Keep-Alive HTTP 连接

    web_enable_keep_alive

    启用 Keep-Alive HTTP 连接

    web_set_connections_limit

    设置 Vuser 在运行脚本时可以同时打开连接的最大数目

    web_concurrent_end

    标记并发组的结束

    web_concurrent_start

    标记并发组的开始

    web_add_cookie

    添加新的 Cookie 或修改现有的 Cookie

    web_cleanup_cookies

    删除当前由 Vuser 存储的所有 Cookie

    web_remove_cookie

    删除指定的 Cookie

    web_create_html_param

    将 HTML 页上的动态信息保存到参数中。(LR 6.5 及更低版本)

    web_create_html_param_ex

    基于包含在 HTML 页内的动态信息创建参数(使用嵌入边界)(LR 6.5 及更低版本)。

    web_reg_save_param

    基于包含在 HTML 页内的动态信息创建参数(不使用嵌入边界)

    web_set_max_html_param_len

    设置已检索的动态 HTML 信息的最大长度

    web_add_filter

    设置在下载时包括或排除 URL 的条件

    web_add_auto_filter

    设置在下载时包括或排除 URL 的条件

    web_remove_auto_filter

    禁用对下载内容的筛选

    web_add_auto_header

    向所有后面的 HTTP 请求中添加自定义标头

    web_add_header

    向下一个 HTTP 请求中添加自定义标头

    web_cleanup_auto_headers

     停止向后面的 HTTP 请求中添加自定义标头

    web_remove_auto_header

    停止向后面的 HTTP 请求中添加特定的标头

    web_revert_auto_header

    停止向后面的 HTTP 请求中添加特定的标头,但是生成隐性标头

    web_save_header

    将请求和响应标头保存到变量中

    web_set_proxy

    指定将所有后面的 HTTP 请求定向到指定的代理服务器

    web_set_proxy_bypass

    指定 Vuser 直接访问(即不通过指定的代理服务器访问)的服务器列表

    web_set_proxy_bypass_local

    指定 Vuser 对于本地 (Intranet) 地址是否应该避开代理服务器

    web_set_secure_proxy

    指定将所有后面的 HTTP 请求定向到服务器

     

    web_set_max_retries

    设置操作步骤的最大重试次数

    web_set_timeout

    指定 Vuser 等待执行指定任务的最长时间

    web_convert_param

    将 HTML 参数转换成 URL 或纯文本

    web_get_int_property

    返回有关上一个 HTTP 请求的特定信息

    web_report_data_point

    指定数据点并将其添加到测试结果中

    web_set_option

    在非 HTML 资源的编码、重定向和下载区域中设置 Web 选项

    web_set_sockets_option

     设置套接字的选项

  • 如何制定成功的测试计划

    2007-05-22 09:57:07Digest 1

    摘要: 软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性,便于测试质量的度量,增强测试过程的可管理性。


     

    在实际软件项目测试过程中,由于对软件测试用例的作用和设计方法的理解不同,测试人员(特别是刚从事软件测试的新人)对软件测试用例存在不少错误的认识,给实际软件测试带来了负面影响,本文对这些认识误区进行列举和剖析。

    误区之一:测试输入数据设计方法等同于测试用例设计方法

    现在一些测试书籍和文章中讲到软件测试用例的设计方法,经常有这样的表述:测试用例的设计方法包括:等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的,这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法,而不是测试用例设计的全部内容。

    这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据,从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试用例设计人员把这种认识拿来要求自己,则害了自己;拿来教人,则害了别人;拿来指导测试,则害了测试团队。听起来似乎是“小题大做”,但是绝不是“危言耸听”。

    无疑,对于软件功能测试和性能测试,确定测试的输入数据很重要,它决定了测试的有效性和测试的效率。但是,测试用例中输入数据的确定方法只是测试用例设计方法的一个子集,除了确定测试输入数据之外,测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

    在设计测试用例时,需要综合考虑被测软件的功能、特性、组成元素、开发阶段(里程碑)、测试用例组织方法(是否采用测试用例的数据库管理)等内容。具体到设计每个测试用例而言,可以根据被测模块的最小目标,确定测试用例的测试目标;根据用户使用环境确定测试环境;根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤;根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

    误区之二:强调测试用例设计得越详细越好

    在确定测试用例设计目标时,一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面:尽可能设计足够多的设计用例,测试用例的数量阅读越好;测试用例尽可能包括测试执行的详细步骤,达到“任何一个人都可以根据测试用例执行测试”,追求测试用例越详细越好。

    这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源,可能等到测试用例设计、评审完成后,留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段,分配给测试的时间和人力资源是有限的,而软件项目的成功要坚持“质量、时间、成本”的最佳平衡,没有足够多的测试执行时间,就无法发现更多的软件缺陷,测试质量更无从谈起了。

    编写测试用例的根本目的是有效地找出软件可能存在的缺陷,为了达到这个目的,需要分析被测试软件的特征,运用有效的测试用例设计方法,尽量使用较少的测试用例,同时满足合理的测试需求覆盖,从而达到“少花时间多办事”的效果。

    测试用例中的测试步骤需要详细到什么程度,主要取决于测试用例的“最终用户”(即执行这些测试用例的人员),以及测试用例执行人员的技能和产品熟悉程度。如果编写测试用例的人员也是测试用例执行人员,或者测试用例的执行人员深刻了解被测软件,测试用例就没有必要太详细。而如果是测试新人执行测试用例,或者软件测试外包给独立的第三方公司,那么测试用例的执行步骤最好足够详细。

    误区之三:追求测试用例设计“一步到位”

    现在软件公司都意识到了测试用例设计的重要性了,但是一些人认为设计测试用例是一次性投入,测试用例设计一次就“万事大吉”了,片面追求测试设计的“一步到位”。

    这种认识造成的危害性使设计出的测试用例缺乏实用性,或者误导测试用例执行人员,误报很多不是软件缺陷的“Bug”,这样的测试用例在测试执行过程中“形同虚设”,难免沦为“垃圾文档”的地步。

    “唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中,用户可能对软件的功能提出新需求,设计规格说明相应地更新,软件代码不断细化。设计软件测试用例与软件开发设计并行进行,必须根据软件设计的变化,对软件测试用例进行内容的调整,数量的增减,增加一些针对软件新增功能的测试用例,删除一些不再适用的测试用例,修改那些模块代码更新了的测试用例。

    软件测试用例设计只是测试用例管理的一个过程,除此之外,还要对其进行评审、更新、维护,以便提高测试用例的“新鲜度”,保证“可用性”。因此,软件测试用例也要坚持“与时俱进”的原则。

    误区之四:让测试新人设计测试用例

    在与测试同行交流的过程中,不少刚参加测试工作的测试新人经常询问的一个问题是:“怎么才能设计好测试用例?”。因为他(她)们以前从来没有设计过测试用例,面对大型的被测试软件感到“老虎吃天,无从下口”。

    让测试新人设计测试用例是一种高风险的测试组织方式,它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高,编写效率低,审查和修改时间长,可重用性差。

    软件测试用例设计是软件测试的中高级技能,不是每个人(尤其是测试新人)都可以编写的,测试用例编写者不仅要掌握软件测试的技术和流程,而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

    因此,实际测试过程中,通常安排经验丰富的测试人员进行测试用例设计,测试新人可以从执行测试用例开始,随着项目进度的不断进展,测试人员的测试技术和对被测软件的不断熟悉,可以积累测试用例的设计经验,编写测试用例。

    来源:http://sd.csdn.net/n/20060720/92826.html

  • 谈谈软件测试面试问题

    2007-05-21 17:14:06

    前段时间公司招聘软件测试人员,虽然基本上都是招的应届毕业生,但我还是从现实以及网络上找到了一些应聘软件测试/QA的面试问题集,当然这个也都不会有标准答案的,现在只是以偶的一点理解加上网上的一些内容列举出来供有需要的XDJM们作一下参考:

       1. 首先一般都是比较老套点的问题:介绍一下你的经历。

       HOHO......这个问题我想谁都被问过吧,注意一下重点,不要紧张慢慢说就OK了。

       快速软件测试网为各位软件测试爱好者提供的一个免费的测试交流平台!2. 老套话说了就可以马上切入正题了。根据你的经验说说你对软件测试/质量保证的理解?
    这个就要仁者见仁、智者见智了,也基本上都是书上的东东,如果能有一些自己独特的想法那就最好啦,呵呵

       3. 理解完了那当然就要问一下是不是对软件测试了解啰。这就轮到问软件测试的流程是什么,你原先的公司又是怎么的流程了?
    前面个问题也还是书本上的东西,一般介绍软测的书上都有,实际上国内一般的中小公司根本就达不到书上所说的那些个测试规范,测试流程也是如此,没办法,这就是现在我们整个大的测试环境,这个问题照着书上说的办就行了,后面那个知道该怎么做了吧,尽量把原来公司的测试流程言简意赅的表达出来。

       4. 接着问题就可以有一大堆了,这些问题很多都是要看自己的测试经验以及对测试的理解来作答了,如:
       (1) 你对SQA的职责和工作活动(如软件度量)的理解:
    SQA就是独立于软件开发的项目组,通过对软件开发过程的监控,来保证软件的开发流程按照指定的CMM规程(如果有相应的CMM规程),对于不符合项及时提出建议和改进方案,必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入,从而减少后期软件的维护成本。SQA主要的工作活动包括制定SQA工作计划,参与阶段产物的评审,进行过程质量、功能配置及物理配置的审计等;

       (2) 说说你对软件配置管理的理解

       项目在开发的过程中要用相应的配置管理工具对配置项(包括各个阶段的产物)进行变更控制,配置管理的使用取决于项目规模和复杂性能及风险的水平。软件的规模越大,配置管理就显得越重要。还有在配置管理中,有一个很重要的概念,那就是基线,是在一定阶段各个配置项的组合,一个基线就提供了一个正式的标准,随后的工作便基于此标准,并且只有经过授权后才能变更这个标准。配置管理工具主要有CC,VSS,CVS等,偶只用过CVS,对其它的不熟悉

       (3) 怎样写测试计划和测试用例
        简单点,测试计划里应有详细的测试策略(测试方法等),合理详尽的资源安排等,至于测试用例,那是依赖于需求(包括功能与非功能需求)是否细化到功能点,是否可测试等。


       (4) 说说主流的软件工程思想(如CMM,CMMI,RUP,XP,PSP,TSP等)的大致情况以及你对它们的理解:
       CMM:SW Capability Maturity Model 软件能力成熟度模型,其作用是用于软件过程的改进、评估及软件能力的评鉴
       CMMI:Capability Maturity Model Integration 能力成熟度模型集成 CMMI融入了大部分最新的软件管理实践,同时弥补了SW-CMM模型中的缺陷
       RUP:rational unified process 是软件工程化过程。它提供了在开发机构中分派任务和责任的纪律化方法.它的目标是在可预见的日程和预算前提下确保满足最终用户需求的高质量产品,个人认为:它的核心观念是开发的迭代,每个公司可以根据自身的软件开发的流程和待开发项目的特点对RUP进行适当的剪裁,制定出符合自己的软件开发流程。
       XP:extreme program,即极限编程的意思,适用于小型团队的软件开发,想上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的重要性,强调测试(重点是单元测试)先行的理念。编程可以明显提高代码的质量,持续集成对于快速定位问题很有好处。
    PSP ,TSP 分别是个体软件过程(Personal Software Process),群组软件过程(Team Software Process)大家都知道,CMM只是告诉你怎么做但并没有告诉你如何做,所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做,PSP强调建立个人技能(如何制定计划、控制质量及如何与其他人相互协作等等)而TSP着重于生产并交付高质量的软件产品(如何有效地规划和管理所面临的项目焖偃砑馐酝发任务等等)
       总之,单纯实施CMM,永远不能真正做到能力成熟度的升级,只有将实施CMM与实施PSP和TSP有机地结合起来,才能发挥最大的效力。因此,软件过程框架应该是CMM/PSP/TSP的有机集成。

       (5) 对项目管理、白盒测试、单元测试、自动测试、性能测试、压力测试工具的了解程度和实际使用经验。(其实基本上也就是MI和Rational工具):这个就要看个人的了,没法说了


        5. 还有问一下你是怎样保证软件质量的,也就是说你觉得怎样才能最大限度地保证软件质量?
    测试并不能够最大限度的保证软件的质量,软件的高质量是开发和设计出来的,而不是测试出来的,它不仅要通过对软件开发流程的监控,使得软件开发的各个阶段都要按照指定的规程进行,通过对各个阶段产物的评审,QA对流程的监控,对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方式,是软件质量保证工程的一个重要组成部分。

        6. 然后紧接着就基于目前中国的国情,大多数公司的软件项目进度紧张、人员较少、需求文档根本没有或者很不规范,你认为在这种情况下怎样保证软件的质量?(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量,因为这些公司一般就是这种情况-----既不想投入过多又想保证质量,faint )出现以上的情况,如果仅仅想通过测试来提高软件质量,那几乎是不可能,原因是没有足够的时间让你去测试,少而不规范的文档导致测试需求无法细化何谈足够且有针对性进行测试。所以,作为公司质量保证的你应该先后项目经理确定符合项目本身最适合的软件生命周期模型(比如RUP的剪裁,原型法),明确项目的开发流程并督促项目组按照此流程开展工作,所有项目组成员(项目经理更加重要)都要制定出合理的工作计划,加强代码的单元测试,在客户既定的产品交付日期范围之内,进行产品的持续集成等等,如果时间允许可以再配合客户进行必要的系统功能测试

        7. 差不多了就该问一些只和软件测试相关的问题了,如:
       (1) 你觉得怎样才能做一个(或者,怎样才能算一个)优秀的测试工程师?(faint,这个问题好像是必问的,答案也无非是什么要求全面的技术能力、缜密的逻辑思维、出色的沟通能力、还要有怀疑精神、幽默感、洞察力等等。啥叫优秀啊?该有的能力都有,不该有的也有,而且个个能力还都是出色的,这就是优秀,呵呵,开玩笑的,反正这个问题差不多就这样,具体的什么要求网络上也到处都有。
        (2) 还有其它的如对自己优缺点的评价、自己的职业理想、为何离开上一家公司、自己在职业生涯中印象最深的事情、能否出差和加班、能否承受压力和挑战、薪水要求、何时能到岗等等这些啥面试都要回答的问题,这个就只能自己斟琢着办了。


       (3) 另外还有一个重要的问题就是语言能力啦,尤其是英语水平,这个的话每个具体的公司都有不同的要求,也就没啥好说的了

    引自:http://www.51testing.com/?action_viewnews_itemid_10934.html

     

  • LoadRunner分析报表(转)

    2007-05-21 17:04:15

    前言:总感觉自己写这个题目有点冒昧,因为我从来都不敢说我能全部看懂 LoadRunner的分析报表。然而我最终还是用了这个标题,大家权且把它理解为“为了看懂LoadRunner分析报表”而写下的一些东西吧,因为我发现现在有相当一部分使用LoadRunner的朋友面对LoadRunner的一大堆测试结果常常无所适从,不知道如何把这些测试结果真正利用起来,

    因此我把我个人学习LoadRunner的一些笔记和心得贴在这里,它到目前为止还是一堆很杂乱的东西,并没有形成一个系统的东西,而且其中可能会存在很多错误,希望各位测试同行能多多批评指教。

     

    一、 Web Page Breakdown

     

    DNS 解析时间: 显示使用最近的 DNS 服务器将 DNS 名称解析为 IP 地址所需的时间; DNS 查找度量是指示 DNS 解析问题或 DNS 服务器问题的一个很好的指示器;

    Connect 时间: 显示与包含指定 URL Web 服务器建立初始连接所需的时间; Connect 度量是一个很好的网络问题指示器;它还可表明服务器是否对请求做出响应;

    First buffer 时间: 显示从初始 HTTP 请求到成功收回来自 WEB 服务器的第一次缓冲时为止所经过的时间; First buffer 度量是很好的 Web 服务器延迟和网络滞后指示器;

    SSL Handshaking time 显示建立 SSL 连接所用的时间

    Receive Time 显示从服务器收到最后一个字节并完成下载之前经过的时间;接收度量是很好的网络质量指示器;

    FTP 验证时间: 显示验证客户端所用的时间。

    Client Time 显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时,所经过的时间。

    Error 时间: 显示从发出 HTTP 请求到返回错误消息这期间所经过的平均时间

      

     

    二、 关于 TPS Transactions per Second ): 每秒处理事务数

      

    这个值可以说明系统在特定的负载情况下,每秒可以处理多少个客户端请求,这是一个衡量服务器端性能的重要指标,相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问,到底这个值是怎么算出来的。既然是每秒事务数,那算法自然是“事务数 / 时间”。事务数很好理解,执行了多少就是多少,关键是这个时间。是整个场景执行的时间,还是仅仅是在服务器端执行的时间?因为我们知道,这两个时间肯定是有区别的,前者还包括 thinktime 的时间、 pacing 的时间以及在网络上耗费的时间等等。

     

    为了弄明白这个问题,我今天特地查了一下帮助文档,看到上面是这么说的:“每秒事务数图显示在场景或会话步骤运行的每一秒中,每个事务通过、失败以及停止的次数。”如果按照这句话去理解,那么上面那个问题的答案应该是后者,也就是说,在 Transaactions per Second 这张图中, LoadRunner 是针对场景运行过程中的每一个时间点取样一次,显示在这个时间点上每个事务的通过、失败以及停止的个数。

     

    另外,我还在 Analysis 里面找了一下,发现图表的时间显示粒度也是可以设置的。具体方法为:在图表上点击右键 -> 选择“ Set Granularity ”或者直接按 Ctrl+G 。我试着把时间粒度调成以毫秒为单位,结果 LoadRunner 提示当前不支持以毫秒为显示粒度,由此我推断 LoadRunner 对于 Transactions per Second 这张图,最小的取样粒度为 1 秒。

      

     

    三、 事务响应时间(百分比)图

      

    这个图显示的是事务响应时间范围的分布情况。在场景的执行中,每个定义的事务可能会不止被处理一次(因为设置了持续时间或者迭代次数), LoadRunner 会为每个事务实例的处理分别记录响应时间。在 Summary Report 中, LoadRunner 会针对每个事务的响应时间数据集合,分别取它的最大值、最小值和平均值,通常我们会关注响应时间的平均值。然而很多时候,单单是平均响应时间可能是不够的,因为一旦最大值和最小值出现较大的偏差,即便平均响应时间处在可以接受的范围内,但并不意味着整个系统的性能就是可以接受的,我们有必要再借助其它的分析报表来进一步分析,此时事务响应时间(百分比)图就派上用场了。

     

    事务响应时间(百分比)给出的是每个事务的响应时间按百分比的分布情况,它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。如果最大响应时间非常长,但是绝大多数事务(通常情况下以 95% 为参考)的响应时间具有可以接受的响应时间,则我们认为整个系统的性能还是可以接受的。

     

    注意: Analysis 将对每个可用事务百分比的事务响应时间取近似值。因此 Y 轴的值可能并不准确。

     

     

    四、 事务响应时间(负载下)图

     

     

    这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图,该图可以帮助我们查看 Vuser 负载对性能问题的影响。当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时,可以通过在控制台中设置一个渐变负载的场景的方式来实现。例如每 5 分钟加载 10 个用户等,然后考察得到的这张图表,就能够对此有一个比较好的理解。

  • 写给测试新手(转)

    2007-05-21 14:28:18

    入门
    在五年前我也是一个新手,是个很菜很菜的新手,那个时候我大学还没毕业(专科,没有名气的专科),因为一个机会让我进入了测试行业,我什么都不懂,我不会最简单的网络测试命令ping,不知道什么是搜索引擎,刚刚知道怎么上网,没有文档基础,可以说是一张白纸,然而我接触的第一个项目就是《防火墙测试》硬件防火墙,以前连那个东西是什么都不知道,还以为是防火用的!就这样我被拉了来,进行了一周的培训,我开始工作了,开始是功能测试,不过更多的时间是在搬机器、防火墙等,大部分是体力活,可是我没有选择,因为我知道就业的严峻形势,我坚持。
        也许上天对我不薄,我遇到了一个好老师……途老师,他手把手的教我们测试,平时跟我们住在一起,只要有时间就灌输知识,工作心态等,他管这种叫做洗脑,后来才知道这种方式给了我们很大的帮助,有工作的、和对生活的态度!
        第一个防火墙的项目完成后,我算对测试有了一个大概的认识,不过还不能说是入门,后来我就到了实习的这家公司,我们的总工,也是老大哥(他可不老),给我们制定了在公司内的发展规划和学习规划。在这段时间里真是学了很多的东西和学习方法;
        在这其间我学习了网络基础知识,防火墙基础原理,我的毕业论文《防火墙测试》老师第一个给了我优秀,等等… …同时我还在跟我们的另外一个老师,崔老师,学习一定的文档基础知识,这给以后的编写测试方案和测试报告,打下了基础。
        总结:测试的入门首先要有一个机会,如果没有机会就没有发挥的余地,其次最好要有一个能带你入门的老师,(这个可能也是大家现在报怨最多的,说自己没有好的老师,我比大家幸运了一些),再次也是很重要的一点,你一定要有一个很好的态度和积极向上的心态,只有这样才能去入门,才有进步;最后要有刻苦的精神,测试工作是很累的,入门的时候更是如此。对于新手的学习,主动积极,给自己制定一个计划,比如我想半年达到什么水平,不要太高,但也不能太低,然后自我检查;学习方法;我觉得很重要的一方面是自学,其次要多问有经验的人,多去交流,学会用搜索引擎,google就很不错,现在其实很多问题都可以在网上找到答案,这个适合新手,中手,高手等!
    接下来我想写”升级“!

    晋级
    第一次晋级
        测试真正的入门应该是工作半年后,那个时候我已经完成了《防火墙测试》同时在那个阶段还做了一些如IDS,扫描器等的测试;
        在工作半年后我们接到了我工作中的第一次任务重时间紧的测试,这次测试有60多个项目,包括网络的系统,图像识别系统,Web系统,视频识别系统等等,这些涉及的知识面太大了,在接到这个项目之前和项目开始之前,我们的总工和我们测试部的部长(我的另外一个老师,谢老师给了我很多帮助);因为此测试的系统比较多,涉及的知识面很宽,所以挑战性也很大,需要对每一个被测系统开发测试方案,执行测试,然后生成测试报告,基本上每天都要测试完成两个项目;最终这个项目完成了,我们也锻炼了一只可以打硬仗的测试队伍。
        大概的总结一下这个项目:60多个被测系统,需要根据用户需求开发60多个测试方案,同时要执行完成,生成测试报告;整个项目可以分为以下阶段:
    测试准备阶段—>方案开发阶段—>测试执行阶段—>报告阶段。
    测试准备阶段:主要完成知识的储备,对被测系统的相关知识进行学习,尽量了解测试对象;
    测试方案开发阶段:根据用户需求和测试系统的相关知识开发测试方案,作为测试的依据;
    测试执行阶段:这个阶段是根据开发的测试方案执行测试
    报告阶段:完成测试后根据测试的数据编写测试报告,提交测试报告。
    测试组织:
    测试分为两个测试组,每个组分别负责60多个项目中的一部分;
    测试组有一定的分工:
    测试组长,负责测试的整体工作。
    主测工程师,负责测试的主要执行工作,
    辅测工程师,辅助主测工程是完成测试任务;
    记录人员,负责测试过程中的记录;
    通过这个项目后,我的知识体系得到了很大的提高,虽然有些东西不太明白但是我的知识面扩了很宽;通过这次测试我还学习到了,如何编写测试方案,如何执行测试,如何编写测试报告(入门级);
    可以说从此后,我得到了入门后的第一次高。
    总结:
    1)入门后,要有实战的项目来提高;
    2)通过项目的锻炼,尽量的去掌握被测系统的相关知识;
    3)通过项目的锻炼,尽量的去掌握测试相关环节的技术,如果不能理解先按照要求完成,     然后在去进一步消化;
    4)一定要总结,再苦再累都要抽出时间去总结学到的技术,发现的问题等等;
    5)心态,工作很累,要有一个很好的心态,来乐观的对待劳累的工作。
    开始真正意义的性能测试
    当我晋级后,完成了那个60个系统的验收测试后,我们接到了一个服务器选行的项目,在这次测试中我来负责服务器综合性能的评价,这是我真正的执行性能测试;
        在这个项目中我学到了如何对服务器的性能进行评价,主要是学习了服务器测试的工具如NetBench,ServerBench,BenchMark factory等;
    总结:
    1)要培养独立的测试工具学习能力;
    2)培养测试工具的使用能力;
    3)掌握测试工具能够测试的指标。

    开始独立工作
    工作一年半后开始独立开发测试方案,此时先是对开发方编写的测试方案进行评审(依据我们部长编写的测试方案评审依据进行评审)在这期间主要做了一些验收测试;
        同时领导给了我单独完成一个项目的全部过程,我来组织测试,编写测试方案、组织执行测试、编写测试报告,最后给领导去解释出现的问题。
    总结:
    1)领导的管理是重要的,要能得到机会和指导;
    2)自己的主动也是主要的,要适当的表现自己的能力,给领导信心;
    3)抓住机会锻炼自己,多去请教领导,多交流;
    4)锻炼自己的管理能力。

    选择
    工作两年后我第一次面临选择,一是继续跟原来的一帮同事去做不同的工作,二是离开原来的同事,做现在的工作!我选择了留下,(也是因为在我工作的地方另外一个公司挖我过去同事还有两个同事),我的理由是:留下我可以成为技术骨干,我自信自己有能力独立工作,并且可以带领一个测试组完成需要的工作!因为在原来的公司的话永远都在几个老师的安排和领导下进行工作,对自己的管理能力的培养和独立工作的能力的培养都不会有多大进步,所有我选择了留下,离开原来的那些老师们。
    总结
    敢于选择自己的路;
    要有意识的培养自己的管理能力;
    抓住时机,该走就走。
    编外话:我们原来公司的同事后来都去了公安部,好几个都是督察,跟我同时进公司的一个同时现在也是三级警司;但是我没有后悔,自己选择的路就要自己去走,虽然之后的一年让我很郁闷,但是终于现在好了!

    坎坷
    真的自己独立工作了,让别人认为是技术骨干的时候,才知道好难,以前一直向往这种被别人认可的位置,可是真正到了这个地位才知道要比原来累的多;所有技术的问题要自己搞定,然后向自己的上头汇报,以前做事大部分是半成品,然后有主管技术的头修改后汇报,现在都需要自己一个人完成。(可能不同地方的公司也不一样,我们这里就是这个样子了),偏偏刚刚被挖过来,碰到一个即不怎么懂技术,又不怎么懂管理的领导,郁闷呀;
      本来风风火火想到这个部门干一番事情,可事与愿违,主要原因:一,自己没有调整好心态,太过于自信,这个直接导致我的第一个重要项目的测试方案破产,二是:部门头头管理方式不当,不能按照我推行的方式进行管理,导致整个测试项目严重延期。不幸的是我也从超自信变成不自信,然后我的头又给了我一再的泼凉水,后来干脆不管理,作好自己的事,拿自己的工资就得了,反正你开不了我。这样也不知道经过了几个月我一直在阴影中。
      煎熬(也许可以用这个词)了一段时间后我干脆去跟另外一个部门头去做另外一个项目(惹不起我躲还不行吗?),谁知道躲也躲不了,在做这个项目的时候,其中一个子项目又让我们部门头郁闷了一把,差点就要把我开掉了,还好我有我们副主任撑腰。总算熬过去了。
      这将近快一年半的时间,历经坎坷,我都快被压跨了,当时真的怀疑自己的选择是否正确,我坚持我坚持,相信我不会总这么背,我相信自己是块金子总要发光的.................
    总结
    即使被挖过去的也不要过于自信,太过露底对自己的发展不利(这是我一个朋友跟我说的);
    跟领导打交道要有一定的方法,见人说人话见鬼说鬼话,要学会随机应变(保证工作做到位);
    要推行自己的想法,一定要看准领导,如果领导实在没有能力,又不太能接受别人的意见,那就随他去吧,或者干脆跳槽!
    调整好心态,面对挫折,努力把做不好的事情做好!
    对技术一定要认认真真,做到一丝不苟。

    这一节是讲述的是迎接我的“曙光”

    曙光
    山穷水尽疑无路,柳暗花明又一村,人不会总是幸运也不会总是坎坷,只要你还在努力还在奋斗,曙光就在前方。
      经过快一年半的坎坷工作经历,也锻炼了我的抗压能力和对事情的承受能力,造物主是公平的,在给你磨难的同时也给了你坚强,在去年的六月分终于迎来了我的曙光,实验室体制改革,合并综合部和质量部,改组测试部,测试部有原来的一个部门分为2个部门,我被分到了测试一部,部门头是一位很绅士的博士,在测试上有六年的管理经验,我跟他合作过几年,同时他很能听取测试人员的建议,并且会根据自己的判断实施。
      我很幸运到了一部,然后我实施我的计划,第一步:这个工作模式改革,培养中层,带动底层,团结合作的工作模式,听起来很多公司或者单位都在提,但是我在当时的部门就是实施不下去,那个领导不知道怎么扶持中层,导致每个人都是独立的,没有达到合作的目的。第二步:组织培训,与自我培训,开展部门内部的测试技术培训工作;这项工作也没有什么稀奇可能大家都有过这样的机会,但真正的要让领导去重视是不容易的,前一个领导就是做了一个形式主义,他不反对也不支持(好像是他不知道怎么支持)。所以我,要做就要做到,有计划有目的有安排的实施培训,这样有几点好处;一是可以增强部门整体的技术能力,二是可以锻炼部门内部的交流能力(在我们测试人员来说交流是很重要的);三是能提高部门人员的表达那能力等等。
      第三步:推行测试技术研究工作,这项过做主要是在工作不是很繁忙的时候,组织力量研究测试相关技术或者行业相关技术,做到测试技术的不落后。其实这个事情大家也都想过,但是要真正的做也不是那么容易,这种要形成一种氛围,如果只有一两个人研究或者得不到领导的重视,在部门内部是实施不起来的,个人研究也会不断受到阻碍。
      第四步:推行部门三大体系;质量体系、管理体系和技术体系。质量体系,我们来说主要是依据实验室质量手册,严格执行,在执行中进行改进。管理体系,主要是推广向上负责的体系,做到每个项目都要有人负责,相互合作。周例会制度,(周会可能每个部门都开,但是要起到会议的作用就需要领导多花些心思了)。技术体系,主要是积累测试技术,极其相关研究技术,这个分类就比较多了,比如软件测试技术,硬件测试技术,测试工具使用,测试仪表使用,网络知识,安全知识,编程知识,数据库等等,主要是对相关知识进行积累和总结作成整个的一套体系。
      想法是好的做起来是难的,更难的是要让你的领导接受你的想法,在部门成立的第一次会议中,我向领导提出固定测试组,培养中层的想法,没想到领导跟我想到一块去了,他很支持,但是在会上没有直接表态,领导毕竟是领导,有他自己的想法。(会后才知道他要摸一下底),接下来很顺利就制定了这个制度。
      后面的几个想法我逐一找领导谈了,我们都是不谋而合(我是幸运的),到现在为止上面说的四项内容都在开展,培养扶持了中层,培训了下层;组织了培训而其非常有计划,有安排。领导每次都去听我们讲课,还很认真(感动呀!),技术研究方面,我们在去年年底做完A项目后就开始对现行比较热门的VM技术进行研究,还要写一本书,第四步的内容,质量体系在实施,管理体系也开始了,技术体系总结相关的还没有做起来,但是领导很重视。再次感动ing… …
        古人云:为知己者死,虽然我不能死,但是我也会为有这样的领导而感到骄傲,我会进自己最大的努力作好工作。
        总结:主要是遇到一个好领导,可遇不可求,但是还是要说一下:要注意跟领导的交流方式,领导也很要面子的,所以有些想法最好单独跟他谈,在推行的时候让领导去推,不要多说话,这些都是我的想法,其实领导很多时候比你想的要全面!
        好了我的个人测试经写完了,可能有些朋友看了没有什么收获觉得还不如写写测试中遇到的问题,或者测试技术什么的,不过我觉得做测试首先要学会做人处事,如果这两样都做不好,什么样的工作都做不好,上面所说的是我的一些亲身经历,整理出来给大家一个小小的指导吧(也许没有什么指导,那你就当看自传了)总之一句话,做好人,做好事,才能做好测试。

  • [转贴]谨以此文献给正在郁闷的人们!!!

    2007-05-21 12:55:23

    仅以此段文字献给郁闷的人们:
    一头老驴,掉到了一个废弃的陷阱里,很深,根本爬不上来,主人看他是老驴,懒得去救他了,让他在那里自生自灭。那头驴一开始也放弃了求生地希望。每天还不断地有人 往陷阱里面倒垃圾,按理说老驴应该很生气,应该天天去抱怨,自己倒霉掉到了陷阱里 ,他的主人不要他,就算死也不让他死得舒服点,每天还有那么多垃圾扔在他旁边。可是有一天,他决定改变他的人生态度(驴生态度更确切点),他每天都把垃圾踩到自己 的脚下,从垃圾中找到残羹来维持自己的生命,而不是被垃圾所淹没,终于有一天,他重新回到了地面上。
    不要抱怨你的专业不好,不要抱怨你的学校不好,不要抱怨你住在破宿舍里,不要抱怨你的男人穷你的女人丑,不要抱怨你没有一个好爸爸,不要抱怨你的工作差,工资少,不要抱怨你空怀一身绝技没人赏识你,现实有太多的不如意,就算生活给你的是垃圾,你同样能把垃圾踩在脚底下,登上世界之巅。 这个世界只在乎你是否在到达了一定的高度,而不在乎你是踩在巨人的肩膀上上去的,还是踩在垃圾上上去的。我认为踩在垃圾上上去的人更值得尊重。年轻没有失败,看驴生豪迈,不过从头再来......
  • CMM模型【转】

    2007-05-17 10:43:58

    1.概念:
    CMM是Capability Maturity Model for Software的简称,中文叫“软件能力成熟度模型”,是对组织软件过程能力的描述。CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化,使企业能够更好的实现商业目标。它侧重于软件过程开发的管理及软件工程能力的改进与评估,因此CMM被用作评价软件承包商能力并帮助组织改善软件过程质量,是目前国际上最流行、最实用的一种软件生产过程标准,成为当今企业从事规模软件生产不可缺少的一项内容。
    CMM是由美国卡内基-梅隆大学软件工程研究所(CMU SEI)研究制定,并在全世界推广实施的一种软件评估标准,主要用于软件开发过程和软件开发能力的评估和改进。CMM把软件开发过程的成熟度由低到高分为五级,等级越高,表明该企业软件开发失败风险越低,整体开发时间越短,并能减少开发成本,降低错误发生率,提高产品质量

    2.标准划分— 摘自《使用软件工程》
    CMM将软件分为5个等级:

    1.初始级(initial)
    工作无序,项目进行过程中常放弃当初的规划
    管理无章,缺乏健全的管理制度
    开发项目的成效不稳定,产品的性能和质量依赖于个人能力和行为。

    2.可重复级(Repeatable)
    管理制度化,建立了基本的管理制度和规程,管理工作有章可循
    初步实现标准化,开发工作较好的实施标准
    稳定课跟踪,新项目的计划和管理基于过去的实践经验,具有重复以前成功项目的环境和条件
    3.已定义级(Defined)
    开发的过程,包括技术工作和管理工作,均已实现标准化,文档化。
    建立了完善的培训制度和专家评审制度
    全部技术活动和管理活动均可稳定实施
    项目的质量,进度和费用均可控制。
    对项目进行中的过程,岗位和指责均有共同的理解。
    4.已管理级(Managed)
    产品和过程已建立了定量的质量目标。
    过程中活动的生产率和质量是可度量的。
    已建立过程数据库
    已实现项目产品和过程的控制
    可预测过程和产品质量趋势。
    5.优化级(Optimizing)
    可集中精力改进过程,采用新技术,新方法。
    拥有防止出现缺陷,识别薄弱环节以及加以改进的手段
    可取得过程有效性的统计数据,并可据此进行分析,从而得到更佳方法。

    目前业界的通行标准:每千行源代码所包含的BUG数,CMM1级为11.95个,CMM2为5.52个,CMM3为2.39个,CMM4为0.92个,而CMM5则只有0.32个。在可靠性提高的同时,CMM5软件开发周期是CMM1的36%,而生产成本是CMM1的19%,平均每个软件开发人员的生产率会提高四倍。


    3.关于当前CMM的一些知识——摘自        赛迪网->;技术天地 (可靠度有待考察)

    a)       
    CMM的制订者卡耐基-梅隆大学的软件工程学院(Software Engineering Institute SEI)在2001年12月推出CMM的改进模型CMMI,并宣布到2005年不在支持CMM而是转向CMMI。
    SEI在2000年取消了单独的SW_CMM2.0继续开发,转而综合研究了开发出集成能力成熟度模型(Capability Maturity Model Integration,CMMI)。该模型包括CMMI-SE, CMMI-SE/SW ,CMMI-SE/SW/IPPD/SS等模型组件,CMMI-SE/SW/IPPD/SS包含了CMMI-SE, CMMI-SE/SW模型组件,有连续表示(Continuous Representation)和阶段表示(Staged Representation)两种。

    b)       
    至今(2003.06.18)全球范围内CMU SEI注册的CMM5级组织有 42家,CMM4级组织有87 家。
    去年12月30日,东软成为通过CMM5的第一家中国软件企业(部门级);2003年3月25日,大连海辉科技股份有限公司又顺利的通过CMM5级的评估,成为了中国首家公司整体通过CMM5级评估的软件公司。华为作为中国最大的软件企业之一,是第一个获得CMM4级认证的中国企业,而且也是目前国内少数几家获得该项认证的企业之一。
    截至2003年3月,全国共有近50家软件企业通过CMM认证,其中通过2级的32家,3级9家,4级2家,5级的4家。而全国仅有1400多家软件企业,实施CMM认证的企业比例己经高于世界平均水平。

    c)       
    “国内企业在认证过程中的弄虚作假、评估师受贿等问题已经引起了SEI的关注。”美国SEI注册评估师芭芭拉(Barbara Hilden)对本报记者说。
    通过实施CMM,世界各地的软件企业可以通过共同的语言来协调进程。而达到要求的成熟度有助于提高公司信誉,CMM成了迈向国际市场的“通行证”。
    为此,2000年6月,国务院下发18号文件,其中第十七条明确规定鼓励软件出口型企业通过GB/T19000-ISO9000系列质量认证体系认证和CMM认证。其认证费用通过中央外贸发展基金适当予以支持。
    目前从事CMM认证的商业机构违背认证的“第三方”原则,即几乎所有的商业公司都是聘请主任评估师为企业提供咨询服务,之后由该主任评估师评估。甚至有些商业公司将相关政府机构或者受政府机构委托从事奖励政策管理的管理人员作为合伙人。

    更有甚者,有些国内企业的CMM评估并没有到SEI备案。
      “国内企业在认证中最大的问题是急功近利,难以保证质量,有些干脆就是为了拿政府奖金。”Chuck Song先生这样评价。“与其失去信誉地进行CMM认证,还不如压根不做。因为一旦国际上不再相信中国企业的CMM评级,国内软件企业将很难走出国门。”


    ***(作为将来从事软件行业的技术人员,我觉得应该更多的注重CMM中促进软件技术发展的学术知识,避免形式化的应付,以免敷衍了事,华而不实,弄虚作假。)

    d)       
    微软、IBM、惠普等美国的很多软件公司并没有做CMM认证
    据统计,全世界共有超过20万家软件企业,选择CMM评估的仅有2300家,占1%。
    卡耐基-梅隆大学国际软件研究院中国办公室主任Chuck Song的说法是,“如果一个企业仅用一年多就从2级蹦到5级,在美国是没有人会相信的。”

    按照CMM的思想进行软件项目管理与通过CMM认证并不能划等号。
    其实在软件业最发达的美国,很多软件企业都没有通过CMM认证。这并不是说,这些企业不重视软件质量管理,事实上,这些企业多年来已经形成了一套自己的管理方式,而且这套方式同CMM在本质上是一致的(CMM本来就是SEI从美国的工业界中总结出来的)。
    ***(我们学到得也许只是表面,丢掉了本质 本人意见)

    他(摩托罗拉中国软件中心董事总经理陈玲生)认为,目前国内无论是媒体还是软件厂商对CMM认证都存在一定的误区。有很多软件企业费尽力气进行CMM认证,只是为了品牌效应,而没有认真执行。其实,这样的认证就只能是废纸一张,没有任何意义。CMM是一套科学的管理标准,如果把它看得过高和过低都不适宜。它重在实施,只有认真贯彻,才能取得收效。

  • WinRunner的问题整理

    2007-05-16 13:59:50

    1.WinRunner如何把Real类型转化为指数表示方法
    答:
       指数类型转化为real类型,可以通过下边的代码
       var = 5.3569E+10;
       pause(var);
       #显示 53569000000
       
       Real类型转化为指数表示方式
       var = sprintf("%e",53568544768);
       pause(var);
       #displays 5.356854e+010

    2.什么是同步点,怎样用它?他和Wait有什么不同?
    答: 从功能上他们都可以实现脚本和被测试程序同步的问题,不过同步点有window/object,bitmap方式,她等待的是某个等待的对象     窗体,bitmap的出现,一定程度她也可以作为验证点
         wait这点上无法实现相同的效果。有的脚本中即使你加入wait,但是你无法知道下边的对象窗体图片是否就是成需要运行的正确     出现的
    3.tl_step和tl_step_once的区别
    答:tl_step和tl_step_once都是把运行状态信息放到运行结果中去,区别在如果连接TD,TL_STEP把每步状态信息都插入到测试结果中去,tl_step_once如果连接td,只是插入一次运行步骤的名字
       
    代码例子:
    --------------------------------------------------------------------------------

    for (i=1;i<4;i++){  
         tl_step("Step", PASS, "reporting step, #" &i);  
         tl_step_once("Step Once", PASS, "reporting step once, #" &i);
    }

    --------------------------------------------------------------------------------

    WR中的报告:
    Step: Step, Status: PASS, Descrīption: reporting step, #1
    Step: Step Once, Status: PASS, Descrīption: reporting step once, #1
    Step: Step, Status: PASS, Descrīption: reporting step, #2
    Step: Step Once, Status: PASS, Descrīption: reporting step once, #2
    Step: Step, Status: PASS, Descrīption: reporting step, #3
    Step: Step Once, Status: PASS, Descrīption: reporting step once, #3

    TD中的报告:
    Step: Step, Status: PASS, Descrīption: reporting step, #1
    Step: Step Once, Status: PASS, Descrīption: reporting step once, #1
    Step: Step, Status: PASS, Descrīption: reporting step, #2
    Step: Step, Status: PASS, Descrīption: reporting step, #3

    4.WinRunner和TD集成后脚本运行很慢是什么原因呢?
    答:安装TD和WinRunner服务器上需要独占100GByte,TD需要10OGHZ时钟速度16GB RAM的处理平台

    5.WR是否支持vs.net
      根据Mercury的介绍,他们的对.Net的支持转移到QuickTest Pro上了,如果你需要自动化测试.Net程序(不是web的),建议用

    QuickTestPro。也就是说wr不支持vs.net开发的程序

    6.我对比两个文件file1.txt和file2.txt,文本内容如下
      file1.txt 内容如下:
      10523 8315 6804 8387 3643 4550 3457 3649

      file2.txt内容如下:
      190176 155737 117417 145194 65314 81431 64522 63324
      
      代码如下:file_compare("C:\\file1.txt","C:\\file2.txt","save");
      为什么每次对比这两个文件结果都是通过的。
    答:这个问题的原因在于它在前面的脚本中对文件进行了操作,没有关闭,所以这段代码运行总是通过

    7.如何在winRunner中用Windows的API函数
      在使用该API函数前需要先加载该函数然后声明API函数,代码如下
    load_dll("user32.dll");
    extern int PostMessageA(in long, in long, in long, in long);
    win_get_info("{class:window, MSW_class:AfxMDIFrame42, label:\"!WinRunner.*\"}", "handle", hWnd);
    PostMessageA(hWnd, 16, 0, 0);

    请在尝试以上代码的时候,保存脚本,呵呵!  

    8.怎样处理跟踪键盘操作?
    答:下边的代码希望对你有帮助
        function GetKeyStatus(in vKey){  
          auto pid, thread_id, win_desc, hWnd, KeyState, win_log_name, win_full_desc, focused_obj_desc;
          win_desc = "{active:1}";       
          if (win_exists(win_desc)==0)        {           
             win_get_desc(win_desc, "", "", "", win_full_desc);
                    GUI_map_get_logical_name( win_full_desc, "", win_log_name, "bla");
                 win_get_info(win_desc, "handle", hWnd);
                  pid = GetWindowThreadProcessId(hWnd, NULL);
                thread_id=GetCurrentThreadId();
                   AttachThreadInput(pid,thread_id,TRUE);
                 KeyState=GetKeyState (vKey);
                AttachThreadInput(pid,thread_id,FALSE);
                 if (KeyState < 0)              
                return(0); # Key is pressed
               else           
                return (1); # Key is not pressed       
            }
            else
                    return (-1); # No active window found, so cannot determine key state
        }

    9.WinRunner如何处理excel?
    答:其实解决方法有很多,这里列举两种。
       一.利用其他语言特性开发出dll提供给winrunner使用(vb,vc,delphi等)
       二.在其他环境中实现,用winrunner调用
       第一种我在这里不举例子了,第二种我利用vbs往excel中赋值给大家提供一种思路,代码如下:

    'vbs中的代码
       Dim ExcelApp
       Dim itemX
       if Wscrīpt.Arguments.Count < 2 then
        r = msgbox("Requires 2 arguments", 48, "change_sheet")
       else
        dim fso
        set fso = createobject("scrīpting.filesystemobject")
        xlBook = fso.GetAbsolutePathName(Wscrīpt.Arguments(0))
        xlSheet = Wscrīpt.Arguments(1)
        set fso = Nothing
        Set ExcelApp = CreateObject("Excel.Application")
        ExcelApp.Workbooks.Open(xlBook)
        Set itemX = ExcelApp.ActiveWorkbook.Worksheets.Item(xlSheet)
        itemX.Activate
       
        excelApp.ActiveWorkbook.Worksheets(xlSheet).Range("A1").Select
        excelapp.ActiveCell.FormulaR1C1 = "1"
        excelApp.ActiveWorkbook.Worksheets(xlSheet).Range("B1").Select
        excelapp.ActiveCell.FormulaR1C1 = "2"
        excelApp.ActiveWorkbook.Worksheets(xlSheet).Range("c1").Select
        excelapp.ActiveCell.FormulaR1C1 = "3"

        ExcelApp.ActiveWorkbook.Save()
        ExcelApp.ActiveWorkbook.Close(1)
        ExcelApp.Quit()
       
        Set itemX = Nothing
        Set ExcelApp = Nothing

    end if

    winrunner中的调用代码:
    dos_system("wscrīpt \"C:\\excel_sheet.vbs\" \"C:\\SheetBook.xls\" \"Sheet2\"");  
       
    10.在WinRunner中如何实现得到transaction时间?
    答:一般情况下transaction的时间只能在最后结果中得到,如何在脚本得到这个时间呢,下边的代码可以

    帮助你:
    public transactions[];
    function start_my_transaction(in transaction_name)
    {
            transactions[transaction_name] = get_time();
            tl_step("Start transaction: \"" & transaction_name & "\"",PASS,"Timestamp: " &

    transactions[transaction_name]);
            return (transactions[transaction_name]);
    }
    function end_my_transaction(in transaction_name)
    {
            auto end_time = get_time();
            auto rc;
            if(transactions[transaction_name] == "")
            {
                    tl_step("End transaction: \"" & transaction_name & "\"",FAIL,"Transaction was

    never started.");
                    rc =  -1;
            }
            else
                    tl_step("End transaction: \"" & transaction_name & "\"",PASS,"Elapsed Time: "

    & (rc =  end_time - transactions[transaction_name]));
            delete transactions[transaction_name];
            return rc;
    }

    start_my_transaction("my_transaction");
    wait(2);
    rc = end_my_transaction("my_transaction");
    pause("Elapsed time = " & rc);
  • Winrunner经验总结

    2007-05-16 13:46:12

    1.1 脚本录制规范:
    基本原则是录制脚本要分开、gui文件要合并、批调用回放验证、可移植回放验证。
    1.1.1 录制脚本要分开:
    脚本太大,不仅不利于以后的维护,并且会导致WinRunner的不可预测的错误产生(具体可以参考WinRunner 的Readme文档)。录制时,可以根据测试用例的流程,拆分为几个小流程,对每个小流程分别录制成不同的脚本。
    1.1.2 gui文件要合并:
    首先,要在系统参数中,设置gui的录制模式为“Global GUI Map File
    录制过程中,WinRunner会自动产生gui文件,一个测试用例要确保生成一个公用gui文件。用一个gui文件主要是为了以后gui对象的维护,脚本回放时gui对象的查找。但是由于我们的测试用例是分开录制的,每个小流程录制时都会产生一个gui临时文件,因此录制完脚本后要把临时gui文件合并到该测试用例的公用gui文件中。但是也要注意,开始新的录制前,一定要先手工加载测试用例的公用gui文件。
    如果划分的子流程超过20个,则按每20个子流程录制一个gui文件的方式。Gui文件太大,会影响WinRunner的回放效率。
    1.1.3 批调用回放验证:
    为了提高脚本的正确性,每录制完成一个子流程后,都要恢复数据库,其他初始环境进行回放,以近早发现脚本错误。
    单个测试用例脚本录制完成后,要专门写一个主脚本,进行各子脚本的主次调用处理,然后恢复数据库和其他初始环境进行回放,以验证整个脚本是否可以正确回放。
    1.1.4 可移植回放验证:
    由于WinRunner 工具的限制,在本机回放成功后,如果把脚本移植到其他机器上,往往无法成功。这其中既有自己编写的脚本问题,又有WinRunner录制自动生成的脚本问题。
    自己编写脚本问题:往往是编写的可移植性较差,如加载gui文件时用的是绝对地址,如gui_load(“c:\\aa\\aa.gui”),这样的脚本换到其他机器必然出错。
    WinRunner录制自动生成的脚本问题: WinRunner的录制脚本往往和机器的环境有关,如果换了其他机器环境,往往回放不成功,这就需要手工修改脚本。
    因此,可移植性回放是非常必要的。
    1.1.5 脚本中使用的ODBC数据源名称统一命名为WR。
    1.1.6 录入中文数据时统一使用简体。
    1.1.7 数据表列名称规定
    录入数据驱动的脚本时,数据表列名称统一采用英文,使用PB数据窗口中列对象的名称。数据表列名称下的第一行用中文对英文列名称做注释,使用PB数据窗口中列对象的中文标签,这一行不作为有效的录入数据。与数据表相关的循环语句请修改脚本从数据表的第二行开始读取数据。典型的例子是将数据驱动脚本中For循环的第一个表达式改为table_Row = 2。
    1.1.8 脚本成功回放判定规定
    一个子测试录制完成后,一定要及时回放测试,直到测试报告显示测试结果为OK,且子测试明细报告中没有红色的出错提示。如果是回放主测试,回放成功的标准是:主测试的结果报告显示为OK,同时所有子测试的结果报告也为OK,且子测试明细报告中没有红色的出错提示。
    1.1.9 WinRuner主脚本中关于设置系统日期时间设置的规定,以保证脚本所描述的业务过程按业务逻辑在时间上有序。
    因为脚本回放与脚本录制时的系统日期时间不一致,会导致与系统时间关系密切的测试脚本回放时失败。
    为了消除时间差导致的回放错误,要求每一个测试用例的主测试在第一个子测试前加上date_set_system_date(年,月,日,时,分,秒)函数,以修改本地机器的日期时间等于这个主测试在接力式验收回放成功执行后的日期时间.这样再次回放时系统的日期时间就和上一次成功回放时的日期时间一致。

    1.2 测试脚本存放规范:
    各子测试脚本必须放到同一目录下,即环境目录下的scrīpt目录下。这样便于批调用时引用。
    1.3 Gui文件的存放:
    Gui 文件,必须和测试脚本放到同一目录下,即环境目录下的scrīpt目录下。
    1.4 WinRunner使用规范:
    (1) 必须写上清楚的注释:编写测试脚本,要进行详细的标注,每测试一小段,就要写一段备注,以便于将来修改,格式可以参考如下:
       功能描述:描述脚本的功能
       前置条件:该脚本在满足什么条件下才可以被执行
       步骤描述:描述脚本录制的动作
       检查点描述:描述作了对什么的检查,检查条件。
       录入人:录制人
       录入时间:
       备注:
    (2) gui文件的加载保存:
    每次开始测试用例的录制脚本前,如果该测试用例已经存在gui文件,一定要手工打开gui文件,再开始录制。如果不想手工打开,可以写段自动加载gui的脚本,每次录制前运行一下该脚本。录入脚本后,要注意保存GUI文件,如果测试用例已经存在gui文件,一定要把临时的gui文件合并到该用例的公用gui文件中,然后保存。
    (3) 如果机器数据较慢,或者网络较慢、或者数据库运行较慢,需要把等待打开窗口的时间设长。或者在脚本中插入同步点来处理。
    (4) WinRunner不支持Fomular One,目前不可以用wr测试Fomular One
    使用WinRunner录制时不可以切换不同输入法录制,仅可以用一种输入法。
    (5) WinRunner 对shift 键无法纪录,需要特殊处理 ,可以加入如下处理
    obj_type "dw_1.fslipbugno","<kShift_L>-";(告诉WinRunner按下Shift键)
    中间是选择行的脚本
    obj_type ("dw_1.FBugNo","<kShift_L>+";(告诉WinRunner释放Shift键)
    (6) 保证录制的脚本干净性:
    在录制过程中,不可避免的要进行其他动作,如打开邮件、打开非录制程序等,这些动作也会被WinRunner录制下来,这些动作会严重影响测试脚本的回放(除非作这些动作前停止录制)。
    因此,为了保证脚本的干净,在WinRunner的参数中进行如下设置:设置Recode 的“Selected Applications” 为要录制的程序。
    (7) 录制脚本时,不允许同时打开两个运行程序(指进行wr测试的程序)
    (8) 变量的声明:WinRunner有auto \public \static \extern 四个类型的变量作用域声明,其中public为默认的类型。由于public 是全局的,只要在一个脚本中声明了,在任何其他脚本都可以引用,这就带来一个问题,如果其他的脚本修改了这个public 变量的值,将会引发问题。因此变量声明时必须明确的加上类型(auto \public \static \extern),public 的一般不要使用,推荐使用static \auto 。
    2. 异常处理规范:
    在录制或者编写测试脚本时,必须进行异常的错误处理。以提高程序的错误检查能力。
    2.1 函数异常检测:
    对于一些常用函数,必须进行函数执行异常的处理。至少进行如下函数的异常检测:et_window、win_activate、menu_select_item、ddt_open。
    发现异常后,要终止程序的执行,并发邮件通知相关人员。
    2.2 返回值规范:
    模块、函数的返回值约定如下,0 表示成功 ,其他失败。
    对于一些函数的返回值,需要进行判断处理:
    (1) 每一个call语句都应该检查它的返回值是否为0, 如果不为0则报错退出。
    所有GUI检查点、数据库检查点都应做返回值检查。如果不为0则报错退出。
  • 招聘经理眼中的好简历

    2007-05-16 13:36:13

     动词列表是简历编写指南里保留的项目,调查还发现:简历里尽可能的堆满动词、形容词和副词的求职成功率更高。 51Testing软件测试网)u0}2L0G6L2XZ

    8wO&?!w|\K111426  几乎所有的人事经理都喜欢选择有效的字句,而不是花样繁多的词藻的简历。 51Testing软件测试网0z|%z0W\:kR1ST
    51Testing软件测试网1deZt"j0l

    RG@ o h&f%qiQ111426人事经理心里的单子51Testing软件测试网8]g p m7cY&]

    K1~W1{!T6b|11142651Testing软件测试网3k-|??1[,K8H0{D#a0K#^
      简历中的几个字也会惹恼人事经理,而拒绝继续读简历。有相当多的人事经理以及招聘人员都承认,他们心里有一个单子,上面列着让他们厌恶的字句。 51Testing软件测试网3S_ IiC1zt c
    51Testing软件测试网 P/N&GG.oab:q"Mp
      尽管他们都说自己不太可能因为这些字句而完全拒绝应聘人员,但是他们相信,利用这些字句来吹嘘的简历给人留下印象还不如没有这些字句的。我在本期专栏里总结了一些例子。
    TC?8s!U$PO$`&C11142651Testing软件测试网%I&^n"i q0V9p `5d
      例如,有一个IT公司的人事经理曾经说过,她从来都不喜欢在简历上看到协助(Assist或者Assisted)这样的字眼。“我想知道的是应聘人员(具体)做了什么,而不是他们如何帮助做了什么。如果他们对某项任务足够熟悉,而且想放到简历里,他们就应该使用比‘协助’更好的字,”她解释说。
    !X$k0hM'zi6L111426
    orW+k^4h111426  一篇关于就业的评论建议将任何“协助”这样的表述改为十分具体的内容,说明应聘者在“协助”的时候做了什么。例如,如果你帮助市场部主任研究哪些个人数字助理(PDA)能够满足部门的需要,那么你就可以在简历中这么写:“为市场部研究PDA。”这样修改之后就说明了具体的内容。 51Testing软件测试网A$k$kjwk7z5O~M O

    c p0U.x Kv Kk111426  出于和“协助”相同的理由,人事经理不会喜欢“试验(experimental)”这个字。没有人想听你尝试做过什么——只想听你完成了什么。你不应该写“试用了新的局域网(LAN)管理软件”,而应该说“评估了LAN管理软件。” 51Testing软件测试网2I:f w!T2Hv9N1Lj

    +Ms*B[%_bx"v?111426  大多数人事经理不喜欢听到任何描述某人怎么好地完成了某项任务的字眼。他们说自己希望了解这个人相关的技能,而且希望自己才是这个人工作效果的评判者。因此,像巧妙地(Skillfully)、有效地(Effectively)、仔细地(Carefully)、迅速地(Quickly)、专业的(Expert)、高明的(Mastered),以及类似的字都会弄巧成拙。 51Testing软件测试网0gpY"jUt
    51Testing软件测试网X w)Y4b|0^ Vp3u#O
      在上面所提到的所有字中间,任何由技能(Skill)衍生出来的词——尤其是巧妙地(Skillfully)——只会引起更多的嘲笑而不是(会心的)的大笑。雇主和招聘人员更希望在应聘者简历里看到的是谦虚而不是吹嘘。
    qLj,YrNo#vr111426
    G5~B8_#@v111426  “如果你对它并不很在行,那么你为什么要把它放进简历里呢?”一位招聘人员如是说。
    $Foy|G l y"f-uWW11142651Testing软件测试网9Vs+k?Z*[1{+T

    0Dkh@r!?)Sk111426最佳的技能放在最前面的简历是好简历51Testing软件测试网6l_ z]0[{q ?
    51Testing软件测试网#_+F exv
    51Testing软件测试网%J r-r;L(H"h-{
      明确地表示出在某些方面比别人更好,而且正在使用前面提到过的字眼来说明自己的最佳技能,会引得人事经理更多的注目。只把能够用来相当好地完成任务的技能,以及适合于职位要求的技能列出来。51Testing软件测试网 udn4a!p+pQ%Z

    ]P0?+wd$b WJ+t111426  一旦你删掉了所有自我评价的字眼,就要重新浏览一遍简历,去掉令人乏味的商业用语,例如:尖端的(cutting-edge)、联络人(liaison)、协调(coordinate)、推动(facilitate)、被证明了的能力(proven ability)、配合(synergy)和改造(transformed)等等。
    k?#zOS.|/pco11142651Testing软件测试网LkA6gJu&DA
      人们看到和听到这些字眼太多了,以至于他们再次听到的时候没有一点兴趣。人事经理们说这些字只会占地方,而不会传达有用信息。而且,要知道的是:大多数技术单位的人事经理都会意识到,好的经理人都是注重细节的,所以你可以放心地从你的简历里删掉这些令人乏味的字。
    +` Q1SCw/iv w0S$a9r-o11142651Testing软件测试网sx L!eO#P-s;`%w
    51Testing软件测试网k8n"`D0SOQ+{
    灵光一现的简历51Testing软件测试网 w UgH\K8p#A

    ;E;Bq_ |$D3j}11142651Testing软件测试网^B oP4Q i
      简历里加入更多激情,并且尽可能地具体说明你当前和过去的职责——尤其在这些职责是你现在想要申请的职位内容里一部分的时候。没有什么比看到“负责(responsible for)”这个字之后接有一堆寻常的管理任务更扫兴了。
    Dq-{"t(O11142651Testing软件测试网[1SW~spY/r
      你是个经理,所以你当然会负责什么东西。准确地告诉人事经理自己的职责是什么,并列出一些来,以帮助他们了解你的工作内容。诸如“管理着X个员工”、“监督Y的资产投资预算”,或者“为Z个雇员建议培训计划”等都是有效的方式,它们能够简明扼要地说明你做的以及取得的成果。尽你所能的具体和详细,但是要记住,你不能够泄漏你当前雇主的机密信息。 51Testing软件测试网5r$T7`3HU
    51Testing软件测试网~{8B9V$O#vv3V(_(V
      简历应该总是在说明事实,但是它也是一个市场推销的工具,你正在用它将你最珍贵的产品推向市场——求职者自己。  
    Azm'vto7kJ111426
    *v5k0]"V9m+h-@ r2u111426
    eD*S6oo/tx2U11142651Testing软件测试网gP l1l$N f fW
    出处:HR管理世界
  • 一道受用终身的测试题

    2007-05-16 13:28:17Digest 1

    这是一家公司要招收新的职员其中一个测试的问题…… 你开着一辆车。 在一个暴风雨的晚上。 你经过一个车站。 有三个人正在等公共汽车。 一个是快要死的老人,好可怜的。 一个是医生,他曾救过你的命,是大恩人,你做梦都想报答他。 还有一个女人/男人,她/他是那种你做梦都想娶/嫁的人,也许错过就没有了。 但你的车只能坐一个人,你会如何选择那?请解释一下你的理由。 我不知道这是不是一个对你性格的测试, 因为每一个回答都有他自己的原因。 老人快要死了,你首先应该先救他。 然而,每个老人最后都只能把死作为他们的终点站, 你先让那个医生上车,因为他救过你,你认为这是个好机会报答他。 同时有些人认为一样可以在将来某个时候去报答他, 但是你一旦错过了这个机会,你可能永远不能遇到一个让你这么心动的人了。 问你能怎样回答这问题?????????
    (答案:
    在200个应征者中,只有一个人被雇佣了,他并没有解释他的理由,他只是说了以下的话
    e;Q @N$Xf5Dn7T0
    MoE F.b0“给医生车钥匙,让他带着老人去医院,而我则留下来陪我的梦中情人一起等公车!”
    MOGl.U m0
    Vu1OoOGU9q4I2f$iQ|$P0每个人我认识的人都认为以上的回答是最好的,但没有一个人(包括我在内)一开始想到。51Testing软件测试网5D{)hk'M[a
    51Testing软件测试网1a]VA c uc
    是否是因为我们从未想过要放弃我们手中已经拥有的优势(车钥匙)?51Testing软件测试网 \.G$m J$n]U

    2l0AR1\ V1F0有时,如果我们能放弃一些我们的固执,狭隘,和一些优势的话,我们可能会得到更多。
    GWU(soU0
    6k&v:e%Zb]0E1H$Z}0其实真正让我感到震撼的就是这最后一句话,你能够放弃什么,
    g)x&D4~+wIT5c0我们的一生中,总是有着太多的目标和理想,总想索取,其实有时候放弃也是一种美丽。
  • 获取有效的性能需求——《LoadRunner没有告诉你的》之六

    2007-05-16 11:41:23

        本文是《LoadRunner没有告诉你的》系列的第六篇,我将继续保持“无废话”的原则,用尽可能简洁、明确的语句来表述我对性能测试的看法和经验。在这篇文章中,我们要讨论的是如何获取“有效的”性能需求。

         
        一个实际的例子

        为了便于大家的理解,我们先来看一个性能需求的例子,让大家有一个感性的认识,本文后面的讨论也会再次提到这个例子。

        这是一个证券行业系统中某个业务的“实际需求”——实际上是我根据通过网络搜集到的数据杜撰出来的,不过看起来像是真实的 ^_^

        系统总容量达到日委托6000万笔,成交9000万笔

        系统处理速度每秒7300笔,峰值处理能力达到每秒10000笔

        实际股东帐号数3000万

     

        这个例子中已经包括几个明确的需求:

        最佳并发用户数需求:每秒7300笔

        最大并发用户数需求:峰值处理能力达到每秒10000笔

        基础数据容量:实际股东帐号数3000万

        业务数据容量:日委托6000万笔,成交9000万笔——可以根据这个推算出每周、每月、每年系统容量的增长模型

     

        什么是“有效的”性能需求?

        要想获得有效的性能需求,就要先了解什么样的需求是“有效的”。有效的性能需求应该符合以下三个条件。

        1. 明确的数字,而不是模糊的语句。

        结合上面的例子来看,相信这个应该不难理解。但是有的时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”,或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确,因为还需要考虑区分系统中不同业务模块的负载,以及区分在线用户和并发用户的区别。关于这方面的内容,在下面两篇文章中的留言内容中有精彩的讨论:

     

        2. 有凭有据,合理,有实际意义。

        通常来说,性能需求要么由客户提出,要么由开发方提出。对于第一种情况,要保证需求是合理的,有现实意义的,不能由着客户使劲往高处说,要让客户明白性能是有成本的。对于第二种情况,性能需求不能简单的来源于项目组成员、PM或者测试工程师的估计或者猜测,要保证性能需求的提出是有根据的,所使用的数据和计算公式是有出处的——本文后面的部分会介绍获得可用的数据和计算公式的方法。

        3. 相关人员达成一致。

        这一点非常关键。如果相关人不能对性能需求达成一致,可能测了也白测——特别是在客户没有提出明确的性能需求而由开发方提出时。这里要注意“相关人员”的识别,通常项目型的项目的需要与客户方的项目经理或负责人进行确认,产品型的项目需要与直属领导或者市场部进行确认。如果实在不知道该找谁确认,那就把这个责任交给你的直属领导;如果你就是领导了,那这领导也白当了 ^_^


    如何获得有效的性能需求

        上面提到了“有效的”性能需求的一个例子和三个条件,下面来我们将看到有哪些途径可以帮助我们获得相关的数据——这些方法我在实际的工作中都用过,并且已经被证实是可行的。这几种方法由易到难排列如下:

        1. 客户方提出

        这是最理想的一种方式,通常电信、金融、保险、证券以及一些其他运营商级系统的客户——特别是国外的客户都会提出比较明确的性能需求。

        2. 根据历史数据来分析

        根据客户以往的业务情况来分析客户的业务量以及每年、每月、每周、每天的峰值业务量。如果客户有旧的系统,可以根据已有系统的访问日志数据库记录,业务报表来分析。要特别注意的是,不同行业、不同应用、不同的业务是有各自的特点的。例如,购物网站在平时的负载主要集中在晚上,但是节假日时访问量和交易量会是平时的数倍;而地铁的售票系统面临的高峰除了周末,还有周一到周五的一早一晚上下班时间。

        3. 参考历史项目的数据

        如果该产品已有其他客户使用,并且规模类似的,可以参考其他客户的需求。例如在线购物网站,或者超市管理系统,各行业的进销存系统。

        4. 参考其他同行类似项目的数据

        如果本企业没有做过类似的项目,那么可以参考其他同行企业的公布出来的数据——通常在企业公布的新闻或者成功解决方案中会提到,包括系统容量,系统所能承受的负载以及系统响应能力等。

        5. 参考其他类似行业应用的数据

        如果无法找打其他同行的数据,也可以参考类似的应用的需求。例如做IPTV或者DVB计费系统的测试,可以参考电信计费系统的需求——虽然不能完全照搬数据,但是可以通过其他行业成熟的需求来了解需要测试的项目有哪些,应该考虑到的情况有哪些种。

        6. 参考新闻或其他资料中的数据

        最后的一招,特别是对于一些当前比较引人关注的行业,涉及到所谓的“政绩”的行业,通常可以通过各种新闻媒体找到一些可供参考的数据,但是需要耐心的寻找。例如我们在IPTV和DVB系统的测试中,可以根据新闻中公布的各省、各市,以及国外各大运营商的用户发展情况和用户使用习惯来估算系统容量和系统各个模块的并发量。

    引自:http://www.51testing.com/?action_viewnews_itemid_10568.html

  • 无所不在的性能测试——《LoadRunner 没有告诉你的》之五

    2007-05-16 11:40:03

    提到性能测试,相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底,在大多数情况下,我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致,评判系统是否存在性能缺陷,并根据测试结果识别性能瓶颈,改善系统性能”。

    本文是《LoadRunner没有告诉你的》系列的第五篇,在这篇文章中,我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中,如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。

    因此,本文的结构也将依据软件开发过程的不同阶段来组织。

    另外,建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。

     

    需求阶段

    我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车,如果你面对的正是这样的问题,那么恐怕你只能重做一辆,而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。

    如果我们在系统结构确定之前就能够了解到系统的将要面对的压力,用户的使用习惯和使用频度,我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷,也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长,我们还可以给出相应的解决方案来低成本的解决这类问题,就像上面那辆皮卡,也许你可以有办法把20辆皮卡捆在一起,或者把15吨的东西分由20辆来运。


    分析设计阶段

    系统性能的优化并不是要等待整个系统全部集成后才能开始的,早在分析设计阶段,我们就可以开始考虑系统的技术架构和数据库部分的优化。

    数据库通常位于整个系统的最底层,如果直到系统上线前才发现因为数据库设计不合理而导致性能极差,通常使用任何一种方法来优化都已经于事无补了。要避免这类问题,最常见的做法是在数据库结构确定后,通过工具或脚本向数据库中注入大量的数据,并模拟各种业务的数据库操作。根据对数据库性能的观察和分析,对数据库表结构和索引进行调整以优化数据库性能。

    在系统的技术架构方面,要明白先进的技术并不是解决问题的唯一方法,过于强调技术的作用反而会将你带入歧途。例如:某些业务虽然经常面临着巨大的压力,并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高,并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。

    另外,所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题,未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便,但是它生成的SQL是未经优化的,有时甚至比人工编写的SQL效率更低。

    最后,要知道不同厂家的设备性能是不同的,而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器,表现出来的性能也是不同的。如果有足够的资源,应当考虑提前进行软硬件平台的对比选型;如果没有足够的资源,可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。


    编码阶段

    一片树叶在哪里最难被发现?——当这片树叶落在一堆树叶里面的时候。

    如果你只是在系统测试完成后才开始性能测试,那么即使发现系统存在性能缺陷,并且已经有了几个可供怀疑的对象,但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时,找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试,重点集中在对算法和实现方法的优化上。

    另外,及早开始的测试也可以帮你更容易找到内存泄漏的问题。


    测试阶段

    产品终于交到我们手上了,搭建测试环境,设计测试场景,执行测试,找到系统的最佳并发用户数和最大并发用户数,将系统进行分类,评判系统的性能表现是否满足需求中定义的目标——如果有需求的话 ^_^

    如果发现系统的性能表现与预期目标相去甚远,则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈,优化系统性能。

    在这个阶段还有很多值得我们深入思考和讨论的东西,在本系列后续的文章中,我们将会更多的关注这一部分的内容。


    维护阶段

    维护阶段通常遇到的问题是需要在实验室中模拟客户环境,重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷,性能缺陷与某一具体环境和场景的关联更加密切,所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话,检查该系统是否记录下了软硬件资源的异常或者警告。


    与性能测试相关的其他测试

    可靠性测试(Reliability Testing)    对于一个运营商级的系统来说,能够保证提供7×24的连续稳定的服务是非常重要的。当然,你可以通过一些“高可用性(High Availability)”技术方案来增强系统的可靠性,但是对于系统本身的可靠性测试是不能被忽略的。

    常用的测试方法是使用一定的负载长时间向服务器加压,并观察随着加压时间的延长,响应时间、吞吐量以及资源利用率的变化。要注意的是,所使用的负载应当是系统的最佳并并发用户数,而不是最大并发用户数。

    可伸缩性测试(Scalability Testing) 对于一个系统来说,在一个给定的环境下,它的最佳并发用户数和最大并发用户数是客观存在的,但是系统所面临的压力却有可能随上线时间的延长而增大。例如,一个在线购物站点,注册用户数量不断增多,访问站点查询商品信息和购买商品的人也不断的增多,我们应该用一种什么样的方案,在不影响系统继续为用户提供服务的前提下来实现系统的扩容?

    一种常用的方案是使用负载均衡(Load Balance)和集群(Cluster)技术。但是在我们为客户提供这种方案之前,需要先自己进行测试,保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置,就能够使得系统的容量得到线性的增长?

    可恢复性测试(Recoverability Testing)      虽然我们已经可以准确的估算出系统上线后将要面对的压力,并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力的,但是这个世界上总是有些事情上我们所无法预料到的——例如9.11事件发生后,AOL的网站访问量在短时间内增长到了平时的数十倍。

    我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务,但是我们需要确保当意外过去后,系统可以恢复到正常的状态,并继续后来的用户提供服务——就像从未发生过任何事情一样。

    如果要实现“可恢复性测试”,我们可以借助于测试工具或脚本来逐渐的增大并发用户数,直至并发用户数已经超过了系统所能承受的最大并发用户数,并导致软硬件资源利用率饱和,响应时间无限延长,大量的请求因为超过响应时间要求或无法获得响应而失败;之后,我们逐渐的减少并发用户数,并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。

     

    当然,这一切的前提是在系统负载达到峰值前,Server一直在顽强的挣扎着而没有down掉 ^_^

     

    性能测试,并非网络应用专属

    软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的,但是软件性能和性能测试却并非网络应用的专属名词,因为单机版的应用同样需要考虑性能问题。下面举几个简单的例子来方便大家的理解:

    1. 当使用Word来编辑一个500多页,并包含了丰富图表、图片和各种格式、样式信息的文档时,是否每次对大段的文字或表格的修改、删除或重新排版,都要等待系统花几秒钟的时间进行处理?

    2. 当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时,是否每次都要两三分钟才能看到结果?

    3. 杀毒软件是否每次都要花费两个小时才能完成一次对所有的分区的扫描?

    4. 是否每次在手机的通讯簿中根据姓名搜索某个人的联系方式都要三四秒钟才有响应?

    如果大家有兴趣,也可以通过Google搜索到更多的有关单机应用性能测试的资料。

924/5<12345>
Open Toolbar