测试驱动开发

测试驱动开发（Test-driven development）是现代计算机软件开发方法的一种。利用测试来驱动软件程序的设计和实现。测试驱动开始流行于20世纪90年代。测试驱动开发是极限编程中倡导的程序开发方法，方法主要是先写测试程序，然后再编码使其通过测试。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

测试驱动开发的比喻。开发可以从两个方面去看待：实现的功能和质量。测试驱动开发更像两顶帽子思考法的开发方式，先戴上实现功能的帽子，在测试的辅助下，快速实现正确的功能；再戴上重构的帽子，在测试的保护下，通过去除冗余和重复的代码，提高代码重用性，实现对质量的改进。可见测试在测试驱动开发中确实属于核心地位，贯穿了开发的始终。

测试驱动开发中测试的特征

测试驱动开发中需求分析和详细设计的范畴，在代码基本完毕以后，这些测试也成为单元测试的一个部分。

应用领域

新软件的开发，历史系统的维护。

测试驱动开发相关讨论

正面评价
可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。
可以让开发者在开发中拥有更全面的视角，避免过度实现带来的浪费。

负面评价
开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。
会放慢开实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品质两个方面，单纯的代码速度可能不能完全代表开发速度。
对于GUI,资料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。
使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。
测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。

XP的价值标准

最初，极限编程技术只提出了四条价值标准，而在《极限编程解析》的第二版中又加入了第五条。以下就是这五条标准：
1、沟通
2、简单
3、回馈
4、勇气
5、尊重（最新添加的价值）

沟通

构建一个软件系统的基本任务之一就是与系统的开发者交流以明确系统的具体需求。在一些正式的软件开发方法中，这一任务是通过文档来完成的。

极限编程技术可以被看成是在开发小组的成员之间迅速构建与传播制度上的认识的一种方法。它的目标是向所有开发人员提供一个对于系统的共享的视角，而这一视角又是与系统的最终用户的视角相吻合的。为了达到这一目标，极限编程支持设计、抽象、还有用户-程序员间交流的简单化，鼓励经常性的口头交流与回馈。

简单

极限编程鼓励从最简单的解决方式入手再通过不断重构达到更好的结果。这种方法与传统系统开发方式的不同之处在于，它只关注于对当前的需求来进行设计、编码，而不去理会明天、下周或者下个月会出现的需求。极限编程的拥护者承认这样的考虑是有缺陷的，即有时候在修改现有的系统以满足未来的需求时不得不付出更多的努力。然而他们主张“不对将来可能的需求上投入精力”所得到的好处可以弥补这一点，因为将来的需求在他们还没提出之前是很可能发生变化的。为了将来不确定的需求进行设计以及编码意味着在一些可能并不需要的方面浪费资源。而与之前提到的“交流”这一价值相关联来看，设计与代码上的简化可以提高交流的质量。一个由简单的编码实现的简单的设计可以更加容易得被小组中的每个程序员所理解。

反馈

在极限编程中，“反馈”是和系统开发的很多不同方面相关联的：
来自系统的反馈：通过编写单元测试，程序员能够很直观的得到经过修改后系统的状态。
来自客户的反馈：功能性测试是由客户还有测试人员来编写的。他们能由此得知当前系统的状态。这样的评审一般计划2、3个礼拜进行一次，这样客户可以非常容易的了解、掌控开发的进度。
来自小组的反馈：当客户带着新需求来参加项目计划会议时，小组可以直接对于实现新需求所需要的时间进行评估然后反馈给客户。

反馈是与“交流”、“简单”这两条价值紧密联系的。为了沟通系统中的缺陷，可以通过编写单元测试，简单的证明某一段代码存在问题。来自系统的直接反馈信息将提醒程序员注意这一部分。用户可以以定义好的功能需求为依据，对系统进行周期性的测试。用Kent Beck的话来说：“编程中的乐观主义是危险的，而及时反馈则是解决它的方法。”

勇气

极限编程理论中的“系统开发中的勇气”最好用一组实践来诠释。其中之一就是“只为今天的需求设计以及编码，不要考虑明天”这条戒律。这是努力避免陷入设计的泥潭、而在其他问题上花费了太多不必要的精力。勇气使得开发人员在需要重构他们的代码时能感到舒适。这意味着重新审查现有系统并完善它会使得以后出现的变化需求更容易被实现。另一个勇气的例子是了解什么时候应该完全丢弃现有的代码。每个程序员都有这样的经历：他们花了一整天的时间纠缠于自己设计和代码中的一个复杂的难题却无所得，而第二天回来以一个全新而清醒的角度来考虑，在半小时内就轻松解决了问题。

尊重

尊重的价值体现在很多方面。在极限编程中，团队成员间的互相尊重体现在每个人保证提交的任何改变不会导致编译无法通过、或者导致现有的测试case失败、或者以其他方式导致工作延期。团队成员对于他们工作的尊重体现在他们总是坚持追求高质量，坚持通过重构的手段来为手头的工作找到最好的解决设计方案。

XP 核心的实践

极限编程的12个实践是极限编程者总结的实践经典，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。

1、小版本。为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。

2、规划游戏。就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。

3、现场客户。极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。

4、隐喻。隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。

5、简单设计。极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：1、通过测试。2、避免重复代码。3、明确表达每步编码的目的，代码可读性强。4、尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。

6、重构。重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。

7、测试驱动开发。极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。

8、持续集成。集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。

9、结对编程。这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。

10、代码共有。在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。

11、编码标准。编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。

12、每周40小时工作。极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。

在第二版的Extreme programming explained中，在主要实践之外，还列出了一系列延伸的实践。

核心实践源自被广泛接受的最佳实践，并且被推向极至：

开发人员和客户之间的交互是有益的。因此，一个极限编程的小组从理论上要求需要一个软件使用者在身边，这个使用者制定软件的工作需求和优先等级，并且尽可能在各种问题出现的时候马上就能回答（实际工作中，这个角色是由客户代理商完成的）.

如果学习是好的，那么就把它做到底：这样减少了开发和回馈周期的长度，测试也能更早完成。

简单的代码更可能工作。所以极限编程的程序设计师在一个软件专案中唯写出能够满足目前实际需求的代码，这样或多或少降低了代码的复杂性和重复性。

如果简单的代码是好的，那么把变得复杂的代码改写成简单的。

代码评审是好的。因此，极限编程的程序设计师以两人搭档的方式工作。他们共享一个屏幕和键盘，增加了队员之间的交流，也让代码在一被写出的时候就被人评审了。

测试代码是好的。因此，在极限编程中，测试用例在实际代码之前就被写出来了。代码只有在通过测试的时候才被认为完成了。（当然，需要进一步分解来降低复杂性）。整个软件系统用一种周期化的，实时的，被预先变好的自动化测试方式来保证它的确有作用。参看 测试驱动的开发。

一般来说，极限编程被认为对于少于12人的小团队很有用。一些人认为极限编程可以用于大的团队，但是其它人认为统一软件程序更适合大的团队。然而，极限编程在一些超过100人的开发小组中获得成功。并不是极限编程不能够推广到更大的团队，而是很少有更大的团队来试著用它。极限编程的人员也拒绝去随便推测这个问题。

RUP：Rational Unified Process，统一过程

Rational统一过程(RUP)是Rational软件公司（现在Rational公司被IBM并购）创造的软件工程方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。

在软件工程领域，与RUP齐名的软件方法还有：
净室软件工程（重量级）
极限编程（extreme programming）和其他敏捷软件开发（agile methodology）方法学（轻量级）

产品生命周期中的指导方针和模版

RUP为项目成员定义了在一个产品生命周期中如下指导方针和模版。

迭代式开发

给定的时间内，开发一个大型的复杂的软件系统，定义问题并构建解决方案是不可能一蹴而就的。在项目的开发过程中，由于体系结构方面的约束，客户的需要或对原始问题更精确的理解，需求会经常地变更。迭代式开发允许通过后续的细化产生对项目更好的理解，并在每个迭代的阶段，把项目的最高风险的事项作为最高优先级的任务集中精力解决。理想的，每一次迭代都以一个可执行的发布为结束，这样可以减少一个项目风险，更多地允许客户的交互并帮助开发人员集中精力。

管理需求

对于任何大型项目来说，一个文档框架是必不可少的；因此RUP描述了如何描述功能性，约束，设计决定和业务需求。

用例和场景是过程规定的制品的例子，在贯穿系统整个开发和部署的过程中，用例和场景在捕捉功能需求和提供一致的线索上是非常有效的。

使用基于构件的体系架构

基于构件的体系架构（CBA）创造了容易扩展的系统，并提升了软件的重用性和可读性。一个构件经常与面向对象程序设计中的一个对象有关。

RUP提供了构建这种系统的一个系统化的方法，关注于在把所有资源投入到一个项目之前，开发出一个早期的可执行的体系架构。

这些构件通过一些基础平台，如CORBA和COM组装在一起。

软件的可视化建模

将你的程序设计从代码上抽象出来，并用图形化构件块展现出来是得到解决方案的全面意象的一种有效方法。这对于项目的技术人员来说，一方面，能够更容易地勾画出如何最好的实现一个给定逻辑集合的轮廓，另一方面，能够更容易地构造在业务过程和实现业务过程的实际代码之间的中间物。

统一建模语言（UML）是表示项目的产业标准方法，因此经常被RUP使用。

验证软件质量

质量评估是所有软件项目中最经常的失败所在，因为通常这样项目的仅仅在项目总结中进行质量评估和甚至由另外的团队来进行质量评估。 RUP在规划质量控制和评估方面有所帮助，并把质量控制和评估包括在每个项目成员都参与的整个过程中。

控制软件的变更

在所有的软件项目中，变更是不可避免的，RUP定义了控制和监控变更的方法。一个表面上很小的变更可能以完全不可预计的方式对应用程序产生影响，这一点对一个成功项目至关重要。RUP同时定义了安全的操作环境，保证一个程序员对另一个系统的修改将不会对他系统地修改。这一点与基于构件的体系架构有很大的关系。

迄今为止，这些指导方针是通用的，可以在一个项目的生命周期中遵守。为了把握一个项目的时间尺度，RUP把一个项目分为四个不同的阶段：
构思阶段
细化阶段
构建阶段
移交阶段