第1章 测 试 入 门
关于"Android"和"开放手机联盟"，很多书中都有谈及，我们就不累述。本书涉及更高级的主题，我们希望在您阅读本书之前，最好有Android程序开发经验。不过，我们会先回顾一下测试的基本概念、技术、框架以及Android平台上的测试工具。
1.1 简史
Android平台是在2007年末引进的。那时候，基于Android平台测试的技术支持很少，而且我们中一些人习惯于边开发边测试，将测试作为开发流程中紧密耦合的一部分，因此，是时候开发一些框架和工具来支持这种测试方式了。
那时候，Android平台用Junit提供了一些不够成熟的功能支持单元测试，但是，支持力度不够并且帮助文档很少。
在我编写自己的库和工具的过程中，发现了Phil Smith的Positron库。他的库是开源的，非常适用于Android测试。于是，我在他的杰作基础上进行补充，新增功能、弥补不足。他们的库中不包含某些自动化测试的东西，所以我新起了一个项目与之互补，项目命名为Electron。Positron和Electron两个项目，当然不是像真正的正反粒子那样互斥，相反，它们像正反粒子那样蕴含着大能量，能产生大量的光波。
后来，2008年初，Electron项目参加第一届Android开发挑战赛。虽然在一些类目中，Electron的分数不错，但是在框架类项目比赛中毫无立足之地。那个时候，Eclipse上已经可以执行单元测试了。但是，并不是在真机上执行测试，而是在本地开发机上的JVM虚拟机上。
Google也提供了执行应用程序的模拟器代码，通过Instrumention类实现了这一功能。当你打开模拟器运行程序时，Instrument类会在你应用程序之前初始化，可以通过Instrument来模拟各种系统交互，执行程序。我们通过AndriodManifest.xml文件来设置模拟器。
1.2 软件Bug
无论你多努力，代码设计花费多少时间，编程时候有多小心，你的程序中都会有Bug,这是不可避免的。
Bug和软件开发是息息相关的。硬件工程中，用Bug这个单词来描述瑕疵、问题、错误已经有几十年了，甚至比计算机出现得还早。尽管如此，关于Bug这个单词的故事是由哈佛大学的Mark II计算机操作员创造的，1878年，在托马斯爱迪生给普斯卡斯蒂瓦达的信中可以看到这个单词的早期应用。
"我所有的发明都如此。第一步是直觉，随之是头脑风暴，然后困难都浮现出来。这些困难一点点被解决，然后Bug出现了，这些Bug就是所谓的小错误和困难。Bug出现后，需要投入几个月的精力去密切观察、学习，最终达到商业上的成功，否则，必然失败。"
Bug是如何严重影响你的项目的呢？
众所周知，Bug会从很多方面对你的项目工程造成影响，越早发现修复越好。无论你是为了优化用户体验， 开发一个简单的Android程序；还是为设备操作员新建一个Android客户版本，Bug都在延迟你的交付时间，燃烧你的金钱。
在所有的软件研发模式中，"测试驱动开发"是软件开发流程中最敏捷的方式。它驱使你在开发过程中更早地发现、面对Bug，你也很可能预先解决更多的问题。
此外，比起那些在最后才进行测试的团队，利用这种测试驱动开发模式的研发团队，生产效率更高。如果你在移动行业参与软件开发，有理由相信赶时间的情况下，"测试驱动开发"这种方案不合适。因为，通常这种方式解决的问题都很可能是已经规避了的，这点很有趣。
2002年美国国家研究所的一项研究调查表明，每年软件Bug损失595亿美元，如果软件测试执行得更好的话，超过三分之一的损失是可以避免的。
然而，请别误解以上所说的。软件开发没有特效药，是什么让你高效，让你的项目易于管理？是你有条理地利用这些方法和技术，掌控你的项目。
本文选自《Android应用测试指南》第一章，本站经人民邮电出版社和作者的授权。
版权声明：51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
