【金阳光測试】基于控件核心技术探讨---Android自己主动化系列(2)---2013年5月

第一讲分享了下安卓自己主动化一些概况和一些自己主动化框架现状和技术可以解决什么样的问题。

这次课就深入到android世界里面。遨游、翱翔。深入了解自己主动化測试核心技术。

搞过编程开发的同学听到instrumentation这个东西一定不陌生。在android架构里面分四层(最以下是硬件驱动相关抽象层。不是笔者讨论的内容范围),往上面一点是协议栈。也不是讨论的核心,都和c语言相关。一直到第三层框架层(framework)。

细分有二:

A.   android的改良虚拟机dalvik和Runtime(java执行时环境)。这个我还要略微解释下(懂的人请跳过),谷歌把java虚拟机(pc上面的虚拟机)进行改良,进行内存等优化,取消了远程登录等功能。发展成为自己的虚拟机。这样做优点是把每一个独立的进程进行虚拟机封装,从而进程崩溃不会影响system进程。保证了安卓系统稳定性。

B.   Runtime是一个和外部程序的接口(有些地方叫协议)把非常多丰富的c++库、3D和2D动画、媒体库、字体库、sqilite等优良的特性引入到上层。

当一个android系统启动的时候,载入完成守护进程和一些驱动等等步骤会调用init方法:Android的init进程为SIGCHLD绑定了信号处理函数sigchld_handler()。并创建了一个socket用于接收该函数中发送的socket消息。sigchld_handler()函数仅仅是简单的派送一个消息到该socket。

看得头晕的同学请无视他们。

你仅仅要记住,c側的框架层载入完成,将要调用一个java层最根上的父类。就是Zygote。英文名字是孵化、受精卵,大意是生孩子。全部的进程都由它产生,它和系统服务结合共同产生ActivityManagerService、WindowsManagerService和DialogservicesManager等,由zygote控制它们和线程binder对象进行通信,共同产生android四大组件(activity、broadcast、services、contentprovide)。在zygote创建process(线程)对象同一时候。我们最终看到幕后蠢蠢欲动的instrumentation。

饶了一大圈的盖世太保最终出现了。它可以在全部组件的初始化之前产生,全部它可以监视全部组件信息、状态、变化、消亡等,当然,在监控之前。它会拿到这些组件的那个上下文引用(context),控制应用程序的多个生命周期。发送UI事件给应用程序;在运行期间检查程序状态。

这就是自己主动化最核心的技术—设计模式之监听者模式。

在操作系统中。应用程序组件是控件的父类。由instrumentation监控和获取信息。然后由instrumentationTestRunner来控制脚本才进行一次自己主动化測试,你能够在adb shell里面执行这个脚本,或者用eclipse+junit方法来执行脚本。都是能够的。

这里的Instrumentation类。它可以监视应用程序跟系统的交互。Instrumentation对象会在应用的其它全部组件被实例化之前实例化。须要调用instrumentation类必须继承android.app.instrumentation才干使用它。

因为android的核心不是app,是activity。

这和ios苹果大相径庭。苹果是delegate托付和发送消息机制为主的MVC模型(视图、控制器和模型)具体苹果ios自己主动化測试文档会在第9讲以后问世。尽管android也有消息,可是安卓的消息通常是传递键值对(key-_value),在安卓里面叫bundle对象。是一种被泛型的字典。这里顺便提下后起之秀winphone
8。它的机制更诡异,是一种墓碑化休眠保存机制(这个winphone自己主动化和单元測试会在第15讲以后给大家具体剖析)。正由于有了它,winphone为了达到它最好的用户体验,虽然是多线程,可是同一时间仅仅能有一个进行激活状态,正由于如此,它单核的机器性能和效率远远盖过android和苹果。所以说。做了三十年的操作系统的微软水平真不是盖的。用户体验等等都优越苹果和android,虽然非常少人使用。

好,废话少说,切入正题。

Instrumentation会去androidmanifest.XML找里面注冊的activity、service等一些组件信息,当然还会包含布局文件layout里面xml的组件和控件在gen目录里面生成的R.java的id搜集而且保存下来,这些id都以0x的16进制的int。能够说是控件的身份证信息。你要是认为麻烦,能够用hierarchyviewer去查看,顺便提一下,用这个工具必须得root手机,当然笔者是不提倡把一个好的user版本号手机随便刷成root,这里要给买来的普通用户手机正正名,root是打开管理员su权限,让终端使用者有最高权限去操作手机,不论什么东西都有利有弊。弊端是你同一时候给了应用程序相相应的权限:比方其它应用程序能够跨进程訪问(这在android世界里面是破坏了谷歌的整套设计规则),搞android开发的知道,进程之间不能随便訪问和建立通信。除非你打开AIDL绑定的服务接口或者你在编译手机的时候偷偷的把app签名做成系统级别的签名。

除此以外。在一般用户权限做了非常多限制,大大的保证了你机器稳定性和安全性。可是你要root的话。非常多东西就不可控了。表现出来的现象是你手机莫名其妙重新启动、死机、无响应。或者你操作不当误删除了实用的模块,比方打电话不小心卸载,你就仅仅能去又一次刷过机器,所以说,普通用户还是不要随便刷机,由于谷歌压根就不限制你安装应用程序,不像苹果非得越狱才干任意安装应用。

当然你用自己主动化測试的时候也得在manifest申明。例如以下图


         

第一个红箭头这个带.的ResultActivity前面省略了命名空间(android叫包名),由于就一个包。当然在真正測试demo里面。大家还是要新建一个包名+test,測试完成删除就好;

第二个uses-library,由于现有的基于控件的instrumentation和兴许给大家介绍的Robtium框架,是封装了instrumentation的。都不能单独进行測试,必须配合junit4(junit3已经废弃。虽然能用,可是高级功能和annotation等须要junit4,这是一个元数据。也就是解释数据的数据,不明确的同学能够网上搜索下,不是这次的重点。

(这个具体使用会在第5篇以后具体介绍))框架一起进行測试,所以这条语句就是为了导入junit包。让结果执行在junit框架里面。

第三个红箭头就是盖世太保,有了它我们就能够随时调用和给你见到布局文件的菜单进行操作了,都不须要开权限,当然你得统一签名,由于測试源码我们有,这步省略。(后面第7章会教大家不用源码的方法),你能够点击,断言,back等都是能够的。

到此为止,自己主动化核心技术之中的一个---基于控件的精髓就在此。以后大家别见市面上有多少种android自己主动化工具吹嘘:能够远程控制、能够鼠标控制手机、能够自己主动录制脚本。

是,可是不是他们本事高强。事实上都是调用了谷歌封装instrumentation。所以厉害的还是谷歌。并非做自己主动化工具的人,不相信的同学能够关注我兴许的讲座。我也随便整合一个所谓的框架来执行自己主动化脚本,做測试工作中的项目,到时候请大家拍砖。

^_^(除了第二种自己主动化核心技术---ORC和元素识别,会在第7篇以后给大家揭秘)

这次技术分享就到这里,第三讲主要给大家分享自己主动化測试鼻祖Monkey 的原理和灵活使用它的一些高级法则,灵活执行它能够对測试起到非常大的帮助。

金阳光自己主动化资料+视频:

1.官网:http://www.goldensunshine.cc/

2.关注我新浪微博:金阳光woody

3.百度搜:金阳光  測试,找到金阳光老师视频

4.很多其它最新视频在qq群:212260449更新

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

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

时间: 2024-08-27 14:35:44

【金阳光測试】基于控件核心技术探讨---Android自己主动化系列(2)---2013年5月的相关文章

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

Android自己主动化測试框架和工具在四年多的发展日趋成熟. 从五年前的第一代自己主动化架构演进到眼下第四代(本系列讲座第7篇后将具体剖析第三代和第四代自己主动化框架)从曾经最早谷歌推崇的monkey随机測试工具到点触流自己主动化工具monkeyrunner.MonkeyTalk.基于元素识别的自己主动化框架sikuli.seeTest.iTest.基于控件识别的Robotium.SL4A.这三种技术各有千秋.基本上如今做出的自己主动化框架都是整合或者改动了以上这些免费的自己主动化框架:比方中

Android自己主动化測试之Monkeyrunner用法及实例

眼下android SDK里自带的现成的測试工具有monkey 和 monkeyrunner两个.大家别看这俩兄弟名字相像,但事实上是完全然全不同的两个工具,应用在不同的測试领域.总的来说,monkey主要应用在压力和可靠性測试上,执行该命令能够随机地向目标程序发送各种模拟键盘事件流,而且能够自定义发送的次数,以此观察被測应用程序的稳定性和可靠性,应用起来也比較简单,记住那几个命令即可了.而monkeyrunner呢,相比之下会强大一些,它主要可应用于功能測试,回归測试,而且能够自定义測试扩展,

Android自己主动化測试解决方式

如今,已经有大量的Android自己主动化測试架构或工具可供我们使用,当中包含:Activity Instrumentation, MonkeyRunner, Robotium, 以及Robolectric.另外LessPainful也提供服务来进行真实设备上的自己主动化測试. Android自身提供了对instrumentation測试的基本支持,当中之中的一个就是位于android.test包内的ActivityInstrumentationTestCase2类,它扩展了JUnit的Test

dui框架开发系列:基于控件组合或继承实现 可视化界面编辑工具 的优劣

大家好,我要介绍的所有知识点都是WINCE/windows触摸屏DUI开源框架constvar(点击下载代码)开发过程中遇到的比较有讨论价值的问题. 本文要讨论的是可视化界面编辑工具与控件实现方式的一些关系. 可视化界面编辑工具是DIRECTUI界面框架不可少的工具,它应当是整个框架的比较重要的一部分.VS中的可视化开发工具很强大,比如用MFC拖出来的界面,接近所见即所得,而且消息事件方法属性的增删改查都很便利,接口也很统一,可以说已经做得非常好了.说实话,平常如果做工具软件对界面没要求的那种,

基于Monkey的Android自己主动化測试

使用Monkey,能够相应用的稳定性和健壮性进行压測,測试的结果对于产品在复杂环境下的执行情况有很重要的參考意义. 以下是一个演示样例,带有对应的凝视.简单明了.供大家參考. #!/bin/bash # define case base information case_name="monkey case" case_ver="1.0.2" case_package_name="cn.packagename.platform" case_even

使用Adt自带的工具进行Android自己主动化測试(三)

在这个系列的上一篇文章中,我们介绍了MonkeyRunner,并提到假设依据坐标来编写自己主动化脚本的话存在着一定的局限性(点击文末"阅读原文"能够打开这篇文章查看).这篇文章将进一步介绍依据控件的id来编写自己主动化脚本的方法 依据控件的id来操作控件 从Android 2.3.3開始.MonkeyRunner添加了EasyMonkeyDevice和By这两个类.它们都位于com.android.monkeyrunner.easy包内,借助这两个类,我们就能够依据控件的id来操作控件

【Android自定义ViewGroup】不一样的轮子,巧用类变量解决冲突,像IOS那样简单的使用侧滑删除,一个控件搞定Android item侧滑删除菜单。

================================================================================== [1 序言] 侧滑删除的轮子网上有很多,最初在github上看过一个,还是ListView时代,那是一个自定义ListView 实现侧滑删除的,当初就觉得这种做法不是最佳,万一我项目里又同时有自定义ListView的需求,会增加复杂度. 写这篇文章之前又通过毒度搜了一下,排名前几的CSDN文章,都是通过自定义ListVIew和Vie

最常用和最难用的控件--ListView(Android第一行代码)

由于手机屏幕空间都比较有限,能够一次性在屏幕上显示的内容并不多,当我们的程序中有 大量的数据需要展示的时候,就可以借助 ListView 来实现.ListView 允许用户通过手指上下 滑动的方式将屏幕外的数据滚动到屏幕内,同时屏幕上原有的数据则会滚动出屏幕. 1.ListView 的简单用法首先新建一个 ListViewTest 项目,并让 ADT 自动帮我们创建好活动.然后修改activity_main.xml 中的代码,如下所示: <LinearLayout xmlns:android=&qu

Android自己主动化測试——CTS測试

一.为什么须要兼容性測试(下面称CTS)? 1.1.让APP提供更好的用户体验.用户能够选择很多其它的适合自己设备的APP.让APP更稳定. 1.2.让开发人员设计更高质量的APP. 1.3.通过CTS的设备能够执行Android market. 另外,CTS是免费的,并且非常easy. 二.CTS是开源的測试框架,使用它来測试你的设备是否具备兼容性.CTS主要包括两个组件: 执行在PC上的測试框架组件.主要用来管理測试用例(test case)的执行. 执行在设备或模拟器上的測试用例.这些用例