修炼着,快乐着,只愿努力长成想要的样子~~~~~

发布新日志

  • 软件测试知识复习

    believe 发布于 2007-06-14 11:20:40

    软件开发过程及软件质量保证
    1.软件开发过程的几个主要阶段:
    1)定义。明确开发的目标,软件的需求
    2)计划。制订软件开发所涉及到的计划。
    3)设计。设计、编码、编写文档等,完成要求的软件特性。
    4)稳定化。主要是测试和缺陷修复,确保软件的质量。
    5)安装。安装、提交完成的软件,为客户提供运行环境。
    2.几种常用的软件生命周期模型:
    1)瀑布模型。
    2)原型模型。
    3)增量模型。
    4)螺旋模型。
    软件测试人员的角度来看软件开发过程,需要注意的是:测试贯穿在整个开发过程中,而不是在某个阶段集中地做一下测试而其它阶段不用理会测试工作

    一个软件之所以被认为为质量优秀,是它内在具备了这样一些特性:
    满足用户的需求;
    合理进度、成本、功能关系;
    具备扩展性和灵活性,能够适应一定程度的需求变化;
    能够有效地处理例外的情况;
    保持成本和性能的平衡。

    软件质量保证(Software Quality Assurance-----SQA)是为了确保软件开发过程和结果符合预期的要求而建立的系列规程,以及依照规程和计划采取的一系列活动及其结果评审。

    软件质量保证的活动主机包括:
    技术方法的就用;
    正式技术评审的实施
    软件测试;
    标准的执行;
    修改的控制;
    度量;
    记录和记录保存。

    软件错误的定义:软件错误是软件产品中存在的导致期望的运行结果和实际结果间出现差异的一系列问题,这些问题包括故障、失效、缺陷。


    软件测试:
    软件测试就是为了发现软件中存在的错误而分析或执行程序的过程。具体地说,软件测试是分析程序或根据软件开发各阶段的规格说明和各程序的内部结构而精心设计出一批测试用例,并利用测试用例来运行程序,以发现程序错误的过程。

    软件测试有两个基本的功能:验证(Verification)和确认(Validation)。
    验证指保证软件正确地实现了特写功能的一系列活动。
    确认指保证最终的产品满足系统需求。
    通俗的说:验证保证产品的正确性;确认保证生产了正确的产品。

    软件测试人员应该至少具备以下两个关键领域方面的知识:
    1)软件测试技术;
    2)被测应用程序及其相关应用领域知识。

    理解以下的描述:
    测试能提高软件的质量,但是提高质量不能依赖测试;
    测试只能证明错误存在,不能证明错误不存在;
    测试的主要困难是不知道该如何进行有效地测试,也不知道什么时候能够放心的结束测试;
    每个程序员都应当测试自己的程序(份内事),但不能作为程序已通过测试的依据(所以项目需要独立的测试人员);
    80-20原则:80%的错误聚集在20%的模块中,经常出错的模块改错后还是会经常出错;
    测试应当循序渐进,不要企图一次性做完。"欲速则不达"。

    测试人员的目标和主要工作:
    目标:(1).基本目标是发现软件错误;
    (2).要尽可能早的找出软件错误;
    (3).必需确保找出的软件错误得以关闭。

    主要工作:
    1)规划测试任务
    2)设计测试(包括编写测试用例等等)
    3)建立一个合适的测试环境
    4)评估、获取、安装和配置自动测试工具
    5)执行测试
    6)撰写适当的测试文档

    软件测试的分类
    1.从是否需要执行被测试软件的角度分:有静态测试和动态测试。
    2.从测试是否针对软件结构和算法的角度分类分:白盒测试和黑盒测试。
    3.从测试的不同阶段分:单元测试、集成测试、系统测试和验收测试四个阶段。
    其中系统测试有:功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等等。

    针对某些功能作用的测试:
    回归测试:指错误被修正后或软件功能、环境发生变化后进行的重新测试。
    功能测试:测试软件的功能是否符合功能性需求,通常采用黑盒测试方式。
    负载测试:测试软件系统的最大负载,超出此负载软件有可能会失常。
    压力测试:与负载测试差不多,叫法不同。
    易用性测试:测试软件是否易用,主观性比较强。一般要根据用户的反馈信息来评价。
    安装与反安装测试:测试软件在"全部、部分、升级"等状况下的安装/反安装过程。
    恢复测试:测试系统从故障中恢复的能力。
    安全性测试:测试系统防止非法侵入的能力。
    兼容性测试:测试系统与其它软件、硬件兼容的能力。
    内存泄漏测试:测试软件在运行过程中是否会造成内存泄漏。
    比较测试:通过与同类产品比较,考察该产品的优点、缺点。
    Alpha测试:一种先期的用户测试,此时系统刚刚开发完成。
    Beta测试:一种后期的用户测试,此时系统已经通过内部测试,大部分错误已经改正,即将正式发行。同Alpha测试一样都由用户进行,场地不同,Alpha测试一般是把用户请到开发方的场地来测试,Beta测试是指在一个或多个用户的场所进行测试。

    测试工作的主要步骤:
    1)测试计划:测试人员要首先对需求进行分析,最终定义一个测试集合。
    2)测试设计与开发:根据软件需求、说明书完成测试用例设计并编写必要的测试驱动程序。
    3)执行测试:需要做的工作是,建立测试环境;根据前面编写的测试计划和测试用例运行测试;记录测试结果;报告软件缺陷;跟踪软件缺陷直至其被处理;分析测试结果


    PS 测试工程师职业素质
    1)责任心
    2)学习能力
    3)怀疑精神
    4)沟通能力
    5)专注力
    6)洞察力
    7)团队精神
    8)注重积累
  • [转]面试,用30分钟决定你的职业

    llzkgy_2006 发布于 2007-05-29 15:48:54

    面试,用30分钟决定你的职业




      为什么你想要这份工作?

      先来做一个成语填空。我发现,这个四字成语可以用来形容许多人在找工作时的心态:东——西—— .东邪西毒?东成西就?东南西北?东方不亮西方亮?

      拜托,有点专业精神好不好。想不出来吧?我来揭晓答案,这个成语是:东食西宿。

      这是一个生僻的成语,生僻到几乎所有的汉字输入法软件的词库中都没有这个成语。

      而且这个成语因为意思刻薄,也很少在生活中为人们使用。

      它究竟是什么意思呢?这个成语背后的故事是:古时候有一户人家的女儿到了出嫁的年龄,东边邻居的儿子和西边邻居的儿子都来提亲。 东边的邻居家境殷实,但是儿子非常难看并且不解风情;西边的邻居家境清贫,但是儿子一表人才并且知书达理。父母做不了决定,就去问女儿的意见。女儿考虑了半天,终于羞答答地表态:我能不能在东家吃饭,然后晚上住在西家?

      本来,追求两全其美的心态也无可厚非。我相信在这个世界上也的确有收入又高又不辛苦的工作,然而,对于刚刚从大学里走出来的学生或者是其他资历尚浅的年轻人来说,讨价还价的能力几乎为零。文凭的意义仅仅在于可能给了你一块敲门砖,但是,如果你以为你的十年寒窗苦读能够给公司带来的价值,可以等于甚至大于一个在实践中已经摸爬滚打了10年的老手,那么你已经在心态上犯了第一个不实用主义的错误。

      从另外一个角度来说,没有东食西宿的好事,也说明了每一份工作总是会有它的不尽如人意之处。我的许多朋友,都是工作在投资银行和咨询公司的年轻精英们,他们衣着光鲜,坐飞机出差几乎如同我们普通人打车;平时出入各大写字楼、五星级宾馆,偶尔神秘地提到自己正在做的项目,满嘴的专业术语让人立刻觉得高深莫测,更不要提他们的五位数的月薪,轻松入读名牌MBA的可能,以及未来看似无限的“钱途”。这一切难道不让人羡慕不已吗?

      然而,在我没有开始找工作之前,我参加了几次他们的聚会,惊奇地发现,每次的聚会都会有一个环节叫做“抱怨比赛”。来自不同公司的精英们,开始争先恐后地抱怨自己的工作时间太长、没有个人生活的乐趣、熬夜导致健康下降、项目中自己的任务太过于无聊,等等。

      这听上去是不是颇有些令人惊奇呢?其实,著名的“二八原则”在任何一项工作中同样都是适用的——一份工作,其中令旁观者羡慕、在闪光灯下或者是给工作者带来真正的成就感的部分,大部分只占工作内容的20%而已。而另外的80%的工作内容,则可能充斥着艰苦的劳动、枯燥的重复、巨大的身心压力等等可能不为外人所知的辛苦的一面。

      我最欣赏的日本的行为心理学家、效率大师多湖辉就曾经说过,幸福的人生不过就是能够以自己喜欢做的事情为工作,并且还能够从工作中获取到合理的报酬而已。不过,这个看似简单的要求,多湖辉接着补充说,也仅有非常小的一部分人能够真正实现这种幸福。

      为什么一本讲面试的书要从讨论对工作的态度开始呢?难道高明的面试者不是可以通过面试获得这个世界上所有想要的工作吗?或者说,不论是什么工作,神奇的面试者都可以进入面试室,把自己推销出去,就好像传说中最伟大的推销员能够把梳子卖给僧侣、把冰箱卖给爱斯基摩人、把二胡卖给西洋管弦乐团一样?

      并不是这样的。假如你真的把面试看成一场推销,伟大的推销员,也是依靠自己对顾客需要的了解来赢得订单。更何况,一场好的面试,在我看来,远远不是一场推销,而更是一个坐在面试桌前的双方,互相发现对方对于自己的意义和价值的过程。你对一份工作的态度是冷淡、热情、充满兴趣、无所谓还是势在必得……会直接影响着你在面试中表现出来的态度。它们通过你的眼神、声调、动作、微笑弥散开来,透过空气,慢慢地感染到你的面试官。

      于是,你的面试官接收到了这种“感染因子”,他突然抛出一个问题:告诉我,你为什么想做这一行/进这个公司?

      你一定会在面试中遇到这个问题。而这个问题的潜台词丰富得令人难以置信。结合你们对话的上下文和面试的气氛,这个问题可能包含着面试官各种各样的微妙的态度:热身的问题:“让我再看看他的简历,我完全忘了他的背景了。让他先随便说说废话,我好趁这个时间想想该问他些什么。”这种情况大多发生在面试刚一开始的时候。

      积极的信号:“这个小伙子不错。让我来看看他对我们这行究竟有什么了解,顺便再给他一些积极的鼓励。”

      消极的信号:“你说你讨厌加班、不喜欢数学,平时的爱好就是睡觉。你为什么跑来申请一所会计师事务所?!你是不是真的走错门了?如果是这样,这就是我最后一个问题了。”

      不安全感:“这家伙看上去实力很不错,为什么跑来申请我们这种工资低又辛苦的活儿?没准就是来拿我们练练手的。”或者,“GRE、TOFEL这孩子都考了这么高的分,看上去他只差一张美国签证了。是不是明年他就准备拍拍屁股出国了?我得不动声色地问个究竟。”

      ……

      不同的情况还可能有很多种。如果你能判断出面试官的情绪和意图,你也许可以更好地调整自己的情绪和回答的内容。然而,万变不离其宗,你的回答也许永远都逃不过这个最基本的问题:你真的想做这份工作吗?为什么?而且,如同我后面还会强调的那样,按照你的真实想法回答问题,往往是回答面试问题的最正确的态度。

      更多的情况是,你往往并不知道自己是不是真的喜欢你所申请的工作,也许你申请它,不过是因为听别人说这是一份好的工作,而且人人都在申请。或者你对这个工作所知甚少,仅仅知道它的工资不错。可是,你难道真的可以说,你想做这一行是因为它的****水吗?

      是的,你可以这样说,如果这一点真的对你很重要。高报酬的薪水同样也意味着更高的责任和对职业奉献精神更高的要求,指出这一点来,说明你对这份工作的期待和认识没有什

      么不妥。如果你家境贫寒,你需要尽快****帮助你的弟弟妹妹继续完成教育,向你未来的老板指出这一点只会展现你的责任感并且赢得他们的尊重。事实上,喜欢一份报酬优厚的工作本身并没有任何的错误,特别是考虑到你的面试官同样也在享受着这份工作的这个优点。

      当然,如同那句成为越来越多的人的口头禅的话所说:钱不是问题,或者,钱不是最重要的。可是你会发现,还是有很多人在去面试之前根本就没有好好想过对这个问题的答案;或者,他们想了,但没有答案。

      我听说过的一个北邮的朋友,走进中国电信的面试室,面对“你为什么想来电信行业发展”的问题,想了半天,终于憋出来一句话:“我的手机是全球通,是中国电信的,所以我想来中国电信工作。”相信我,他不是故意想幽默。

      其实对这个“你为什么要选择这份工作”的回答,也许我们需要有一个系统的分析和观点。

      《宪法》中规定了我们都有劳动的权力,然而在现实中,我们每个人都得自己负责去寻找到一个劳动的机会。因此,对于几乎所有的毕业生而言,“就业”,是迈向职业生涯的第一个门槛。跨过去,才能够真正的开始从学校向职场的转变。就业之后,如果你幸运,或者你精心地挑选对了你的第一份工作,你发现你很喜欢也很适合,你愿意稳定地在你现有的位置上发展自我、展现你的才华、实现自己的价值,那么,应该说,你开始有了“职业”的认同,从人人都会有的对第一份工作不确定心态中稳定了下来。

      比起那些发现自己的第一份工作并不令自己满意的人来说,你可以有更长期的计划去建设你的职业,而不需要迅速地考虑跳槽甚至更改自己的行业。

      “事业”是比“职业”更高的一层状态。也许一个人对一份职业产生了强烈的热爱和认同,使得这份职业变成了自己的事业;也许一个人开始了创业,从此成为了自己的老板。“职业”更多的是一个阶段性的概念,而“事业”已经开始带有人生追求的色彩。

      如果你觉得这种“就业——职业——事业”的三分法似乎还有些道理的话,那么什么是我们就业应该考虑的方向就变得很清楚了。

      假设同时毕业的三个好朋友,A选择了去一家广告公司,一年后跳槽到一家房地产公司,一年后又跳槽到一家网络公司;B选择去了一家大型外企的人力资源部门,工作两年后被提升为经理,同时在职继续攻读人力资源方向的MBA;C进入了政府部门,在基层锻炼了两年后回到部委工作。

      这三个年轻人当然都还很年轻,他们未来的发展充满了不可预期的变化。但是让我们仅仅从“就业——职业——事业”的三分法的角度来看,A一直在就业的状态中,而B正在建设自己的职业,C开始经营的是自己的事业。

      《基业长青》中对世界上最成功的公司的战略进行了分析后,得出一个结论,那些成功的公司,最相同的地方是:长期地专注做一件有长远意义的事情,最后获得了成功。公司的发展如此,人的发展是不是也可以从中借鉴到一些道理?

      因此,如果说单纯的就业仅仅解决了你依靠劳动自食其力的问题,一个更好的就业,应该是能够使你获得一份你可以持续建设的职业,甚至是一份你可以终身经营的事业(当然,不参加就业而直接创业的,也应该归到追求事业的一类中去)。以就业为目标,也许你看重的仅仅是一份经历、工资或者就是工作本身;而以寻找到一份职业为目标,你要考虑的就应该包括这份职业会如何给你带来成就感、如何帮助你继续学习、成长,它的中远期发展前景如何;如果你是在寻找一份事业,那么,你更加需要好好地和你内心深处的渴望对话:你是一个怎样的人?你希望向什么方向前进?

      好了,经过了一番深思熟虑,现在是自信而沉稳地回答你的面试官关于“你为什么要选择这份工作”的问题的时候了。答案就是告诉他你在寻找的是什么,而为什么这个行业/公司能够提供给你所寻找的东西。

      通常,一个热情、有事业心的年轻人会希望在工作中寻找到:明确的学习内容和目标不断学习和锻炼的机会挑战感和成就感对某一个行业的特定知识和特殊技能潜在的作为终身事业追求的可能工作带来的自我实现感:报酬、社会认同、价值观有意义的工作内容、工作伙伴和工作环境……

      你可以继续在这个单子上面加上你真想要的东西。每个人都是特殊的,每个人都会有不同的内容补充进来。告诉你的面试官你真正想要的东西,这种诚实能够使你们双方产生一种开诚布公的交流氛围。更加重要的是,想清楚你真正想要什么,能够避免你自己为了得到工作本身而迷失了自己的追求,因为,当你一不小心实实在在地获得了一个工作机会时,它看上去总会变得更加顺眼一些。而如果它其实真的不是你想要的,这种额外的获得只会成为你继续寻找的阻力。但是你也必须脚踏实地地总结出你对于工作的理想和期望,不要太理想主义,走向了唱高调般的反面。一个对于咨询行业的合理的理想表述可以是:“我喜欢发现和解决困难的问题,通过努力找出答案。特别是当这个答案可以帮助到其他人更好的工作和生活时,我会更加觉得愉快与有成就感。”然而我在麦肯锡的面试现场却听说过这样的回答:“我希望我的工作能够增加中国宏观经济和微观经济运行的效率,同时积累经验,将来使自己开办的公司进入世界500强。”

      还有另一个有些异曲同工的例子,说明任何远大的理想都应该和脚踏实地的工作联系起来。我的一位好朋友告诉我,他在面试一家投资银行时,解释他为什么被投资银行业所吸引时说:“我觉得做这一行可以直接和很多企业的高层直接会面,通过我们的工作影响他们的决策,从而影响到整个经济和市场。”——他突然发现面试官的嘴角开始慢慢地往下撇,于是他紧接着说,“当然,这是在我能够成为像您这个级别的资深银行家之后。我非常清楚作为一个初级的分析员每天所面对的都是大量的基本案头工作。”

      谢天谢地,他看到面试官嘴角的曲线终于又向上弯了回去。

      第二章:世界上最漫长与最短暂的30分钟咬文嚼字有时往往能够给人带来许多有趣的启发,比方说让我们来琢磨琢磨“面试”

      这个词。从科举应试,到金銮殿试,尽管我们伟大的中华考试文化源远流长,“面试”这个词看上去却像是个舶来品——面试,顾名思义,当面的考试。似乎在引进这个词的语言学家那里,面试就已经被定性为了一种测试,因此不是面聊、面看、面笑。而测试,我们知道,它好像总是会让人紧张、手心出汗、心跳加速的……

      世界上最漫长与最短暂的30分钟

      咬文嚼字有时往往能够给人带来许多有趣的启发,比方说让我们来琢磨琢磨“面试”

      这个词。从科举应试,到金銮殿试,尽管我们伟大的中华考试文化源远流长,“面试”这个词看上去却像是个舶来品——面试,顾名思义,当面的考试。似乎在引进这个词的语言学家那里,面试就已经被定性为了一种测试,因此不是面聊、面看、面笑。而测试,我们知道,它好像总是会让人紧张、手心出汗、心跳加速的……

      反过头来看英语中的“面试”——interview,却似乎没有沾上任何和“考试”相关联的味道。除了面试之外,interview包括的意思还有:会见、采访。其令人紧张的程度怎么看也比不上考试。如果我们把interview这个词拆开,也不过是inter和 view,直接翻译成中文最多是“大家互相瞅瞅”的意思。

      也许词语的意思会随着人们生活的发展而变化,就好像今天有人说请你“吃饭”,但通常你可能根本不会吃到一粒米饭,但是还是没人肯说是去请你“吃菜”。那么,“面试”发展到了今天,除了“考试”的意思,还可以被理解成什么呢?

      有人说面试就是一场推销:你向面试官花言巧语地推销自己,试图从他那儿拿到作为订单的工作合同。

      有人说面试就是一场谈判:大家坐在桌子两端,唇枪舌剑,你来我往。谈判的目的就是要说服面试官,不雇佣你,将会是他们最大的损失。

      也有人说面试更像是一场戏:平时只穿牛仔裤的你必须换上西服,西装革履风度翩翩外交辞令地扮演一个你根本不熟悉的角色。演得好你就有资格继续演下去,演得不好你就别想有人捧你让你红。

      还有人说面试就是一场审判:面试官就是审判官,他的决定掌握着你命运的转折。你只能为自己作出无力的辩护,其他的都只能交给你上辈子积的德和你上星期在卧佛寺捐的香火(卧佛寺,因为“卧佛”谐音offer,据说求offer必应,于是成为北京地区香火最盛的寺庙之一)。

      还有人说……

      众说纷纭,不由让我想起了一桩著名的禅门公案。两僧打坐,甲僧对乙僧说,我看你像狗粪。乙僧对甲僧说,我看你像尊佛。禅师说,乙僧心中是佛,看别人也是佛;甲僧心中是狗粪,看别人也是狗粪。

      在我看来,你怎么看面试,恐怕也决定了你在面试中的感受如何。如果你进入面试屋的时候,心里想着的是进入考场、谈判场、戏场或者审判室,你的心情想必也难以愉快而轻松,你脸上的微笑也不免会生硬与干涩。

      所以,为什么不把面试看成是一场难得的对话?试着更多地把自己定位为一个前来学习人生和工作经验的学生,而面试官作为一个愿意与你分享关于工作、职业发展和人生经验的前辈。你会发现,抱着这种心态,面试压抑的气氛在不知不觉中从一问一答,而慢慢地变成了一个双向的交流。事实上,甚至应该这么说,能够和杰出的职场人士如此平等、轻易地交流(特别是想到这些人将来可能会是你好几个级别以上的老板时),面试真是再理想不过的一个机会了。

      反过来,对于那些平日忙于在商业世界里打拼的面试官们来说,回到有些陌生又有些熟悉的菁菁校园面试,见到一张张写满渴望、勇气和单纯的年轻的脸庞,为什么不和眼前的这个看上去聪明、可爱和善解人意的孩子聊聊自己的过去,指点一下他未来的发展,多获得一些崇敬的目光呢?他们当然会这样做,只要你给他们机会。

      对于任何一个富有远见的组织来说,招揽到出色的人才,无论对于公司还是其他机构,都是成功地完成自己的使命的基础。面试对于公司的意义在于,提供一个认识候选人的机会,从而在此基础上判断,谁是更加适合公司需要的人才。尽管,每家公司的面试组织程序会有所不同,但是它们还是有基本相同的先后顺序。了解这些基本的程序,能够帮助面试者减少对面试的神秘感,增加信心,更好地设计自己的面试策略。

      通常面试程序可以被分成以下几个部分:

      (1)确定所需要招聘的职位的工作描述、薪酬范围和应聘者所需要的资格。

      (2)通过招聘会、海报、广告等形式,把招聘信息传达给潜在的应聘者。

      (3)收集应聘者的简历,筛选简历得到可以进一步面试的合适数量的应聘者。

      (4)电话面试。一般由人力资源部门或者投资银行与咨询公司中资历比较浅的分析员或者咨询员打来,在面试中进一步确认应聘者的背景、语言表达能力等。通过筛选得到可以进一步面试的合适数量的应聘者。

      (5)第一轮面试。

      (6)第二轮面试。

      (7)确定入选的候选人,人力资源部门和他们保持联系,推销公司,确保他们接受合同。同时,公司也可能继续和几个作为万一“正选”拒绝接受要约后的“后备”候选人保持“暧昧”的关系。

      (8)人力资源部最后检查应聘者的背景、提供的材料无误。

      你在申请公司的时候不一定会经历所有的程序。比方说,电话面试往往只是那些非常强调英语口语能力的外企才有的步骤,他们希望借此道程序排除一部分口语能力不强的应聘者,国企、私营企业或者政府机关,基本上不会有这道门槛。

      对于外企而言,面试程序也各不相同,投资银行一般在电话面试后只会安排一轮面试,但这轮面试中会有4到6个级别不同的银行家在一个集中的时间内展开“车轮大战”式的面试。这一方面是因为银行家时间紧张,整天在天上飞来飞去,如果不固定一个时间集中面试,整个面试可能会因为每个人的时间安排不同而拖得很长;另外,这种车轮大战式的面试在另一个方面也能够很好地测试出应聘者是否能在这种长时间压力的工作环境下有良好的表现和发挥。说实话,一个人30分钟,连续3个小时的面试下来,真是有筋疲力尽、大脑缺氧的感觉。

      咨询公司的风格又不一样,他们往往在电话面试后安排两轮面试,并且面试的内容与大部分投资银行的传统面试也不相同。咨询行业的面试几乎都是案例面试,应聘者遇到最大的挑战来自解决现实中的咨询员遇到的真实问题。面试官往往仅仅告诉应聘者一些最基本的事实,应聘者必须通过与面试官的讨论,发掘、掌握更多的有用信息,决定采取某一种方法,有逻辑地找出这个问题的答案。案例面试的最终的答案有可能是一个估计出来的数字,也有可能是一套商业战略,还有可能是发现一个重要的原因。比方说,我自己曾经碰到的最让我

      摸不着头脑的一个估计数字的题目是:北京市大概有多少下水道的井盖?

      如果说投资银行的面试方式是把应聘者放在压力之下,看他的举止反应;咨询公司是把应聘者放在问题之中,看他的分析能力和聪明程度,那么,对于一般的工业性的跨国公司(P&G、Unilever、GE等等)来说,他们会更小心地详细考察应聘者过去的背景,会愿意和应聘者在一起花更多的时间,来观察和判断应聘者是否具有他们公司文化所欣赏的品质和特点,是否能够和这个庞大的公司机器上的所有人相处和谐。其中最典型的也最有名的面试风格应该是宝洁公司严格的“笔试——职业英语能力测试——性格特征测试——HR面试——广州总部部门面试”

      爱因斯坦曾经这样对年轻学生解释过相对论:当你和一个美丽的姑娘坐上两个小时,你会感到好像坐了1分钟;但要是在炽热的火炉边,哪怕只坐上1分钟,你却感到好像是坐了两小时。

      同样,面试可能是世界上最漫长的30分钟,也可能是世界上最短暂的30分钟。当你和你的面试官都有一种频频想看表的冲动时,抱歉,你的这场面试看起来是失败了。而当你走出面试间,一低头看表,发现不知不觉地已经超出了30分钟时,这往往是证明你刚才的面试进行得很顺利。

      一个面试官就曾经告诉我,当他在面试开始5分钟后,就决定不可能给这个应聘者任何机会的时候,他恨不得立刻就结束这场面试。但是,他不能,因此,他只好盯着手表,等到刚过25分钟的时候,立刻开始问应聘者:你还有什么问题吗?

      30分钟的面试时间里可以发生很多的事情,但是也可能没有发生太多的事情。毕竟,即便是中央电视台的播音员,按照1分钟300个字的速度说话,30分钟滔滔不绝地一直在说,也说不到1万个字。通过不到1万个字的信息量,你是否能够获得这个可能是命运转折的机会就这样被决定了。所以你要明白,可能真的需要字字珠玑,字字千金,你才能打动命运女神的垂青。

      一个常规面试的30分钟里可能出现的事件和顺序大致上是这样的——但是,同样,法无定法,任何变数都会发生,掌握常规和随机应变并不矛盾——敲门,你满面笑容地进去,握手,请坐。然后面试官会给你一个很短的自我介绍,时间已经过去了3分钟,面试算是正式开始了。最理想的状态,你的面试官的第一个问题是:简单地介绍一下你自己吧。正中下怀,于是你开始背你写好的稿子,啪啦啪啦啪啦,你最好最多别超过5分钟,否则面试官十有八九会打断你,他觉得你背得太熟了。于是,面试开始10分钟后,真正的较量开始了。在接下来的15分钟之内,才是你真正抓住面试官,给他留下决定性印象的时候。15分钟之内,一问一答,能够有几个回合呢?完全取决于你回答问题的长度。你可以一个问题用10分钟来回答,另一个问题用5分钟,这样你就让刁钻的面试官没有机会问你别的问题了;你也可以每个问题都用一句话来回答,这样你很快就可以让面试官弹尽粮绝,没有那么多准备好的问题来问你了——我希望你能看出来我是在开玩笑。

      对你而言,控制时间和节奏成为了和给出好的答案同样重要的任务,如果前者不是更重要的话。有几个重要的原则你必须记住:

      (1)你必须努力掌握对节奏的控制权,而不要把它交给你的面试官。

      如果你回答问题总是拖沓冗长、毫无逻辑也看不出什么时候能结束,面试官会不得不总是打断你的回答:“我明白你的意思了,那么,下一个问题是……”这种被打断回答的情况往往会带来紧张,出现几次,你就会发现清晰的思维和顺畅的表达就这样被打断了。

      所以,千万不要给面试官这种机会。通常情况下,只要你把握得当,他们也并不会主动地抢。

      然而也有这样的面试,面试官无意或者故意地不断打断你的回答,试图获得面试节奏的控制权。那么,在这种情况下,你必须保持冷静,努力地把节奏感再抢回来。你可以在面试官突然打断你的回答,插入一个问题时,有意识地保持10秒钟的沉默,装作在思索这个问题,实际上是在冷静,找回自信和节奏,然后用一种和刚才回答问题不同的语速重新开始。还有的时候,当你觉得你是在回答到关键时刻被打断的话,不要就此罢休,你应该在回答被打断之后的新问题前,有礼貌地说:“在我回答这个问题之前,我觉得我应该对刚才那个问题的回答补充一点……”然后尽快完成你刚才没有机会完成的观点。

      (2)永远不要在一个问题上纠缠太久。

      这15分钟,或者说整个面试,就是一张你无法先看到整张试卷的试题,有点像GRE的机考,更糟糕的是,你实际上连每道题的分值都不知道。在面试的时候,你不知道你在努力地向面试官说清楚的那个复杂的问题究竟能给你增加多少分,而你花了七八分钟在这个问题上,也可能下一个问题对你来说既简单、分数又多。所以,当一个问题开始出现你很难说清的情况时,不要纠缠太久,简单地说:“关于这个问题,我想我现在只能说出这么多了。”让面试向你的下个机会走去。

      (3)在15分钟内取得尽量多的共识。

      在一般情况下,面试官不是来寻找一个永远的“持异议者”的。当你在回答一些关于观点、价值、方法方面的问题时,你会发现,也许经常会出现面试官频频点头,或者他面无表情,甚至摇头的情况。点头很大程度上说明你们的共识,而通常,共识比异议更容易给你的表现加分。

      熬过了这15分钟后,接下来是你最后的机会了。面试官通常会问你有没有任何问题问他。永远别说没有,除非他之前告诉你他已经决定录用你了。最后的问题可能毁了你之前的所有的努力,也可能把你从一场失败的面试中挽救回来。

      然而想出一个好的、最后的问题往往比准备一个好的自我介绍还要难。有的时候,你希望通过一个好的问题,让人对你刮目相看。但是通常你会发现,更容易的是问一个面试官有话可回答的问题,然后你加上几句评价,把这个面试画上句号。

      如果你之前的面试进行得都很顺利的话,在最后一个问题上应该保守一些,只要不犯错误就行。所以你可以问问面试官怎么走进这一行的,怎么看待这一行等等。如果你之前的面试感觉不佳,你希望通过最后一个问题来绝地反击的话,你不妨问面试官一个让他给你出主意的问题,顺带着你可以说出一个你没有来得及在面试中提起的卖点,加深面试官对你正面的评价。

      比方说,我知道的一个聪明的问题,我的一个好朋友明白自己在面试中的英语口语能力令面试官一直表现得对她缺乏兴趣,于是她最后问道:“您知道,我在高中的时候一直是学俄语的,进入大学后我才从ABC开始学英语,现在刚刚学了3年。虽然我已经可以在托福考试中取得630分的成绩,但我知道我的英语口语还需要很大的提高,您能在这方面给我一些好的指点吗?”

      那位香港长大、哈佛毕业的面试官立刻有些羞涩地说:“不、不,你的英语已经很让人满意了。我是中国人,我的中文说得还没有你的英文好。你只学了3年就已经这么好了,应该是你给我一些指点。”

      结果,这个只学了3年英语的女孩子击败了其他学了十几年英文、口语比她好得多的竞争者——我觉得她就只用了这最后一个问题即确定胜势。
  • 软件测试面试题

    kxiaofei 发布于 2007-06-21 16:56:00

    01. 为什么要在一个团队中开展软件测试工作?
      因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
    02.
    您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?
      我曾经做过web测试,后台测试,客户端软件,其中包括功能测试,性能测试,用户体验测试。最擅长的是功能测试
    03.
    您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同04. 的测试类型的区别与联系(如功能测试、性能测试……)
      测试类型有:功能测试,性能测试,界面测试。
      功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
      性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。

      界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
      区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题的,然后再考虑该功能点的性能测试
    04
    .您认为做好测试用例设计工作的关键是什么?
    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题
    05.  
    请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。
      黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
      白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
      软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:
      1、是否有不正确或遗漏的功能?
      2、在接口上,输入是否能正确的接受?能否输出正确的结果?
      3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
      4、性能上是否能够满足要求?
      5、是否有初始化或终止性错误?
      软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:
      1、对程序模块的所有独立的执行路径至少测试一遍。
      2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。
      3、在循环的边界和运行的界限内执行循环体。
      4、测试内部数据结构的有效性,等等。
      单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
      单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
      集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。
      系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)
      系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
      验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。
    06.
    测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?
      软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)
    07.
    您认为做好测试计划工作的关键是什么?
      1. 明确测试的目标,增强测试计划的实用性
      编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
      2.坚持“5W”规则,明确内容与过程
      “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
      3.采用评审和更新机制,保证测试计划满足实际需求
    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
      4. 分别创建测试计划与测试详细规格、测试用例
      应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
    08.
    您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

      1.等价类划分
      划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
      2.边界值分析法

      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据
    .
    3
    .错误推测法

      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例
    .
    4
    .因果图方法

      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
    09.
    请以您以往的实际工作为例,10. 详细的描述一次测试用例设计的完整的过程。

      就说最近的这次网站功能的测试吧
      首先:得到相关文档(需求文档和设计文档),理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK了),考虑到测试环境,测试用例,测试时间等问题。
      第二步:设计测试用例,测试策略是:把网站部分的功能点测试完,然后在进行系统测试(另外个模块呢有另一个测试人员负责,可以进行联调测试),网站模块的测试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑):这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3个步骤,网站才算完成了它的任务。有3个步骤呢,就可以分别对  这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50个用例。界面测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。
      第三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了,只有有机器能空于下来做该功能测试就可以做了),因为网站本身的环境搭建和其他的系统有点不同,它需要的测试环境比较麻烦,需要web服务器(Apache,tomcat),不过这次需求呢,网站部分只用到了tomcat,所以只要有tomcat即可
      第四步:执行测试
    11.
    您以往是否曾经从事过性能测试工作?如果有,12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
      是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。
    性能测试类型包括负载测试,强度测试,容量测试等
      负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
      强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况
      容量测试:确定系统可处理同时在线的最大用户数   
      在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比),

      Web服务器指标指标:
      * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数;
      * Successful Rounds:成功的请求;

      * Failed Rounds :失败的请求;

      * Successful Hits :成功的点击次数;

      * Failed Hits :失败的点击次数;

      * Hits Per Second :每秒点击次数;

      * Successful Hits Per Second :每秒成功的点击次数;

      * Failed Hits Per Second :每秒失败的点击次数;

      * Attempted Connections :尝试链接数;  

    13.
    您在从事性能测试工作时,14. 是否使用过一些测试工具?如果有,15. 请试述该工具的工作原理,16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
    17.
    您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
    18.
    在您以往的工作中,19. 一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
    20.
    您以往所从事的软件测试工作中,21. 是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,22. 请结合该工具描述软件缺陷(Bug)跟踪管理的流程。
    23.
    您认为在测试人员同24. 开发人员的沟通过程中,25. 如何提高沟通的效率和改善沟通的效果?维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么?
    27.
    在您以往的测试工作中,28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么?您是如何来对待这些事情的?
    31.
    在即将完成这次笔试前,32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面)
    33.     
    你对测试最大的兴趣在哪里?为什么?
      最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了1112点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的12点我没有把握,其他点我都很有信心做好它。
      刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。
      不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。
      我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。
      第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。
    34.
    你的测试职业发展是什么?
      测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的1112点要求自己,不断的更新自己改正自己,做好测试任务。
    35.
    你自认为测试的优势在哪里?
      优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。
    36.
    你以前工作时的测试流程是什么?
      公司对测试流程没有规定如何做,但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结,吸取同行的方法)后的流程吧。需求评审(有开发人员,产品经理,测试人员,项目经理)->需求确定(出一份确定的需求文档)>开发设计文档(开发人员在开始写代码前就能输出设计文档)->想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能会补充用例)->提交bug(有些bug需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)。
    37.
    当开发人员说不38. BUG时,39. 你如何应付?
      开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。
    23
    .你为什么想离开目前的职务?
      因为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有67个),这是我的第一份工作,对公司也有较深的感情,因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。
    24
    :你对我们公司了解有多少?
    25
    :你找工作时,最重要的考虑因素为何?
      工作的性质和内容是否能让我发挥所长,并不断成长。
    26
    :为什么我们应该录取你?
      您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。
    27
    :请谈谈你个人的最大特色。
      我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。
    28.
    白箱测试和黑箱测试是什么?什么是回归测试?
    29
    。单元测试、集成测试、系统测试的侧重点是什么?

    30
    。设计用例的方法、依据有那些?
    31
    。一个测试工程师应具备那些素质和技能?
    32.
    集成测试通常都有那些策略?
    33.
    你用过的测试工具的主要功能、性能及其他?
    34.
    一个缺陷测试报告的组成
    35.
    基于WEB信息管理系统测试时应考虑的因素有哪些?
    36.
    软件测试项目从什么时候开始,?为什么?
    37.
    需求测试注意事项有哪些?
    38.
    简述一下缺陷的生命周期
    39.
    测试分析测试用例注意(事项)?
      你在你所在的公司是怎么开展测试工作的?是如何组织的?
      你认为理想的测试流程是什么样子?
      你是怎样工作的?
      软件测试活动的生命周期是什么?
      请画出软件测试活动的流程图?
      针对缺陷采取怎样管理措施?
      什么是测试评估?测试评估的范围是什么?
      如果能够执行完美的黑盒测试,还需要进行白盒测试吗?为什么?
      测试结束的标准是什么?
      软件验收测试除了alpha,beta测试以外,还有哪一种?
      做测试多久了?

      以前做过哪些项目?
      你们以前测试的流程是怎样的?
      <答:测试计划-测试用例设计-测试执行-测试分析报告>
      用过哪些测试工具?

      为什么选择测试这行?
      <答:它是一个新兴的行业,有发展潜力,而且很锻炼人,需要掌握更多的技能,比做开发要更难>
      为什么值得他们公司雇用?

      如果我雇用你,你能给部门带来什么贡献?
      如何从工作中看出你是个自动自觉的人
      你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)
      通常你对于别人批评你会有什么样的反应
      如果明知这样做不对,你还会依主管的指过去做吗
      如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理
      你觉得什么样的人最难相处
      为什么值得他们公司雇用?
        帮助公司提高软件质量和测试部门的技术水平
      如果我雇用你,你能给部门带来什么贡献?
        分享我的测试经验和测试技能,提高测试部门技术水平
      如何从工作中看出你是个自动自觉的人
            自动自觉范围太广

         1. 工作成果
       
     2. 工作质量  
      你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)

        在有足够的资源和合理的工作量的情况下,完全可以按时完成,并能比一般人做的更好
      通常你对于别人批评你会有什么样的反应
        有错即改,无措勉之
      如果明知这样做不对,你还会依主管的指过去做吗
        在公司内部下级是否有申诉渠道?
      如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理
        为什么抱怨?是怎么样的问题?
        如果是客服问题,提交客服部门解决
        如果是质量问题,分析原因,下一版本改进
      你觉得什么样的人最难相处
        自以为是的人

      什么叫单元测试?
        请就软件测试人员应该具备什么样的基本素质说说你的看法。
      请就如何在开发中进行软件质量控制说说你的看法
       简述软件测试的意义,以及软件测试的分类
    1
    、功能测试,性能测试,界面测试,安全测试(可以简单点,比如只涉及到COOKIES里的内容),压力测试(商业性质的网站)等等,B/S软件也要根据其具体功能采用不同的测试策略。
    2
    、态度、责任心、自信、敏锐的观察力、良好的发散思维
    3
    、先设计后开发模式,加强单元测试,加强代码走查,有一套完整的白盒测试方法。关键是加强开发人员的质量意识,增进程序员向工程师水平发展。
    4
    、意义嘛,就自己想吧。软件测试的分类,这个很多人都按各种方法去分。无明确答案给你。
    对测试的理解——基本的测试知识,对测试是否认可? 75
       3
    、谈一谈过去自己的工作——了解经历、提供进一步提问的素材,表达能力   
    测试技能

    测试设计的方法并举例说明——测试技术的使用

    测试工具——熟悉程度,能否与当前工作匹配?

    如何做计划?如何跟踪计划?——日常工作能力
    如果开发人员提供的版本不满足测试的条件,如何做?——与开发人员协作的能力

    熟悉unix系统、oracle数据库吗?——是否具备系统知识

    做过开发吗?写过哪些代码?——开发技能

    阅读英语文章,给出理解说明?——部分英语能力

    文档的意义——是否善于思考?(最简单的概念,不同层次的理解)

    假如进入我们公司,对我们哪些方面会有帮助?——讲讲自己的特长

    随便找一件物品,让其测试——测试的实际操作能力

    软件测试的方法有?
    软件测试的过程?
    有一个新的软件,假如你是测试工程师,该如何做?
    软件测试分哪两种方法?分别适合什么情况?
    2
    。一套完整的测试应该由哪些阶段组成?分别阐述一下各个阶段。

    3
    。软件测试的类型有那些?分别比较这些不同的测试类型的区别与联系。

    4
    。测试用例通常包括那些内容?着重阐述编制测试用例的具体做法

    5
    。在分别测试winformC/S结构与测试WEB结构的软件是,应该采取什么样的方法分别测试?他们存在什么样的区别与联系?

    6
    。在测试winformC/S结构软件时,发现这个软件的运行速度很慢,您会认为是什么原因?您会采取哪些方法去检查这个原因?

    7
    。描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程

    你在五年内的个人目标和职业目标分别是什么?

      分析这个问题是用来了解你的计划能力的,通过这个问题,面试人同时还可以知道你的目标是否符合企业对你的安排。
      错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁,我认为做太多的个人计划是荒谬可笑的,不是吗?
      评论这种回答属于令人反感的一类。首先,当有人想了解你的目标时,"将来的某个时候"这种通俗说法并不奏效。其次,认为企业很脆弱,领导者更换频繁,这种说法毫无疑问会令人反感,而且也是不合理的。最后,认为做计划可笑,看不起这个问题,而且反问面试人,这些都注定了这样的求职者最终会失败。
      正确回答从现在起的五年之内,我希望能够在一个很好的职位上待几年,而且最好有一次晋升,然后就期待着下一步。不管是向上提升,还是在企业内横向调动,对我个人来说,我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
      评论这个问题没有回答得过分具体(那样可能会产生漏洞),而且它表明你有雄心,并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望,表明你是一个有灵活性的人。
     问题23 你怎样做出自己的职业选择?
      分析 面试人提出这个问题是为了了解求职者的动机,看看他(她)应聘这份工作是否有什么历史渊源,是否有职业规划,是不是仅仅在漫无目的地申请很多工作。
      错误回答 我一直都想在企业界工作。自孩提时代起,我就梦想自己至少也要成为大企业的副总裁。
      评论 除了难以令人相信之外,这种回答还存在一个问题:它表明求职者会对副总裁以下的职位不感兴趣。
      正确回答 在上大学四年级前的那个夏天,我决定集中精力在某一领域谋求发展。尽管我是学商业的,但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标,想清楚了自己擅长做的事情以及想从工作中得到的东西,最后我得出了一个坚定的结论,那就是这个行业是最适合我的。
      评论 这种回答表明,求职者认真地做过一些计划,缩小了自己的关注点,而且也认准了前进的方向。这种回答还表明,求职者理解个人职业规划的重要性,并且有能力做出认真的个人决策。
    1.
    你都用什么测试方法
    2.
    怎么编写案例
    3.
    怎么才能够全面的测试到每一个点
    1.
    你都用什么测试方法
    针对不同的产品或者系统或者模块,有不同的测试方法。总体而言有白盒测试和黑盒测试。
    2.
    怎么编写案例
    案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
    3.
    怎么才能够全面的测试到每一个点
    测试的全面性主要需要在设计测试计划的时候考虑,从测试策略,产品需求等等多个角度考虑从而定义全部的测试点。
    1
    、谈谈软件测试技术,以及如何提高
    2
    、谈谈软件测试职业发展,以及个人的打算
    3
    、谈谈软件测试在企业的地位,也可以结合软件生命周期来谈
    有可能清晰的思路比确切的答案更重要
    在这里,主要说下笔试和面试的问题,希望大家共同参考。
        1
    ,一般公司里实际的软件测试流程是什么样的?你们公司又是怎样的?
        2
    ,软件工程师要具有那些素质?
        3
    ,你会哪些测试工具?怎么操作?
        4
    ,你能不能说下你的35年的职业计划(规划)
        5
    ,你觉得你来应聘有那些优势?
    其余的还好说,但就第4个问题,我感到不好说哦!希望大家给个意见
    第一关:首先要自我介绍,自己的性格怎么样,目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看?还有对于软件测试有什么自己的想法。为什么会想到要做这行(因为我的简历上的工作经历没有关于测试方面的)。哦,还有期望薪资。
    第二关:认为软件测试人员所要具备的基本素质,如果遇到问题会怎样处理,如果得不到研发人员的配合(就是研发说这个不是问题)你又会怎么处理?然后就是一些基本概念,比如软件测试的流程有哪些?如果我上任了,首先会怎么开始自己的工作计划。
    (前两关通过了后面这个就好过多了)
    第三关:像我介绍了一下公司的情况,告诉我主要针对什么内容的测试,会不会使用数据库。告诉我大概要做哪些内容,详细的可以上岗以后慢慢熟悉。大概就这么多了,这对没有经过这一关的不知道有没有帮助,仅供参考吧

  • 从失败中涉取经验 网站设计的十种常见错误

    风在吹 发布于 2006-12-04 14:16:45

    网站是企业面向公众的脸面,本文将介绍10种商业网站设计常见的败笔,从以往的案例和教训中吸取经验可以帮助您避免重蹈覆辙,并可以将您的网站设计得具备实效同时为您的企业带来附加价值。

    在最初设计网站的时候,您有多种选择,机会看上去似乎是无穷无尽的,可以做的事情远远超出想象。尽管构建网站的潜力无限,但是有很多再平常不过的错误会导致网站设计的失败,使您无法实现为企业增加附加价值的目标。

    针对企业网站,我列出了十种常见的设计错误,当然这些问题对于个人网站、业余爱好者和非盈利性机构的网站来讲也是适用的,无论如何请您都要尽力避免这些常见的非常糟糕的错误。

    1.关于我们(About Us):每个网站都应该对此提供非常清晰和直观的信息,包括一段简短的夸大其词的描述,或者在主页上提供“关于我们”页面的突出而明显的链接,并描述您的网站及其所提供的价值。

    有些用户可能并没有发现这个网站对他们有帮助,对此进行解释也是非常重要的,提供足够的信息来说明,这样用户就不会对网站的目的感到迷惑了。您最好提供向访问者说明为什么他或她不会对这个网站感兴趣,这样可以打发走不感兴趣的访客,这比试图欺骗他们直到他们自己花费了大量时间之后才知道网站上并没有他们所须的内容要好很多。毕竟,一个直接表明自己功能的网站要比故弄玄虚而且难以使用的网站更能获得良好的口碑和认同。

    2.Alt和Title属性的文本描述:对于支持这些属性的网站,要确保您在每个XHTML标签上都使用了alt和title属性。如果用户使用的浏览器不支持网站的图片,那么对于可访问性而言这些信息是至关重要的,同时它们还能提供主要内容之外的信息。最常见的功能是为残障人士提供可访问性,比如使用屏幕阅读器访问网站的盲人。但是,也不要在alt或者title属性中写入过多的文字,应当让这些文字简明扼要,清晰易懂。不要让您的用户淹没在大段大段的模糊信息,或是毫无用处的弹出信息中,应当让网站实现最容易访问的状态,因为alt和title标签的基本作用就是提升可访问性。

    3.对URL进行存档管理:将网站上过期的页面放到存档中是网站更新中常见的变化,但对于搜索引擎而言,会造成很大的困难,比如指向您网站中某个页面的链接失效了。因此,在构建网站之初,就要确保转移到存档部分内容的URL不会发生变化。口碑是在国际互联网上营造人气和声望的基石,如果您网站上的页面链接隔不了几天就会发生变化,那么恐怕很难赢得良好的口碑。

    4.在内容上标注日期:通常,您需要经常更新网站才能赢得回头客,人们也只有在新内容出现的时候才会来浏览网站。在内容上标注日期,这样访客才能知道那些是新的,是按照什么顺序出现的。即使在某些罕见的情况下,网站内容可能并不需要经常更新,那么即使有一个页面被重新编辑过,那么也应当反应出改变的信息。

    对网站上所有的信息加上时间戳,可以帮助您的访客确认哪些信息是过期的,即使您只在每个页面的底部加上“最后更新”的字样,也会有所帮助。而且,这不仅仅给网站的访客带来了方便,对您也是有帮助的:如果读者发现您所说和他们在别处看到的不一致是由于信息的更新引起的,那么他们会增加您网站的口碑,并且会成为回头客,愿意经常访问您的网站以获取更多的信息。

    5.内容密度:在一个位置放太多的信息会把访问者吓跑的,虽然常识告诉我们要尽可能多地提供信息,但是物极必反,好东西多了也可能会有副作用。如果提供了太多的信息,读者在阅读时很容易疲劳,然后就开始略读,最后索性不读了。

    尽量保证您的初始信息与主题密切相关,并且简短,可以被读者一次消化,同时可以提供深入信息的链接。使用符号列表是一种非常棒的方法可以将信息分解为不同的部分,从而更容易理解,这样访客也就不会被吓跑。同样的原则对链接列表也是适用的,太多的链接挤在一起和静态的杂乱无章的信息毫无区别。让链接列表短一些,这样读者可以花费很少的力气就能找到他们所需的信息。如果您能帮助他们找到所需的信息,那就会为您的网站增加额外的价值,同时还要尽量保证这些信息容易消化
    6.装饰性图片:除了一些旗帜和表明品牌的图片之外,应当尽可能少使用装饰性的图片。如果对读者有帮助,才使用图片来进行辅助说明;如果这些信息是您希望提供的内容时,才使用这些图片。不要在网站上撒满图片来进行装饰,这样会把访问者吓跑的。因此,只使用有效的图片,而不是装饰性的图片,即使使用装饰图片也不要太多。载入图片往往很慢,这延缓了读者寻找文字的时间,而且很多浏览器中或者使用屏幕阅读器的时候图片是看不到的;而另一方面,文字则是通用的。

    7.间接链接/中转链接/重定向链接:不要阻止其它网站直接链接您的网站内容,有很多大型的内容提供商违反了这一规则,比如新闻网站将其它网站引用的链接重定向,这样访问者往往停留在您的首页。使用这种笨拙的手段似乎认为强迫访问者进入首页就能让他们对其它的内容感兴趣,但实际上,这样做的结果只会让人们扫兴而走。如果寻找某一篇文章遇到了麻烦,您的客户会放弃在您的网站中寻找而跑到其它的地方。更糟糕的情况是,其它网站带来的链接可能会显著地提升您在搜索引擎中的排名,如果让这些重定向的链接失效,那么等于您在反对被人对您的网站进行链接,因此,永远不要拒绝别人对您网站的链接。

    8.最新内容:在第四个问题中,我提到了对网站内容注明日期,从而显示出内容的变化,任何定期更新的网站都应该让这些变化容易被访问者了解,最近更新部分的内容绝不能和三年前的一样,这样就无法体现出丝毫变化。

    新的内容应当保持足够的新鲜度,这样您的读者才能从中获取信息中的价值。如果您的网站更新得非常快(比如Slashdot),那么对这些信息进行分类会有所帮助,比如将新闻分门别类地存放,这样读者就能轻而易举地找到他们感兴趣的话题中最新的内容。有效的搜索功能和优秀的网站管理可以帮助读者查找他们以前曾经看到过的信息,尽可能地帮助他们实现这些功能。

    9.缩略图的尺寸:当提供有大量图片的图库时,使用链接到每张图片的缩略图是一种常见的策略。所谓缩略图就是图片的缩小版本,可以让浏览者看到众多的图片。但是,在展示缩略图时,要切记不能将缩略图做得太小,因为这样网站的访客就无法从中获取有效的信息。

    对图片文件进行按比例的裁减是非常重要的,不要使用XHTML和CSS来变更图片的大小,因为文件的尺寸是不会变化的,发送到客户端浏览器的还是这些大尺寸的版本。在载入布满缩略图的网页时,如果这些缩略图仅仅是被标记语言和样式表改变了尺寸的话,那么浏览器依然会消耗掉大量的处理器时间和系统内存资源;这可能会导致浏览器崩溃和其它的问题,至少会导致漫长的加载时间。网站的访问者会因为缓慢的加载时间转而访问其它的网站,崩溃的浏览器更会吓跑访问者。

    10.网页标题:很多网页设计者并没有为他们的网页设定标题,这明显是个错误,搜索引擎会根据网页的标题来进行识别;而且,用户在浏览器的收藏夹中存储网页地址的时候,默认的名称也是网页的标题。

    一个不太明显的错误是网站的设计者在每个页面上都使用相同的标题,如果为每个页面都提供不同的标题来进行识别,那将会非常有帮助。当然,标题应当是简洁清晰的,冗长的网页标题和没有标题的网站是一样糟糕的。

    以上的这些注意事项对网站设计来讲是非常重要的,但常常没有受到重视或是曲解了其中的要领,也许其它方面的成功可以克服一些细微的失败,但是却永远无法弥补这些缺陷。在设计网站的时候牢记这些原则,可以让您的网站获得更高的成功机会。

  • 成长是唯一的希望

    rong8674 发布于 2007-05-29 18:05:00

     只要你认为你可能,没什么不能。

        虽然有时,会有很多声音,认为你不能。

        每一次打破别人对我说的不可能(当然我先须相信我能),都是我成长的勋章。

        个人的方向盘操之在己,为什么不能?走在自己要走的路上,其实一点都不苦,最苦的是走在你不要走的路上,还得在众人推挤簇拥下到达你不要去的地方。

        对那些发誓登上喜马拉雅最高峰的人来说,沿途冰天雪地,哪里会让他们觉得苦,在他们眼中,在在都是天地晶莹,难得美景。

        你一定会听到很多质疑,如我一样……

        有一只乌鸦,嘴里衔了一块肉,碰到一只狐狸。

        狐狸对牠说,乌鸦啊,看你的羽毛黑黑亮亮的,你的歌喉必然也不差;今天天气真好,你为什么不唱歌呢?

        乌鸦难得听到有人对牠歌喉的称赞,于是牠张开嘴,肉掉了下来。狐狸一马当先抢走了。

        又有一只饿狼,在原野中遇见一条狗。狗说,你应该和我回家,我的主人不曾使我挨饿,美味的食物、香喷喷的澡从没缺过。狼有点心动。可是在这时,牠看见狗脖子有伤痕。狗说,没什么,早上我的主人牵我散步时,把我拉伤了。狼说,哈,我还是过我那餐风露宿的日
    子好了。

        先问自己,你嘴里衔了什么?还有你喜不喜欢被主人牵着走?如果你们真那么功利,那么看得起自己比别人看得起会更「有用」些。

        舒曼曾说,只有小提琴,组织不了一整个管弦乐团。这个世界因个人所爱不同,灿烂美丽。
     
        我知道我爱,所以可能。在自己的路上选其所爱,爱其所选,选错了跌伤了再爬起来,就是成长。

        成长是唯一的希望。

        别人可能打击你。反正死狗是没人踢的。难以应付的是自己打击自己。

        人很奇妙。当事情多能「操之在我」时,偏偏打击自己,事情明明「操之在他」时,又不服气,又怨天尤己,比如爱情。

        爱是X+Y所产生的变量。我们偏要主宰,偏以为自己的意志就是命运的注定,偏要连别人手中的方向盘也要牢牢握住,尽管你根本不知道,这有两个方向盘的车要开去哪里。

        不信自己能操控自己的未来,竟如此渴求自己能操控爱情,真是人性的吊诡。

        一个阻碍成长的感情不是真爱,只是控制欲这个怪兽变出的异形。多少扼杀成长的刀斧,假爱之名。

        在爱中,或在失去爱的时候,在频遭冷嘲热讽的低潮期别忘了,你认为你可能。

        至少你会继续成长,即使,未必成功。

        成长本身就是生命最丰厚的犒赏。
  • QTP脚本的学习

    Lola1123 发布于 2007-06-11 16:48:19

    空闲的时候就学习如何编写QTP脚本,今天学了一天,头都大了,有没有什么好的方法,有经验的朋友分享一下经验啊;我能看懂脚本但自己写下来就麻烦了.

    QTP专家视图中使用的是VBscrīpt,大家可以查看一些关于VB的使用来帮助理解QTP专家视图中的脚本。
    在此提供一些向导性说明和注意事项,希望队大家有帮助。
    1 VBscrīpt是不区分大小写的,比如,两行语句的作用是相同的。
    Browser("Browser").page("Page").webButton("Login").click
    Browser("Browser").Page("Page").WebButton("Login").Click
    2 字符串常量一定要用双引号“”引起来,比如,
    Browser("Browser").Page("Housing Contract Def").WebEdit("txtCompoundName").Set "测试"
    其中“测试”,是字符串常量,如果用数字常量,则不需要引号;
    3 使用变量,要先定义
    普通类型的变量,使用Dim语句定义,格式Dim 变量名 (as 变量类型),比如
    Dim num as int
    num=Browser("Browser").Page("HousingContractDef").WebList("lstCity").GetROProperty(Property)
    如果要指定一个用于存储对象的变量,则使用Set语句,比如,
    Set UserEditBox=
    Browser("Browser").Page("HousingContractDef").WebEdit("txtCompoundName")

    UserEditBox.set "特色体能"
    4 使用括号的规则,一般如下:
    如果想调用一个方法的返回值,那么这个方法的参数必须用括号括起来。比如,
    (1)Set WebEditObj = Browser("Mercury Tours").Page("Method of Payment").WebTable(FirstName).ChildItem(9,3,"WebEdit",0)
    WebEditObj.Set "Example"

    (2)call 语句中,Action的参数列表需要用括号括起来,
    Call RunAction("BookFlight",oneIteration)

    (3)Check 方法的返回值,所以check方法的参数CheckPoint("MyProperty")必须要用括号括起来。
    a = Browser("MyBrowser").Page("MyPage").Check(CheckPoint(MyProperty))

    (4)Click方法不用括号,因为不需要返回值;
    Browser("Browser").Page("Page").WebButton("Login").Click
    5 控制语句的使用
    If ...Then...Else, For...Next,Do...Loop

    6 实例解析
    (1)Browser("Browser").Page("Housing Contract Def").WebEdit("txtCompoundName").Set "testing"
    Browser("Browser")表明这个浏览器测试对象的名字为Browser;
    Page("Housing Contract Def")表明当前页的名称是Housing Contract Def;
    WebEdit("txtCompoundName")表明当前被操作的对象是一个WebEdit类型的对象,
    它的名称txtCompoundName;
    Set "testing" 表明要将txtCompundName这个WebEdit对象设置的值设置为“testing”;

    (2)在写脚本的时候,键入了一个对象的类型Browser(,系统就会自动列出对象仓库中所有Browser类型对象供用户选择;如果此时对象仓库中只有一个对象,就会直接输入该对象;
    (3)在一个对象后面,输入一个表示层次关系的点号(.),系统就会自动列出该对象的所有属性和方法信息;
    (4)如果键入的方法包含参数,那么在输入完这个方法的名称后,QTP会以tip的形式给出方法后面的参数列表。比如,select方法,当键入Browser("Browser").Page("Housing Contract Def").WebList("lstSex").Select后,系统会自动显示select(items)信息。

    (5)Data Table 参数化语法:
    Object_Hierarchy.Method DataTable(ColumnName,SheetID)
    Object_Hierarchy指对测试对象的层次定义,层次对象之间用.号分隔;
    Method 指对被操作对象使用的方法,比如,select;
    DataTable指的是要从DataTable 中获得数据;
    ColumnName,指的是DataaTable中提供数据的列的名称;
    SheetID:指数据所属的sheet,如果使用一个全局参数,则sheetID为dtGlobalSheet.
    Data Table的应用说明:比如,在Mercury Tours系统中,航班的选择时,有出发地——目的地,录制一次只能选择一个出发地和一个目的地;如果想测试起始和目的地为其它城市时,系统是否能正常运行,无需在进行录制,只需对出发地(fromPort)和目的地(ToPart)进行参数化即可。
    以ToPart为例说明————参数化前的语句:
    Browser("Welcome:Mercury Tours").Page("Find a Flight:Mercury").Weblist("ToPart").select"London"
    参数后的语句:
    Browser("Welcome:Mercury Tours").Page("Find a Flight:Mercury").Weblist("ToPart").select DataTable("ToPart",dtGlobalSheet)










  • 软件测试类型知多少?

    sanwong823 发布于 2007-04-14 13:11:16

    软件测试类型知多少?

    软件测试的类型多种多样,测试类型与被测软件的测试需求相关。对于初学者,需要了解最常见的测试类型,也有必要了解其他的测试类型,作为进一步提高的目标。 

    以下转载了比较齐全的测试类型,请那位朋友帮助把全文翻译一下。

    • 黑盒测试(Black box testing)
      • not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
    • 白盒测试(White box testing)
      • based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.
    • 单元测试(unit testing)
        
      • the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.
    • 增量集成测试(incremental integration testing)
      • continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
    • 集成测试(integration testing)
      • testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
    • 功能测试(functional testing)
      • black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)
    • 系统测试(system testing)
      • black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
    • 端到端测试(end-to-end testing)
      • similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
    • 健全测试或冒烟测试(sanity testing or smoke testing)
      • typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.
    • 回归测试(regression testing)
      • re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.
    • 验收测试(acceptance testing)
      • final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
    • 负载测试(load testing)
      • testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.
    • 压力测试(stress testing)
      • term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
    • 性能测试(performance testing)
      • term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
    • 易用性测试(usability testing)
      • testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
    • 安装/卸载测试(install/uninstall testing)
      • testing of full, partial, or upgrade install/uninstall processes.
    • 恢复测试(recovery testing)
      • testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
    • 故障复原测试(failover testing)
      • typically used interchangeably with 'recovery testing'
    • 安全性测试(security testing)
      • testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
    • 兼容性测试(compatability testing)
      • testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
    • 探索性测试(exploratory testing)
      • often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
    • 随机测试(ad-hoc testing)
      • similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
    • 上下文驱动测试(context-driven testing)
      • testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
    • 用户验收测试(user acceptance testing)
      • determining if software is satisfactory to an end-user or customer.
    • 对比测试(comparison testing)
      • comparing software weaknesses and strengths to competing products.
    • Alpha 测试(alpha testing)
      • testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
    • Beta测试(beta testing)
      • testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
    • 植入测试(mutation testing)
      • a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

    原始出处:http://www.softwareqatest.com/qatfaq1.html

  • [转] 软件测试常识

    sanwong823 发布于 2007-05-06 12:02:44

    [转]软件测试常识

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。
     
    此文来源于51testing博客,转载请注明出处

  • [转] 无忧测试论坛《每日一帖》

    sanwong823 发布于 2007-05-10 22:19:11

    无忧测试论坛《每日一帖》5月份精华

    http://www.51testing.com/Integ/20041227_1.htm

     

    来自 http://www.51testing.com 这是论坛版主天网每天提供给测试网友的精神食粮,感谢天网

    1 帖【 2004 5 10 】:软件测试的理想模式是什么?

    Brian Marick :我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效,而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组,他们不可能有时间把所有测试都做好。所以,最佳的方式是让开发人员承担一定量的测试,独立测试组给予他们支持。独立测试组主要承担整个系统的测试,去寻找开发人员还没有发现的缺陷,如子系统间的交互、运行条件、内存使用等。

    如何更有效地开展系统测试呢?让测试人员在项目初期就参与进去,让他们看到第一版的系统需求、用户手册和系统原型,在系统实现前就对需求进行捕获和跟踪。在该过程中,他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行,并且在该过程中会发现一些缺陷。大家都知道,这个阶段,问题发现是非常 “ 便宜 ” 的。

    这样,系统测试工程师在项目早期就介入,产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计,因为书写完整测试的条件还不成熟,但这却是构建完整测试的基础。

    注: Brian Marick 是 Reliability Software 公司的专职测试技术顾问。

    2 帖【 2004 5 11 】:测试经理角色定位

    Johanna Rothman :测试经理服务于两种完全不同的客户:测试工程师和高层管理者。对于测试工程师,测试经理帮助他们开发产品测试策略,积累产品测试经验并在测试组内充分共享。对于高层管理者,测试经理搜集尽可能全面的产品信息,供其就产品是否可以发布进行决策。但是有一点是相同的:无论是对于测试工程师还是高层管理者,测试经理将帮助其定义和校验产品发布标准。

    产品发布标准的定义和校验:作为一个测试经理,应该找机会与市场、开发人员商讨产品发布标准,并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望,要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义,就可以通过测试去验证产品在多大程度上满足了客户需求。

    对于测试工程师而言有一点非常重要:将测试任务按优先级划分,使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情,所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。

    高层管理者需要充分理解产品发布标准,以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布,该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后,项目组也可以更清楚地了解和认识产品质量。

    3 贴【 2004 5 12 】:测试的基本原则

    (美) Roger S. Pressman
    在设计有效测试用例之前,测试工程师必需理解软件测试的基本原则。这里有一组测试原则:
    1 、所有的测试都应追溯到用户需求。正如我们所知:软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。
    2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。因此,所有测试应该在任何代码被产生前就进行计划和设计。
    3 、 Pareto 原则应用于软件测试。简单地讲, Pareto 原则暗示着测试发现的错误中的 80 %很可能起源于程序模块中的 20 %。当然,问题在于如何孤立这些有疑点的模块并进行彻底的测试。
    4 、测试应从 “ 小规模 ” 开始,逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找错误,最后在整个系统中寻找错误。
    5 、穷举测试是不可能的。即使是一个大小适度的程序,其路径排列的数量也非常大。因此,在测试中不可能运行路径的每一种组合。然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。
    6 、为了达到最佳效果,应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试(测试的主要目标),所以创建系统的软件工程师并不是构造软件测试的最佳人选。

    4 贴【 2004 5 13 】:什么是 的测试?

    什么是 “ 好 ” 的测试? Kaner , Falk & Nguyen
    1 、一个好的测试发现错误的可能性很高
    为了达到这个目标,测试者必需理解软件、并尝试设想软件如何才能失败,例如:在 GUI (图形用户界面)中有一种潜在的错误,即错误识别鼠标位置,那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
    2 、一个好的测试并不冗余
    测试的时间和资源是有限的,没有必要构造一个与其他测试用例完全相同的测试,每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如,软件 SafeHome 中有一个模块被用来识别用户密码以决定是否启动系统,为了测试密码输入的错误,测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码( 4 个数字),然而,每一个有效 / 无效密码将只检测一种不同错误模式,例如一个将 8080 作为有效密码的系统将不会接受非法密码 1234 ,如果接受 1234 ,将产生错误,另一个测试输入 1235 ,与 1234 的测试意图相同,因此是冗余的,然而,非法输入 8081 或 8180 就有些细微的差异,即对与有效密码相近但并不相同的密码应该进行测试。
    3 、一个好的测试应该是 “ 最佳品种 ”
    在一组目的相似的测试中,时间和资源的限制可能只影响其某个子集的执行,此时,应该使用最可能找到所有错误的测试。
    4 、一个好的测试既不会太简单,也不会太复杂
    虽然有时会将一组测试组合到一个测试用例中,其副作用可能屏蔽错误,通常每一个测试应该独立执行。

    5 贴【 2004 5 14 】:软件可测试性

    Roger S. Pressman
    理想情况下,软件工程师在设计计算机程序、系统或产品时应该考虑可测试性,这就使得测试工程师能够更容易地设计有效的测试用例。

    什么是 “ 可测试性 ” ?软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提下,进行测试设计、测试执行的能力。 James Bach 这样描述可测试性:软件可测试性就是一个计算机程序能够被测试的容易程度。

    以下是一个常见的软件可测试性检查表:
    · 可操作性- “ 运行地越好,被测试的效率越高。 ”
    · 可观察性- “ 所看见的,就是所测试的。 ”
    · 可控制性- “ 对软件的控制越好,测试越能够被自动执行与优化。 ”
    · 可分解性- “ 通过控制测试范围,能够更好地分解问题,执行更灵巧的再测试。 ”
    · 简单性- “ 需要测试的内容越少,测试的速度越快。 ”
    · 稳定性- “ 改变越少,对测试的破坏越小。 ”
    · 易理解性- “ 得到的信息越多,进行的测试越灵巧。 ”

    6 贴【 2004 5 15 】:实时系统测试

    Roger S. Pressman

    很多实时系统的时间依赖性和异步性给测试带来新的困难--时间!测试用例的设计者考虑的不仅是白盒和黑盒测试用例,而且包括事件处理(如中断处理)、数据的时间序列以及处理数据的任务(进程)的并发性。很多情况下,提供的测试数据有时使得实时系统在某状态下可以正常运行,而同样的数据在系统处于不同状态时有时又会导致错误。

    另外,实时系统的软件和硬件之间的密切关系也会导致测试问题,软件测试必须考虑硬件故障对软件处理的影响,这种故障很难实时仿真。由于实时系统的特殊性和复杂性,还没有一个完善的综合性的测试用例设计方法,但是,大致可以分为以下四个步骤:

    1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例,并在测试时执行每个任务。任务测试能够发现逻辑和功能错误,但是不能发现时间和行为错误。

    2 、行为测试。利用 CASE 工具创建软件模型,就可能仿真实时系统,并按照外部事件的序列检查其行为,这些分析活动可作为创建实时系统时设计测试用例的基础。

    3 、任务间测试。在隔离了任务内部和系统行为错误以后,测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务,看任务间的同步是否会产生错误。另外,测试通过消息队列和数据存储进行通讯的任务,以发现这些数据存储区区域大小方面的错误。

    4 、系统测试。集成软件和硬件,并进行大范围的系统测试,以发现软件 / 硬件接口间的错误。

    7 贴【 2004 5 16 】:单元测试、集成测试、系统测试、验收测试、回归测试

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

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

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

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

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

    8 贴【 2004 5 17 】:软件测试策略

    Roger S. Pressman
    测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因,应当为软件工程过程定义一个软件测试的模板-我们可以把特定的测试用例方法放置进去的一系列步骤。

    人们已经提出了许多软件测试策略,所有这些策略都为如开发人员提供了一个供测试用的模板,而且它们都包含下列的类属特征:
    · 测试开始于模块层,然后 “ 延伸 ” 到整个基于计算机的系统集合中。
    · 不同的测试技术适用于不同的时间点。
    · 测试是由软件的开发人员和(对于大型系统而言)独立的测试组来管理的。
    · 测试和调试是不同的活动,但是调试必须能够适应任何的测试策略。

    软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试,同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南,并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的,所以测试的进度必须是可测量的,而且问题要尽可能早的暴露出来。

    9 贴【 2004 5 18 】:白盒测试

    Rex Black
    白盒测试,也称为结构化测试、基于代码的测试,是一种测试用例设计方法,它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够:
    1 )保证一个模块中的所有独立路径至少被使用一次;
    2 )对所有逻辑值均需测试 true 和 false ;
    3 )在上下边界及可操作范围内运行所有循环;
    4 )检查内部数据结构以确保其有效性。

    “ 我们应该更注重于保证程序需求的实现,为什么要花费时间和精力来担心(和测试)逻辑细节? ” 答案在于软件自身的缺陷:
    1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时,错误往往开始出现在我们工作中。日常处理往往被很好地了解,而 “ 特殊情况 ” 的处理则难于发现。
    2 、我们经常相信某逻辑路径不可能被执行,而事实上,它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的,这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误,只有路径测试才能发现这些错误。
    3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时,有可能产生某些笔误,很多将被语法检查机制发现,但是,其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。

    正如 Beizer 所说的: “ 错误潜伏在角落里,聚集在边界上 ” ,而白盒测试更可能发现它。

    10 贴【 2004 5 19 】:黑盒测试

    黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误:
    1 )功能错误或遗漏;
    2 )界面错误;
    3 )数据结构或外部数据库访问错误;
    4 )性能错误;
    5 )初始化和终止错误。

    白盒测试在测试的早期采用,而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构,而是注意信息域。黑盒测试用于回答以下问题:
    1 )如何测试功能的有效性?
    2 )何种类型的输入会产生好的测试用例?
    3 )系统是否对特定的输入值尤其敏感?
    4 )如何分隔数据类的边界?
    5 )系统能够承受何种数据率和数据量?
    6 )特定类型的数据组合会对系统产生何种影响?

    运用黑盒测试方法,可以导出满足以下标准的测试用例集:
    1 )所设计的测试用例能够减少达到合理测试所需的附加测试用例数;
    2 )所设计的测试用例能够告知某些类型错误的存在或不存在,而不是仅仅与特定测试相关的错误。

    11 贴【 2004 5 20 】:软件测试充分性准则

    ( 1 )空测试对任何软件都是不充分的。
    ( 2 )对任何软件都存在有限的充分测试集合。
    ( 3 )如果一个软件系统在一个测试数据集合上的测试是充分的,那么再多测试一些数据也应该是充分的。这一特性称为单调性。
    ( 4 )即使对软件所有成分都进行了充分的测试,也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
    ( 5 )即使对一个软件系统整体的测试是充分的,也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
    ( 6 )软件测试的充分性应该与软件的需求和软件的实现都相关。
    ( 7 )软件越复杂,需要的测试数据就越多。这一特性称为复杂性。
    ( 8 )测试得越多,进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

    12 贴【 2004 5 21 】:静态测试

    在软件开发过程中,每产生一个文档,都必须对它进行测试,以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的,也与项目管理过程相一致。每当一个文档通过了静态测试,就标志着一项开发工作的总结,标志着项目取得了一定的进展,进入了一个新的阶段。

    静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试,是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段,由于可运行的代码尚未产生,不可能进行动态测试,而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小,因此,在这些阶段,静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上,人们总结出了一些行之有效的静态测试技术和方法,如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合,对软件开发过程进行监视、控制,从而保障软件质量。

    13 贴【 2004 5 22 】:什么是测试需求?

    Brian Marick
    测试需求的概念比较简单。例如,比方说一个计算平方根的程序,如果输入一个大于或等于零的数,程序可以给出一个结果;如果输入一个小于零的数,程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试;对零非常接近的负数进行测试,这就是两个具体的测试需求。

    在一个更加复杂的程序中,你可以将打算测试的项目做成一个列表。但是,这些测试需求都不会确定具体的测试数据。例如,一个银行交易程序,一个测试需求是试图支付客户的金额为负数,另一个测试需求是交易中的客户并不存在,等等。你有一系列这样的测试需求,它们并没有指出具体的数值或数据,如客户的姓名。

    测试的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求,当然是最理想的情况,但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例,就可以不必考虑那些复杂的测试用例,但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

    这里有一个测试需求的实例:对一个哈希表的插入操作进行测试,有以下这些测试需求:
    1 )插入一个新的条目
    2 )插入失败-条目已经存在
    3 )插入失败-表已满
    4 )哈希表在插入前为空
    这些就是测试需求,而非测试用例,因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例,就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审,确保正确和没有需求遗漏。

    14 贴【 2004 5 30 】: GUI 测试

    Roger S. Pressman

    图形用户界面( GUI )对软件测试提出了有趣的挑战,因为 GUI 开发环境有可复用的构件,开发用户界面更加省时而且更加精确。同时, GUI 的复杂性也增加了,从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似,所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南:

    窗口:
    · 窗口是否基于相关的输入和菜单命令适当地打开?
    · 窗口能否改变大小、移动和滚动?
    · 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问?
    · 当被覆盖并重新调用后,窗口能否正确地再生?
    · 需要时能否使用所有窗口相关的功能?
    · 所有窗口相关的功能是可操作的吗?
    · 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用,并适当地显示?
    · 显示多个窗口时,窗口的名称是否被适当地表示?
    · 活动窗口是否被适当地加亮?
    · 如果使用多任务,是否所有的窗口被实时更新?
    · 多次或不正确按鼠标是否会导致无法预料的副作用?
    · 窗口的声音和颜色提示和窗口的操作顺序是否符合需求?
    · 窗口是否正确地被关闭?

    下拉式菜单和鼠标操作:
    · 菜单条是否显示在合适的语境中?
    · 应用程序的菜单条是否显示系统相关的特性(如时钟显示)?
    · 下拉式操作能正确工作吗?
    · 菜单、调色板和工具条是否工作正确?
    · 是否适当地列出了所有的菜单功能和下拉式子功能?
    · 是否可以通过鼠标访问所有的菜单功能?
    · 文本字体、大小和格式是否正确?
    · 是否能够用其他的文本命令激活每个菜单功能?
    · 菜单功能是否随当前的窗口操作加亮或变灰?
    · 菜单功能是否正确执行?
    · 菜单功能的名字是否具有自解释性?
    · 菜单项是否有帮助,是否语境相关?
    · 在整个交互式语境中,是否可以识别鼠标操作?
    · 如果要求多次点击鼠标,是否能够在语境中正确识别?
    · 光标、处理指示器和识别指针是否随操作恰当地改变?

    数据项:
    · 字母数字数据项是否能够正确回显,并输入到系统中?
    · 图形模式的数据项(如滚动条)是否正常工作?
    · 是否能够识别非法数据?
    · 数据输入消息是否可理解?

    15 贴【 2004 5 31 】: Client/Server 测试

    Roger S. Pressman

    通常,客户 / 服务器软件的测试发生在三个不同的层次:
    ( 1 )个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行;
    ( 2 )客户端软件和关联的服务器端应用被一起测试,但网络运行不被明显的考虑;
    ( 3 )完整的 C/S 体系结构,包括网络运行和性能,被测试。

    下面的测试方法是 C/S 应用中经常用到的:
    应用功能测试 —— 客户端应用被独立地执行,以揭示在其运行中的错误。
    服务器测试 —— 测试服务器的协调和数据管理功能,也考虑服务器性能(整体反映时间和数据吞吐量)。
    数据库测试 —— 测试服务器存储的数据的精确性和完整性,检查客户端应用提交的事务,以保证数据被正确地存储、更新和检索。
    事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性,也关注性能问题。
    网络通信测试 —— 这些测试验证网络节点间的通信正常地发生,并且消息传递、事务和相关的网络交通无错的发生。

数据统计

  • 访问量: 11032
  • 日志数: 10
  • 建立时间: 2007-05-18
  • 更新时间: 2007-07-12

RSS订阅

Open Toolbar