从桌面应用自动化测试看移动应用自动化测试

自从图形化界面成为个人桌面电脑的主流，应用程序复杂程度与日俱增，针对人机交互的自动化测试迫在眉睫，从而在市场上涌现了一大批针对图形界面应用程序功能测试的自动化测试工具（参考链接1）。2001年QTP第一个版本发布；2002年Robot初始版发布。自此，自动化工具已经经历了十年的发展。随着近两年移动应用呈现爆炸性的增长，移动应用自动化测试工具也开始陆续呈现（参考链接2）。

需求的延续

无论从PC端应用的自动化测试，还是移动应用的自动化测试，人们的关注点从未转移，期望也从不改变，那就是，尽可能多的模拟人工测试动作和相应的结果检查，从而释放手工劳动，替代大量重复性的执行和验证工作。进入移动应用时代，移动应用项目开发一直走的是“短小精干”的路子，即应用程序小而精。开发模式也抛弃了传统的规范流程，热衷于敏捷式开发。版本发布周期约来越短，迭代频密。这些似乎与自动化测试遥不可及。但是，随着移动应用逐渐从个人娱乐领域渗透到商业应用，诸如金融、办公、政务等方面的应用比重逐步扩大，对移动应用质量的要求也越来越高，自动化测试始终会回到人们的视线之内。在加上安卓特有的碎片化问题，使得安卓平台自动化回归测试和兼容性测试的呼声极高。

理念的传承

回顾桌面应用的自动化测试历程，我们看到，工具的发展经历了从最初“坐标点操作”过渡到“对象识别”的过程。移动应用测试工具走的路子也有几分相似。以开放的Android平台为例，最开始出现Monkey/MonkeyRunner等坐标点操作的工具（后来有很多工具开发商做了对MonkeyRunner的封装）；之后出现了如Robotium等基于源码层面对于界面控件识别的工具；也有一些工具开发商如DroidPilot.com推出了纯粹的对象识别工具；当然，也有一些如PerfectoMobile.com的工具开发商，为了兼容iOS/BlackBerry/Windows Phone等平台，采用图像识别技术。但无论如何，“关键字驱动”、“数据驱动”等理念已经是传统PC行业自动化测试的成功经验，移动应用测试方面应该借鉴。再搭配性能测试工具、轻量级测试需求管理、用例管理、缺陷跟踪等工具，相信足以成为移动应用项目质量保证的基础工具支撑。

有所不能vs凡事都能

似乎所有管理者都期望一旦引入自动化测试，则万事大吉，貌似自动化能做到全方位的测试服务，可以释放测试工程师了。但事实求是的说，即使在拥有十年历程的传统自动化测试行业，自动化所能涉及的测试用例比例也是有限，通常覆盖60%～80%的测试用例，已经能说是不错的成绩了。问题是，项目的成本和进度，以及测试人员的配备，是否能足以支撑自动化测试持续的进行。否则事半功倍，未免太可惜了。借鉴传统项目的自动化测试失败案例，对于项目预算相对较少的移动应用开发项目，考虑引入自动化测试的确需要慎之又慎。

精益求精

然而对于自动化测试工程师来说，通常并不满足于部分用例的自动化测试，甚至仅仅是自动化冒烟测试。他们总想走的更远，甚至不惜代价去完善一些凤毛麟角之功能。当然，从这一点也可以看出自动化测试工程师们精益求精的精神，同时，也对自动化测试工具开发者提出了更高的要求。从目前发展现状来看，他们也的确在着眼于提高工具的测试深度和广度，增强工具易用性，剥离工具对于源代码的依赖，延伸传统自动化测试的方法论。希望看到移动应用自动化测试领域呈现蓬勃的发展。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/

软件自动化测试工具的历史进程 软件测试最早可以追溯到1958年的美国第一个载人航天计划-水星计划，当时在该计划中首次诞生了软件测试团队。当然，在此之前也肯定是有软件测试存在的，但远没有这次有了自己的江湖地位。但这也仅仅是软件测试的萌芽，远没有到开宗立派的地步。
步入职场，对比刚毕业时的那段创业时间，觉得自己有一些做的不对的地方，或者整个创业团队导致失败的地方。 失败原因很多，天时、地利、人和都有因素，这次只想说说关于大家对开发的误解，这也是失败的原因之一。