也许从眼前来看，这样的进度效率上是慢了，但是从整个项目的进度来说，这样来做会让我们交付的每个版本都是一个可靠的版本，换句话说，“增加了开发成本，减小了维护成本”。

　　对于产品公司来说，每个公司都不希望客户天天打客服电话抱怨Bug；对于网站来说，每个人都不希望用户点了某个按钮却来到了一个错误页面。

　　对于某些由用户来代作测试的做法，个人更认为是极其可笑的！这正如某个程序员写了一段效率极低的代码，当Code-Review时，他说，这是CPU太差，换个好的硬件，加内存，加CPU，就好了。都是非常不负责任的做法。

　　也许这个时候会有人说，大到微软，小到豆瓣还搞两个Beta版呢，可是这里不得不说一句，兄弟，你又错了，他们发布Beta版不是为了让你点出哪个按钮出错误，而是为了搜集用户的需求，更好地完善功能而已，改进！=改Bug。

　　5、关于测试环境

　　什么是测试环境？我的定义是可以基本模拟真实生产环境的供开发，测试人员使用的虚拟的，不对外公开的环境。

　　在这里我突出两个要点：A. 基本模拟真实环境 B. 虚拟的环境

　　A否定了把本机作为测试环境。B否定了把真实环境作为测试环境。

　　本机的作用用于保证代码的基本逻辑无误，但是想用本机的简单测试来作为发布的测试环境，是非常可怕的。首先，本机连接的数据库与真实的环境一般来说都是有较大差距的，其次，本机的配置与服务器的配置差距是很大的，用本机做出的测试的响应时间几乎是没有任何参考价值的。最后，很多的真实环境是本机无法模拟出来的。

　　对于产品公司来说，一台测试服务器，对于互联网公司来说，一个测试站点的重要性都是不言而喻的。也许有些朋友认为我在说废话，可是我们看看身边，没有去投入去做的公司，我想大大存在。

　　6、理想的测试

　　在Roy的文章中，提到了要把测试脚本，安装脚本，配置文件也作为产品交付的一部分。

　　从理论上说，我认同这样的观点，迭代不仅仅是对代码的迭代，同样应该包含对这些测试脚本的迭代。

　　可是考虑中国大多数公司的现状，这一点，只能停留在理论阶段。

　　7、“最后一公里”的根源

　　Roy在文章中举了一个让我觉得非常恰当的例子。大致意思是这样的：

　　一个人白手起家开公司，做了一个软件，功能很少，加上这个人的人手很紧，时间很急，项目做的很垃圾，但是因为功能很少，所以还看不出来，也涉及不到什么维护的成本。软件的销量不错。

　　但是逐渐的，这个软件庞大了起来，这个人一想，唉，在这个基础上加功能吧，这样比较容易，好吧，功能还是很少，没有问题。

　　这个项目越做越大，终于有一天，原来的项目已经被修得惨不忍睹了，维护成本也大得惊人了，不得不对产品进行重构了。可是这个时候，项目已经太大了，重构的成本也太大了。

　　这就是存在“最后一公里”问题的软件的根源！

　　一句话总结，“得过且过”成全了“最后一公里”。