更多考虑
在以上的章节中，我们的着眼点都是在工具和技术上的讨论。但是对于真实的移动应用测试项目，一旦引入自动化测试，必然需要考虑对整体进度、项目成本的影响。所以，这里会有以下考虑：

评估自动化工具的引入对现有项目进度的影响
对于传统项目，如果在前期已经有自动化测试的规划，项目经理手上应该有足够的资源调配自动化测试工程师，使得他们可以是一个独立于手工测试之外的团队，这种做法并不会对项目进度产生太大影响。但是对于移动应用测试，通常的项目周期都会比较短，而且测试团队的成员数量不足以额外的配备专门的自动化测试工程师，很可能是一些手工测试工程师挤出时间来做一些小量的自动化测试脚本，用于版本发布时的快速冒烟测试。这种花在自动化测时间上的比例，相比于本来不是很长的测试周期，也许会显得特别突出。

团队工作模式的变化
如果如上所言，只是手工测试工程师挤出时间来做一些小量的自动化测试脚本，用于版本发布时的快速冒烟测试，那对于自动化的整体效果来说并不见得有很大帮助。至少对于目前大部分安卓开发项目来说，很少见到投入一至两位专职自动化测试工程师来做这类事情。但是，如果考虑到将来频繁的版本发布，以及安卓应用独有的海量的兼容性测试，对于自动化的前期投入还是显得有必要的。

如下图，传统模式，测试工程师可能在第一轮测试才有一次Full Test，在后续的回归测试中，可能只能做到部分回归。


如果引入自动化测试工程师，同步开发测试脚本(理想情况，每个应用自动化比率达到70%~80%，整体自动化比率达到60%~70%)，有可能使得回归测试比率有所提高。


从零做起
既然如此，何不从现在开始，从零开始，在项目中尝试引入自动化测试，哪怕只是抽调部分人力着手部分应用的自动化测试，至少可以达到Daily Build Smoke Test的效果。再者，移动应用自动化测试行业正处于起步阶段，此时介入也不失为一个好时机。

结论
回顾上述讨论的内容，我们设想能在移动应用自动化测试领域延续桌面系统自动化测试的成功经验，从理论基础、工具支持、以及后续项目管理方面都做了一番探讨。尽管主要还是局限于安卓应用的自动化方面，对于iOS提及较少。不难理解，iOS本身支持的机型有限，对于设备兼容性测试并不是重点关注的内容。而在功能性回归测试方面，它本身也有相关工具支持。至于像Blackberry之类的平台，因为本身并没有呈现爆炸性的应用增长，所以也没有列在讨论范围。所以，本文仍以安卓平台作为自动化测试的突破口，希望从中能结合市面上的一些商用工具，尝试实践以“关键字驱动”为基础的自动化测试，而非原始的以“坐标点”为基础的屏幕点击测试。对于开源工具也没有提及，原因是考虑到像Robotium和MonkeyRunner之类的流行工具可能更贴近于开发工程师使用，而非更贴近于测试工程师。所以，我们希望在上述的讨论中能带给读者在测试项目中新的启发。