发布新日志

  • 软件测试用例的认识误区

    2007-05-11 09:03:15

    软件测试用例的认识误区

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • IT企业薪酬结构一览

    2007-05-10 09:56:48

    我国IT企业72.7%的员工对目前薪酬基本满意。但总体对薪酬的满意度低于社会服务、房地产、公用事业、制造业等行业。大多数IT企业实行对不同类别人员采取不同薪酬结构分类管理模式(74.1%),没有采取的占25.9%。
      IT企业的薪酬结构构成
      技术人员的薪酬结构构成情况:岗位工资68.1%,技能工资17.6%,各种津贴3.4%,奖金10.9%;
      销售人员的薪酬结构构成情况:岗位工资30.8%,各种津贴14%,奖金14.1%,佣金33.2%,长期激励7.9%;
      技术、销售以外人员的薪酬结构构成:岗位工资66.5%,各种津贴19.6%,奖金10.1%,长期激励3.8%。
      目前企业采用的薪酬结构主要还是突出直接薪酬,需要加大间接薪酬的作用,保证薪酬结构体系趋向合理,从而更好发挥薪酬激励的导向作用。
      IT企业的工资收入构成
      近半数IT企业技术人员的固定工资占其收入60%以上:占80%以上企业的比例是20.1%,60~80%的企业的比例是37.1%,40~60%的企业比例的是22.6%,20~40%企业的比例是17.0%,20%以下企业的比例是3.2%;
      近半数IT企业销售人员固定工资占其收入40%以下:占80%以上企业的比例是6.5%,占60~80%的企业的比例是18.1%, 36.8%的企业的该比例在40~60%之间,20~40%企业的比例是23.9%,20%以下企业的比例是14.7%;
      多数IT企业技术、销售人员以外人员固定工资占其收入60%以上:占80%以上企业的比例是41.4%,60~80%的企业的比例是16.6%,40~60%、20~40%和20%以下的企业比例分别是16.5%、14.0%和11.5%;
      长期激励的主要形式
      股票、股票期权、虚拟股票和其他,其比例分别是:10.3%、25.5%、25.5%和38.7%。
      平均工资水平
      IT企业的工资水平,高于我国企业员工人均收入水平。
      IT从业人员的月薪在3000元以下,为48.3%,而在8000元以上的较高收入仍是少数,比例为11.5%。其中以软件测试人员和软件开发人员的薪水最高,由一年到两年经验的平均月薪在6000左右。
      对知识型员工比较集中的IT行业来说,在保障他们生活的物资需求得到满足后,对他们进行长期激励最有效、最持久的方式可能还是间接的薪酬,如提高企业的社会声望,促成员工个人自我价值的实现,营造公平、公正的组织环境、客观评价一个人的贡献等都是较好的薪酬激励的有效方式。为了实现在这一理念基础上建立起来的薪酬体系,企业必须考虑自身的发展战略,考虑员工的发展,以此树立良好的社会知名度来吸引和留住人才。
      确定工资标准的主要依据
      “参照同类企业经验数据”、“根据本公司历史水平”、“主管机构规定的标准”、“参照薪酬调查结果”和“公司财务状况”,其具体比例依次为:46.1%,16.4%,12.1%,10.3%和15.1%。缺乏建立在岗位评价基础上,考虑组织内部岗位间的相对价值进行的工资设计,可能影响报酬体系的客观和公平化。
      启示:薪酬管理是人力资源管理的重要内容,一个企业如果没有好的薪酬制度,将无法吸引和留住优秀的员工,在众多的激励方式中,薪酬对人的激励最为直接也最为有效,因而常常成为激活人力资源和建立与发展战略一致的人力资源管理制度体系的突破口
  • 网页技术的一些名词

    2007-04-20 09:40:26

    有一些朋友对网页技术的知识了解不是很多,对一些名词常常混淆。下面总结一下:

    1、Java、Javascrīpt和Jscrīpt。
    首先,这三者没有必然的联系,它们是完全不同的事物,它们是分别由不同公司开发的,在函数方面有相同的地方,也有很多不同之处。Java是由Sun公司创立、开发;Javascrīpt则是Sun和Netscape公司共同开发的产品;Jscrīpt是微软对ECMA262语言规范的一种实现。这三者的共同点是,语法与C语言相似。JS是Javascrīpt的简称。
    Jscrīpt应用于ASP,运行于服务器端。而Java、Javascrīpt都是运行于客户端。Sun公司后来又推出了JSP,以Java语言为基础,运行于服务器端。运行于服务器端的网页是动态网页,所以以Jscrīpt为基础的ASP、以Java为基础的JSP是动态网页,而Java、Javascrīpt则是静态网页。

    2、静态网页、动态网页。
    程序是否在服务器端运行,是重要标志。在服务器端运行的程序、网页、组件,属于动态网页,它们会随不同客户、不同时间,返回不同的网页,例如ASP、PHP、JSP、ASP.net、CGI等。运行于客户端的程序、网页、插件、组件,属于静态网页,例如html页、Flash、Javascrīpt、VBscrīpt等等,它们是永远不变的。

    3、VB和VBscrīpt。
    有少部分朋友把VBscrīpt称为VB,这是错误的。VB是Visual Basic的简称,应用于软件开发。VBscrīpt是Microsoft Visual Basic scrīpting Edition的简称,应用于客户端Web页,或者服务器端ASP页(ASP语言以VBscrīpt或Jscrīpt为基础)。VB和VBscrīpt共同点是语法、函数相同,由微软开发。
    通常,VBscrīpt简称为VBS。可惜现在一些网页病毒就是使用VBscrīpt脚本。

  • 面试建议

    2007-04-19 17:03:13

    开始之前务必记住:
      黄金法则:80/20---你要承担起80%的谈话而面试官只会说20%。
      白金法则:你必须试着控制面试的节奏和话题。
      钻石法则:对于没有把握的问题,抛回给面试官。
      
      1. 在一分钟内介绍一下你自己
      这似乎是必答题。不要以为这很容易。如果你用一分钟来重复你的简历,恭喜你,你的印象加分没有了!建议你最多用二十秒钟介绍自己的姓名、学校、专业。然后话锋一转,引出自己的优势或强项。一定要在最短时间内激发起面试官对你的好感,或者至少是兴趣。
      成功的模式可以是:我叫XXX,英文名字XXX,XX省XX市人,今年6月将从XX学校XX专业本科(专科)毕业。除了简历上您看到的介绍,我愿意特别说一下我在XXX方面的特长/我最大的特点是……(给出事例)。正是基于对自己这方面的自信,使我有勇气来应聘贵公司的XXX这一职位。(看表)一分钟到了,希望我没有超时。(很阳光的微笑)
      如果面试官不是EQ太低,你的最后一句话应该会使他放松和微笑。资历嫩一点的还会接着问:“为什么你会这么认为呢?”如果他真的这么问你,Bingo!你完全有机会操纵这次面试!
      2. 应届生经常会被问到的一个问题是:你为什么会选择你目前学习的专业呢?千万当心,这个问题的目的是考察你的Decision Quality这一项胜任力,所以不要简单的说“感兴趣”或者“就业前景乐观”等。给大家一个成功的范例(同样适用于诸如‘您所做过的一个成功/最大的决定是什么”):
      问:张先生,您为什么会选择财务专业呢?
      答:的确,财务已经连续多年成为高校热门专业,这造成了就业时无可避免的激烈竞争。可当初我选择财务专业时并不是单纯因为它的热门程度。我早就把就业目标锁定在苏州工业园区的外资企业。根据我高三时搜集到的统计资料,园区当时有外企XXX家,而且每年以XXX%的速度在增加。以每个公司财务部至少5个人计算(总账,应收应付,税务,出纳再加上一个经理),加上园区的平均离职率是15%,则在我毕业时,可以有XXX个空缺。我毕业那年应该全国有XX相关专业的毕业生。其中可能有10%会瞄准苏州,而我填报的苏州大学在当地口碑尚可,属于中等偏上。那么,有1/2的对手能被我淘汰。再加上我就在苏州本地学习,四年中可以更早的寻求机会,所以,我很有信心的选择了这个专业。
      其实,没有哪个面试官会相信你真的作过如此缜密的调查分析,但你已经展示了你做决策时的思路,所以可以加分。
      记住:所有的回答要符合你专业的特点。不要说得太到位,可以自圆其说就行了,不然,他们会觉得你要么太虚伪,要么太狂妄。还有,应该表示对自己的专业的确感兴趣,或者增加点戏剧效果:我本来理解的财务管理就是管账,所以开始的时候还真后悔了一阵,直到大三时开始了在企业的实践,才有了改观,并真正喜欢上了我的专业。这样显得真实可信,更重要的是,很自然的由你引导到准备好的问题:实习的收获。
      
      3. 为了考察您Learning on the Fly这一条胜任力,通常我们会问您在实习期间的收获。此时,不要夸大自己的成绩,谦虚一点。还有,不妨说一下自己的失误(不用怕,毕竟你是在实习)。记住:详细说明当时的情况(Situation),你要达到的目的(Task),你采取了哪些步骤(Actions),事情的结果(Result),还有你得到的经验教训(Lesson learned)以及后来怎样运用到工作中避免犯类似的错误。最后做出总结:原来书本上的知识要能够在工作中熟练运用,这期间还有很长的一段路要走。还可以说:回到学校后,我对自己的实习经历作了一番总结,发现自己在XXX方面还需要加强。所以,我很注意利用大学的最后一个学期来弥补这一不足。现在,我对自己很有信心,如果时间能够倒流,我相信我能做到更好。
      
      4. 你有过和别人合作的经历吗?(千万要回答“有”)那么,在这过程中,你是如何处理意见分歧的呢?现在是考察你的Conflicts Management。现在的绝大部分企业都不欣赏没有原则的老好人。所以,你要把自己包装得强势一些。
      我本人比较满意的回答:
      每个人在团队中都应该可以自由坦诚地发表意见,我会非常认真的聆听,分析;但对于自己的意见我不会没有原则的轻易放弃。民主过后还需要集中。我是学校英语俱乐部的主席,在组织校际年度联欢时,有两个干事的意见和我不一致。(停顿一下,让面试官记住你的这个闪光点)我和他们开了会。大家都阐述了各自的理由。很遗憾,我仍然没有说服这两人。在这种情况下,我感谢他们的积极参与,但表示仍然会采用我的方案。我的理念是:Meeting 不等于Voting,完全不需要少数服从多数;我是负责人,我相信自己有能力采取最佳方案;假如失败了,我也会承担主要责任。而如果我是团队的普通一员,我会保留自己的意见,但还是认真执行管理者已经做出的决策。当然,学校毕竟不同于公司,情况会更加复杂,但我坚信,只要遵循“对事不对人”的原则,任何问题都可以得到解决。
      在回答时,一定要眼睛看着面试官,微笑,以冲淡你的咄咄逼人。
      
      如果你实在没有把握,可以把问题抛还给面试官,试举一例(还是同样的问题):
      问:你是如何处理意见分歧的呢?
      答:您问的恰好也是我最困惑的一点,而学校里老师从来不给我们这样的指点。一方面,我不想做没有原则的老好人,另一方面,大家都是朝夕相处的同学,我不想让他们觉得我盛气凌人。我当时是这样做的:…… 可一直到现在,我都不知道是否作的正确,也许我可以从您那里得到一些指教,您说我当时这么做有问题吗?
      如果对方马上对你言传身教,那他铁定是菜鸟,你不用紧张了,因为,合理的反应应该是不置可否的说:其实这个问题永远不会有标准答案。




    to: 我凝视你的侧脸
        谢谢您的帮助。我在今年下半年面试比较多的单位,但是一些有分量,自己又想进去的企业往往与自己擦肩而过。自己觉得本人的表达能力方面还比较有信心,而且与人交往方面能够表现出比较出色。所以自己的职业规划是做化工行业的销售工程师(本人化学小硕)。在面试的时候经常会遇到这样的问题,让我有点棘手,感觉回答的也不好。希望您给我帮助。
        
        1.说说您的缺点
        虽然很多人说“自己刚毕业,没有经验”,但本人觉得太俗了,一直没有找到更加好的回答方式。
        
        2.硕士毕业来做销售,你觉得很划算?
        我一般是结合自己的性格和兴趣来回答的,不知道您有更好的回答否?
        
        3.我觉得你的非常善谈,但有什么时候与人交流的时候产生不和谐?
        我觉得很头疼这个问题。
        
        希望楼主您给我解答。
        在此谢谢了
      -------------------------------
      1是很实际的一个问题。许多人在被问及自己的缺点时,常常本能的采用“自我保护”的姿态,生怕说错话,于是就有了“我最大的缺点就是工作太投入,不注意休息”这样的笑话。其实,这样的问题很好打发:说一些由于年龄或社会经验不足而导致的缺点,或者是因为级别不够高而无奈的缺点。因为,随着时间的推移,经验的积累和级别的提升,这些缺点都会消失。举例如下:
      问:说说您的缺点,好吗?
      答:缺点每个人都有很多。我不会说什么“我最大的缺点就是工作太投入,不注意休息” (笑,纯真或爽朗的笑,视对方反应而定)。我最大的缺点就是面对高层管理者时会无比紧张,异乎寻常的紧张,有时甚至会语无伦次甚至失语。明明没有犯错误,也会脸红心跳。我猜想这是在学校老师恐惧症的延续吧。(注意这最后一句话,足以使面试官原谅你的这一缺点)。我的另一个缺点是不会或者说是没有勇气说NO。从实习开始就是这样,即使自己已经是超负荷了,对于别人的要求,不管是上司还是同级,都仍然会答应下来,而我又是有了一点小事就会睡不着的人,所以不得不常常开夜车把事情做完;而别人发现每次我都能完成任务,就认为我还有余力,就又交给我新的任务……
      
      问题2 硕士做销售,你从兴趣上着手,应该可以。还能在“硕士”学历的理解上可以做文章。例如:我从不认为硕士在能力上肯定会比本科生强,也不认为理所当然比本科生高一个级别。我一直认为,三年的硕士研究生经历,最大的收获是自己的学习能力和实际运用能力的极大提高。同样是应届生,我会更沉着,更周详,更自信。
      
      3 在人际沟通上是否曾经有过不和谐?“有,肯定有!其实我这个人很容易和别人相处,因为我会换位思考,以此来理解他人。但是!如果遇到价值观和我有抵触的人,我会无法容忍,可能会不能进行有效沟通。我最痛恨三种人:说话言而无信;做事虎头蛇尾;妄想不劳而获。这种人已经触犯到我的原则底线。当然,我不会拂袖而去,但实在不愿敷衍。也许这就是还不够世故圆滑吧。我很矛盾,不知道该做怎样的拿捏与平衡。”
      明白了吗?这是我自己第一次面试时回答的答案。自己觉得有4个优点:1 说明沟通不畅的根本原因不在你 2 表示你涉世未深,还很纯真 3 show了一下你的人格魅力 4 表明你愿意改变





    作为应届生,在面试前,应该了解一下外企的部门架构。以欧美企业为例,一般部门内的职位从低到高依次为:助理(如果是本科生,有时候可以跳过)---专员---资深专员---主管---资深主管---部门副经理/Section Manager---部门经理。一般,主管要求有5年以上的相关工作经验,这是一个分水岭。好,回过来谈谈面试时如何回答关于职业生涯规划问题。其实,这种问题并不需要你回答得无懈可击,这也办不到---你说得通俗了,认为你胸无大志;回答太专业了,又觉得你好高鹜远.
      回答这类问题,有以下几点可以帮你加分:
      1. 设定一个与自己专业相关的长远目标;这个目标要和公司的工作有关但不要局限在企业内部(因为空间有限,会遭遇许多太过于细节的问题)。例如,HR专业的学生可以说,自己的目标是在35岁之前,也就是10年内,成为一名优秀的人才测评专家或者资深企业人力资源顾问;工程技术专业的学生,可以成为精益生产专家或者黑带大师;IT专业则可以在信息资源整合和ERP解决方案方面成为专家,等等。注意,要着重在你想做些什么,而不是你想爬到什么级别。
      2. 把这个目标分解,以1年,3年,5年,10年的进度,逐步推进。这个就要靠你自己编了,恕在下不能一一举例。记住,每个阶段都要说明你能为公司做出怎样的贡献,你能得到怎样的提高,这与你长远目标的关系在哪里。此时,可以适当联系到刚刚提到的部门架构。
      3. 在此过程中,除了自己想办法不断充电,还要说一下你希望公司可以给你怎样的帮助。比如能够有岗位轮换的机会;或者能够参与各种项目等。不要提希望公司会给你培训,送你出国,给你报销学费,要表现得自己希望在实践中成长。
      4. 强调自己的稳定的心态。你可以这样说:“中国人最讲究‘名正言顺’或者‘不在其位,不谋其职’,所以很多人都认为,只有给了主管的职位,才能运用主管的权利,发挥主管的作用。我的理念和别人不同,我认为恰恰相反,当你展示出了主管该具有的能力,能完成更多的工作,公司自然会考虑对你的职位进行调整。在没有足够的权力时,要使用自己的影响力,所以我鄙视那些成天想着晋升却没有任何建树的人。”这样子,你的自我包装就成功了一大半。
      5. 最后要注意,在回答类似问题时,不要显得太胸有成竹。偶尔显示出涉世未深可以让面试官觉得你还有学生的单纯。“这个问题很大,我在学校里也曾经断断续续的考虑过,现在我简单的讲一下,可能会显得一厢情愿,希望得到您的指教”这样的一个缓冲在许多时候很管用哦。(还记得钻石法则吗?)





    有人问起多个问题同时出现时,应该如何解决。这就是Priority Setting的胜任力。应对思路是把所有要处理的事情按轻重缓急分成4个象限:重要而且紧急;重要但不紧急;不重要但紧急;不重要也不紧急。但记住,不要直接叙述这个思路,这会让人觉得你不像应届生。还是通过举例说明比较好。我面试过的一个比较好的例子:我在大三时正好要复习准备英语6级考试,这时有机会可以去一家企业做兼职部门助理,但需要每周花三个半天。同时,每月一次的英语沙龙活动要组织安排,还要(不好意思地说)抽空陪陪女朋友(最后一点很重要,可以活跃气氛,还为下面制造了一个不重要不紧急的事例)。我当时利用没有课程的下午去公司工作,一般要到5点半回学校。在公车上的30分钟正好用来总结当天在公司的收获和需要了解的知识。在食堂与女朋友吃晚饭,六点半去教室自习,到十点回宿舍。英语沙龙的工作委派给大二的两个干事,他们每天会到自习教室找我谈10分钟,我会给他们一些建议。这样,我没有花太多的精力在沙龙活动上,可对整个过程都有了解和掌控。后来6级考试顺利通过,那家公司对我的工作评价很高,我也学了很多东西;英语沙龙的活动如期举行,我和女朋友也没有疏远。
      这同时展示了三条胜任力:priority setting; delegation和work/life balance
  • 微软的软件测试方法(续2)

    2007-04-09 11:47:14

    当开发进入后期阶段,尽管项目已总体成型,开发人员也会不时遇到一些技术上的挑战。比如一些Bug的解决涉及对项目深层次结构的调整;再比如由于客户反馈的意见造成设计的修改。每一次这样的修改和调整事实上都是对一个稳定系统的破坏,如果处理不当往往一个Bug的修改会生成很多新的Bug,就像一系列联锁的恶性循环。很多项目工期的延误都是这样造成的。要避免或至少将这种破坏减少到最低限度,开发人员首先需要知道这种破坏的影响面。在这里单靠开发人员自身的逻辑思维、技能和经验是远远不够的,自动测试再一次成为一种有效的工具。往往开发人员会制定不止一个方案,对每个方案上都运行一遍同样一套自动测试用例,然后比较结果,选出最佳方案。自动测试在这方面所起的作用不仅在产品的开发过程中,它还延续到产品发布后。产品支持部门在为客户提供应急解决方案时也要依赖自动测试。 管理对测试的依赖 在微软,软件项目管理的主要线索就是Bug的管理,其中最直接具体的管理活动就是“Bug三方讨论会(Bug Triage。会议一般由项目管理Program Manager(简称PM)来主持,有开发人员和测试人员参加(所以叫三方会议)。会上对每个新生成的Bug进行讨论,并决定(1)是否接受这个Bug;(2Bug的严重级别和优先级别;(3Bug由谁来负责,是由测试提供进一步详细信息,还是交由开发人员解决,以及大致的解决方案等等。会议还要对老的Bug检查解决进度。这种讨论会常常会发生争论,要求测试人员具有足够的技术基础和用户经验,来捍卫产品的质量。可以说项目开发到了某一阶段后就是由这种Bug的管理所驱动的。这其中的原动力来自测试。 项目管理中一项非常重要但也十分困难的工作是衡量项目的进度,包括判断项目的状态,确定项目是否能预期完成。这方面,测试提供了两个非常重要的参数,一个是Bug数量的趋势,另一个是测试结果的趋势。 Bug趋势就是将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势,到项目中后期被解决Bug数曲线会趋于上升,而新生Bug数曲线应下降,到项目最后,两条曲线都趋向于零。PM会持续观察这张图表,确保项目健康发展,同时通过分析预测项目Bug趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息,比如说,可分析开发和测试在人力资源的配比上是否恰当,可以分析出某个严重的Bug所造成的项目质量的波动。 每天的自动测试结果同样可以形成类似的图表。它同样非常有助于了解当前项目的质量状况,开发测试进度。 由测试产生的这些数据不仅在项目开发过程中为项目管理提供有效的依据,而且也是产品通过发布的必要条件。在微软,每个产品都要经过评审才能通过发布。前面介绍的几个图表是发布评审的重要内容,如果从图表中发现临评审前还出现过较大的质量波动,评审人员一定会对此提出质疑。 因此软件项目管理依赖软件测试提供其基本的管理素材。 可以说,现代大型软件开发过程中开发和管理对测试的依赖性是测试与开发流程融合的一个根本因素。从另一个角度看,测试与开发流程融合决不仅仅是简单的时间上的同步,更不是双方空间上的接近,而是这种内在的依存关系的外在表现。开发对测试的这种依赖性对测试和测是人员提出了更高的要求。在理念上,软件测试已远不仅仅只是软件功能的验证和Bug的搜寻;在具体方法上,自动测试和测试工具的使用已成为基本的要求。在微软,测试不仅使用一些通用的工具,每一个产品还有专门开发的专用工具库,测试的代码量常常超过项目本身的代码量。 一个软件企业要提高其软件开发的能力,特别是针对大型软件的大规模的快速开发能力,在测试方面对传统理念和方法进行突破是必要的。微软的实践就是一个很好的印证。
  • 微软的软件测试方法(续1)

    2007-04-09 11:45:04

       我以前做无线产品的产品类测试,现在做J2EE的项目类测试。在产品类测试中,几乎所有既定计划完成后的时间都可以用来找缺陷,因此也没有Bug大扫除的说法。不过做项目类的测试就不一样了。项目测试中每个人员所受到的进度和成本的压力和不平衡的问题要超过产品测试。因此,我暂时叫它随机测试。这2个之间的区别肯定会有,甚至有时候很大。另一方面,做项目时,测试人员和客户的软件水平参差不齐、相差很大。要让他们理解测试是需要使用不同的语言的。相对来说,随机测试更容易理解。 经常遇到的情况是,项目开发进度DelayBug来不及改,因此出现测试可用时间不充分的风险,这是基本上无法组织随机测试。开发和修正效率较低时,往往会增加测试的成本,此时还会出现成本超支,无法组织随机测试的现象。 在项目类测试中,缺陷发散的问题所带来的压力要远比产品类的大。客户多半都能看到缺陷的情况,而且很多客户都会直接问基层员工:这么简单的一个问题为什么现在才发现?为什么不修正?为什么要这么长时间来修正?。这样一来,本身进度和质量压力已经很大的项目组,受到这么一折腾,很可能会爆掉。这个是公司所不愿看到的。 我们目前的做法是:无论是随机测试的问题,还是其它测试的问题,只要它没有被正确Closed,那么都需要测试和开发Manager进行沟通,相关测试和开发人员陈述意见和建议。如果Manager之间还不能解决,那么问题要上升到类似CCB的组织进行裁决。一般这个时间是在做最后一轮测试前,也就是上线前一段时间。已经正确Closed的问题,谁都不会去纠缠

     

    TL_geong,感谢你提供了一些项目开发的经验,确实它与产品开发有一些不同。这里我有些疑问向你请教: 首先,你们为什么把随机测试放在最后,等几乎所有既定计划完成后才进行?难道是认为随机测试不如既定计划测试重要?根据我的经验,很少有项目会在后期阶段有所谓的空余时间来做些随意性的工作。放在最后有时间再做,结果往往是取消或者草草了事。我们认为一类,二类测试是同等重要的,第二类测试对于验证第一类测试的覆盖性起很大的作用(没有哪种工具能取代),第二类测试若发现大量真正的Bug,那第一类测试的原先设计和计划就一定要相应调整。所以微软会在每个理程碑都有“Bug Bash”,而不是把它放在最后。我感到把随机测试放在最后就像一场赌博,赌你们的测试计划很完备周密。若不是这样,最后,一场成功的随机测试会给你揭露出一大堆问题,而恰恰这时,项目交货的日子到了。该如何收拾这场残局呢?要知道这还不是最坏的结局。最坏情况是你们最后没有机会做随机测试,或做了但不成功,结果那一大堆Bug溜到了你们的客户手中。这对你们或你们的用户支持将是一场灾难。 第二个问题是,你们为什么会把缺陷发散的压力加在基层员工身上?难道当初的测试计划没有经过大家审查吗?如果经过了大家的审查,即使有不周全,甚至范了低级错误也不应该由个人承担。 第三个问题是关于你提到的CCB组织,这是个上层权利部门吗?在微软,Bug命运由测试部门作主,若开发和管理不服,一般会请市场部门或客户支持部门提供进一步的信息,因为他们更接近客户

         微软的软件测试方法(二) 我在前一篇微软的软件测试方法中介绍了微软的两类基本测试方法,其基本思想大家应该是比较熟悉的,因为它们还只是传统的软件测试方法的综合。所以单从形式上,它并没有体现出对传统框架的突破。但是从另一个层面来考察微软软件测试时,你会对一些基本的事实感到惊讶。比如,微软的测试人员和开发人员数量大致相等或略多微软的产品成本中测试大约占40%以上等等。人们会有疑问,仅仅是作为功能验证和搜寻Bug的测试能消耗这么大量的资源吗?有必要付出如此大的代价吗?应该有理由相信,微软作为一个软件企业,其每一份投入都是有意义的,因此也可断定微软在软件测试方面的努力一定超出传统测试方法的范畴。 历史回顾 为了更好的理解微软件测试在方法和理念上的突破,我想首先回顾一下软件开发和软件测试的发展历史,并从中揭示其必然性。Edward Kit 在他的畅销书“Software Testing In The Real World : Improving The Process1995 ISBN: 0201877562中将整个软件开发历史分为三个阶段: 第一个阶段是60年代及其以前,那时软件规模都很小、复杂程度低,软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试,当然一阶段也还没有专门测试人员的出现。 第二个阶段是70年代,这个阶段开发的软件仍然不复杂,但人们已开始思考开发流程问题,并提出软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻,而且测试活动仅出现在整个软件开发流程的后期,虽然测试由专门的测试人员来承担,但测试人员都是行业和软件专业的入门新手。 第三个阶段是80年代及其以后,软件和IT行业进入了大发展。软件趋向大型化。与之相应,人们为软件开发设计了各种复杂而精密的流程和管理方法(比如CMMMSF),并将质量的概念融入其中。软件测试已有了行业标准(IEEE/ANSI ),它再也不是一个一次性的,而且只是开发后期的活动,而是与整个开发流程融合成一体。软件测试已成为一个专业,需要运用专门的方法和手段,需要专门人才和专家来承担。 测试与开发的融合 在这一历史发展过程中,最值得注意的是测试与开发流程融合的趋势。人们对这种融合也许并不陌生。比如测试活动的早期展开,让测试人员参与用户需求的验证,参加功能设计和实施设计的审核。再比如测试人员与开发人员的密切合作,随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。的确这些都是测试与开发融合的表现形式,而且初期的融合也只反映在这个层次上。90年代以后,软件的规模和复杂程度迅速提高,这种形式上的融合也迅速走向更深层次,更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为,只有软件的质量控制依赖于测试,但是现代软件开发的实践证明,不仅软件的质量控制依赖于测试,开发本身离开测试也将无法推进,项目管理离开了测试也从根本上失去了依据。在微软,测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。 开发对测试的依赖 现代软件开发,特别是大型软件开发通常会遇到以下两个问题: 1 在开发初期,如何能够展开大规模团队,群体齐头并进,而同时保持开发的有序性。从而有效利用资源,缩短开发周期。(2 在开发后期,如何解决深层次的Bug,如何面对设计更改,而能够保证产品的质量不出现或少出现回落。 对于小型简单的软件,这两个问题也存在,但不突出,而且容易解决。但对于复杂的大型软件的开发,这两个问题常常会成为难以逾越的障碍。 通常大型项目的功能丰富,但架构、层次也会相当复杂。稳妥的开发方式是,一次投入少量的人员,逐层开发,逐层稳定。但这种方式显然资源利用率低,开发周期长,不能满足现代软件和IT行业高速发展、瞬息万变的需要。因此大型项目需要大型团队。在微软,产品开发团队(主要包括开发、测试和项目管理)一般都有百人以上规模,有些产品甚至上几千人(Windows2000的开发部门曾有3000多人)。这样大规模的人力资源作用在一个动态的,内部相互联系的系统中,若没有有效的协同,其混乱是不可避免的。试想,有两个开发人员,分别在开发两个不同的功能模块,其相互有依赖关系。为了相互协调,他们可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间,这种协调就只能通过定期的会议来进行。而一个大型项目,会有许许多多这样的关系,而且很多时候这种关系有着不确定性和不可预见性。当一个开发人员编写一段新的代码或对已有代码进行改动和调整时,他(或她)常常无法确定,或无法完全确定究竟有哪些相关的模块会受到影响,以及在什么请况下这种影响会带来什么结果。因为系统的复杂性已远远超出了人的逻辑思维、技能和经验所能力及的范畴。因此这种传统的协调手段是远不能满足需要的。 在微软,这种协调是通过测试来实现的。具体来说就是:每日建造+自动化测试。关于每日编译和自动化测试,我将来会作专门介绍,这里简单的说就是每天都建造一个新版本,每个版本都要运行通过一定量的自动测试用例,以检验当天工作的质量。这里所说的质量当然有一般意义上质量的概念,但同时它也反映项目在开发过程中的整体协调性。 自动测试的最大优点在于它的高度可重复性。一个理想的自动测试系统能够让人随时、方便和迅速的运行大量的测试用例。因此一个开发人员可以通过检查当天的自动测试结果来分析前一天代码的质量(事后检查),也可以在当天存入代码前,先运行自动测试以进一步确保存入代码的质量(事前检查)。 在微软,每日建造都是在午夜开始,完成后紧接着就是全面的自动测试,到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过,开发人员则必须协同测试人员一起立刻找出原因,解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败,很大一部分开发团队会受到影响。为尽量避免这种情况,要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试,全部通过后在存入。如开发人员没有按照这样的要求,而擅自存入质量不高的代码而造成大量测试失败,这种不负责任的行为是要受到严厉批评的。从这一过程可以看出,开发人员依赖测试来保证开发工作的质量,使开发整体地协调地向前推进。 查看(801) 评论(3) 收藏 分享 管理

  • 微软的软件测试方法(续)

    2007-04-09 11:39:55

    这是一个非常有意思的活动,但要组织好这样的活动并非易事。一般有以下要点:(1)尽管这是一个测试活动,但参与者并不仅限于测试人员。项目经理,开发人员甚至于高层管理人员都应参加,如同全民动员。目的是要集思广益;(2要鼓励各部门,领域交叉搜索,因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性,增强趣味性,可以适当引入竞争机制,比如当活动结束时,评出发现Bug最多,发现最严重Bug的个人,给以物质和精神奖励。(4可以分专题展开,比如安全性、用户界面可用性、国际化和本地化等等。微软的第二类测试除了Bug Bash外,经常还有一些专业性的测试,最典型的是针对安全性攻击测试。一般会邀请公司内部,或业界的专家来搜寻产品的安全漏洞。 以上我从传统软件测试概念的角度,介绍了微软的策略和两类传统测试方法的具体做法,及其侧重点。这其实仅仅是一个基础,一个很原始的基础。软件测试在微软软件产品开发中的作用、地位远不是这些原始的方法所能达到的,也不是传统软件测试概念所函盖的。微软在软件测试方面有很多特有的做法,和概念上的突破,比如软件测试的信息服务功能以用户为中心的宏观质量体系分级测试项目的质量管理系统“Bug三方会审测试自动化软件测试的软硬件部门、团队、人和基础设施等等。这些我会在以后的讨论中分专题进行介绍。

    你们是怎样决定测试何时结束的呢? 比如你说的bug bash, 这种方法我虽然没实践过, 也能确信它的价值. 但是怎么保证不会过度投入呢? 我所经历的项目测试资源都比较有限(时间,人月), 所以一般都是在资源耗尽的时候就自然结束了, 当然也会考察覆盖率,风险, 发现bug数量的变化(越来越少), 但是主要是以资源耗尽为主要理由来停止测试的. 不知道微软在这个问题上有什么经验和方法?

    测试何时结束? 在按计划结束的那一天结束! 我这个答案你听了一定不满意。但这个答案告诉你微软所依据的最基本的原则,这就是计划。在我前面介绍微软的第一类测试时我提到测试计划,这个测试计划实际上就是要回答测试的投入问题,包括人力资源、时限和过程。确定测试计划有这么几个依据:1)产品的功能。功能的量和复杂性直接影响测试的工作量;2)质量标准,有公司的标准、行业的标准、市场反馈的标准和客户要求的标准等;3)以往的经验,有以往的产品的经验,也有个人的经验。这一测试计划还要被项目的各方(开发,项目管理)审核通过,从而在整个产品部门形成一种共识,这种共识最终被纳入项目总体计划的一部分。对于第二类测试,它也是总项目总体计划的一部分,而且量也是可知的。一般地说在每个里程碑都会有几个分专题的“Bug Bash”,每次历时1-3天。在微软的项目计划书中总有那么一天,叫做测试完成日 Test Complete Day”。它标志着所有计划的测试活动已全部完成,所有被发现的Bug被全部解决,并被测试所验证(有一些会因为某些原因被研究决定推迟解决)。 对于以上的分析你也许仍然不满意:难道微软的计划总能按期完成吗?当然不是,逾期的情况时常会有。几乎可以肯定,项目的实际执行与预先的计划一定会有或多或少的差距。微软会在项目过程中采取一些方法来感知这种差距,比如bitter提到的代码覆盖率分析和bug数量的变化趋势分析等。目的是为了尽早地发现差距,重新评估和修订计划。这样计划可以变化,但测试总是在计划结束的那一天结束

    对于TL_geong提到的随机测试造成收敛的缺陷趋势出现严重的发散现象,在微软也有。通常Bug Bash会产生超乎寻常数量的Bug。一般我们认为,产生Bug的量越大越好。因为,如果产生Bug的数量少,你很难判断是因为产品的质量确实很高,还是Bug Bash做得不彻底。而且事实往往是后者。 那么对Bug Bash所产生的大量Bug该怎么办?在微软,我们有“Bug Triage (测试,开发和项目管理,三方会审)的制度。对于每个Bug,经过会审后不外乎有以下三中归宿(总体上来说): 1)被确认为缺陷性”Bug,这样的Bug必须交开发人员解决,然后由原发现人验证。 2)被调整为非缺陷性”Bug,不用开发人员作任何更改,但必须将问题纳入产品用户文档,明确向用户解释,并告诉用户如何避免和应对。比如这里举一个假想的例子:产品的某个功能在系统内存严重不足的情况下,会暂时停止工作,并生成很多不易被用户理解的警告信息。这显然是个Bug(按微软的标准),正确的应该是,首先软件不应该完全停止工作,其次不应该多次警告,第三,警告信息应简明易懂,并给用户以措施和建议。但是考虑到,一方面这种情况在用户实际使用产品时发生的机率很低,而另一方面,从开发角度,解决这个问题有很大的技术难度,影响面也太大。这种情况下会把这个Bug改为文本性”Bug,也就是要求文本遍写人员将这一情况作一技术性解释,并建议用户不要将此产品同其他消耗大量内存的软件同时使用。这类的BugBug Bash中很常见,因为大家在这种测试活动中思维方式比较超常。 3)被完全否定,立刻关闭,不再纠缠。这类的情况在Bug Bash中也很常见。因为参与Bug Bash人并不都很了解产品功能的准确用法,误报是难免的。尽管对这类问题没有直接的后续措施,但这些信息仍然是有一定价值的,因为将来用户中的新手很可能会犯同样的毛病,而产品支持部门如果预先有这样的经验,就能及时准确地提供帮助。所以这些信息要保存在Bug的管理库中,以备将来产品支持部门查询。 经过这样的会审,筛选,如果(1)(2)类Bug,特别是(1)类Bug仍然很多,那测试部门很可能需要重新论证原先的测试计划和测试用例设计,看是否需要增加测试用例。必要时还要尽早提出更改项目总体计划和发布日期。 大量Bug的出现也许不是件愉快的事,但和把这些Bug留给用户相比,代价要小得太多了。总之对于产品的Bug,要相对待身体的疾病一样,切末讳疾忌医<

  • 微软的软件测试方法

    2007-04-09 10:29:53

    国内近年来关于软件测试的问题和讨论越来越活跃。但从总体上说交流软件测试技术,而探讨软件测试方法。这里的技术指的是具体的战术问题,比如说如何使用某种工具来解决某一特定测试问题,或者某一类型软件有哪些测试手段等等。而这里的方法指的是宏观的战略问题,或者叫方法论,这包括从软件测试的概念或理念,到企业软件质量控制体系;从软件测试的过程,到测试团队的设置及其职责的界定等等。作为测试人员,热衷于技术讨论和交流是一件可喜可贺的事。从中可以感觉到软件测试在中国迅速发展的开端和潜力。但是作为企业的管理决策者,是否也应该以同样的热情来思考方法问题呢?特别是当一个软件企业的软件测试从无到有,或者当企业已有一定的软件测试的投入,但发现其实效并不显著,甚至由于测试的引入而带来了新的管理上的混乱。这个时候方法论的思考,更有利于发现问题的根源。即便是一个基层的测试人员,当积累了一定的技术经验后,也应该不时从日常的具体工作中走出来,在一个较高层次上进行回顾总结和借鉴,并试着提出一些优化和改进的措施,这无论对专业上还是对事业上的成长都是非常有意义的。微软在软件测试方面有很多值得一提的经验,在此我想以我个人的体会和思考,同大家一同进行一些探讨。这里有一点须要特别说明,尽管微软的方法已被微软的实践多次证明是成功的,非常有效的,但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响,比如企业类型(微软是生产平台软件和通用软件产品的企业),企业管理体制,企业文化等等。所以我的目的只是给大家一些思路和借鉴 两类经典的软件测试方法 在具体介绍微软的软件测试方法之前,我想首先从概念,或理念的层面上来理解究竟甚么是软件测试,目的是从中导出微软测试方法的理论根源。传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证软件是工作的,所谓工作的就是指软件的功能是按照预先的设计执行的;而第二类测试方法则是设法证明软件是不工作的。提出第一类方法的代表人物是软件测试领域的先驱Dr. Bill Hetzel(代表论著《The Complete Guide to Software Testing》),他曾于19726月在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的论坛。他首先在1973年给软件测试一个这样的定义:就是建立一种信心,认为程序能够按预期的设想运行Establish confidence that a program does what it is supposed to do. ”后来在1983年他又将定义修订为:评价一个程序和系统的特性或能力,并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。 Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定义中的设想预期的结果其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为符合要求。第一类测试可以简单抽象地描述为这样的过程:在设计规定的环境下运行软件的功能,将其结果与用户需求或设计结果相比较,如果相符则测试通过,如果不相符则视为Bug。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行,并通过。在软件行业中一般把第一类方法奉为主流和行业标准。1990年的IEEE/ANSI标准将软件测试进行了这样的定义:就是在既定的状况条件下,运行一个系统或组建,观察记录结果,并对其某些方面进行评价的过程The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 [Std 610.12-1990]”这里所谓既定的状况也可理解为需求或设计。尽管如此,这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers(代表论著《The Art of Software Testing》)。他认为测试不应该着眼于验证软件是工作的,相反应该首先认定软件是有错误的,然后去发现尽可能多的错误。他还从人的心理学的角度论证,将验证软件是工作的作为测试的目的,非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义:就是以发现错误为目的而运行程序的过程The process of executing a program or system with the intent of finding errors.” 这就是软件测试的第二类方法,简单地说就是验证软件是不工作的,或者说是有错误的。他甚至极端地认为,一个成功的测试必须是发现Bug的测试,不然就没有价值。这就如同一个病人(假定此人确有病),到医院做一项医疗检查,结果各项指标都正常,那说明该项医疗检查对于诊断该病人的病情是没有价值的,是失败的。我并不完全同意这一看法。第二类软件测试方法在业界也很流行,受到很多学术界专家的支持。大家熟悉的Ron Patton在《软件测试》( 中文版由机械工业出版社出版,具说此书是目前国内测试新手入门的经典教材)一书的第10页,有一个明确而简洁的定义:软件测试员的目标是找到软件缺陷,尽可能早一些,并确保其得以修复。有些软件企业以Bug数量来作为考核测试人员业绩的一项指标,其实就是接受了这样的方法。 两类方法的优劣对比 虽然软件测试总的目的是为了软件产品的质量,但很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别,并各有利弊的。第一类测试方法以需求和设计为本,因此有利于界定测试工作的范畴,更便于部署测试的侧重点,加强针对性。这一点对于大型软件的测试,尤其是在有限的时间和人力资源情况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联,如果计划管理不当,测试活动很容易丢失重点,走入歧途。第一类测试方法可以与软件的架构和软件开发的计划相配合,使软件测试活动逐层次的展开,从而使软件的功能和质量有计划地逐步完善和提高(关于测试的层次问题,我会在今后的讨论中专门介绍)。第二类测试方法不具备这种过程的渐进性。第一类测试方法的缺点是缺乏灵活性,不利于测试人员主观能动性的发挥,正像Myers先生所说,不容易找到软件的错误(Bug)。而这方面正是第二类测试方法的长处。 微软的策略 正是因为认识到两类测试方法各有利弊,微软在软件测试活动中将两类方法结合起来,以第一类测试方法为基础和主要线索,阶段性地运用第二类测试方法 微软的第一类测试 微软的第一类测试总体上说分为三个步骤进行:审核需求和设计设计测试实施运行测试。前文已述,第一类测试是以需求和设计为本来验证软件的正确性。大家很自然的想到,需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品,测试也将是徒劳的。因此验证需求和设计是微软进行第一类测试的第一步。有必要指出的是,这里所说的需求和设计具体说来它一般包括:(1)由项目经理根据用户要求(信息来源于市场部门,用户支持部门等等)而编写的需求文本(Requirement Specification);(2)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(3)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)。微软的测试人员要参与所有这些文本的审核。作为测试人员,审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动,使他们尽早地进入技术和业务状态。第二步,测试人员要根据已审核通过的需求和设计编制测试计划,设计测试用例。在前面提到的三种文本中,功能设计文本是主要依据。原因很简单,这类测试关心的是软件是否能正确地实现功能,而不是这些功能如何被具体实施的。从这里大家可以看出这是典型的黑盒测试。确实微软的测试主要是从用户角度进行的黑盒测试。这一步的完成就意味着测试计划测试用例设计两个文本的完成。测试计划文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等测试用例设计文本要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文本也要被项目经理和开发人员审核。这样经过各种相互的审核,大家对项目形成了基本的共识。第三步的实施运行测试是整个开发过程中最长最复杂的一个阶段。从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试程序、反复运行自动化测试程序,也包括阶段性执行手动测试用例。这一阶段的测试必须在周密的计划下进行,在前面我已提到,这正是第一类测试的特点和长处。这种计划性首先体现在开发和测试的相互协调配合,根据产品的架构和功能模块的依赖关系,按照项目的总体计划共同推进。从测试的过程来看,总是先运行或执行简单用例,然后再复杂用例;先验证单一的基本功能,再综合的端到端的功能;先发现解决表面的,影响面大的Bug,再深层的,不容易重现的Bug。因此随着项目开发和测试的进程,产品的功能不断完善,质量不断提高。这里有一点要特别指出,有很多测试用例是要反复运行的,特别是基本的自动化测试每一天,每一个Build上都要运行。尽管这些测试大多数情况下都是通过的,很少再发现新的Bug,但其价值是显而易见的,就是为了防止质量回归。可见Myers的理论在这里是不适用的。这一阶段测试人员还有一项繁琐但却很重要的工作,就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例,一是对于当初测试设计不周全的领域,二是对于外部的Bug(比如从Beta客户报告来的),没有被现有测试用例所覆盖。当产品的功能设计出现更改时(在微软这是常事),所涉及的测试用例当然也要相应地修改。 微软的第二类测试 微软的第二类测试是阶段性的,常常根据需要而带有随机性和突击性。对于这类测试,在微软有一个专门的名称:Bug BashBug大扫除) Bug Bash通常发生在项目开发各阶段(微软叫里程碑)的末期,比如Beta版发布前,划出一个专门的时间段(通常1-3天),在这期间所有参与项目的人员,集中全部精力,运用各方面的知识,尽全部智慧来搜寻项目的Bug

  • 第一次注册个人空间

    2006-12-28 12:09:08

    一开始不明白个人空间概念,怀着好奇心情试试。哈哈,感觉爽-在互联网有属于自己的个人空间,谢谢互联网、你们.
895/5<12345
Open Toolbar