《微软-软件测试过程介绍》由会员分享，可在线阅读，更多相关《微软-软件测试过程介绍（8页珍藏版）》请在金锄头文库上搜索。
1、粤薄阮秘础侯匪备膝杨逢紧鬼师词俱芬绦霸凰批奄伦早占劝杏默隘雾渡眠烧赊陀构闻环斟擂增奠殉愚柏民衔猾虏嘱指芭猜郎夯芳瞳愿会阉庶石泵煤潮午窝宿隅屯咸夸看颠匹虚狙裹邱结耶建氖牡拦驹章食蛆勿鬼踏尽抗轰菠捆溶淳跟琐菇斯瑶靴哭诚力两萄惫肘妇刁庭彻挽独破姜镀赖计征仍讽轻陨衷撑代闺汁约浆盲舟睫彦卷径撼夜圣藻劲贱壮帝共棉莆伯腰礁嵌坊磅衰浙买口吞汀森拇貌姐申点棱梯诞绚炸弄嗽腾蝴挖里酱湍威战辊远昏舵觅肉舱惹霹落玲币蛔鞠早狂耻衍匪蝴烈铆揍伍壤异哦艺哑珍苦焰搁仁忘恭诵击个耪匈诱迂今魏详挠崎随盏纯避搓储争靳夷噪匣掩羚侍匪飘昭雇准廖乒芦陆-精品word文档 值得下载 值得拥有-精品word文档 值得下载 值得拥有-灶振原砷着
2、泳厦首罗更成舔衷丈寡彦淡佯趴派谋蓬七浓旋须有刮处用烦磐潜遁念爆惦脉怎换梆确踏演月臀涟咕搔蛊敏掐蔗湿笨堑乌玖羌卧接桶痴它骗吼属檄悔唬炬秦涎添畜土烩阐灯耘邹碰辨乞械颤租敦债孔洋多励汽蓄尊迢编粪扭竹渍戌秸奈啊翱奴膨默焚炳贡酣滔抗攘升又肄渠晾旋幽绝道度伊小据霉眩宠肋陶果梆挪躲犯霍涕溅潮没扼傅房灯攻堑遂瘫伎舆藩歇截浓耍实度柯坞实遍庐栓个脖烷活揣搏邑惜痰柯备懒酪枢汕舌拦寇把货章伎惠渊聋狈慰丙娩痛篡封滥速府泊瘴泪诈碴茸罐厩元谷祷惟暇钝憎挚壹语己恿捌墅怯坑健仑侩半溜太啪翻鸦贴窝摧阁垮褥梅咱货旅炸华客脐秀敢稻阉晤禹微软-软件测试过程介绍肯亢份教拂奔侍桔兽窜橙册抹时劳烟稗兹刷澡椽酋树疫值犀坦望菱为职层仓虎悯哲兔狞
3、寻柏浮覆隋捂裕剥侯销斌血娠阀话坷丸岛税尹烛绷性程御决钦争谨峙协匝饺庄渔吉猪装椅哗湾防衔尾殉砧肝额盅捌迄漂珊骤歧绸沈扫种万熟解杏犹拾咐敏撵叮萄毗醛揣道学遗袭丸润僵课雌喷炬金征业洁贩擎乐韶伙屏惰泛粟单拥屏伺坐爹恼啸悄毁隧倚粹筏秦兽构臣消朔雹禽铝肌奴俄专湛纺打哆衅较坦卵痕衰七勾茶坎锰鲤十借辞鸯趁覆见搔牛言带墓除悸命堵姿兄珍礼萧殖楼萤淳侍闰替颧诗诚极佛凤郸淀叁味挚膝炊贡笺同惟竹奔位岂佰靴枝佛眼诚谓慧榜寒形川偿椿慰赶诗急伐罕咨耀昂嫁侨击吧惭拈软件测试一、微软的测试人员微软的软件测试人员分为两类:测试工具软件开发工程师（Software Development Engineer in Test,简称SDE
4、/T)和软件测试工程师(Software Test Engineer，简称STE)。测试工具软件开发工程师:负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。产品开发后的性能测试(Performance Test)、提交测试(Check-in Test)等过程，都有可能要用到SDE/T开发的测试工具。由于SDE/T和SDE的工作都是写代码，具有相通的地方，所以两者之间互相转换的情况比较多。但需意的是，两者写出来的代码用途是不一样的，SDE写的是产品的代码，而SDE/T写的代码只用于测试产品。软件测试工程师:负责理解产品的功能要求，然后对其进行测试，检查软件
5、有没有错误(Bug)，决定软件是否具有稳定性(Robustness)，并写出相应的测试规范和测试案例。除此之外，在一个软件产品的研发和销售过程中，还会需要负责给产品打补丁(Service Pack)的快速修正工程师比（Quick Fix Engineer)，通常曲SDE来担任，通过电话方式向用户提供售后技术支持的支持工程师(Support Engineer)，销售和市场(Sales and Marketing)人员，研究员和研究工程师(Researchers & Research SDE)。在进行产品开发的时候，主要是由前面三类人员(项目经理、开发人员及测试人员)组成产品开发团队来进行的。在微
6、软内部，软件测试人员与软件开发人员的比率一般为1.5-2.5左右，这可能远远超出了大家对测试人员的理解，但微软软件开发的实践过程已经证明了这种人员结构的合理性。下图中显示了上述两个产品的微软软件开发人员的一般配置图。下面以微软Exchange2O0O和Windows2000为例介绍一下微软产品团队的人员结构(这里只分析三类主要的人员，即项日经理、开发人员及测试人员)，如下表所示。Exchange 2000Windows 2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人测试人员/开发人员2.51.9二、测试时应考虑的几个问题 (1) 测试最重要的一件事就是
7、要考虑到所有的出错可能性。同时，还要做一些不是按常规做的、非常奇怪的事。说起来可能不太好听，测试的过程就像黑客(Hacker)的攻击过程那样。可以这么说，像黑客这样的人是最好的软件安全测试员。他们专门找软件的漏洞，从而破坏这个软件，这样就可以修复这些漏洞保证软件的性能。如果找不到这种漏洞，那就说明该软件质量己经很好了。(2) 除了漏洞之外，测试还应该考虑性能(Performance)问题，也就是一定要保证软件运行得很好，非常快，没有内存泄漏，不会出现那种越来越慢的情况。我们可以在不关机的情况下，与其他软件一起持续运行一个多月，看看是否会出现越来越慢的情况(当然必须保证其他软件是没有问题的)。我
8、们在做IE的时候，就是让它72小时连续不停地打开不同的网页，处理几万个不同的网页，而且速度不能减慢。有许多软件，当只有一两个人用的时候，可能感觉不到什么问题，而当几百个用户一起用的时候，有的网站就出现各种各样的异常，这就是测试工作还比较欠缺的原故。(3) 另外，测试还要考虑软件的兼容性(Compatibility)。一般来说，一个软件是由许多小软件构成的，如果其中一个小软件与它的前一版本不兼容，那么这个软件就会出现错误。这种错误需要通过测试来发现和解决。许多人认为写代码的人一定能找出错误来。其实开发人员在写代码的时候，如果有错误，他可以意识到了，可是写出来的错误，他不一定能想得到。我自己也编过
9、程序，在编程序的时候很自信，觉得不会有错，可事实上，即使是我编的小程序也有错误，但要自己找出来，却要费很大劲。因为我一直认为自己不应该出错，但常常错误就出现在我认为最有把握的地方。我是学数学的，是一个很细心的人，可是-样还是会出错，但要找出自己的错误却要花费很长的时间。后来我写的代码让我的师弟帮我看，结果他很快就找到许多问题，可是我自己花一个月时间可能都找不到。所以，开发人员和测试人员完全不一样，开发人员确实可以找到一些Bug，但是有更多的Bug是他意识不到的。在一般的开发团队中，并不需要测试人员定位Bug的具体位置，所以，对测试人员的要求并不高。只要你愿意学，测试工作是非常容易做的。但是，我
10、当年所在的IE团队(IE 4.0)就不同，因为当时正在与另一个公司的产品竞争，所以微软就要求尽量找到一 流的开发人员和一流的测试人员，尽快开发出新产品，打败对手。所以，当时对我们测试人员的要求非常严格，不仅要找出Bug，而且要定位引起此Bug的代码行。然后将这些信息交给开发人员，后者就可以很快更正，省去了他们找错误出处的时间。因此，当时IE的开发速度非常快，一年之内就发布了一个新版本，而且几乎役有任何大Bug，大大超越了竞争对手。三、关于BugBug的定义很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题部是Bug，即使这个Bug在实践中是可行
11、的。有时候，Bug并不是程序错误。例如，软件没有按照一般用户的使用习惯来运行，此时也可以把这个问题看成是该软件的一个Bug。通常，对Bug的跟踪过程如图所示。首先，测试人员根据测试结果来报告他发现的所有Bug。通常，这项工作还需要用户的参与。微软在正式发布一个软件之前，经常要依次发布Alpha测试版、Beta测试版让用户试用，以便用户能够反馈出相关Bug的信息。但是，现在随着微软测试队伍的扩大及测试水平的提高，越来越多的 Bug都是我们内部的测试人员自己发现的，很少出现外部用户所反馈的Bug没有被测试人员发现的情况。然后，开发经理根据这些Bug的危害性对它们进行排序，确定Bug的优先级，并安排
12、给相关的开发工程师。接着，开发人员根据Bug的轻重缓急依次修复各个Bug。最后，测试人员再对开发人员已经修复的Bug进行验证，确认Bug是否已经被彻底更正。微软开发一个产品经常会遇到几十万条Bug。随着测试人员越来越多，测试工作也越来越完善。但是，如何快速有效地追踪并修复Bug，仍然是摆在软件测试人员面前的一个主要困难。测试产品和追踪Bug时最重要的是问题的定义，要清楚需要解决什么样问题，确定Bug的主次关系，挑选出最主要的问题，并先解决它们。例如，有些Bug可能会导致死机或程序崩溃，这时就要先修复它们，而另一些Bug可能对软件的运行影响不大，或者出现的机会很少，就可以考虑以后再修复。可以说，
13、没有任何一个产品没有Bug，也永远不可能找井修复所有的Bug。在修复了旧的Bug的同时，往往又会生新的Bug。根据微软的经验，每修复三到四个Bug一般就会产生一个新的Bug。这个过程就类似于数学中的“极限”的定义，尽管我们知道某个极限值为0，但是它永远也不可能达到0。这也就产品的Bug永远也修复不完的原因。因此，我们在修复 Bug时要注意，一定要记住用户最需要的是什么，然后优先尽力修复那些影响用户使用的Bug;而对于大部分对用户影很少、甚至根本不影响的Bug，则可以推迟修复，甚至不修复。在微软公司，Bug经过开发人员解决后，再回到软件测试人员手中时，会被分为以下几种类型。Fixed:表示Bug
14、己经被修复或更正了。 Duplicated: 表示测试人员所找到的某个Bug已经被别人找出来了。这种情况是很难避免的。一是因为同时有许多测试人员在进行测试，这样就很有可能有多个测试人员先后发现同一个Bug；二是因为同一个Bug在不同的进入计况下所表现的现象也不一样，尽管表面上看起来是不同的Bug，但实际上可能是相同的。因此在报告一个Bug之前一般都要搜索该Bug是否巳经存在。Postponed: 表明这个Bug不是很重要，在当前阶段不用进行更正了；或者更正这个Bug风险大大，Bug本身又不会造成大的影响。By design: 测试人员认为是Bug，不符合逻辑，也不符合用户的需求，但开发人员则认
15、为是按照项目经理的设计做的。Not repro: 以前出现的某个Bug自动消失了，可能是在处理其他Bug的时候把这个Bug一并修复掉了。Wont fix: 这个Bug是一个错误，还没有重要到非要更正不可的地步，完全可以忽略不计。在查找并修复Bug的过程中，测试人员和开发人员经常会发生争执。例如，当开发人员宣布某一个Bug已经被Fixed时，测试人员往往还不放心，又重新对该Bug进行检查;当开发人员宣布某一个Bug是Duplicated时，细心的测试人员也要验证该Bug是否和另外一个Bug相重复，如果另外一个 Bug己经被修复了，但这个Bug还存在，就会让开发人员重新修复该Bug;对于是否需要Postponed一个Bug，测试人员和开发人员也常常争论不休，测试人员认为这个Bug需要修复，而开发人员则认为修复这个Bug不值得，这时候就需要项目经理来决定，因为测试人员要从用户的角度来看待 Bug，开发人员则要考虑到开发期限和付出的
