目录

　　1、什么是最后一公里
　　2、不得不说的“敏捷”
　　3、效率!= 时间短
　　4、测试随时随刻
　　5、关于测试环境
　　6、理想的测试
　　7、“最后一公里”的根源
　　8、如何避免“最后一公里”
　　9、总结

　　1、什么是最后一公里

　　初次接触最后一公里这个概念，应该是在大学的计算机网络课程中。

　　“最后一公里”指从通信服务提供商的机房交换机到用户计算机等终端设备之间的连接。而“最后一公里”问题其实也就是指由于每个用户的位置，设备等的不同而造成的布线困难问题。

　　接下来，让我们把这个“最后一公里”的概念延伸开去：最后一公里指的是一件事情已经进行到最后，但是还欠缺一件事，而这件事还是非常关键的。

　　在软件世界里，这个“最后一公里”问题指的就是满足了功能需求，尚未投入实际运行并创造业务价值的阶段。

　　2、不得不说的“敏捷”

　　“敏捷开发”这个词不知道从什么时候开始被无数次地提上台面。这个概念本身是没问题的，当然，他的意图是好的，思想也是好的。

　　错只错在太多人把“敏捷”的概念定位在了单独的快上，拿到需求不去架构设计，把数据库搭好，大家开始写页面。发生了需求变更，填个If，再改，加个局部标记变量，补上一个else if，我想这是很多公司都很常见的情况吧。

　　然后，Leader们美名其曰“敏捷”。然后，很多“小兵”也就跟风着说，我们公司是敏捷开发。

　　在我看来，敏捷有很多实施手段，但最后的目标有两点：A. 效率  B. 迭代。

　　注意，我这里说的是效率，而不是时间，那是因为敏捷解决的问题是节省从项目需求确定到最终版本的时间，而不是到Beta版，或者“垃圾”版本的时间。

　　关于迭代，敏捷中有这样一个概念，叫“拥抱变化”，在我看来，变化是能够保证敏捷软件完善的驱动，变化驱动迭代，架构师，开发者不去假想变化，而是由实际的变化去迭代，去完善软件，而我看来，这个才是敏捷真正的核心。

　　那好，接下来，我们就从这两个角度来谈“最后一公里问题”。

　　3、效率!= 时间短

　　小学生都会了解这样一个公式：效率=质量 / 时间。在软件世界，让我们继续来完善这个公式：

　　效率=最终版本的质量/∑时间，也就是说最终版本的质量除以整个该项目所花费的时间。对于项目如此，对于网站也是如此。

　　在这里，我还是无法免俗地反复谈测试的重要性。

　　4、测试随时随刻

　　在软件开发中，最早流行的应该是瀑布模型，然后逐渐地被螺旋模型取代，螺旋模型的核心在于：A. 每个阶段的风险评估 B. 一层一层迭代。在每个螺旋生命周期中，最后一步都是测试！

　　其实在我看来，这个模型还是不够完善的，测试应该是无处不在的。在我眼中，一个理想的状况应该是每个开发人员身旁都能配备着一个测试人员，测试人员需要对每个公开的方法进行测试，对每一个模块进行测试，这些不是在界面上点来点去，而是要编写详细的测试用例，对输入和输出都进行详细的控制。

　　接下来，是对功能性需求的测试，这个主要是针对需求文档编写测试用例，对模块或系统进行测试。这个是软件公司大多数测试都在做的事情。

　　接下来，还有很重要的一点就是性能测试以及一些附加功能，如权限的测试等等。