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

　　测试用例1：

　　测试点1：……        开发完成

　　测试点2：……        完成90%

　　测试点3：……        开发完成

　　……

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

　　测试用例1：

　　测试点1：……        测试通过

　　测试点2：……        测试通过

　　测试点3：……        测试失败

　　……

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

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

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

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