本节书摘来自异步社区《Android 应用测试指南》一书中的第1章，第1.2节软件Bug，作者 【阿根廷】Diego Torres Milano（迭戈 D.），更多章节内容可以访问云栖社区“异步社区”公众号查看

1.2　软件Bug
无论你多努力，代码设计花费多少时间，编程时候有多小心，你的程序中都会有Bug,这是不可避免的。

Bug和软件开发是息息相关的。硬件工程中，用Bug这个单词来描述瑕疵、问题、错误已经有几十年了，甚至比计算机出现得还早。尽管如此，关于Bug这个单词的故事是由哈佛大学的Mark II计算机操作员创造的，1878年，在爱迪生给蒂瓦达的信中可以看到这个单词的早期应用。

“我所有的发明都如此。第一步是直觉，随之是头脑风暴，然后困难都浮现出来。这些困难一点点被解决，然后Bug出现了，这些Bug就是所谓的小错误和困难。Bug出现后，需要投入几个月的精力去密切观察、学习，最终达到商业上的成功，否则，必然失败。”

Bug是如何严重影响你的项目的呢
众所周知，Bug会从很多方面对你的项目工程造成影响，越早发现并修复越好。无论你是为了优化用户体验，开发一个简单的Android程序；还是为设备操作员新建一个Android客户版本，Bug都在延迟你的交付时间，燃烧你的金钱。

在所有的软件研发模式中，“测试驱动开发”是软件开发流程中最敏捷的方式。它驱使你在开发过程中更早地发现、面对Bug，你也很可能预先解决更多的问题。

此外，比起那些在最后才进行测试的团队，利用这种测试驱动开发模式的研发团队，生产效率更高。如果你在移动行业参与软件开发，有理由相信赶时间的情况下，“测试驱动开发”这种方案不合适。因为，通常这种方式解决的问题都很可能是已经规避了的，这点很有趣。

2002年美国国家研究所的一项研究调查表明，每年软件Bug造成的损失595亿美元，如果软件测试执行得更好的话，超过三分之一的损失是可以避免的。

然而，请别误解以上所说的。软件开发没有特效药，是什么让你高效，让你的项目易于管理？是你有条理地利用这些方法和技术，掌控你的项目。