测试驱动开发（Test Driven Development，简称TDD），可能挺多人都接触过，它大约诞生于上个世纪九十年代（好像很久远，其实也还好，大约1996年），属于极限编程的一部分。

　　也许有人会问，这么“古老”的东西今天还来介绍干嘛呀，呵呵，名正言顺的回答是，古老的瀑布模型都现在还在用了，这个相对“现代”的当然还能讲了。当然原因并非如此了，这几天领导们觉得产品质量得提高一下，分析了一下原因，觉得用TDD方法应该会比较有用。所以呢，我们就需要开始这个旅程了......

　　下面我就来介绍一下，具体我们具体碰到的问题，以及怎么来实施测试驱动开发吧（当然成不成功还说不上，但是万事总需要一个开始！）

　　以前的文章也说过了，我们是用敏捷的方式，主要是Scrum来管理我们公司的软件开发整个过程的，从需求获取到设计到开发到测试，都是用 TechExcel DevSuite 系统来进行管理，从理论上来说这样管理应该是没啥问题的，每个迭代周期中，开发做完一个功能，测试就可以投入测试工作，发现问题及时解决。但是理论总是需要实际来检验的，这种模式运作一段时间以后，陆陆续续发现还是存在着不少问题，不过主要的问题还是一个，就是Bug总是很多，倒不是说开发能力问题，而是很多Bug涉及到的地方开发人员想不到，开发总是认为自己已经很好地实现了设计的意图，所以产品是Perfect的，但是测试人员总是发现了大量的问题。

　　就这样子，Bug很多，必然会产生几个结果，一个就是开发人员能力被怀疑，第二个就是为了修Bug，又花费很多时间，最后一个当然就是产品质量总是上不去了。

　　其实开发人员也挺无辜的，一个功能的测试点不可能在设计文档里方方面面都写到，而且测试人员很多测试点可能并非是常见的操作，不过现在问题出来了，总是需要办法解决的，思来想去，领导们想到测试驱动开发这个概念，当然我们公司这个测试驱动开发的概念跟其真正的概念还是有点区别的，标准的概念应该是如下：

　　测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码，然后只编写使测试通过的功能代码，从而以测试来驱动整个开发过程的进行。这有助于编写简洁可用和高质量的代码，有很高的灵活性和健壮性，能快速响应变化，并加速开发过程。

　　测试驱动开发的基本过程如下：

　　1、快速新增一个测试

　　2、运行所有的测试（有时候只需要运行一个或一部分），发现新增的测试不能通过

　　3、做一些小小的改动，尽快地让测试程序可运行，为此可以在程序中使用一些不合情理的方法

　　4、运行所有的测试，并且全部通过

　　5、重构代码，以消除重复设计，优化设计结构

　　简单来说，就是不可运行/可运行/重构——这正是测试驱动开发的口号。

　　我们而言，因为有自己的实际情况，所以就采用它的思想，但是用自己的方式去实现，其实测试驱动开发的思想就是“测试的目的是让你知道，什么时候算是完成了。如果你聪明，你就应该先写测试，这样可以及时知道你是否真地完成了。否则，你经常会不知道，到底有哪些功能是真正完成了，离预期目标还差多远。”

　　根据这个思想，我们对开发流程作了一些改动（原有的开发流程就不多讲了，详见我之前写的文章），对于一个设计好的功能，测试人员需要先开始写测试用例，虽然产品还没有出来，但是根据设计文档，基本上也知道是怎么样的一个功能，所以按照标准的测试点与自己的一些想法，先把测试用例写出来，基本上在真正测试时，这些测试点测完，其实这个功能也就测得差不多了：

　　测试用例1：

　　测试点1：……        开发中

　　测试点2：……        开发中

　　测试点3：……        开发中

　　……