1.安卓软件基本有两层组成,第一层是基于java的应用层,第二层是基于linux的底层操作系统。
2.我们通过robotium写的自动化脚本是执行在java应用层上,也就是说我们获取的所有东东都是在布局上面取到的。
我们理清楚这几点之后,开始了解其执行原理。
1.我们的被测对象是apk的源代码,我们的测试代码是基于源代码来编写的脚本。(也有脱离代码方式的执行)
2.我们在run单元测试的过程中,首先安装被测对象的apk(有代码的情况下),然后安装测试代码的apk.
这里我们大概可以这么理解,其实我们制作了2个apk的软件应用程序,通过1个apk来自动测试我们另外一个apk.
而这些都是通过操作UI界面的布局,控件==来执行的,我们报错的话都是通过抓一些控件或者算法来判断。
这时候缺点就很明显了,假设一些返回的提示框我们应用层抓不到的话我们就很难准确的做到安卓的自动化。
就算是用sl4a,monkey还是monkeyrunner我们只是测试应用层上面的东西。
这时我准备在工作和家里实验一个想法,把安卓的自动化做到linux系统上。
很简单的思路:我们在安卓真机或者安卓模拟器上面制作一个批处理bat或者sh脚本,通过任意脚本软件来监听。
简单的一个tcl伪代码获取日志的例子:
1.通过shell脚本打印日志adb logcat > /data/log.txt
2.利用expect搭建起tcl和shell桥梁,假设$testfile为log.txt路径
set testfile2 [open $testfile a+] set tellfile [tell $testfile2]
3.应用层在执行自动化用例。
4.把执行所产生的日志进行截取:
set testfile2 [open $testfile] seek $testfile2 $tellfile puts seektell===[read $testfile2] close $testfile2
5.可以根据开发给的错误码来匹配里面有无产生错误。
难点:
在应用层的自动化脚本能否通过runtime()。exec的方法调用linux应用层的抓日志脚本,这点关键(待工作时实验)
在java脚本和shell脚本中间的延时如何设置和处理。
总结:这是我比较大胆的想法,毕竟我觉得在底层抓到的bug才是比较准确的判断出是否出现了问题,也发现很多例如内存溢出的问题。
同时现在我编写的robotium自动化虽然已经覆盖了很多用例,但是除了做基础的操作遍历和发现一些匹配字符的单,其实作用不算太大。就是重复的检验了工作而已,并没我之前做的别的业务自动化那么产生实际的效果。