【金阳光測试】大话Android自己主动化測试--Android自己主动化系列（1）--金阳光于2013年4月份

        Android自己主动化測试框架和工具在四年多的发展日趋成熟。

从五年前的第一代自己主动化架构演进到眼下第四代（本系列讲座第7篇后将具体剖析第三代和第四代自己主动化框架）从曾经最早谷歌推崇的monkey随机測试工具到点触流自己主动化工具monkeyrunner、MonkeyTalk。基于元素识别的自己主动化框架sikuli、seeTest、iTest、基于控件识别的Robotium、SL4A。这三种技术各有千秋。基本上如今做出的自己主动化框架都是整合或者改动了以上这些免费的自己主动化框架：比方中兴通讯的EasyTest3.0（眼下应用层自己主动化測试的先驱和王者，基本上能够对80%以上用例实现自己主动化。有非常多自家的核心技术，比方远程监控、一套脚本控制a b c三台机器三方通话。来回切换，不须要人工干预，智能设置断点。自己主动化下载版本号、双台终端无线虚拟屏幕互相映射、脚本自己主动分配样机…难怪去年亏损28亿还没有倒下）、华为终端的自己主动化框架（据说是在风河公司自己主动化框架下自己在填坑。哎，世界500强的华为人才都死绝了吗？）、东舟软件自己主动化SmartRobot（从曾经A模式和B模式打Patch包，到如今三种技术完美整合。有时候小公司还是非常牛逼的）、印度博思软件的自己主动化框架（对monkeyrunner进行二次封装。形成自己脚本语言，没有什么创新）、美国风河公司的：windtest managerment（这个太强大了，从底层驱动、芯片的自己主动化。对硬解码、软解码自己主动化、包含上层的framework框架自己主动化，能够白盒自己主动化，也能够黑盒系统功能自己主动化）、包含眼下出来的測试云Itestin、腾讯无线的QQdriver自己主动化框架。

都逃不出以上三种核心技术（这三种核心技术介绍会在第4篇和第5篇具体剖析）

        自己主动化測试细分为黑盒自己主动化測试和白盒自己主动化測试（第3篇会具体介绍白盒自己主动化測试）：我们熟知的压力測试、可靠性測试、负载稳定性測试、功能性測试都属于黑盒測试范畴；而白盒通常是单元測试、接口測试、持续的集成測试（也叫冒烟測试）、某系性能測试都能够用白盒測试来进行。

由于白盒測试要求測试project师编码能力较强，非常多中小型公司无法真正落实和开展。据笔者了解也仅仅有百度、企鹅、阿里真正花精力去做。尽管前期投入较大，可是中后期才会日渐收益。

        自己主动化測试难点不在于一个操作流程和过程（也就是脚本可以依照用例去执行）。假设有一天你的自己主动化脚本能帮你解决手工问题，那么你不过达到了第一代自己主动化水准。由于一个完整的自己主动化框架须要解决的问题至少有三：1.各种业务逻辑是否已正确实现2.各种业务约束是否正确实现3.各类特殊的数据是否可以正确处理。

聪明的同事一看就知道，须要添加验证点，彻底解放人工去推断。是的。

以上说的三个自己主动化框架已经包括了这些功能。所以说市面上眼下框架至少是第二代自己主动化框架以上。可是实际上測试复杂度远远超乎想象，比方眼下我们部门项目app測试需求有：

     1)    内存是否泄漏？

     2)    稳定性是否过关

     3)    对系统和应用程序兼容性怎样？

     4)    多程序，多进程交是否正常？

     5)    软件的容错机制怎样？

     6)    数据的完整性、唯一性、正确性是否已经通过測试？

     7)    系统及数据的安全性是否已通过測试？

     8)    软件的易用性是否满足用户的  需求…………………

       第二代自己主动化框架非常多手段显得力不从心，并且加上脚本移植问题、工作流程脚本共享、协同工作、生成报告等和工作流程相关的一系列问题，自己主动化框架部署和调整往往花时间比手工測试还要多一些，这些种种问题造成自己主动化框架无法普及和推广。

       无论前途有多么险恶，道路多么曲折。

引来无数高手和英雄共同模式和开展。建立适合自己公司的自己主动化框架。在众多比較成功的经典的自己主动化框架面前。我们惊叹人类无穷无尽的智慧和毅力。

       在这些成功的自己主动化框架面前（第6讲会具体介绍经典的企业级自己主动化框架）。这些专家已经攻克了智能手机80%以上的測试用例。虽然技术上已经解决。可是推广运用自己主动化取代人工非常多公司转化測试用例不到30%（原因会在兴许讲座剖析）。基本上做到的由：基本功能、菜单遍历、压力、性能、可靠性、并发測试、随机測试等。

        这里分享一个用自己主动化測试代替人工的设想：

如果6个组。每一个组5个人。每一个组不同项目，每一个项目得进行两个全面測试版本号和三个回归測试版本号。一个全面測试版本号得7个工作日，一个回归測试版本号5个工作日。

       1.版本号測试前每一个组必须得做预測试（开发自測也算）

       2.每一个组的全面測试版本号（前两个）必须得做压力測试：比方app压力、通话压力

       3.每一个组会測试出许很多多概率性问题（包含待跟踪）。无法在本次版本号中复现（操作次数大于30次才可能复现）

       4.每一个组无法每天晚上或者每一个周末都加班

       5.忘记抓log和找不到开发想要的路径和信息

        总结：自己主动化測试的长处是把每天须要反复劳动的操作变成机器自己主动执行。把測试员从繁重劳动中解脱出来，去做一些经验性操作和复杂操作。

        这次技术分享就到这里，请随时关注下一篇：android自己主动化測试预备知识---基于控件核心技术探讨。

附：

      金阳光自己主动化资料+视频：
     1.官网：http://www.goldensunshine.cc/
     2.关注我新浪微博：金阳光woody
     3.百度搜：金阳光 測试，找到金阳光老师视频
     4.很多其它最新视频在qq群：212260449更新

     5.资料csdn博客：http://blog.csdn.net/haorenmin2008

     6.金阳光微信公众账号:搜索金阳光自己主动化