| 词条 | 用例驱动开发 |
| 释义 | 用例驱动开发，TDD(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD得原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。 简介TDD得基本思路就是通过测试来推动整个开发得进行，但测试驱动开发并不只是单纯的测试工作，而是把需求分析，设计，质量控制量化的过程。 TDD的重要目的不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员去除模棱两可的需求。TDD首先考虑使用需求（对象、功能、过程、接口等），主要是编写测试用例框架对功能的过程和接口进行设计，而测试框架可以持续进行验证。 优点：在任意一个开发节点都可以拿出一个可以使用，含少量bug并具一定功能的产品。 缺点：增加代码量。测试代码是系统代码的两倍或更多。 用例驱动开发我们做任何事情，背后都有一股驱动力。简单地说，人类的多数行为都是受到“欲望”驱动。 我们做程序员的，也需要一股实实在在的驱动力，来驱动我们完成手头的工作。如果找不到这股驱动力，或者驱动力不够强，我们便会觉得心烦；随便上上网，看看技术文章，学学新技术，不知不觉，一天就过去了。 要高效地编写代码，需要高效的驱动力。 用例驱动，是一种高效的驱动力。 创新TDD 无疑是一种创新方法，或者说是 Kent 独创的方法（当然，Kent 老是把贡献归功于自己的老搭档 Ward Cunningham），而“创新”方法的问题就在于它的“创新性” —— 除了创造者之外，过去没有人熟悉它，没有人想到它，或者说大家过去都不是那么干的，所以 TDD 才能引起轰动，才能激发大家学习的好奇与热情。 那么，问题就来了：难道过去的方法都不行了吗？世界上只有 Kent Beck 一个顶呱呱的、最聪明的程序员吗？答案肯定是否定的。道理其实也是很简单，过去十年里世界上大概有成百上千个相当成功的项目，可这些项目也没有用 TDD，Kent 也没有参加过这些项目呀。 过去十年来，我也一直在编程（从海底、平原到高原，各个层次上的），我本人也亲历过不少成功的项目，有些还是相当 tough 的。我还认识不少国内外一流的程序员，他们都远比我聪明。可在我的印象中，他们好像也不完全是像 Kent 和 TDD 那么做的，也就是说他们拥有不同的成功故事。 一两个人的最佳实践与成千上万人的最佳实践，含金量明显不同。所以，搞清楚 TDD 与我们传统的最佳开发方法（最佳实践）的真正区别就很有必要了。TDD 到底与我们这些普通人（大众成功者）过去的做法有何不同？TDD 的真正价值到底在哪里？它对传统是颠覆，还是互补？它有没有缺陷、漏洞？我们怎么用 TDD，让它发挥最大价值？我想，通过认真、严肃的比较和研究，这些问题就能逐一搞清楚。 Kent 在 TDD 这本书中一共用了 17 个章节讲述了一个 Money 测试驱动开发的故事。在 2006 年的这个暑假里，我打算用我所掌握的、熟悉的方法也把这个 Money 案例从头到尾做一遍。其实上周的某个下午，我已经在 Eclipse 上把结果（答案）做出来了，花了近三个小时。从这次试验中我获得了不少有趣的结果，剩下的工作就是如何用可亲的文字把我的研究成果告诉大家，与大家分享。 我把我所采用的这个常规方法叫做 UDD（Use Case-Driven Development）。现在外面叫“用例驱动”的方法有很多，所以我只好再加一个前缀，叫 ZX-UDD（暂定名）。我有可能把这个案例分析做成一本电子书（open book with source）。当然，这本书还暴露了我所拥有的，也是天下所有程序员所共有的?—— 证明我们不是总是比大师笨，即使诸葛亮也有不敌三个臭皮匠的时候（joking）。 UDD vs TDD在开始案例讨论之前，让我们先做一下简短的理论性分析。 既然测试可以驱动开发，那么请问，什么驱动测试呢？答案是：软件需求，具体来说就是反映用户使用目标的 Use Case（用例）。我们知道，test case 是用例的一个实例（instance），与用例执行的一个情节（scenario，又译场景）相对应。 系统分析项目总体概述业务描述 上海普信仓储有限公司是一家第三方的专业提供低温仓储与配送的公司。我们为客户提供冷链食品以及其他需要在低温下保存的物品的仓储及配送服务。 服务（１） 零散仓储 （２） 包库仓储 （３） 仓储配送 （４） 对外运输。 不同的服务方式，决定了不同的计费方式。 零散仓储：是指物品寄存于我公司，客户不关心具体存放的位置，只需要存放进去就可以了。 然后客户来我公司通知我公司出库。这时，对于某个品种，有两种计费指标，一个是按面积，一个是按吨位。以客户的某个品种第一次入库为时间限，然后以一个月为计算单位，一个月内，每平方或者每吨收款。到了指定的日期，就自动生成了应收款凭证。 包库相对于零散仓储，包库就简单一些，包库只需要将指定的库位包给客户就可以了，然后按月收费。 仓储配送：是指我们既为客户提供仓库服务，又为客户提供配送服务。这里我们往往跟客户谈的是：一年之内，整个交易额的百分比作为仓储费，百分比作为配送费。但为了核算成本的需要，我们也需要知道这一年内，客户仓储的总吨位。 对外运输：鉴于我公司将购置一定数量的冷藏车，有可能在淡季的时候为客户提供冷藏运输服务。 对于零散仓储和包库，我们在每次进出库的时候，还会有一个速冻费（或者预冷费）和上下力资费用产生。 围绕着以上的核心业务，我们同时会产生以下的数据 客户应收款车辆的维护保养费用情况 入库单，出库单，配送单，财务结算单等。 除此之外，为了给提供我们的办事效率，以及减少产品过保质期的损失，因此我们需要对库位进行科学的安排，以及对保质期进行科学的管理，入库到指定的位置，出库到指定的位置去取。 我们的库位共分为四级，先是1－13的冷库间，然后是以每个冷库间的门为左右的库位，然后，以ABCDEF命名，定位于每冷库格，每个格从入口处到里，又可以划分为7列，每列放10个铲板。 一般我们这样定义库位1左A0201表示每个冷库的左侧的A格第2列的01个铲板。 我们允许库位的定义在最末一节可以根据客户的自定义来处理。将01-10这十个铲板分为前，中，后。也可以分为其他。 TDD 本质我们知道 XP 中的需求是以“用户故事”（User Story）的形式描述的，而用户故事实质上就是一种软件“特性”（Feature），所谓的“用户故事”不过是特性的一个别名而已。为什么 Kent 不把 TDD 叫做 F(eture)DD 呢？大概是因为 FDD（Feature Driven Development）这个名称已经被别人用去了，FDD 是另一种知名的敏捷方法。当然，Kent 的用户故事与 FDD 的 Feature 是两种略有区别的特性。 |
| 随便看 |
百科全书收录4421916条中文百科知识，基本涵盖了大多数领域的百科知识，是一部内容开放、自由的电子版百科全书。