我的测试驱动实践

测试与交付是程序员每天都要面对事情，除了一些成熟的或则具有较高质量要求的企业会有一套比较完成的测试和交付流程外，实际上很多情况下，这两方面做的真的不是很好，即使是在一些知名的公司。这种情况在国内尤甚，我们对软件的追求是时间高于一切。
没有具体统计过，在不规范的开发过程中，由于 修复 BUG 而浪费的时间到底占整个开发过程的比例是多少，但是为了追求在某个不合理时间点的交付而造成的质量低下问题，会造成我们浪费了大量的时间在 BUG的泥潭中不能自拔，最后甚至整个团队都几近崩溃。
其实结对编程与测试优先的开发策略能够很好的解决产出成果质量的问题，起码可以极大的提高软件的质量，虽然用在开发阶段的时间多了，但是整个软件的交付周期缩短了。但是从我周边的情况来看，真正实践结对编程或者测试优先的个人或者团队真的很少，在国内的大环境下，遇到一个懂你的上司很难，还要让大支持你的行为，真的很难。
最近在开发一个应用，是一个协议的解析程序。由于协议对应用的行为有了很好的定义，所以我们实践了一把测试优先开发，先写测试用例，再完善功能，每个用例必须通过以后才进行下一 Case的开发，最后项目顺利结束，并且我们的软件质量非常高，由于测试覆盖率很高，所以上线后最初一段时间内几乎没有BUG出现，极大的振奋了团队的信心。这里简单的总结了一下给我们带来的好处。
一、质量可靠，这个就不用多说了，由于是按照需求来写测试用例，并且每次提交都要保证所有的测试用例必须通过，有不通过的情况必须马上解决，否则代码就无法CheckIn。所以在最后验收时，协议所覆盖的功能我们都正确的实现了。
二、对成果有信心，由于每个功能都经过了测试，所以我们对集成测试和用户测试，以及最后的上线都很有信心，没有之前的上线焦虑和恐怖，不用担心半夜被电话骚扰和回滚。
三、持续的回归测试，由于测试时代码提交时触发的，所以每次对修改的测试都是对所有模块的验证，防止出现因为修改造成以来功能的异常。
四、开发进度容易掌控，由于是按照功能进行迭代开发，我们对已经完成的功能很有信心，我们的注意力主要集中在当前功能的开发上，程序员们都知道，专心做一件的效率最高，毕竟质量也高，如果经常因为之前的问题备受打扰，整个人的感觉就不好了，产出也就好不到哪里，最终就是一个恶性循环。
五、领导能够看到项目的进展，领导可以清楚的知道我们的进度，那些功能已经完成，并且可以向用户展示这些功能，因为我们确实是完成了这些功能。
六、节省了测试人员在功能上的测试时间，这一点测试人员非常点赞这种做法，他们巴不得不用测试。

当然还有很多，我就不再挖掘了。采用测试优先的开发方式也会带来几个方面的改变，这些改变可能在刚开始的时候还有些不适应。
一、开发时间长，由于开发时间包含了单元测试用例的开发时间，时间长是自然的。
二、测试用例开发难度，并不是所有的用例都是那么容易测试，模块间的依赖测试、环境测试、性能测试这些非功能性测试却非常的占用时间，并且其测试用例的开发周期普遍要大于功能的开发周期，并且时常需要研究如何编写测试用例才能更好的覆盖所有的功能，有些难度要超过开发功能的难度。
三、测试用例的运行时间会随着功能的增多越来越长，这是自然的，可以采用一些技术手段来提供测试效率，比如采用并发测试等。

实际上越是到项目后期，测试的作用就越发明显，系统越来越大，过去改了一个 BUG引入 一堆BUG的经历历历在目，有了测试用例做保证，心总算可以放下了。交付时更有信心，自动测试毕竟比依赖人的测试要可靠多了。

自动测试与持续测试都不是什么新鲜的东西，很多人都懂，都能侃侃而谈，但是真正实践过的有多少；这些不需要多少的理论支撑，这是实践。
当你用过它你就会爱不释手。