如下图，传统模式，测试工程师可能在第一轮测试才有一次Full Test,在后续的回归测试中，可能只能做到部分回归。
如果引入自动化测试工程师，同步开发测试脚本（理想情况，每个应用自动化比率达到70%~80%,整体自动化比率达到60%~70%），有可能使得回归测试比率有所提高。
从零做起
既然如此，何不从现在开始，从零开始，在项目中尝试引入自动化测试，哪怕只是抽调部分人力着手部分应用的自动化测试，至少可以达到Daily Build Smoke Test的效果。再者，移动应用自动化测试行业正处于起步阶段，此时介入也不失为一个好时机。
结论
回顾上述讨论的内容，我们设想能在移动应用自动化测试领域延续桌面系统自动化测试的成功经验，从理论基础、工具支持、以及后续项目管理方面都做了一番探讨。尽管主要还是局限于安卓应用的自动化方面，对于iOS提及较少。不难理解，iOS本身支持的机型有限，对于设备兼容性测试并不是重点关注的内容。而在功能性回归测试方面，它本身也有相关工具支持。至于像Blackberry之类的平台，因为本身并没有呈现爆炸性的应用增长，所以也没有列在讨论范围。所以，本文仍以安卓平台作为自动化测试的突破口，希望从中能结合市面上的一些商用工具，尝试实践以“关键字驱动”为基础的自动化测试，而非原始的以“坐标点”为基础的屏幕点击测试。对于开源工具也没有提及，原因是考虑到像Robotium和MonkeyRunner之类的流行工具可能更贴近于开发工程师使用，而非更贴近于测试工程师。所以，我们希望在上述的讨论中能带给读者在测试项目中新的启发。
版权声明：本文出自 anthony.wang 的51Testing软件测试博客：http://www.51testing.com/?507238
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
