提到测试，大家都会把它归于测试人员的工作。测试人员主要在功能级别上做黑盒测试，基本以手工测试为主。极少的人会使用自动化测试。我们都明白软件开发，越到后期，错误的修复成本越大。测试人员介入测试一般都是项目的后期了，这个阶段的测试成本是很高的。因此测试需要在前期低成本阶段尽早介入，很多同学会问，功能都没有开发出来，怎么做测试呢？其实，测试本身也是有层级的，不同阶段需要的测试也不一样。

2004年左右，Mike Cohn提出了测试金字塔的概念，如下图：

整个测试分成3层，UI层，服务层、单元测试层。处于金字塔顶端的是UI测试，就是文章开头提到的这类测试。旁边的乌龟表示测试速度相当慢；美元符代表着高成本，这个成本除了指测试本身的高成本外，还意味着测试问题修复的成本也很高。中间是服务层，主要指接口或组件级别的测试。金字塔底部是单元测试，单元测试的特点是快速，运行时间在毫秒级别；针对性强，如果测试报错，直接能定位到是哪一行代码的问题。单元测试的粒度又很小，所以能快速的修复。底部的两边画了兔子和美分符，整个金字塔从上往下，速度依次加快，成本逐渐降低。

但在实际的项目中，往往都是下面这种“冰淇淋”模型：

单元测试和接口测试严重缺乏，功能开发完成后，直接进入UI测试。这种模式下，UI测试越多，就越头重脚轻。为什么测试投入了很多，整个产品的质量也不见得有多少提高？因为结构错了。开发和测试人员在无休止的bug 修复/验证循环中，身心俱疲，代码的乐趣在哪？工作的价值在哪？当这些都没有了，何来的质量？

“金字塔”和“冰淇淋”两种模式，如果在建筑行业，我相信没人会选择后者，但为什么在软件行业，“冰淇淋”模式还有大片的市场呢？

软件的质量如何来保证，戴明早已经告诉我们了：“我们应该停止依靠大量检验来保证质量，而是要改进工艺流程，从一开始就生产出优质的产品。”

对于软件项目，所谓的改进工艺流程，就是让测试具备“金字塔”的层次结构。

前两天看到朋友圈里开发在抱怨自己都要变成测试了，不禁想起之前的公司老大给我们讲“eat your own dogfood”,当时不明白是啥意思，“狗粮”这个词，本能的让我感觉不是什么好话。它原本的意思是要求员工尽量多的使用自己开发的产品，从而提高产品的质量。老大对我们开发讲这句话，意思也清楚，开发必须要对自己的代码质量负责。开发吃狗粮的方式就是金字塔的底下2层。我们当时连顶层的UI自动化测试都做了，但效果并不是太好，UI级别的自动化测试太脆弱了。

我一直认为，开发一定要有测试思维，优秀的代码是自己不断测试/重构中产生的，而不是靠外人的测试。