项目延期，造成我们不得不去编写更多的代码。所以与其“浪费时间”去不停地测试代码，不如不停地去开发项目。而这样做的结果就是代码质量进一步下降，并最终（或早或晚）导致返工。返工又通常会在最有限的时间里变得十分紧急（有些人叫这种现象为“墨菲是个乐天派！”）。其实返工什么也改变不了，项目现在只会进一步被延迟。很奇怪吧，我们编写越多的代码，我们的项目完工越晚。一种常用应对措施是让更多的开发人员被参与到项目的研发中，然而这样的作用也只是加剧消极反馈循环而已。

　　若项目缺乏测试，在验收和生产环境时，通常用户则会发现许多 bug，这将会快速地降低用户对项目的信任度，从而产生消极反馈。这种反馈传递给（工作过度的）开发人员，就造成开发人员“疲劳”现象。后果就是开发人员工作积极性下降，开发人员离职，……，项目又进一步延迟了。

　 　五、打破消极循环

　　我想你已经想到有一个办法可以解决这种现象。让我们来绘制一幅不同的场景：我们可以从一个理想计划“项目按时完工”开始。我们开发代码，然后立即测试它。测试最好是自动化（编码实现）的，这样我们可以轻松有效的去执行它们。我们把开发和测试紧密的结合在一起，每个开发测试循环可以很快速的执行。当一个开发测试循环结束时我们有信心保证代码质量是很高的，因为它已经通过了测试。而且用户因为发现缺陷（bug）的数目变少而对我们继续高度信任。即使他们发现了一个缺陷（这依然是有可能的），我们也可以扩充我们的测试集合，去避免相关缺陷的重现。如此下去，返工将不再是必须的，项目得有继续。如果我们的项目已经延期了，就需要我们花些时间来采用这种方法论。对新功能的冻结也许是必须的。停止开发新的代码，取而代之去为最严重的（恼人的－清晰的－高代价的）缺陷编写测试。

　　项目延期的情况下再去为你完整的代码库编写测试是不可行的，只针对其中的一些部分就可以，不要去浪费你的时间。但是要记住其它部分也还是需要编写测试的。我在这种情况下会去找出最严重的问题（划分优先级），然后为它们编写测试。之后“快速”修改代码就会变的更容易，并且可以保证在修改其他部分是它不会出错。 自动化测试可以很频繁的执行，从而降低了缺陷（bug）重现的风险。大讲台，最实用的 IT 职业在线学习平台。好了，现在可以开始去有效的强健我们项目了

　　 六、总结

　　大部分的项目中，会考虑测试和编码之间的平衡。不过我希望大家都能清楚，测试其实是项目的加速器，而不是在浪费时间。