（计算机软件与理论专业论文）测试驱动开发在nunit框架下的研究与实践.pdf

测试驱动开发在n u n i t 框架下的研究与实践 摘要 软件开发过程是一个对国民经济建设和软件技术发展均有重大理论意义和实用价值的研究课 题。在软件开发过程中，用户需求不断变化，各种意想不到的情况层出不穷，令软件开发过程很难 保证按预定的计划实现，给项目计划和论证工作带来了很大的困难。面对需求的不断变化。高效的 软件开发过程对软件开发人员来说至关重要。 敏捷软件过程是一种敏捷、高效、适应需求变化的开发过程。极限编程是敏捷开发方法的一种， 比较适合企业级的应用开发。 本文主要研究了软件过程和敏捷开发方法，分析了敏捷过程和极限编程的价值观、实现准则， 论述了测试驱动开发的核心理念及其过程。并在分析传统软件生命周期模型的基础上，借鉴r a t i o n a l 统一过程与面向对象技术相结合的经验，提出了一个测试驱动的过程模型，并对测试驱动过程模型 进行了详细阐述。 为了检验测试驱动过程模型是否具有可操作性，将t d p m 应用到p f m 系统开发实践中，运用 t d d 方法，借助n u n i t 框架，完成了p f m 系统执行引擎、处理器集合的设计，顺利地通过了系统 集成和目标平台测试，并利用c o c o m o i i 模型评估了p f m 系统的工作量和进度。 通过实验对比，分析了t d p m 相对于传统开发模型高效率、低成本、适应需求变化的特点，具 有可操作性。 关键词：极限编程；测试驱动开发；n u n i t 框架；测试驱动过程模型；p f m 系统 n r e s e a r c ha n dp r a c t i c ef o rt b s t d r i v e ni nt h en u n i tf r a m e w o r k a b s t r a c t a sar e s e a r c ht o p i c ，s o f t w a r ed e v e l o p m e n tp r o c e s sh a v em a t e r i a l l ya c a d e m i cm e a n i n g sa n du s e v a l u e s f o rt h eu s e rr e q u i r e m e n t sr a n d o mc h a n g e ，a l lk i n d so fu n l o o k e dc a s e se m e r g ei ne n d l e s s l y , t h e s o f t w a r ed e v e l o p m e n tp r o c e s sc a n n o ta s s u r ei t si m p l e m e n ta c c o r d i n gt os c h e d u l e ，s i m u l t a n e i t yi tb r i n g t r e m e n d o u sd i f f i c u l f i e sf o ri t e m sp l a na n da r g u m e n t a t i o n i nt h ef a c eo fr a n d o mc h a n g i n go ft h eu s e r r e q u i r e m e n t s ，h i g h p e r f o r m a n c es o f t w a r ed e v e l o p m e n tp r o c e s si sv e r yi m p o r t a n c ef o rd e v e l o p e r a 百l es o f t w a r ed e v e l o p m e n tp r o c e s si sa na g i l e ，h i g he f f i c i e n c y , a c c o m m o d a t et h er e q u i r e m e n t s c h a n g i n g t h ee x t r e m ep r n g r e m i n gi so n eo f t h ea g i l es o f t w a r ed e v e l o p m e n tm e t h o d s t h ep a p e rm a i n l yr e s e a r c ht h es o f t w a r ep r o c e s sa n dt h ea g i l ed e v e l o p m e n tm e t h o d s , a n a l y s et h e v a l u e sa n di m p l e m e n t i n gr u l e so ft h ea 翻l ep r o c e s sa n de x t r e m ep r n g r a m i n g , d i s c u s st h en u c l e a lm e a n s a n dp r o c e s s o f t e s t - d r i v e n d e v e l o p m e n t t h e n b a s e o n t h e a n a l y s i s o f t r a d i t i o n a ls o f t w a r e l i f ec y c l e m o d e l a n dc o n s u l t i n gt h ec o m b i n e de x p e r i e n c eo ft h er a t i o n a lu n m a dp r o c e s sa n d0 b j e e t - o r i e n t e dt e c h n i q u e , p r o p o s ea t e s t - d r i v e i lp r o c e s sm o d e l a n di i l u m i n a t ei td e t a u e d l y f o rv a l i d a t i n gt h et d p m sm a n e u v e r a b i l i t y , a p p l yt h et d p mo nt h ep r a c t i c eo fp f ms y s t e m d e v e l o p m e n t , e x e r c i s et l l et d dm e t h o d s i nv i r t u eo f t h en u n i tf r a m e w o r k , a c c o m p l i s ht 1 1 ed e s i g no f t h e p f ms y s t e me x e c u t i n ge n g i n ea n dh a d l e rc o n c o u r s e s f i n a l l ye v a l u a t et h el o a d sa n dp l a no ft h ep f m s y s t e mu t i l i z i n gc o c o m o l im o d e l t h r o u l 曲c h e e ke x p e r i m e n t , a n a l y s et h et d p m sc h a r a c t e r i s t i co fh i g he f f i c i e n c y , l o wc o s t , a d a p t i n g t h ec h a n g i n g o f r e q u i r e m e n tr e l a t i v i n gt ot r a d i t i o n a ld e v e l o p m e n tm o d e l ，p o s s e s sm a n e u v e r a b i l i t y k e yw o r d s ：e x t r e m ep r o g r a m m i n g ；t e s t - d r i v e nd e v e l o p m e n t ；n u n i tf r a m e w o r k ；t e s t - d r i v e n p r o c e s sm o d e l ；p f ms y s t e m 1 1 1 学位论文独创性声明 本人所呈交的学位论文是我在指导教师的指导下进行的研究_ t - 作及取得的研究成 果。据我所知，除文中已经注明引用的内客外，本论文不包含其他个人已经发表或撰写 过的研究成果。对本文的研究做i b 重要贡献的个人和集体，均已在文中作了明确说明并 表示谢意 作者签名：三型日期：业7 j t ? 4 - t 学位论文使用授权声明 本人完全了解大庆石油学院有关保留、使用学位论文的规定，学校有权保留学位论 文并向国家主管部门或其指定机构送交论文的电子版和纸质版有权将学位论文用- i - 4 赢利目的的少量复制并允许论文进入学校图书馆被查阅有权将学位论文的内容编入有 关数据库进行检索有权将学位论文的标题和摘要汇编出版保密的学位论文在解密后 适用本规定 学位论文作者签名：彳墓冲j 导师签名：泻亟厢 日期：2 o - 口7 汤弓闩l 翻 日期2 t 7 d 7 多1 2 创新点摘要 本文的主要创新点可归纳如f ； 1 通过学习传统软件过程模型理论和敏捷开发方法，针对t d d 中开发的无序现象，借鉴r a t i o n a l 统一过程与面向对象技术相结合的经验，提出了一个o o a d 和x p t d d 相结合的测试驱动过程模 型。 2 通过t d d 和面向对象技术的有效结合，采用测试驱动过程模型，在n u n i t 框架下设计并实践 开发了p f m 系统，在实际操作上验证了测试驱动过程模型实践开发的可行性。 3 分析t d p m 在p f m 系统应用情况，利用c o c o m o i i 模型评估了p f m 系统开发的工作量和 进度，定义并总结了t d p m 的特点，在理论上验证了测试驱动过程模型。 大庆石油学院硕士研究生学位论文 引言 随着软件需求和应用的日趋深入与复杂化，软件开发的难度和遇到的问题以几何级 数形式增长。复杂程度高，开发周期长，结果无保证，是软件开发的通病。在实际工作 过程中，软件开发的多变性和不可控制性，严重影响项目开始时建立的开发体系和方法。 敏捷开发中的极限编程正是在这种情况下逐步流行起来。 在极限编程中处于核心地位的测试驱动开发( t d d ) 以测试作为开发过程的中心， 要求在编写任何代码之前，首先编写用于定义产品代码行为的测试，而编写的产品代码 又要以使测试通过为目标。这种开发技术的优势体现在能够造就简单、清晰和高质量的 代码，能够有效的保证项目的质量。 作为极限编程的重要特点，测试驱动开发方法在国外从理论到实践都积累了丰富的 经验，并且近两年在国内的软件企业中也受到了相当的重视。将其引入到国内的软件开 发上，对启发开发人员学习快速变化多样的开发技术，减轻开发压力，提高软件产品质 量，会起到非常重要的作用。但如何正确的理解和应用，尤其是相关难点的解决还有待 进一步的研究和实践。 本文研究了敏捷过程和测试驱动开发方法，在n u n i t 框架“l - 经过实践开发，提出了 一个o o a d 和x p 厂r d d 相结合的测试驱动过程模型，并通过p f m 系统的开发，验证了 测试驱动过程模型。主要包括： 1 ) 将o o a d 和x p t d d 相结合，给出测试驱动开发模型： 2 ) 在n u m t 框架下，应用测试驱动开发模型，开发文件管理工具p f m 系统，验证 开发模型。利用c o c o m o i i 模型评估了p f m 系统的工作量和进度。通过模型评估，分 析了t d p m 相对于传统开发模型高效率、低成本、适应需求变化的特点，具有可操作性。 在软件学科和许多其它领域中，针对同一个问题，通常至少有两种以上的解决方法。 相对于传统的以架构设计为中心的自顶向下过程，x p 中的t d d 方法的出现则证明了以 代码设计为中心的自底向上过程的合理性和有效性。 较之传统的根据详细设计编码，再反复进行测试修改的编程方法，测试驱动开发更 有助于提高软件质量，降低b u g 数量，它不但满足了设计需求，而且降低了系统出错的 风险。在工作量上，代码量虽然提高了，但后期测试和维护的工作量减少了，而且得到 了一套完整的可回馈的测试，为后期维护提供了方便。在时间进度上，测试与编码工作 同步完成，虽然编码的时间拉长了，但不妨碍最终产品的提交。 实际上，c m m ，x p 等都不是全新的发明，这些理论及应用是对几十年来国外软件 开发实践成功经验的总结、继承和发展。如果在应用中脱离实际、反而囫囵吞枣、盲目 照搬，就会冒很大的风险。我们应当注重理解、消化这些先进思想方法的外延和内涵， 从中学到最佳实践方法，取长补短、持续改进，逐步建立起一套适合自我、行之有效的 过程体系。 引言 整个系统的开发是一个非常复杂的任务。大量的测试设计和编码工作是在系统的不 断扩展中逐步完善的。由于测试驱动过程模型的提出和p f m 系统的成功实现，测试驱 动开发在n u n i t 框架下的研究与实践取得了令人满意的效果的效果，为系统提供了一套 完整的可回归的测试，能马上提高代码的质量，减少了后期调试的工作量，减少了b u g 数量，并且设计出可重用和具有可测试性的、简单可行的代码。 2 人庆石油学院硕十研究生学位论义 1 1 传统软件开发 第1 章软件开发与敏捷过程 1 1 1 传统软件开发的阶段 从工程学角度出发，软件开发过程包括计划、分析、设计、编码、测试和维护等几 个阶段【1 1 。 1 计划 对所要解决的问题进行总体定义，包括了解用户的要求及现实环境，从技术经济和 社会因素等三个方面研究并论证本软件项目的可行性，编写可行性研究报告，探讨解决 问题的方案，并对可供使用的资源( 如计算机硬件、系统软件、人力等) 成本，可取得的 效益和开发进度进行汇总。 2 分析 对所要解决的问题进行详细定义，这需要软件开发人员和用户共同讨论决定，哪些 需求是可以满足的，并加以确切地描述。编写软件需求说明书、初步用户手册、确认侧 试计划和数据要求说明书等。 3 设计 根据需求说明书的要求，设计建立相应的软件系统的体系结构，并将整个系统分解 成若干个子系统或模块，定义子系统或模块间的接口关系，对各子系统进行具体设计定 义。编写软件概要设计和详细设计说明书，数据库或数据结构设计说明书，组装测试计 划。 4 编码 把软件设计转换成计算机可以接受的程序，即写成以某一程序设计语言表示的“源 程序清单”。 5 测试 在设计测试用例的基础上对软件进行测试，以验证系统是否按所要求的性能和功能 设想运行。编写测试分析报告。 6 维护 根据软件运行情况，对软件进行适当修改，以适应新的要求，以及纠正运行中发现 的错误。编写软件问题报告、软件修改报告。在实际开发过程中，软件开发并不是从第 一步进行到最后一步，而是在任何阶段，在进入下一阶段前一般都有一步或几步的回溯。 第1 章软件开发与敏捷过程 在软件开发中，重复经常出现。在测试过程中的问题可能要求修改设计，用户可能会提 出一些需要修改需求说明书的新要求，等等。 软件开发方法从大的方面来说，有瀑布模型、螺旋模型、喷泉模型、r u p ( r a t i o n a l u n i f i e d1 ) i - o c e s s ) ，敏捷编程。在这些开发方法中，前4 个都是重型软件开发方法，注重文 档的完整，程序的易读性，结构的完整性，它们被广泛的用在公司的大型软件开发中。 1 1 2 传统软件开发中的弊端 随着国家信息化建设的加快，国内许多的软件公司快速成长，在学习国外公司管理、 技术经验的过程中，已经从过去的三、四十人发展到现在的五、六百人，甚至数千人。 公司的销售渠道在加强、开发队伍在加强、实施队伍也在建立和完善之中，公司完整的 组织体系慢慢地建立起来，过去许多原有的工作方式方法，随着机构的建立。逐步的消 失了，在消失的东西中，同样存在着许多好的工作作风与方法，这些东西已经无法再找 回来了，软件设计人员对于企业需求的感觉在这个变化过程中几乎消失殆尽，由于这种 消失，逐步地使软件公司背离了面向用户的宗旨，使这一宗旨成为了说教。那么促成这 种现象的快速演变的核心本质的组织体系究竟是怎样的呢? 为了把这个病源说清楚，在 这给大家展示一下现在国内大、中型软件公司的常用结构示意图和在开发工作方面的职 责。 软件开发理论上是一个迭代过程开发人员喜欢走的捷径 图1 - 1 传统软件开发结构不意图 这是目前软件公司常用的组织体系结构。在这里之所以使用“体系”二字，是为了 消除某个体系下可能存在的多种不同类型的部门：如多个行业部门、如多个产品部门，在 这个结构中有三个体系涉及商品化软件建设，第一个体系就是渠道和销售部门，他们的 基本职责是使用商品化的软件获取客户，同时向实施体系和开发体系传达用户的核心需 求。第二个体系就是实施部门，他们在第一阶段实现客户需求的调研，并将用户现实需 求传达到开发体系，当然在部分软件公司中，偶尔会派出开发体系下的需求分析部门的 人员参与需求调研工作；而另一个方面在软件交付给实施部门后，实施部门将根据企业 需求的调研结果，开始软件的实施工作。第三个体系就是开发部门，他们实现需求分析 与定义，实现商品化软件概要设计与详细设计，实现软件代码的编制，实现商品化软件 的测试，直到软件测试通过、并提供软件交付。 4 大庆石油学院硕上研究生学位论文 在这种结构中有两个层面和两个断带，第一个层面是渠道体系、实施体系的需求调 研过程，接下来是一个明显的断带，通过这个断带转入到第二层开发体系的需求分析阶 段。最后经过商品化软件测试后的交付，又通过第二个断带将软件传递给第一层实施体 系的实施过程，直到完整交付为止。通过这个过程可以明显感到信息传递的错位与断裂， 在这种状况下所实现的商品化软件必然会导致在适应企业实际需求方面的不足。并且目 前这种现象，如果不在其它方面实现有效调节，必然会导致更大的断带，和人员能力的 急剧衰退。 从以上分柝中我们可以看出：一个正常的开发运作方式应当是相当平滑的，首先是 只有一个层次，而且也不存在断带，只有这样的开发结构才是企业现实需求的商品化开 发结构。 1 1 3 企业应用系统开发的特点和难点 1 开发进度难以控制 在软件开发过程中，用户需求变化等各种意想不到的情况层出不穷，令软件开发过 程很难保证按预定的计划实现，给项目计划和论证工作带来了很大的困难l l j 。 许多重要的大型软件开发项目，如m m0 s 1 3 6 0 和世界范围的军事命令控制系统 ( w w m c c s ) 2 1 ，在耗费了大量的人力和财力之后，由于离预定目标相差甚远不得不宣布 失败。 2 软件质量差 软件项目即使能按预定日期完成，结果却不尽人意。1 9 6 5 年至1 9 7 0 年，美国范登 堡基地发射火箭多次失败，绝大部分故障是由于应用错误造成的。程序的一些微小错误 可以造成灾难性的后果，例如，有一次，在美国肯尼迪发射一枚阿脱拉斯火箭，火箭飞 离地面几十英里高空开始翻转，地面控制中心被迫下令炸毁。后经检查发现是飞行计划 程序里漏掉了一个连字符。就是这样一个小小的疏漏造成了这支价值1 8 5 0 万美元的火 箭试验失败p j 。 3 软件维护困难 正式投入使用的软件，总是存在着一定数量的错误，在不同的运行条件下，软件就 会出现故障，因此需要维护。但是，由于在软件设计和开发过程中，没有严格遵循软件 开发标准，各种随意性很大，没有完整的真实反映系统状况的记录文档，给软件维护造 成了巨大的困难。特别是在软件使用过程中，原来的开发人员可能因各种原因已经离开 原来的开发组织，使得软件几乎不可维护。 企业应用系统与其它软件系统相比，其特点是客户需求的不确定性和多变性。企业 应用系统开发的难点也是如何挖掘和确定客户的需求。传统方法一般是要求把前期调研 分析工作做细、做完整，并以合同的形式与客户确认需求，进行“需求冻结”。客户要 补充或更改需求就得补充合同，其实这是对客户不负责任的表现。事实上，在开发前期 第1 章软件开发与敏捷过程 很难一次性挖掘和确定客户的所有需求。高层管理员虽了解全局工作流程和业务管理方 式，但不熟悉具体业务的操作细节；底层业务虽精通自己的业务的操作过程，但对全局 又缺乏了解。许多需求是在原型演示、试用、测试，甚至在实际使用过程中才挖掘和确 定的。 另外，在传统开发方法中，客户很少或几乎不参与开发过程。从分析、设计、编码 一直到内部测试，整个开发过程对客户几乎是透明的，客户在测试或培训时才见到“庐 山真面目”。过程的透明性【4 1 - - 般会造成最后系统的工作模式和操作界面与客户的要求 存在一定的距离，甚至会截然相反，这对整个系统的开发会带来灾难性的后果。 1 2 敏捷开发和敏捷过程 1 2 1 敏捷性研究 敏捷性( a g i l i t y ) 的概念首先是在制造领域中提出的。敏捷制造最早源于1 9 9 1 年美国 里海大学亚柯卡研究所与其合作者共同提交的 2 1 世纪制造业发展战略研究报告。按 照敏捷制造创始人r o g e r n a g e l 和r o c kd o v e 给出的定义，敏捷性是企业在不断变化和不 可预测的竞争环境中发展壮大的一种能力。敏捷是对迅速变化、不断细分、高绩效、高 品质的全球市场、客户定制的商品和服务所产生利润的商业竞争的全面响应。敏捷是动 态的、适应于具体情况的、迎合变化的和自我完善的。 软件过程的敏捷性是2 0 0 1 年提出的概念，m a t t i n gf o w l e r 较早从敏捷与重载( h e a v y w e i g h t ) 方法的比较中，给出了关于软件项目敏捷性的阐述网，提出敏捷的最根本之处在 于： 1 敏捷强调自适应，而非预测。本质上重载方法是抵制变化的，而敏捷方法则强 调适应变化。 2 敏捷方法以人为中心，而非以过程为中心。敏捷方法强调软件开发应合乎人类 本性，软件开发应带来乐趣。 a l i s t a i rc o c k b u r n 认为敏捷性是指有效率和有机动性。敏捷的过程是轻且够用的，轻 是一种保持灵活机动性的方式，够用则是使游戏能进行下去的条件。 j i m h i g h s m i t h r g 敏捷的概念给出了更深刻的阐述，他强调敏捷不仅仅是一种反应， 而且是一种行动：它是一种生命的方式，是以不断的突变( e m e r g i n g ) 和变化( c h a r t i n g ) 来回应商业动荡的方式。因此，敏捷性是一种创造变化和回应变化的能力，从而在动荡 的商业环境中获得利润。 h i g h s m i t h 提出了三个特性，进一步刻画了敏捷的概念： ( 1 ) 机敏和即兴性( n i m b l e n e s sa n di m p r o v i s a t i o n ) ( 2 ) 现实一致性( c o n f o r m a n c et oa c t u a l ) 6 大庆石油学院硕h 开究生学位论文 ( 3 ) 柔性与结构性的平衡( b a l a n c i n gf l e x i b i l i t ya n ds t r u c t u r e ) 1 2 2 敏捷开发 2 0 0 1 年2 月，1 7 位软件晃专家，包括k e n tb e c k 、a l i s t a i rc o c k b u r n 、j i mh i g h s m i t h 等，发起成立了敏捷软件开发联盟( a g i l es o f t w a r ed e v e l o p m e n ta l l i a n c e ) ，通常称为 敏捷联盟( a g i l e a l l i a n c e ) ，并发表了敏捷软件开发宣言【，制定了敏捷过程应遵循的 标准。这表明，在软件业经历了无数次的项目失败之后，人们开始反思软件开发的工程 特性，反思计划和控制的有效性，反思过去对于不确定性的态度和反应。 l 。敏捷联盟宣言的内容【6 】 个体和交流胜于过程和工具。 工作软件胜于综合文档。 客户协作胜于洽谈协议。 回应变革胜于照计划行事。 第一条价值陈述认识到，过程和工具虽然很重要，但人才之间的交流更重要。严格 的方法学及业务过程在传统的软件开发学中强调过程重于人。然而敏捷开发方法将这一 点反了过来。 类似地，虽然综合文档并非有害，但重点一定要在最终产品工作软件上。就是 说，每一个项目组必须自己决定，哪些文档在交付工作软件时是非有不可的。摆在开发 者和发起人面前的工作软件说明了实质一哪些地方与当初的承诺是不同的。工作软件可 以被包装、修改、分析，但却是真实的。 洽谈协议，无论是通过内部项目章程，或者是通过外部的合法合同，并不是坏事， 但光有这些是不够的。客户要的是交付能满足他们需求的产品。洽谈协议会增加不确定 范围( 偶然性) 。这会使完成项目的时间更长，成本更高，并减缓对变化了的需求做出响 应。客户和供应商的团队协作可能是最好的解决方案。协议和项目章程提供了边界条件， 这样参与者得以工作，但只有通过不断的协调，开发小组才有希望真正理解客户需求， 并交付客户需要的产品。 2 敏捷宣言遵循的原则【6 i 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优 势。 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时 间间隔越短越好。 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且 信任他们能够完成工作。 7 第1 章软件开发与敏捷过程 工作的软件是首要的进度度量标准。 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期 的、恒定的开发速度。 不断地关注优秀的技能和好的设计会增强敏捷能力。 简单是最根本的。 最好的构架、需求和设计出于自组织团队。 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自 己的行为进行调整。 1 2 3 敏捷过程 敏捷过程( a g i l ep r o c e s s ，a p ) 是一种典型的软件过程模式，它对软件过程模式中的 四大要素生命周期、人员、方法与产品及相互关系均进行了论述，是这几年来软件 工程发展的最新成果。它包括极限编程( e x t r e m ep r o g r a m m i n g ，x p ) 、动态系统开发方法 ( d y n a m i cs y s t e md e v e l o p m e n tm e t h o d , d s d m ) 、c r s t a l 方法、瘦开发( l e a n d e v e l o p m e n t ) 、适配性软件开发( a d a p t i v es o f t w a r ed e v e l o p m e n t , a s d ) 、特征驱动开发 ( f e a t u r ed r i v e nd e v e l o p m e n t ，f d d ) 、开放式源码( o p e ns o u r c e ) 等，其中最重要的是 极限编程。 1 3 极限编程( ) 1 。3 1x p 简介 1 9 9 6 年3 月，k e n tb a c k ；i 生总结d a i m l e r c h r y s l e r 软件开发经验的基础上，开创性地提 出了极限编程方法学。他和软件开发大师m a r t i nf o w l e r 台著的 p l a n n i n ge x t r e m e p r o g r a m m i n g ) ) 是关于x p 的奠基之作。之后，一系列的作品，如e x 仃e m ep r o g r a m m i n g e x p l a i n e d ：e m b r a c ec h a n g e ) ，让更多的人领略到了极限编程的精髓，也逐步导致了极 限编程的流行。 ) 是敏捷开发方法的一种，特点是敏捷、高效、适应需求变化，比较适合企业级 的应用开发【6 1 。 x p 的核心价值可概括为：沟通、简单、反馈和勇气【6 】。沟通与客户以及开发团 队内部持续的交流；简单总是将焦点放在最小限度的解决方案上；反馈通过单 元溟4 试和功能测试获得快速反馈；勇气积极寻求更简单的解决方法，勇于改进代码 的设计和质量。 x p 是一种近螺旋式的开发方法，它将复杂的软件开发过程逐一分解成单个小周期， 8 大庆石油学院硕上研究生学位论文 通过与客户交流、反馈，使开发双方清楚进度变化、待解决的问题和潜在困难，便于调 整开发过程【7 1 。其开发过程如图1 2 所示。 x p 最需要优先考虑的是通过尽早地和不断地提交有价值的软件使客户满意，其运 作项目的方法是分成多次迭代。 图1 - 2x p 项目开发过程图 在x p 项目的开发过程中，以测试先行的驱动方式来实现单元测试，从而测试可以 不受实现的干扰。传统测试理论的目标和相关的工具所关心的问题是程序的正确性。它 们的目的是寻找代码中存在的错误，它们的测试对象是已经存在的代码。x p 中的单元 测试并不完全是一种质量保证体系和发现错误的工具，而是一种设计方法。 编程与测试的结合有利于赢得更高的生产效率，节省调试时间，作为一种新的软件 工艺，x p 的一个中心理念是以适应式( a d a p t i v e ) ，而非预测式( p r e d i c t i v e ) 的方式开 发软件。 1 3 2x p 的特征 在9 0 年代早期，一个名叫k e n tb e c k 的人在思考更好的软件开发方法。他与w a r d c u n n i a g h a m 共同合作了一段时间，两人共同见证了一种软件开发途径：使得一切简洁、 高效。k e n t 于1 9 9 6 年3 月在d a i m l e rc h r y s l e r ( 戴姆勒一克莱斯勒) 的一个项目软件开发 中开始应用新的观念，其结果就是极限编程方法。k e n t 逐步认识到改进任何软件项目， 都有四个方面的因素。需要改进沟通、需要力求简洁、需要工作成效的反馈，以及需要 一直勇往直前。沟通、简洁、反馈和勇气，是x p 程序员所追寻的四大价值i r l 。他们与 客户及同伴沟通，保持设计的简洁明了，通过对软件的测试得到反馈，尽可能早地向客 户提交系统，依照建议迸行变更。在此基础上，x p 程序员们就能够勇敢地面对需求和 技术的变更。 x p 作为敏捷开发方法中的一员，具备敏捷开发方法的一切共性：低管理费用、高 产品质量、最大限度满足客户、采用短发布周期等。同时，x p 明确提出了4 种价值观： 简单、交流、反馈和勇气，以及“创造并支持着价值观”的1 2 个实践【“。 9 第l 章软件开发与敏捷过程 下面列举了四种价值观的含义以及创造和支撑这些价值的实践，即x p 的核心准则： ( 1 ) 沟通 项目中出现的问题往往是开发人员与设计人员、设计人员与客户之间的沟通不畅造 成的。有时程序员不把设计中的重要变化告诉别的成员，或不向客户询问自己不明确的 问题，而导致在关键性领域的决策中出现严重失误。有时管理员不向程序员询问该闯的 问题，而导致项目进度被误报。 ( 2 ) 简单 x p 的宗旨是“只做能成功的最简单的东西”。k e n tb e c k 指出与其实现一个复杂的 系统，不如设计一个能够满足目前需要的、简单的系统。由于需求变化很快，x p 提议 将今天的工作做的简单些，宁愿在明天需要更多的时间来进彳亍改进，也许它要比今天作 的复杂，但这样也比以后永远用不到要强得多。 ( 3 ) 反馈 要不断的对系统当前的状态进行反馈。反馈以不同的时间规模来进行。反馈越多， 沟通就越容易，如果沟通清晰，就能够知道应该对系统做哪些测试，同时测试又使程序 员了解到何时完成一个简单的系统。 ( 钟勇气 。 这是x p 最重要的核心准则。x p 强调要“拥抱变化”，对于用户的反馈，x p 程序 员要勇于对自己的代码进行修改。可能修复会使得原来运行通过的测试有一半出现了错 误，但是经过团队的共同攻关，最终仍会再一次向着胜利的方向前进。 勇气与沟通、简单和反馈之间相互支持。沟通支持勇气，因为它带来了高风险、高 回报的试验的可能性。简单也支持勇气，因为有了一个简单的系统，无意中被破坏的可 能性就大大减少。勇气支持简单，因为只要能简化系统，程序员就会去尝试。 x p 的四个核心准则提供了成功解决方案的标准，从这四个核心准则又衍生出了五 个基本原则用以规范x p 的开发： ( 1 ) 快速反馈：x p 提倡尽可能早的、迅速的反馈，让编程人员把注意力放在最重要 的软件功能上。 ( 2 ) 假设简单性：x p 试图把注意力集中在尽可能简单的实现上。它倡导为高效的完 成今天的工作而工作，并不计划未来对软件的扩展，而是相信自己在将来必要时有增加 系统复杂性的能力。 ( 3 ) 提倡更改：x p 强调要“拥抱变化”，有了快速的反馈，就应有对反馈结果的执 行措施。 ( 4 ) 递增更改：x p 提倡小改动，用期望的功能逐步增强系统，因为第一次就进行巨 大改动往往难以成功。递增更改应用在) 的诸多方面，设计每次只改动- - d 点儿，计 划每次只改动一小点儿，团队每次只改动一小点儿等。 ( 5 ) 优质工作：质量是最重要的。x p 强调团队中的成员要对工作充满兴趣和信心， 保持编程人员的最高水平，因为只有出色的工作才能确保优异的质量。 i o 大庆石油学院硕士研究生学位论文 传统的方法是通过提高过程严密性和增加管理费用来消除和降低风险，而x p 是以 简单的方式来考虑问题，不做多余的开发工作，有意识地培养开发人员间的默契，将合 作的优势发挥到极限，强调跟客户的交流，及时将反馈体现在产品上，从而创造出令客 户满意的产品，这一切都促成了x p 的成功。 x p 针对软件开发的每个环节，制定了一下规则和惯例，在软件开发过程中使用。 x p 方法是一种全薪的软件开发方法和管理模式，以简洁、沟通、反馈和勇气为核心。 通过简单的惯例和规则，使整个团队协同工作，充分的反馈到团队整个项目的状态和计 划进度，并能根据实际情形，对惯例做出调整。 目前，国内软件公司大多规模偏小，软件项目开发过程多数极不规范，从需求、计 划、进度、测试、发布等各环节都存在诸多问题。最常见的就是导致进度滞后、成本超 支。而x p 方法正是适用于这样的情况，针对软件开发的制约因素所制定的新型方法， 为这些问题提供了满意地解决方案。国内软件行业引入x p 方法，将x p 开发方法和管 理模式应用于国内广大中小型软件企业中，进恧由此提升软件开发能力和管理水乎，这 可以说是一条必由之路。 - 1 3 3x p 的主要思想和内容 x p 的思想浓缩在它的四个价值观【s 】上。 沟通：设计者，开发者、客户三者之间的相互交流是x p 成功的关键； 简化：是设计和编码的指导原则，不做假想设计，尽量使代码简单化； 反馈：用户能及时和详尽的意见反馈是x p 成功的保征； 勇气：是适应变化的前提，要求设计者和开发者在必须做出取舍或是重构时，勇于 抉择，勇于实践。 这四点是x p 的目标，也是要求，更是其成功的必要前提，另外，简化设计的时候 都要求设计是满足当前功能需求的最简化版本( 它能运行所有测试、不包含重复代码， 明确陈述设计者对所有代码的意图、包含尽可能少的类和方法，： 使用x p ，最显而易见的，是从一个新项目入手。开始收集用户故事( u s e rs t o r i e s ) 充 当用例的角色，但并不完全相同。u s e rs t o r i e s 用来制定发布计划会议的时间估算，也用 于取代庞大的需求文档【9 1 。由客户撰写，内容是需要系统为客户做的事。与应用场景类 似，但不限于只描述用户者界面。格式为大约三段文字，有的客户以自己的语言撰写， 没有专业术语的限制) ，指导风险事项的解决方案。做这些只需要几个星期。然后制定 发布计划会议。邀请客户、开发人员和经理制定大家都首肯的进度表。制定迭代计划， 以此为依据开始迭代开发。 通常只是在项目出现麻烦之后，人们才会寻找像x p 这样的新方法。在这种情况下， 应用x p 的最好方法，是仔细评估当前的软件开发方法，确定制约开发进度的因素，首 先用x p 来解决这些问题。举例来说，如果发现在开发进度的2 5 时，需求说明完全不 第l 章软件开发与敏捷过程 能用，那么就得和客户一起做这项工作，改为写用户故事。如果遇到了需求变更之类的 棘手问题，导致进度不停的修改，那么每隔几次迭代，试一试相对简单和容易一些的发 布计划会议( 首先需要的是用户故事) ，试一试开发的某种迭代风格，以及及时风格的计 划。如果最大的问题是b u g 层出不穷，试一试自动化验收测试。在回归和确认测试中使 用这一组测试套件。如果最大的问题是集成b u g ，可以试一试自动化单元测试。要求所 有的单元测试都通过。 软件开发项目由于内容繁杂，管理不易，可以说是个世界性的难题。人们不断对此 进行研究、探索、实践、总结、创新，产生了一代又一代的软件开发思想、方法、模式， 在不同时期对软件开发起到指导作用，使得软件开发工作以更有效、更合理的方式进行。 软件开发方法、项目管理模式，是软件开发的灵魂，直接决定了项目的进度、成本、计 划与成败。针对软件开发中存在的实际问题，引入先进的开发思想、方法、模式，顺应 国际软件开发的大潮流，是软件行业的当务之急。 有了指导性的准刚，接着就是如何进行软件开发的问题。x p 开发中的基本活动包 括四项i l o 】：编码、测试、倾听和设计。 ( 1 ) 编码：编码是软件开发中必不可少的一项工作，编码提供了简洁明了的交流机 会。 ( 2 ) 测试：有了测试，程序员可以在更长的时间内进行更多更改，对系统的信心就 会随着时间的推移不断增强。测试分为两种，一类是程序员编写的测试，来确定程序正 常运行；另外一类是客户编写的( 或是由客户指定编写的) 功能测试来确保系统整体上 以他们期望的方式运行。 ( 3 ) 倾听：普通程序员往往对客户的业务一无所知，所以，采取的方式是对程序员 进行业务培训。培训时间一般不会超过两天。另外，结对编程也起了良好的培训作用。 ( 4 ) 设计：设计是创建组织系统中的逻辑结构。传统的软件设计是自项向下的它 的前提是需求不变化，或者很少变化。但x p 认为需求是会经常变化的，因此设计不能 一蹴而就，而应该是一颚持续进行的过程。 x p 倡导简单设计，k e n tb e c k 的口号是：”d ot h es i m p l e s tt h i n gt h a tc o u l dp o s s i b l y w o r k 和“y o ua r c h ) tg o i n gt on e e di t ”( 通常称之为y a g 原则) 。核心思想就是不要为了 考虑将来，把目前并不需要的功能加到软件中来。粗看之下，这是不切实际的口号，但 在实际中，当一些软件因为复杂设计而导致开发成本上升的时候，就会发现简单的设计 是有道理的。以上所介绍的四中基本活动相互支持，相互制约。 1 3 4x p 的方法和特点 极限编程的方法，是针对需求变更的问题域的。客户对系统应该做什么并没有确定， 系统功能隔几个月就得变，在许多软件开发中，需求的不断变更是唯一的真理。这正是 x p 会成功，而其它软件开发方法的不成功之处。 1 2 大庆石油学院硕士研究生学位论义 x p 的实践准则l 如下： ( 1 ) 系统隐喻( m e t a p h o r ) ( 2 )代码集体所有( c o l l e c t i v ec o d eo w n e r s h i p ) ( 3 ) 简单的设计( s i m p l ed e s i g n ) ( 4 ) 重构( r e f a c t o r i n g ) ( 5 ) 频繁发布小版本与客户参与( s m a l lr e l e a s ea n do n - s i t ec u s t o m e r ) ( 6 ) 持续整合( c o n t i n o u si n t e g r a t i o n ) ( 7 ) 单元与功能测试( u n i ta n df u n c t i o n a lt e s t i n g ) ( 8 ) 成对开发与开放的工作空间( p a i r p r o g r a m m i n g a n d o p e n w o r k s p a e e ) x p 的大部分价值观和实践准贝f j 与a p 的基本价值观和原则是一致的，如短交付周期、 客户作为团队成员等。x p 的结对编程、隐喻、测试先行是对a p 的进一步发展和补充。 x p 也用于解决项目风险问题。如果客户要求在一个确定的日期提交个新的系统， 风险就很大。如果此系统对软件团队来说是个新的挑战，风险就更大了。如果那个系统 对整个软件界者是一个新的挑战，那么风险可谓系千钧于一发，不堪负重。x p 实践就 是降低风险，增加成功的可能性。 尽管3 0 个成员以上的较大的项目也有成功运用x p 的纪录。但x p 主要适用于成员 不是很多的中、小的软件团队。程序员可能很普通。x p 的使用，不需要程序员拥有博 士学位。不是不能在大的团队项目中使用x p ，应该指出的是，对于需求不断变更，或 高风险的项目，小的x p 团队会比大的团队更有效。 x p 需要一支广泛的开发团队。x p 团队不仅包括开发者，也包括经理和客户。大家 一起并肩作战，提出问题、协商范围和进度，制定功能测试，要求开发人员也不仅仅只 参与软件的开发。 另外一个要求是可测性。一定要制定自动单元和功能测试。在某些方面确实需要应 用一些小的测试技巧，也有可能需要改变系统设计，使得测试更容易。切忌有志者事竟 成，测试要得法。 最后一条是效率。相同条件下，与其它项目相比，x p 项目毫无疑问是效率最高的。 但这从来不是x p 方法的目标，其真正的目标始终是按时提交所需的软件，如果这一点 对项目很重要的话，那么就是时候使用x p 方