【推荐】极限编程的十二大原则——测试

测试：一个功能存在的前提是有一个测试能够验证它，任何有被破坏的可能的代码就必须有一个对应的测试。

以前当硬件环境有限的时候，程序的编写非常讲究效率，对内存的使用都要精打细算。很快的，硬件环境极大的改善，开发工具越来越“傻瓜”，程序员们再也不用精打细算的过日子了，然而渐渐的，程序员的简洁意识也越来越薄弱，所以，内存泄露的问题越来越严重。

我印象非常深刻的就是以前听过一个同事讲过这样一件事情：他们做软包的部门有一次将测试完成后的程序交给外方，结果外方根据他们的测试用例逐一验收，结果当一个操作重复进行了将近500次的时候，程序崩溃了。当外方将这个信息反馈给中方人员的时候，他们的第一个反应就是“这帮人疯了，谁会去重复做一个操作这么多次啊！”，因为他们在测试的时候就是做一次，得到一个结果正确了就算通过了。

测试原则在我理解中应该是敏捷开发中最重要的原则。因为对于敏捷开发，它是欢迎变化的，也就意味着频繁的修改。如果这种频繁的修改没有测试做保证的话，那么最终的结果只能是一堆错误百出、隐患重重的垃圾。这其实也是很多敏捷开发的实践活动没有取得成功的重要原因：在实践中没有抓住测试这个环节，忽视了测试的重要性，或者就是根本没有能力做到符合标准的测试的能力就急急忙忙的进行敏捷开发的实践。

和很多人谈起敏捷开发、极限编程的时候，大家对于结队编程、工作40小时、减少文档这类特点最感兴趣、羡慕不已，仿佛敏捷开发的这些特点才吸引了他们去关注敏捷开发的。却忽视了对测试、重构这些真正需要我们认真思考的原则，一说起测试的问题，他们就会说这些我们现在也在做啊！可是，我们有没有认真地考虑过我们现在做的测试是否全面了，对测试的目的、意义、方法的认识是否到位了？

极限编程中对测试总结了7种类型，来看看吧，我们目前的测试能做到哪些？：

（1）自动化回归测试（Automated regression test）

运行自动化测试代码来验证当前的修改没有破坏已有的功能。

（2）单元测试（Unit test）

验证单元级别的代码工作是否正常。

（3）公共API测试（Public API test）

验证被第三方开发人员调用的API可正常工作，并且得以文档化。

（4）私有API测试（Private API test）

验证内部使用的API工作是否正常。

（5）命令行测试（Command-line test）

验证在命令行输入的命令工作正常。

（6）用户界面测试（User interface test）

验证界面层的功能是否正常。

（7）“狗粮”测试（Dog-food test）

这里用了一个有趣的名字“Dog-food test”，自己的“狗粮”自己先尝尝！在企业内部使用自己开发的产品，通过这种实际地使用来确保功能正确，满足使用要求。

开发人员会有一种长期沉积的观点：测试，那是测试人员的事情！我们虽然要求提交测试之前要有自测，可是我看到的也仅仅是一个自测报告，我们自测的时候是否有测试用例？是否有测试代码？这些测试代码都是否做了很好的保存，以便将来修改程序时能够复用作回归测试？

在以前的软件开发团队中，我们要求对所有的数据层（java程序）都要有单元测试代码，用来测试输出的XML格式数据，并将这个XML格式数据作为接口提交给界面层（javaScript、HTML）测试界面功能，同时还要对中间的业务层（java程序）作单元测试验证业务功能的输出输入。这些都是开发人员自己利用Junit框架编写的测试用例和代码，而所有这些也都跟源程序一样规划目录结构，作为源程序结构的一部分进行版本控制。这些方法就保证了当人员的变动时、当程序需要修改时，通过这些单元测试代码可以有效地保证软件变更后的功能验证。

其实我一直都觉得，无论软件、硬件开发，测试人员应该是有丰富的开发经验，并且要有比开发人员更深入的思考水平。如果进行敏捷开发实践的话，开发和测试人员的区别无非是负责编码和负责编写测试代码的区别，而从编码难度上，两者是没有什么差距的，甚至从思考的程度上，编写测试代码要更想得更多、更深入一些。

可以看出，敏捷开发中对测试的要求如此之高，也就对所有希望进行敏捷开发实践的团队提出了一个很高的要求：我们是否能够有能力将测试提到如此高的层面？我们是否有能力如此之高的测试人员？我们能够坚持无论任务多么紧张，都不能裁减测试的原则？所有的这些问题从本质上说其实都是对长期以来沉淀的观点、思维习惯的一种挑战。因此，敏捷开发与其说是一种开发方法，不如说是一种开发理念，它需要的其实是我们观念上的变革！