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

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

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

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

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

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

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

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

　　1、快速新增一个测试

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

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

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

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

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

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

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

　　测试用例1：

　　测试点1：……        开发中

　　测试点2：……        开发中

　　测试点3：……        开发中

　　……

　　然后呢，开发开始会先正常地按设计文档来进行开发功能，但是他开发到差不多的时候，他需要去检查这些测试点，如果他自己验证了这些测试点在产品里已经实现，他需要把这个测试状态变成“开发完成”，如果一个功能的测试点都通过了，这个功能才算真正完成他的这一步了。

　　测试用例1：

　　测试点1：……        开发完成

　　测试点2：……        完成90%

　　测试点3：……        开发完成

　　……

　　接下来的话，既然功能在开发那里已经完成了，测试人员会去检查开发人员是否真正完成了这些测试点，如果确认通过么，会把测试点状态设置成“测试通过”。

　　测试用例1：

　　测试点1：……        测试通过

　　测试点2：……        测试通过

　　测试点3：……        测试失败

　　……

　　不过很多时候，测试不是在一个功能开发完以后做的，而是在开发中已经在进行了，如果一个功能需要几天完成，测试人员会每天把做完的部分测一下，所以为了保证每个功能能及时开发与测试，开发人员还需要实时更新已完成的测试点的状态，因为我们每天都会产生一个Build，只要一个测试点完成了，很快会有Build进行测试，一做完更新状态有助于测试人员及时去检查与反馈。

　　另外在测试过程中，甚至在开发过程中，我们还会经常碰到两个问题，一个是功能的设计突然变化，一个是测试人员觉得测试点要修改或增减，这些都很有可能对开发过程造成很大的影响，所以对于这些事情，我们需要及时预警及时通知与调整。

　　我们公司特色的测试驱动开发大约流程是这个样子，其实一句话概括是“让开发人员能用测试人员的眼光去开发一个产品”，目前我们还在 DevSuite 系统中进行配置必要的流程（很多开发与测试人员有时候因为太忙所以很多事情的处理与反馈总是不太“积极”，所以还是有必要有系统进行约束），估计这几天能配置完成，我个人觉得一开始实施起来会很有挑战，因为这个流程需要开发、测试甚至是设计人员非常紧密的合作，任何一个小延误都可能造成后续流程的连锁出问题，比如开发人员没有及时去看测试点或者没有及时更新测试点状态，造成测试人员没有及时去测，当真正去测的时候，开发人员可能又在忙于其他功能而没延误修上个功能的Bug，而以后修Bug对产品的损伤又将是不可预测的……

　　当然，从理论上来说，光明在不远处，不过不经历些风雨怎能见彩虹，我们以前从瀑布到敏捷也经历了不少风雨，这次也会，但是相信还是能成功看见彩虹的，呵呵，以后实施成功了再Update大家具体细节。