微软公司软件开发模式简介    @ 2004-11-24, 17:10

微软公司软件开发模式简介
出处不详

北京大学出版社96年底所出的《微软的秘密》一书是目前我所见到的对微软公司软件产品开发过程介绍的最专业、最深入的一本书。通过本书,我们可以看到微软公司是如何对科学地对软件产品开发进行有效地管理,我想这些经验对于中国的广大软件开发人员,尤其是关心中国软件产业发展的各位朋友是大有益处的。所以特将此书中涉及软件产品开发的部分内容摘录出来(第四章产品定义与开发过程),加上我在微软中国工作的实际经验总结出这篇文章,希望与大家共同分享。本文作为摘录,自然是挂一漏万,所以建议大家若有时间还是找来原书一读。

  在微软的产品定义与开发过程中,微软软件开发遵循着一种可称之为靠改进特性(Feature)与固定资源(Resource)来激发创造力的战略。该战略可分为五个原则:

  将大项目分成若干里程碑式(Milestone)的重要阶段,各阶段之间有缓冲时间,但不进行单独的产品维护。
运用想象描述和对特性的概要说明(Program Specification)指导项目。
根据用户行为(User Behavior)和有关用户的资料确定产品特性及其优先顺序。
建立模块化的和水平式的设计结构,并使项目结构反映产品结构的特点。
靠个人负责和固定项目资源实施控制。
原则一:将大项目分成若干里程碑式的重要阶段,各阶段之间有缓冲时间,但不进行单独的产品维护。 项目进度安排与里程碑
微软通常采用同步-稳定产品开发法。典型项目的生命周期包括三个阶段:

计划阶段:完成功能的说明和进度表的最后制定
开发阶段:写出完整的的源代码
稳定化阶段:完成产品,使之能够批量生产(Roll Out)

  这三个大阶段以及阶段间内在的循环方法与传统的瀑布(Water Fall)式开发方式很不相同,后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的螺旋式的生命周期模型。   计划阶段的产品是想象性描述与说明文件,用来解释项目将做什么和怎么做。在管理人员拟定进度表、开发员写出代码之前,这些东西都促进了人们对设计问题的思考与讨论。开发阶段围绕三次主要的内部产品发布来进行;稳定化阶段集中于广泛的内部与外部测试。在整个产品生产周期中,微软都使用了缓冲时间的概念。缓冲时间使开发组能够对付意外的困难和影响到时间进度的变故,它也提供了一种手段,可以缓和及时发货与试图精确估计发货时间之间的矛盾。

  在开发和稳定化阶段的所有时间中,一个项目通常会将2/3的时间用于开发,1/3的时间用于稳定化。(Office部门副总裁曾这样概述通常的进度:一般说来,在总的进度表中,用一半的时间写出产品,留下另一半的时间调试或应付意外事故。这样,如果我有一个两年的项目,我会用一年来完成事先想好的东西……如果事情有点麻烦,我便去掉我认为不太重要的特性。)。这种里程碑式的工作过程使微软的经理们可以清楚地了解产品开发过程进行到了哪一步,也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足发货时期的要求。

计划阶段

  计划阶段是在一个项目的生命周期中,所有于开发前进行的计划所占用的时间。计划阶段产生出想象性描述、市场营销计划、设计目标、一份最初的产品说明、为集成其他组开发的构件而规定的接口标准、最初的测试计划、一个文档策划(印刷品和联机帮助形式的)以及一份可用性问题清单(Usability List)。计划阶段从想象性描述开始。想象性描述来自产品经理以及各产品单位的程序经理;它是对规划产品的市场营销设想,包括了对竞争对手产品的分析以及对未来版本的规划。想象性描述也可能讨论在前一次版本中发现面必须解决的问题以及应添加的主要功能。所有这些都基于对顾客和市场的分析以及从产品支持服务组处得到的资料。

  说明文件从一个大纲开始,然后定义出新的或增加的产品特性,并对其赋以不同的优先级。说明文件只是产品特性的一个预备性概览;从开始开发到项目完成它要增加或变化20% – 30%。虽然在生命周期的后期说明变化一般较小,但越到后期,开发员就越是必须具充分的理由来作改变。

  通常程序经理使用VB创建项目原型。他们也开展设计可行性研究以了解设计中的取舍情况,尽快做出涉及产品说明的决定。对于重要产品的说明需由公司高层领导进行复审。对于不太重要的产品,则由部分经理去完成。

开发阶段

  开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性,规定出特性的细节和技术上的相关性,记录下单个开发员的任务以及对进度的估计。在开发阶段中,开发员在功能性说明的指导下写源代码,测试员写出测试项目组以检查产品的特性与工作范围是否正常,用户教育人员(User Education)则编写出文档草案。

  当测试员发现错误时,开发员并不是留待以后处理,而是马上改正,并在整个开发阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计。当达到项目中的一定阶段点后(40%时),开发员就试图锁定产品的主要功能要求或特性,从此只允许小范围的改动。如果在此点之后开发员想作大的改动,他们必须与程序经理以及开发经理进行讨论协商,也许还要征求产品部门经理的意见。   一个项目是围绕着3或4个主要的内部版本,或里程碑子项目来组织开发阶段的。一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码、优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间,即缓冲时间(Padding Time)。(苹果公司的小组是割裂的、独立的,各自开发各自的东西。在还有3个月就要发货时,才会将所有的东西集成起来;Borland公司以一种渐近的方式进行开发,即把工作分成许多小的部分,并且总是让开发的东西能够运转。看起来似乎这种渐进的方法费时,但实际上几乎没有用过很长时间,因为这使你总是能掌握住事情真实的情况。)

  当对最后一个主要的里程碑版本做了测试与稳定化之后,产品就要进行外观固定(UI Freeze),即确定产品的主要用户界面,如菜单、对话框以及文件窗口等。此后有关用户界面将不再进行大的改动,以免引进同步修改相应文档的困难。

稳定化阶段

  稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能,除非是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间,以应付不可预见的问题或者延迟。

  下面我将Micosoft开发软件的模式用以下这张简图加以描述:(这张图对微软的测试进行了比较详细的描述,我个人认为微软的测试是Microsoft软件产品开发中一个十分重要也是十分有特色的分工。这是通过在微软将近一年的观察和与国内同类企业的分析,我才得出这样的结论。大家都很明白,国内的软件开发商在这方面做得很不够,尤其不重视软件的内部测试,在他们的思想中,可能有一个误区:认为测试应该完全去由用户去负责,其实不然,在软件的开发流程中,软件的测试与开发是一种矛与盾的关系,互为补充,缺一不可。在微软,可能这种关系发挥到了极至:有时开发部门与测试部门互相较着劲,开发经理和测试经理的地位是相同的,有时甚至测试经理的地位甚至凌驾于开发经理之上,但他们之间没有根本的利益冲突,只有一个共同的目标:将产品的质量提高。)   补充一点:(对微软的测试流程加以简要的描述一下)微软内部,专门有一个小组负责为微软的工程师们提供日常工作和管理的工具软件,他们是非盈利机构,其主要任务是开发微软内部所需要的工具软件:例如:

  SLM(Source Library Tree),源代码管理工具,负责管理软件开发过程中各个程序员的源码,各个程序员负责写自己的模块,每天将完成的代码Check-in到一个中央服务器的SLM树中,这个SLM树由预先定义好的脚本在固定的时间开始编译,通常这个过程需要好几个小时,所以微软内部根据各个项目组的情况有各自的规定:比如开发员必须在下班前(比如下午6:00)之前将当天修改的代码Check-in进去,这样SLM才开始编译。

  第二天,QA组的各个测试员从服务器上下载前一天的一个Build开始测试,将测试的情况及时的反映到另外一个工具软件中:RAID(Raid is a tool for entering, tracking, analyzing, and reporting product defects during development and maintenance.).这个工具负责管理产品的BUG情况,每个BUG包含很多属性:比如状态(活动的、解决的、关闭的)、严重级、优先级、哪个区域、哪个版本出现的、发现者、要将这个BUG赋给哪一个开发员等等一系列属性。还可以根据这个工具查询哪个开发员当天的BUG活动的、解决的数量,哪个测试员的BUG质量数目等等一些基本的产品质量情况,这样项目经理可以很容易的掌握该项目的具体进展情况。如果在项目的开发中期,发现的BUG数目比解决的BUG数目持续的多(意味着该产品的活着的BUG越来越多),可能意味着这个项目出现了问题,决策者可以迅速的作出相应的决策,及时的纠正产品开发中出现的失误(微软曾经有很多产品因为这样的因素被Cancel了)。还有项目经理可以根据这个工具,及时的掌握、了解每个测试员和开发员的工作状态,这一点很重要。有很多人曾经说过:Microsoft凭借着SLM和RAID打败了无数的竞争对手,通过我在微软的经历,我看这话一点也不假。这两个工具确实是非常杰出的工具,微软将它们使用到了十分艺术的程度上,对微软的成功起着非常重要的作用。更难能可贵的是,目前这些工具在功能上还在不断的进行改进、升级,使得微软的工程师们工作起来更加如虎添翼、虎虎生风,这样的企业哪有不成功的道理?

  在测试过程中,也不是随便的对软件产品毫无目的的瞎使用、乱使用,微软也有一套十分先进的方法和工具支撑着测试的每个方面:比如ATCM( Access Test Case Management),一种基于Test Case(测试用例)的测试管理工具就承担着这方面的工作。

微软也许正是靠着程序员的聪明和测试员的勤奋构建起软件帝国的大厦、谱写着软件事业的辉煌。
按此在新窗口打开图片]

Product Developing Process in Microsoft

上图中: QA是微软大的产品部门下设的一个比较专业的测试部门(Quality Assurance Dept)

  项目进度表中的缓冲时间(Padding Time)
微软使用缓冲计划,以在最高的效率与较好地对未来作预计之间求得平衡。这种应付突发事件的时间在开发和稳定化过程中是每一个主要里程碑的一部分。缓冲时间主要用于弥补由于对特性(Feature)的不完全理解,或者是技术困难或是由于疏忽而忘记把任务写入进度,或者是未料到的难题而形成的漏洞。缓冲时间有助于一个项目适应意料之外的事件。

原则二:运用想象性描述和对特性的概要说明指导项目

  为了给出足够的开发框架以使工作能持续进行,并且能容纳开发过程中出现的变化并保持足够的灵活性,微软采用想象性描述和概要的说明来指导项目开发,而不是在一开始就努力写出一份完整和详细的说明。所谓想象性描述是由程序经理和来自市场营销组的产品计划人员共同编写的一份非常短的文件,在其中主要是定义产品开发的目标(不涉及产品的具体细节!)。通常对一个全新的产品,想象性描述一般会相对较详细,在其中还含有一份粗略的说明文件。总的来说,微软对于想象性描述的要求是: 越短越好,尽量说明”产品不做什么”(而不是”产品要做什么”!)。

  运用想象性描述,程序经理开始编写功能说明文件,该文件解释产品的特性是什么以及这些特性如何与其他特性及产品发生关系。最初它只是一个概要性的说明文件,随着项目的进展,程序经理会随时向其中添加更多的细节,最终的说明文件将变得象用户手册一样。完整的说明不只起着对产品最新功能的描述作用,而且它还是在产品投产与发货之前进行测试与评估的主要依据。
想象性描述有助于决定删除哪些特性。

  微软内的各个开发组采用想象性描述帮助细化产品版本的规定主题,然后以此主题来决定是否需要增加产品各个可能的特性。通常不要轻易改变所确定的主题,否则可能造成产品开发上的混乱。

编写说明文件

  说明文件在产品小组的所有成员之间,产品小组之间以及产品小组与管理部门之间起着传递产品的设想与要求的作用。在说明文件中必须清楚地描述产品特性(描述每个特性如何工作,外观如何以及从用户的角度出发如何与用户交互。如果特性有一个界面,还应包括一张示意图,以显示出界面的效果),并赋于其相应的优先级。程序经理据此建立起项目的开发进度表。此外在其中还应包括以下各项内容:用一句话表示的项目开发目的,关于产品是什么与不是什么的清单,对顾客的定义,对竞争产品的定义,产品对系统的要求(包括操作系统版本、最小内存要求、硬盘空间、处理器速度以及显示器分辩率),对第三方(如打印机驱动程序、组件)的任何依赖性。程序经理负责协调并”写下”说明

程序经理(Program Manager)应考虑以下问题:

这项特性的要点是什么?
用户如何使用该特性?
这项特性有意义吗?
该产品中或微软的其他产品中有类似的特性吗?
有哪些问题被遗漏了?
组内的交流令人满意吗?

   最终程序经理通过与组内开发人员的共同讨论决定有关特性的内容,并将其写下来。

构造原型
   构造原型是程序经理具体说明一件新产品或一个新版本的最好方法,这从许多方面来说都使开发前测试成为可能,尤其在可用性方面,并且有助于对与用户交互情况作出好的理解,它也能使产品说明更紧凑。

  微软的开发人员通常采用VB构造用户界面原型,但是对于构造计算机屏幕模型之类的工作,画笔(Paint brush)也是一个很好用的工具。死板的说明变成有生命的文件,说明不应过于详细以至限制了发明创造。在项目开发过程中,说明文件的早期版本会有相当大的增加与改变。由于说明的变动可能会导致相应开发工作的极大变动,所以微软通常是将精力首先集中于那些没有什么用户界面的特性上,因为在完成开发前不必去了解用户对它们有何反应,也就是说这些特性不大可能改变。然后再面对其它特性。但是当产品开发到一定程序后,例如40%之后,程序经理必须严格控制对特性的修改(主要是指增加新的特性),否则不光会造成开发延迟,而且会压缩可用的测试时间。

原则三:根据用户行为和有关用户的资料确定产品特牲及其优先顺序

  对于一个开发项目而言,如何确定最终产品中应包含什么特性通常是比较困难的一件事。为此微软采用了一个称之为基于行为制定计划的方式来进行特性选择与优先级安排。

  基于行为制定计划法从对用户行为,诸如写信或做预算,做系统研究开始。然后,根据某一特性在支持重要的或者是经常的用户行为上的程序对其进行评价。这样做的优点是对特性取舍更具理性:讨论对顾客想要做什么加以更好的安排,对某个给定特性是否方便了特定任务的更集中的辩论,可读性更强的说明,以及在市场营销、用户教育和产品开发中更好地同步。

特性选择和优先级安排中的基于行为制定计划
   基于行为制定计划法中的关键点在于按用户行为、产品特性以及行为和特性之间的内部联系来分析产品。程序经理和产品计划者把产品试图支持的用户任务或方案分成大约20个行为,然后他们努力把行为(以及任何子行为)映射入微软的现行特性和竞争对手产品的特性中去。他们也把行为映射到不同的顾客形象或不同的市场部分中去。   当说明产品的新版本时,基于行为制定计划法帮助程序经理和开发员集中他们的精力与创造力。象Excel之类的项目,争取在每个新版本中加入的主要行为不超过四个。绝大多数特性直接映射入这些行为之中。该做法使项目可以按特性对用户的价值来进行分级。通过分级,促使程序经理和开发人员都行动起来,使他们的特性支持尽可能多的行为。这种良性竞争对于用户有益,同时也利于提高生产率。

为顾客行为而非产品特性准备资料
   基于行为制定计划进度,项目在计划阶段首先集中于行为,其次才是特性。程序经理和市场营销人员并不去思考和排除他们喜爱的特性,再围绕它们搞出想象性描述的草案。他们真正做的是列出一份顾客都做些什么的清单,然后把想象性描述集中于支持那些行为的特性上。 以行为为中心对产品进行全面考虑
   由于基于行为制定计划法是从整个产品的观点着眼,因此有助于在不同职能上工作的项目成员理解产品做什么,以及其他产品的相应特性如何可能支持那些需要或不需要其他应用软件产品的行为。

做市场营销研究以支持基于行为制定计划法
   为支持基于行为制定计划法,从市场营销组来的产品经理与程序经理、开发人员一起开展一些联合的研究,如指导对用户的研究工作。然而,一般来说是产品经理做大多数的研究,并可使其更明确地影响微软产品的演进。 原则四:建立模块化的和水平式的设计结构,并使项目结构反映产品结构的特点

  微软产品设计中的一个关键概念是产品的基础结构(Infrastructure),尤其是生命周期短的应用软件,应随项目的进展变得更加单一(而不是错综复杂)。当开发组构造产品的第一版时,他们更多地使用分级式结构,好为产品设计规定出一个最初的架构。随着时间推移,他们向单一的结构迈进,以使项目能集中于特性开发。微软越来越强调不同产品间的特性共享。共享有助于使不同产品的性能与感觉(Look and Feel)都统一协调起来;它也方便了需要不只一个应用软件的用户,减少了代码的重复书写,缩小了单独一个应用软件的规模。

  微软用特性小组组织产品开发,这种方法使得每个人都容易明白小组是如何与整个产品相关联的。项目从规定概要说明开始。概要说明的形式是一份已确定了优先级安排的内容清单,涉及产品下一版本将要开发的相对独立的特性,以便由分开的特性小组加以开发。

  程序经理和开发员把项目分成特性子集,再将之分配给每个特性小组,让他们在3到4个主要的内部项目里程碑中进行生产。这种产品组织与开发方法使微软能靠简单地增加开发员和创建一个大的小组来渐进地增加产品的功能。

把特性(与函数)作为开发单位
   微软软件产品的特性是用户最终可见的相对独立的功能单位,就如建筑材料一般,对应用软件产品更是如此。系统软件产品,如NT或者95的特性,对最终用户通常不直接可见。微软和其他公司有时简单地称这些不直接可见的特性为函数

  程序经理承担开发一组特性或函数,实现从说明经测试、文档化直到最后完成的过程。他们必须与开发员合作,后者负责估计进度表与完善每个特性。开发员还要在一台联网开发计算机上存储一到几个文件,用以保存特性的程序源代码。大多数特性的开发与改进只要一名开发员,而有的大型特性则要一个小的小组。 产品结构是决定其长期结构完整性的基石
   产品结构是产品内部的基干,它规定了重要的结构构件以及这些构件如何组装到一起。产品结构及用于组装结构的构件,提供了实现产品特性(即做详细设计与编码)的支柱。产品的结构对最终用户而言,通常并非直接可见。只有结构要实现的特性是可见的。产品结构也是决定产品长期结构完整性的基石。产品功能的任何改变都不应造成潜在的产品结构散架。

产品的层次结构
   对于产品,也可以采用层次结构的方法加以分析。通常定义良好的层次结构有助于对产品特性进行灵活的增加、删除与改进。此外良好的层次结构有助于产品在不同平台上的移植。(例如Excel总共定义了五层,其中只有最底层的操作系统层是与平台相关的,其它各层均是通过调用其下层所提供的API接口加以实现的,所以其移植极其方便。而在Windows 95中通过虚拟机的概念实现了对16位、32位以及DOS程序的支持。)

小的结构文档:源代码是唯一文件
   除了API文档,微软不对其产品结构生成相应的文档,虽然有时高级开发员可能会写下高层结构。对复杂的特性,许多开发员在某些点记录并复查特定于他们所负责的结构细节,但此工作是可选的,并不强制执行。除了源代码文件与特性说明,为数不多的组为新程序员准务了描绘某层结构的文档(主要的数据结构,如何工作等等)。但是这些文件并不时常更新,经理们也不要求项目组生成此类内部文档。在有关的说明文件中,并不涉及实现问题。开发员应该知道如何去实现,或者能够去学会。记录的关于结构的文档如此之少是因为一个开发员的工作是编写我们要卖的代码,而不是花时间写高水平的设计文件设计文件不应与源代码分离。分割代码与保持事情的简单

特性小组和作为”内容专家”的小组领导
   特性小组一般由一个领导和3至8名开发人员组成,工作于相关的特性领域。小组的规模常常视小组领导的经验和能力而定。特性小组领导向项目开发领导汇报并负责项目的全部开发工作;而项目开发领导则拥有对产品的更为全局性的观点,从而最有可能发现不互相关联的问题。在特性小组中的每个人均是此领域的专家,他们了解如何使用产品、了解竞争对手的产品、了解未来将向何处去。通常为便于交流,提高软件的组织结构(软件倾向于映射出构造它的组织的结构),应保持特性小组的小规模。

原则五:靠个人负责和固定项目资源实旋控制

  对于软件项目而言,精确估计产品的开发与交付进度是很困难的。对此微软采取的方法是将进度安排和工作管理的责任推到最底层,即单个的开发人员和测试人员那儿去。这保证了每个人除了作为小组的一部分外,还负有个人的责任。单独的开发人员设立他们自已的进度表,程序经理把单独的进度表汇总起来,再加上缓冲时间,以制定出一个全面的项目进度表。顶层的总经理也固定人员与时间等基本资源,以确保项目集中并限制其努力与创造程序。   关键的目标,尤其对应用软件,是指明产品的目标出品日并争取尽可能长久地坚持它。程序经理和开发员从出品日回溯,规定中间的项目里程碑的日期。这个固定的出品日法的中心在开发员身上。以避免因为项目没有固定的结束点,导致在最终无用的设计、再设计和测试的循环中消耗一年或更多的时间。 开发人员做出他们自已的进度估计
   日期设定方法”。但是开发人员一般会做出较乐观的估计,因此开发经理还需对他们所提供的日期进行调整并加上缓冲时间以避免因因信息不完全而出现的问题。微软这种制定进度的方法的优点在于:它从人们那儿得到更多的合作,因为日期是自已定的,不是经理定的;进度总是富有进取性,因为开发人员不可避免地会低估他们真正需要的时间。

对细致的任务的进度估计
   微软的第二个进度安排方法是:对要完成的任务做非常详尽的考虑,在此基础上请开发人员给出他们对实现的估计,以此力图促使更加现实主义并避免过度低估。

  通常微软把任务细化到4小时(半天)到3天之间。对于准确进度的安排,微软的经理是这样认识的:任何任务只要超过一星期,那人们就一定没有充分地全盘考虑它。任何任务某人估计只用少于半天就可完成,则他对它考虑得太多了。他应该用更多的时间去编程,更少的时间来考虑。对于类似类于Windows NT之类的操作系统而言,进度安排更加困难,对其一般以几天或者半周为工作单位进行进度估计。

安排开发人员与小组进度时的心理学
   当项目变大时,微软把员工分成小组。然后经理把进度的责任和所有权尽可能地分发下去,直到小组和个人;这使二者都产生了一种拥用工作的感觉。它还在小组中,个人中,尤其是小组领导中造成强烈的跟上其它同事预计进度的压力,因为经理可能再平衡进度,从落后的小组或个人手中拿走工作。这样,同事间的压力使经理不需要太多的努力就可以对个人或单个小组的进程实施严格控制。

“固定的”出品日( RTM: Release To Manufacture)
   为了把创造力约束在时间限制之中,微软现在在新产品或者产品新版本开始前争取固定出品日,至少是有出品日的内部目标。这给人们施加砍去特性和集中在一个项目上的压力,逼迫他们去苦苦思考应将哪个新特性加入产品中。虽然最终产品的交付目标可能是由高级执行人员设定,但是开发人员与小组仍然设定他们自已的进度表。   微软一般根据预先的时间进度的大致估计出一个RTM日期,然后向前回溯相应的各个Milestone日期,如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC(Code Complete)等等各个Milestone的相应日期。制定出十分详尽的产品研究开发时间进度表,产品开发组的各个成员以这个进度表为目标统一协调工作。微软十分强调软件开发过程中的Teamwork Spirits,这种理念贯穿在微软各个产品开发的各个阶段。这也是微软得以成功的一个十分重要的原因。

小结:同步-稳定开发法

计划阶段

定义产品的想象性描述、说明与进度

  想象性描述 产品和程序管理部门运用广泛的顾客意见来确定和优化产品的特性。
说明文件 基于想象性描述,程序管理部门与开发组定义特性的功能,结构问题,以及各部分间的相关性。
制订进度表与构造特性小组 其于说明文件,程序管理部门协调进度表,安排出特性小组,每个小组包括大约1名程序经理,3 – 8个开发员,3 – 8个测试员(以1:1比例与开发员平行工作。)

开发阶段

  用3 – 4个顺序的子项目,每个产生一个里程碑式的产品发送,来完成特性的开发。程序经理协调开发过程。开发员设计、编码、调试。测试员与开发员配对,不断进行测试。

子项目1 前1/3的特性:最重要的特性与共享的构件。
子项目2中间1/3的特性。
子项目3最后1/3的特性:最不重要的特性。

稳定化阶段

  全面的内外部测试,最后的产品稳定化以及发货。程序经理协调OEM与ISV,监督从顾客得到的信息反馈。开发员进行最后的调试与代码稳定化。测试员发现并清除错误。

内部测试 公司内部对整个产品做详尽的测试。
外部测试 公司外在的”β”测试点,象OEM,ISV以及最终用户处对整个产品做详尽的测试。
发货准备 为批量生产准备发布最后的金盘(Golden Disk)与文档,制作之前,还需要进行各种严格的检查:如政治敏感性术语检查、病毒检查、文件相关性检查等。

测试理论(转贴) | 评论已关闭 | 121,985 次阅读
单元测试指导 *    @ 2004-11-24, 16:09

单元测试指导

张华( www.51testing.com 顾问, CSAI 理事)( 2004-6-2 )

一、单元测试环境配置测试

1. 网络连接是否正常

2. 网络流量负担是否过重

3. 软件测试平台是否可选

4. 如果( 3 ),是否在不同的软件测试平台进行软件测试

5. 所选软件测试平台的版本(包括 Service Pack )是否正确

6. 所选软件测试平台的参数设置是否正确

7. 所选软件测试平台上正在运行的其它程序是否会影响测试结果

8. 画面的分辨率和色彩设定是否正确

9. 对硬件测试平台的要求和支持程度

二、代码测试

A 静态测试

1. 同一程序内的代码书写是否为同一风格

2. 代码布局是否合理、美观

3. 程序中函数、子程序块分界是否明显

4. 注释是否符合既定格式

5. 注释是否正确反映代码的功能

6. 变量定义是否正确(长度、类型、存储类型)

7. 子程序(函数和方法)接受的参数类型、大小、次序是否和调用模块相匹配合

8. 函数的返回值类型是否正确

9. 程序中是否引用了未初始化变量

10. 数组和字符串的下标是否为整数

11. 数组和字符串的下标是否在范围内(不越界

12. 进行数组的检索及其它操作中,是否会出现漏掉一个这种情况

13. 是否在应该使用常量的地方使用了变量(例:数组范围检查)

14. 是否为变量赋予不同类型的值

15. ( 14 )的情况下,赋值是否符合数据类型的转换规则

16. 变量的命名是否相似

17. 是否存在声明过,但从未引用或者只引用过一次的变量

18. 在特定模块中所有的变量是否都显式声明过

19. 非( 18 )的情况下,是否可以理解为该变量具有更高的共享级别

20. 是否为引用的指针分配内存

21. 数据结构在函数和子程序中的引用是否明确定义了其结构

22. 计算中是否使用了不同数据类型的变量

23. 计算中是否使用了不同的数据类型相同但长度不同的变量

24. 赋值的目的变量是否小于赋值表达式的值

25. 数值计算是否会出现溢出(向上)的情况

26. 数值计算是否会出现溢出(向下)的情况

27. 除数是否可能为零

28. 某些计算是否会丢失计算精度

29. 变量的值是否超过有意义的值

30. 计算式的求值的顺序是否容易让人感到混乱

31. 比较是否正确

32. 是否存在分数和浮点数的比较

33. 如果( 32 ),精度问题是否会影响比较

34. 每一个逻辑表达式是否都得到了正确表达

35. 逻辑表达式的操作数是否均为逻辑值

36. 程序中的 Begin … End 和 Do … While 等语句中, End 是否对应

37. 程序、模块、子程序和循环是否能够终止

38. 是否存在永不执行的循环

39. 是否存在多循环一次或少循环一次的情况

40. 循环变量是否在循环内被错误地修改

41. 多分支选择中,索引变量是否能超过可能的分支数

42. 如果( 41 ) , 该情况是否能够得到正确处理

43. 全局变量定义和用法在各个模块中是否一致

44. 是否修改了只作为输入用的参数

45. 常量是否被作为形式参数进行传递

B 动态测试

1. 测试数据是否具有一定的代表性

2. 测试数据是否包含测试所用的各个等价类(边界条件、次边界条件、空白、无效)

3. 是否可能从客户那边得到测试数据

4. 非( 3 )的情况下,所用的测试数据是否具有实际的意义(客户业务上的)

5. 是否每一组测试数据都得到了执行

6. 每一组测试数据的测试结果是否与预期结果一致

7. 文件的属性是否正确

8. 打开文件语句是否正确

9. 输入 / 输出语句是否与格式说明书所记述的一致

10. 缓冲区大小与记录长度是否匹配

11. 使用文件前是否已打开了文件

12. 文件结束条件是否存在

13. 产生输入 / 输出错误时,系统是否进行检测并处理

14. 输出信息中是否存在文字书写错误和语法错误

15. 数字输入框是否接受数字输入

16. ( 15 )的情况下、数字是否按既定格式显示

17. 数字输入框是否拒绝字符串和非法数字的输入

18. 组合框是否的能够进行下拉选择

19. 组合框是否能够进行下拉多项选择

20. 对于可添加数据组合框,添加数据后数据是否能够得到正确显示和进行选择

21. 列表框是否能够进行选择

22. 多项列表框是否能够进行多数据项选择

23. 日期输入框是否接受正确的日期输入

24. 日期输入框是否拒绝错误的日期输入

25. 日期输入框在日期输入后是否按既定的日期格式显示日期

26. 单选组内是否有且只有一个单选钮可选

27. 如果单选组内无单选钮可选,这种情况是否允许存在

28. 复选框组内是否允许多个复选框(包括全部可选)可选

29. 如果复选框组内无复选框可选,这种情况是否允许存在

30. 文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理

31. 文本框中数据格式(大小、对齐方向、颜色、背景)是否符合规范

32. 密码输入框是否按掩码的方式显示

33. 控件是否存在默认输入值,若存在,默认值是否得到显示和提交

34. Cancel 之类的按钮按下后,控件中的数据是否清空复原或按既定规约处理

35. Submit 之类的按钮按下后,数据是否得到提交或按既定规约处理

36. 异常信息表述是否正确

37. 软件是否按预期方式处理错误

38. 文件或外设不存在的情况下是否存在相应的错误处理

39. 软件是否严格的遵循外设的读写格式

40. 产生的文件和数据表的格式是否正确

41. 产生的文件和数据表的计算结果是否正确

42. 打印的报表是否符合既定的格式

43. 错误日志的表述是否正确

44. 错误日志的格式是否正确

C GUI 测试

1. 窗体是否能够基于相关的输入或菜单命令适当的打开

2. 窗体是否能够改变大小、移动和滚动

3. 窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作

4. 当窗体被覆盖并重新调用后,窗体是否能够正确再生

5. 窗体相关的功能是否可以操作

6. 是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制,既能正确显示又能调用

7. 显示多窗体时,窗体名称是否能够正确表示

8. 活动窗体是否能够被反显加亮

9. 多用户联机时所有窗体是否能够实时更新

10. 鼠标无规则点击时是否会产生无法预料的结果

11. 窗体声音及提示是否符合既定编程规则

12. 窗体是否能够被关闭

13. 窗体控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致

14. 窗体控件布局是否合理、美观

15. 窗体控件 TAB 顺序是否从左到右,从上到下

16. 窗体焦点是否按照编程规范落在既定的控件上

17. 窗体画面文字(全、半角、格式、拼写)是否正确

18. 鼠标有多个形状时是否能够被窗体识别(如漏斗状时窗体不接受输入)

测试理论(转贴) | 评论已关闭 | 79,851 次阅读
巧妇难为无米之炊 走出软件测试的困境    @ 2004-11-24, 15:56

巧妇难为无米之炊 走出软件测试的困境

作者:刘利君 北京市凯迪四维软件有限公司总经理
发文时间:2004.06.04

来 源: 软件世界

  随着信息技术在国内不同行业应用的开展,人们已经不再怀疑软件对于社会运转的巨大作用。但是,随着人们对软件作用期望值的提高,已经有越来越多人将关注点转移到软件的可靠性上,因此,国内软件测试公司或测评中心如雨后春笋般出现。

软件测试并非万能药

  我们在进行软件测试市场开发的过程中,发现了这样的一个问题:不少企业认为软件测试确实很重要,于是提出:我将执行程序(或者还有没有写完整的用户手册)给你,你给我测吧(对不起,代码不能给,因为涉及产权问题);如果测完通过了,用户就不应该再可能提出问题了。如果最终用户提出了问题,企业就会找到软件测试公司:看,你是怎么搞的,用户提出了问题,你们为什么不能通过测试找到问题?

  我们也遇到这样的情况,某地软件开发商与用户多次出现因软件质量引发的纠纷。于是该公司找到我们说:既然你们是软件测试的行家,你们来做测试吧,只要测试费用一个软件控制在2万元以内,我们给你们介绍生意。最终我们没有敢承担这样的业务,因为我们担心会陷入进退维谷的境地。因此也可以看到,人们对软件测试的理解存在一些误区。

  对于航空工业之中最高级别的软件,为了保障其可靠性,进行测试的工作内容包括语法规则检查和程序分析、条件覆盖、边界覆盖、语句分支覆盖、需求覆盖、强壮性、功能性及输入输出的测试,最终全部通过,也只能保证10-9的缺陷概率。

  因此,软件测试是提高软件质量与可靠性的重要一环,但并不意味着有了软件测试,软件就不存在问题了。如果仅仅是模拟用户进行一下简单的试用,则对于软件质量的验证效用就更差了。

  不妨做一个类比,如果一个工程验收时,外部装修极为符合标准,给人的感觉十分良好,我们是不是可以断定这个工作是质量优良的好工程呢?实际情况经常是,里面豆腐渣外面金钢玉。当然你打开水龙头、打开灯泡不会有问题,如果出现了火灾、大风,这个工程还行吗?不知道。为什么不知道?因为没有看到施工过程是否符合规范;施工过程即使合格,不知道材料是否合格。

  因此,软件测试并不是保障软件可靠性的万能药。

软件测试要分层

  如果仅凭用户手册,做出来的用户验收测试仅仅是以偏概全的特例测试。有经验的测试者不过是将测试用例设计得更科学些系统些,另外就是增加一些强壮性测试及压力测试。对于一个安全性可靠性要求不是很高的软件,这样做也许就够了。

  但是,我们知道,目前我们国家在搞以十二金为代表的电子政务工程。这些工程中涉及财税的部分以及电信、金融、保险、航空、航天等高科技领域或对软件可靠性要求高的领域,他们的对软件的测试仅仅如此是远远不行的。不妨简单地想象一下,航空机载嵌入式软件要求出现缺陷的概率是10-9,仅凭前面的测试能够满足要求吗?

  而进行如此严格要求的测试,投入的人力与财力将是十分巨大的。一般来讲,至少是开发费用的3~5倍,而且要求开发过程十分规范。

  总体来讲,我们不赞成简单地进行用户模拟测试的方式,因为这种做法欠系统和完整。

  我个人认为,进行验收测试要完成如下工作:功能遍历、链接测试、界面测试、稳定性测试、数据接口测试、安全性测试、性能测试、负载测试、压力测试、平台测试、浏览器测试、强壮性测试等等。

  如果在测试过程中发现问题,则要根据相关的设计文档,将问题隔离到部件进行部件测试。对于核心模块,如功能核心或主要的控制部分,则要进行模块一级的白盒测试。

测试应与开发过程控制相配套

  许多开发商或用户关注软件质量也重视软件测试,但是由于其开发过程尚不规范,往往导致测试,尤其是模块级的黑盒与白盒测试难以正常开展。原因很简单,就是缺少详细的设计文档以及对应于各模块代码的流程图与接口关系。其结果测试就如盲人摸象——仅靠读程序是不能看出程序本身是否与设计思想一致、软件的输入输出的正确性的。

  因而,要进行软件测试,特别是严格的软件测试,软件的开发过程不要仅符合一般的规范;不仅如此,文档的完备、细致化程度也应相当高才行。为保证测试效果及回归测试的顺利开展,开发过程的配置管理也应该严格有效。

  巧妇难为无米之炊。作为专业的软件测试公司,我们希望通过我们的努力也通过开发商和用户的共同努力,完善并改进开发流程的过程控制和开发文档,使测试工作能更好地提高软件的可靠性。

测试理论(转贴) | 评论已关闭 | 92,361 次阅读
软件测试的现实和理想    @ 2004-11-24, 15:10

软件测试的现实和理想

作者:王宇
发文时间:2003.11.18

来 源: 中国计算机报

  从我在微软工作的经历来看,软件测试绝对不是开发活动完成后的收尾工作,很多大型的开发项目,测试会占据项目周期一半以上的时间。以IE4.0为例,代码开发时间为6个月,而稳定程序花去了8个月的时间。前微软亚洲研究院博士、软件测试专家陈宏刚谈道。从投入的资金和人力物力来看,测试、使产品稳定和修改花去的时间可能占到80%。

  还处在婴儿期

  软件测试之所以发展相对缓慢,一个原因是做研究和做开发的人交流的机会相对少。只有做大型系统工程的人才会对测试提出较高的要求,重要性才能显现出来,而做研究和教学的人没有大型系统工程案例,所以造成了测试理论研究的发展缺乏充实的基础材料。真正做大型系统开发的工程师,又没有时间将第一手的测试经验变成系统的理论。

  在美国,佛罗里达州和华盛顿州分别有一所大学开设软件测试课程,其他有正规课程的学校不是很多。软件测试正停留在没有学科系统、没有系统教育的阶段。虽然已经有学校开设了这门课程,但是使用的教学案例,多半是单机软件,还谈不上系统的理论。陈宏刚博士介绍说。

  高素质的杂牌军

  由于企业对测试人才有着迫切的需要,因此,只好自己培养测试人才队伍。例如微软公司,对不同的产品制定测试规范,开设一些课程,通过讲座的形式对测试技术人员进行培训,但是也还未形成系统的理论。

  即使在微软,测试队伍是典型的杂牌军,没有科班,没有统一的专业,更多的是具有丰富的经验和不同行业背景的员工,例如具有语言学、数学、物理学、计算机、工程、管理等学科等背景的员工。但是,这不是说随便什么人都可以做测试工作,陈宏刚工作过的那个试验室,20个人中有7个博士。可见,虽然测试不是一个专门的学科,但是,这个部门对于一个成熟的软件企业又是至关重要的部门。

  认识需再提高

  IBM和微软公司属于领先的大公司,对测试的认识也经历了一个过程。开始的时候,也是开发人员兼职做测试,就像今天国内一些较小规模的软件企业。但是,后来的结果表明,花在软件修补上面的费用太高,以至于远远超出了所能够允许的范围。这个时候,增加测试队伍的规模,提高测试队伍的素质,提高测试队伍的待遇和受重视的程度是更加划算的。

  还有一个问题是,很多工程师不愿意做测试,认为是一种打下手的工作,没有前途,这也是国内比较大软件企业面临的问题。所以,企业从上到下普遍自觉和不自觉地只重视技术,不重视质量,后果是产品在市场上竞争力不高,产品售后维护和服务费用偏高。

  巨大反差

  微软的开发工程师与测试工程师的比例是1∶2,国内一般公司是6∶1。而且,致命的问题是没有哪个机构专门培养测试工程师。这个矛盾提示我们,在中国不能等到实际的需求和人力资源矛盾十分尖锐的时候,再谈培养问题;也不能等到产品质量成为产业阻碍的时候再来提高软件业的测试水平。测试工作不能靠手工劳动来完成,更多的情况是要使用工具软件和编写测试程序来完成,培养全面的测试专业人才是项任重道远的工作。

测试理论(转贴) | 评论已关闭 | 69,626 次阅读
软件测试过程的持续完善    @ 2004-11-24, 14:57

软件测试过程的持续完善

作者:qz
来自:不详

发文时间:2004/07/19

1.引言

   随着软件技术的迅猛发展,软件的质量愈来愈受到广泛的重视。而测试又是保证软件质量的重要手段。根据IEEE/ANSI标准,软件测试的定义是:”使用为发现错误所选择的输入和状态的组合而执行代码的过程”。这就非常明确地提出了软件测试是以发现错误,检验是否满足需求为目标。软件测试在软件生命周期中占有非常突出的重要地位,是保证软件质量的重要手段。根据Boehm的统计,软件开发总成本中,用在测试上的开销要占40%到50%。软件测试的目的就是在软件投入生产性运行之前,尽可能多地发现软件中的错误,以提高软件的质量。现代的软件测试不仅仅是在软件开发完成以后来做测试工作,而是将测试渗入到软件开发的各个阶段,而且提高自动化软件测试手段,来提高测试效率。

  有些项目的主持人,认为以尽快的速度把测试之前的所有开发阶段完成(实际并没有完成),早日开始测试,以图达到快速和高质量(因为似乎有更长的时间可用于测试)。实际的效果将会是俗语所说的”欲速则不达”。从常识就可以知道,花开发时间去继续扩大发展前面阶段引入的错误,得出的只能是更大量的需要耗时修正的错误。 因此,正确分析与利用测试的结果,我们可以非常有效地进行软件过程改进。

2.完善测试过程策略

1. 双效合一,不断进步

  公司的管理层和质量控制小组通常进行软件过程的改善,并编写出了一系列的企业的标准与规范,经过一系列的评审、培训,然后让开发人员去执行。但是在执行过程中常常碰到阻力,多数是来自于开发人员,除了紧张的开发工作,他们往往会抱怨又多出许多其它工作,比如按照一定的规范的文档的撰写;制定的企业开发规范不符合企业的实际情况,标准太高,无法达到。这一种做法,费时费力不讨好,大家的意见都比较大,规范定的比较完美,而且在评审时还要大家表面上都要认可,制定规范的人花费了很大的精力,对规范的评审浪费了大家的很多的时间,执行时还难以贯彻下去。这种方式肯定收效甚微。这是一种效率比较低的做法。

  通常,还会有另外一种做法:降低要求,暂时抛弃各种标准与规范,采用一种简单易行的策略,即由质量控制小组找开发人员、项目经理让他们自我发现问题:你有什么缺点?你将如何改进?在开发人员、项目管理人员讲自己的改进措施后,让他们确保能做到。在这种办法中,不需要管理人员花费太多的精力进行标准的制定,改进的推动,这些工作都是由开发人员自己去做的,管理人员仅仅是起到了监督的作用,只要开发人员自己说到做到就可以了。但是,我们做了一个尝试,如果仅仅从开发人员的角度出发制定标准,每个人的习惯不同,开发人员往往倾向于按照平日自己的编程习惯制定符合自己需要的规范,这样做的随意性比较大,难以形成统一的、正规的文档体系结构。而且,开发人员往往利用这一点,给自己留有充分的弹性。往往自己制定的规范都有自己不同的解决办法,这样会造成编程风格的不统一。既然是规范,总得有一定的强制性,而如果单单从下而上,放权给开发人员,实施的过程中可能会发生更大的问题。

  综上所述,我们就采取了一个折中的办法,即,根据开发人员的要求,先拟订一份开发规范,然后提交给开发人员或者项目管理人员评审。允许他们提出自己的意见,如果意见合理,可以对规范实施修改。举例来说,假设公司原来的文档体系中本身有一套编程规范,但是在实际开发的时候,其中的某些规则不是很实用,所以,公司就根据每个项目组所使用的开发工具和语言的不同,制定不同的编程标准,而这些编程标准的修改意见,基本上来自于开发人员,但是是经过公司的管理人员和质量控制部审核过的。

  这种做法的好处就是可以主动提高公司全体员工的质量意识。对于高层管理人员而言,所有的规范都是经过他们审核批准的,他们起到监督作用;对于开发人员而言,很多规则是他们提出的,他们会自觉遵守。这样双管齐下,双效合一,不仅会大大提高软件的质量,而且不用将发现错误的责任全部推给测试人员,而是提前预防错误、减少潜在危险的发生、减轻测试人员负担、培养开发人员良好的编程习惯。

2. 重视文档,需要技巧

  软件文档也称文件,通常指的是一些记录的数据和数据媒体,它具有固定不变的形式,可被人和计算机阅读。它和计算机程序共同构成了能完成特定功能的计算机软件(有人把源程序也当作文档的一部分)。硬件产品和产品资料在整个生产过程中都是有形可见的,软件生产则有很大不同,文档本身就是软件产品。没有文档的软件,不称其为软件,更谈不上软件产品。软件文档的编制在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档,对于充分发挥软件产品地效益有着重要的意义。

  然而,在实际工作中,文档在编制和使用中存在着许多问题,有待于解决。软件开发人员中较普遍地存在着对编制文档不感兴趣的现象。从用户方面看,他们又常常抱怨:文档售价太高、文档不够完整、文档编写的不好、文档已经陈旧难于使用等等。

  众所周知,文档的编写对于开发人员来说是一个十分头疼的任务,本来开发周期就很紧,还要按照要求的格式撰写文档。所以,这样结果往往就是文档不全,或者文档过于简单致使测试人员看不懂。甚至于,有时候项目需求早就更新了,而文档的内容依然不变。

  换个角度想想看,如果文档不全,测试人员遇到不理解的地方肯定会去问相应的开发人员,那么开发人员肯定要花费时间做解释。如果测试人员和开发人员处在不同的工作地,这将造成十分的不便。

  在软件开发过程中,文档十分重要,书写文档工作量也是相当大的。但是,只要掌握住技巧,还是可以缓解这令人头疼的问题的。首先,要站在别人的角度上看待这个问题。自己是做开发当然必须十分清楚程序的流程及功能,但是其他人就不一定,包括测试人员。所以,不要排斥写文档,先要换个角度想问题。再次,阐述基本功能,要做到重点突出。就是说,用简单的语言把功能简要介绍。对于其中的重点部分,要突出,要详细。不是说语言上要十分详细,而是理解的角度要详细。为了让测试人员快速理解模块的功能,最好的办法就是:功能流程图、数据流程图和例子。尤其是对于那些有相当强逻辑的程序而言,数据流程图和例子是非常好的方法,它不仅可以帮助指明数据的流向,还可以帮助测试人员理解测试用例的类型,以及结果形式。制作简明扼要的流程图和例子对开发人员而言是一项理清思路、省时省力的工作。而对于测试人员而言则是一份理解程序逻辑和功能的重要文档。在开发过程的后期,可以继续细化和完善文档。

3. 结队编程,提前测试

  为了提高软件的质量,公司可以尝试实行先结队编程,这其中也贯穿着质量意识。因为组成队的两个开发人员轮流编程、轮流写文档、互相监督、互相测试。这样不仅可以有精力把文档写好写全,而且可以提前单元测试,互相监督对方养成好的编程习惯。最终提高工作效率。 结队编程后,单元模块先由项目组配备的测试人员首先进行测试,然后质量控制部的人员按照项目计划检查项目是否按照预定计划正常进行,相关文档是否撰写,并进行集成测试。

4. 善于总结,提高效率

  总结是一种非常好的学习方法,它可以节省精力、节约时间达到事半功倍的效果。在项目的开发过程中,可以将碰到的重要的技术方面的问题要及时记录并将解决方案也记录下来,以便于其他相关人员的参考。同样,在测试的过程中,测试人员应该及时总结发现的错误并归类,标明经常容易出错的地方,将意见提交项目经理,审核后,制定出一份统一标准并提供给开发人员,这样就可以提前避免错误、避免重复错误和重复测试,提高测试效率。不仅如此,项目结束后的各项总结报告将是项目的后期维护或二次开发的宝贵参考资料。

3.结论

软件开发作为一种复杂的智力密集型的活动,同一般产品的设计和生产过程有相当大的差别,人的因素占的比例很大,控制也更为复杂。例如软件的正确性无法证明、测试也很困难,如果希望通过最终的测试确保产品的质量是完全做不到的;生命周期的各个阶段的转化无法确保百分之百的正确和完整,等等。实践证明,如果不从本公司的实际情况出发,盲目地套用一些好高骛远的开发体系或者质量体系文件是行不通的,所建立的体系对提高管理水平非但不能起到多大的促进作用,而且可能会对正常的开发活动起阻碍作用,引起开发人员的反感。这样建立的体系或者难于维持下去,或者要花费宝贵的资源去维持一套无用的体系。所以,建议根据公司的实际量身定做,建立起一套符合本公司情况的切实可行的标准和规范,真正的改善软件过程,加强测试,提高软件质量。

测试理论(转贴) | 评论已关闭 | 95,269 次阅读