测试从来是软件开发方法论中非常重要的组成部分。尤其是随着精益敏捷思想和方法的流行，没有人会反对测试驱动开发的思想，但是测试是个极容易被误解混淆的概念，它包含了太多东西在里面，虽然说同一个词，不同的人其实在说不同的东西。
从广义上来说，任何软件系统或者工程设计，能否达到设计的预期，本身都是需要测试来证明的，不可能自然而然存在即证明。所以是否达到目的肯定是在某个维度上进行测试的结论，只是有些太过于自然不被察觉。其实从这个例子，就已经显示出来，测试应该是需要在思想和方法论上，划分出不同的层次和维度。
在不同的视角去看，对应着不同的开发哲学，需要对应的工具来实施；例如回归测试，也是一个教科书上的常见概念，对原有系统原有功能进行修改之后，要引入回归测试，验证系统是否正确。在这里回归应该是在软件开发的流程视角看到的测试。在实际的工程中，必不可少的是自动化单元测试，借助代码层的xunit或者js领域的mocha、jasmine，在代码发生变更后，及时运行原有功能的测试，并增加对新变动的测试，实际上就在进行回归测试。
单元测试层面之后，还有验收测试，这里可以有人工测试，更应该可以验收测试驱动开发，可以根据剧本人为运行流程，也可以通过一些框架来自动运行，并且形成一个完整的代码库。selenium、robot可以用来完成。验收测试一样需要回归。
还有集成测试，在mvc中，就是对应的在模块层面，将架构中的各个类整合起来，通过一些mock来验证接口和框架。
当然传说中的黑白盒测试等等，既要用在单元测试，也在验收测试中用到。
作为开发流程一部分，在敏捷开发的持续迭代和重构开发中。似乎已经不是很显示的需要回归的概念。不断重构迭代，随时都在开发新的用户故事，使用验收测试驱动开发和单元测试持续迭代是自然而然的。
功能测试，个人觉得应该是通过验收来完成的，验收主要就是验收用户故事是否能够被开发的程序满足。
至于性能测试又是另外一个维度的事物，有独特的价值理念和方法工具，以不同的方式评估系统架构的其他方面。
在实际的开发中，开发环境的搭建，测试环境，灰度发布，勉强也能沾到测试。这个至少在不大的，不需要太复杂分布式配置管理的系统中，为了达到各自的目的，其实对开发有着和单元测试一样的要求。
回到根本，我自己的经验是，当我们谈设计的时候，其实我们是在谈的本质的东西，是软件的研发，怎么跨越从需求到设计再到实现的鸿沟，准确保证符合需求，满足性能、功能、健壮性、实时性等指标。这个需要的并不简单是某种强大的工具，没有什么银弹会自动解决这个问题。归根结底还是怎么设计软件、设计架构，只有可测试的设计才能生产出可测试的代码。正如敏捷软件开发中罗伯特马丁举的例子，从用户故事开始，设计，讨论，产生验收测试用例，验收测试驱动开发；然后是结对编程，单元测试驱动开发，产生详细设计。在每个方面，借助不同的工具，例如selenium、testng在不同的层次，自动化测试也会产生自己的基于工具方法论，这里也不是自动的用工具就完成测试，而是用设计良好的测试代码架构，能够自动测试业务。
