我们知道整个Test Cycle的样子，我们知道功能测试是很重要的。其采用的方法也是很普通的，根据需求写测试用例，站在功能是否被实现或被完美实现的角度去写测试用例，然后按照测试用例来执行所写的测试用例，发现了一定的bug。似乎很合理，似乎无懈可击看。但平静的湖面下面是否存在怪兽呢？

　　第一次听到测试手段的概念，无法理解，觉得测试手段和测试类型几乎差不多，估计是在炒概念，最近很流行。但了解了James Bach的思想后，感觉自己错了，测试手段使测试更加富有，更加活跃，更加专业。

　　我们最熟悉的就是功能测试了，显然功能测试相对于性能测试，接口测试，安全测试，就是一个特别典型的测试类型，我们会对测试类型进行不同的测试策略。那么这里我们从测试手段来考虑，功能测试只是一个测试手段，属于功能测试（测试类型）。我们还可以把功能测试手段和兼容性测试类型给结合起来，好吗？

　　测试手段关注与多个方面：测试员，覆盖率，潜在问题，测试活动，评估

　　那么我们的功能测试其实就是关注测试内容的基于覆盖率的测试手段，逐个测试每个功能，彻底测试每个功能，直到可以确信该功能没有问题。这里面包括白盒功能测试（单元测试）和黑盒功能测试。

　　另外还有些关注测试内容的基于覆盖率的测试手段：

　　特性与功能集成测试：一起测试多个功能，已check功能在一起执行的情况

　　菜单浏览：遍历GUI产品中的所有菜单和对话框，使用每个可以的选项

　　域测试: 使用等价类和边界值方法进行变量输入测试

　　等价类分析: 测试等价的一组变量的取值测试

　　还有很多没有写出来，说一个共同点：就是其实我们的其他很多测试手段都是在广义上的功能测试剥离出来的，也就是说，我们淘宝现在做的功能测试其实都或多或少的包括这些测试手段，但是做到的程度就不一样了。

　　我们测试执行的时候：考虑说要站在用户使用的角度，要站在功能设计是否合理的角度，要站在破坏者的角度，要站在功能是否正确的角度，要站在市场的角度。等等。不同的角度去测试，就会发现不同的bug。

　　我们做功能测试的时候，会全面考虑这些角度，但我们的比重是非常清楚的，也就是我们更多的关注这个功能是否正确，是否符合需求。其最常用的手段就是上面说的彻底的测试每个功能，就是功能测试。

　　那么如果我们看其他的手段，可以发现我们实际在做的功能测试都包含这些测试手段，但一个人的精力是有限的，你把更多的权重放在这里，其他的地方的权重会相对减小。我们为啥会这样呢？ 我们没有深入的分析功能测试发现的bug和使用不同的手段去进行功能测试带来的好处。

　　加上同一个角度的测试执行带来的浮躁和系统免疫现象，我们功能测试的手段的单一性带来的结果是值得怀疑的。我们使用不同的手段去进行类似于功能测试的测试执行，会发现很多bug，这些bug表面上看象功能测试应该发现的bug，象用户测试应该发现的bug。一般情况下什么样的测试手段决定发现什么样的bug。当然不同的手段之间也会存在交集的，也就是说使用ET手段去测试，站在的角度也许会存在变化(在测试执行中)，所以其发现的bug会很有可能是其他测试手段应该发现的bug。

　　总之，测试手段的多样性带来的成果是可观的。当然，成本也是需要考虑的。

　　说的很抽象，后续想想怎么比喻好一点。