常用adb命令及monkey命令详解

基于这篇文章,给大家再深入一下。

传送门:https://jianjiexuan.com/tools/android-sdk/293.html

我将有一段时间进行人生的思考,所以,这边插播一下我的微信,文章可能暂时停停。

一、常用adb命令

1、adb devices:查看已连接的设备

2、adb version:查看adb的版本序列号

3、adb -s <设备名字>:指定某设备做什么(设备名字用1的方法可以查看)

4、adb install <安装包.apk>:安装应用(写清楚apk的完整路径)

adb -s <设备名字> install <安装包.apk>:指定设备安装应用

5、adb shell:通过远程shell命令来控制模拟器/设备

6、exit:退出shell远程连接,回到原路径。(Ctrl+d,退出shell,回到默认路径)

7、adb pull <设备端路径> <pc端路径>:将指定的文件从设备/模拟器上拷贝到pc端(后面的pc端路径可以不指定,默认存储在当前路径下)。例:

  adb pull /sdcard/log.txt c:/monkey

8、adb push <pc端路径> <设备端路径>:将指定的文件从pc端拷贝到设备/模拟器上

9、adb shell pm list packages:列出电脑端所有apk的包名

10、adb shell pm path packages:获取包名对应的apk路径

11、adb shell ps :查看已链接设备上所有进程

12、adb logcat:查看pc端的日志输出。

adb shell界面只需输入logcat,查看设备端日志输出(退出Ctrl+c)

13、adb reboot:重启设备,强制停止monkey时可以使用此命令,简单粗暴。

二、Monkey命令扩展

1、最简单的monkey执行语句:

(adb shell)monkey –p com.jianjiexuan.na –v 500  (对com.jianjiexuan.na 这个程序包单独进行一次500次的monkey测试)

名词解释

-p:用于约束限制,用此参数指定一个或多个包。指定包之后,Monkey将只允许系统启动指定的APP。如果不指定包,Monkey将允许系统启动设备中的所有APP。

指定多个包:monkey -p <packagename1> –p <packagename2>  -p <packagename3> -v 500

-v:用于指定反馈信息级别(信息级别就是日志的详细程度),总共分3个级别,分别对应的参数如下表所示:

  • 日志级别 Level 0

monkey –p com.jianjiexuan.na –v 500

说明:缺省值,仅提供启动提示、测试完成和最终结果等少量信息

  • 日志级别 Level 1

monkey –p com.jianjiexuan.na –v -v 500

说明:提供较为详细的日志,包括每个发送到Activity的事件信息

  • 日志级别 Level 2

monkey –p com.jianjiexuan.na –v -v -v 500

说明:最详细的日志,包括了测试中选中/未选中的Activity信息

2、延时及固定序列

(adb shell)monkey -s 100 -p com.jianjiexuan.na – -throttle 1000 -v 500 (每次执行一次有效的事件后休眠1000毫秒

(adb shell)monkey -p com.jianjiexuan.na – -throttle 1000 – -randomize-throttle -v 500 (每次执行一次有效事件后随机延时0-200毫秒

名词解释

-s:用于指定伪随机数生成器的seed值,如果seed相同,则两次Monkey测试所产生的事件序列也相同的。出现问题下次可以重复同样的系列进行排错

–throttle固定延时,用于指定用户操作(即事件)间的时延,单位是毫秒;

–randomize-throttle随机延时,用于指定用户操作(即事件)间的时延,单位是毫秒。

3、保存monkey运行结果

1)保存在PC中

adb shell monkey –p com.jianjiexuan.na –v 500 > d:\monkey\log.txt   

2)保存在手机中

手机端进入shell模式:adb shell

 monkey –p com.jianjiexuan.na –v 500 > /mnt/sdcard/monkey/log.txt

4、monkey事件百分比的调整

(adb shell)monkey -p com.jianjiexuan.na -v – -pct-anyevent 100 500

指定多个类型事件的百分比:

monkey -p com.jianjiexuan.na -v –pct-anyevent 50 –pct-appswitch 20 500

名词解释

–pct-****:设置某个事件的百分比。后面接数字(0-100),100即100%的概率执行该事件

monkeygai01

注意:各事件类型的百分比总数不能超过100%。如果不进行设置则显示默认百分比。

5、正在运行的monkey如何终止

如在命令窗口端直接打印结果,想要停止monkey的运行,除去重启设备的粗暴方式停止monkey的运行,也可以这样:再打开一个cmd命令窗口

查看monkey的进程:adb shell ps | find “monkey”

monkeygai02kill掉该进程就可以

adb shell kill + 进程编号 ,即adb shell kill 5182

关于其他的细化的,后续会继续更新中。。。

Android App压力测试-Monkey(真机)

昨天一个朋友说自己工作了好几年,但是依然只是会一些功能测试(手工),问有没有什么工具。其实工具永远都是辅助,首先要确定你要往哪个方向发展,然后由这个方向自会引申出很多工具,你再去专研工具,边专研边对这块方向深入,到时候,你就是前辈了,一通百通。

好了,下面来点干货,前两年在新浪博客里写过Monkey在模拟器上如何执行,今天从头到尾讲下在真机上如何运行。我的目的就是,你看了我的东西,是真的能够学会我所说的,不仅仅是知识的硬塞入。

首先,Monkey主要用于移动端的压力测试,在adb shell中,生成用户或系统的伪随机事件。做压力测试的目的就是提高产品的稳定性及留存率。

 什么时候用Monkey测试比较合适?

1)测试节点最好安排在功能系统测试通过,路径上没有问题的时候

2)测试时间最好安排在下班后的夜间进行,不占用上班时间,节约时间成本

Monkey测试涉及的核心:

1)ADB:Android Debug Bridge,安卓调试桥

2)MonkeyScript:一组可被Monkey识别的命令集合,可以完成重复固定的操作
当当当,下面进入正题

一、搭建Monkey的环境

1、下载安装sdk环境,不需要下载开发的api部分。

下载传送门:http://pan.baidu.com/s/1o80il2U

下载之后解压。

2、配置环境变量

在path变量值里加入Android-sdk中platform-tools和tools的目录路径,记得分号隔开。

3、验证是否配置成功

打开cmd命令行窗口,输入adb,出现下面的内容即为环境配置成功

monkey01

二、连接设备

1、首先通过USB线连上手机和电脑,确保手机的调试模式打开

2、cmd命令行窗口输入,adb devices,查看已连接的设备,如下图所示

注:可能是驱动的原因,有时候需要先打开手机助手(豌豆荚),连上手机。与adb.exe冲突,结束adb.exe进程。

monkey02其中,98AFBNM24J7R为已连接设备的名字。

3、指定设备安装测试包

adb -s 98AFBNM24J7R install ***.apk(写清楚apk的完整路径)

如图所示

monkey03

:有的人会出现以下问题:

monkey04这个是为什么呢,看看你连接的手机,因为安装的时候手机要允许。

三、执行Monkey

1、查看该包的packagename

aapt dump badging ***.apk(写清楚apk的完整路径),如图所示

 http://blog.jianjiexuan.com/tools/android-sdk/82.html

monkey05

2、最简单的monkey执行语句

adb -s 98AFBNM24J7R shell monkey -p <packagename>(即上一步查询的东西) -v 1000

这时的执行结果在命令行端显示

monkey06

具体想扩展的直接百度就可以,我这里只给大家一个准确简单的完整流程。

3、存储结果在手机端

进入该设备的shell界面

adb -s 98AFBNM24J7R shell

monkey08

执行:

 monkey -p <packagename>(即上一步查询的东西) -v 1000 > /mnt/sdcard/monkey.txt

加强综合版:有了这个基本可以说自己会monkey了(如果你看到这,可以加我微信了:jianjiexuan520

monkey -p ***** –ignore-crashes –ignore-timeouts –ignore-security-exceptions –monitor-native-crashes –pct-touch 50 –pct-motion 10 –pct-nav 10 –pct-majornav 10 –pct-appswitch 10 –pct-anyevent 10 –pct-syskeys 0 -v -v -v -s 123 –throttle 300 360000 2>/sdcard/yymonkey.log &

fuck,明明打的两个杠杠,显示出来的都是一个,为了避免误导大家,我顺便截个图,你们自己记得修改

命令说明:(具体详细解释可以看另一篇文章)

-p 包名:运行该程序

–ignore-crashes:当应用程序崩溃或发生任何失控异常时,Monkey将继续向系统发送事件,直到计数完成。

–ignore-timeouts :当应用程序发生任何超时错误,Monkey将继续向系统发送事件,直到计数完成。

–ignore-security-exceptions:当应用程序发生许可错误(如启动一个需要某些许可的Activity)时,Monkey将继续向系统发送事件,直到计数完成。

–monitor-native-crashes:监视并报告Android系统中本地代码的崩溃事件。

–pct-anyevent 10等:设定启动activity的百分比为10%(调整其它类型事件的百分比。它包罗了所有其它类型的事件,如:按键、其它不常用的设备按钮、等等。)

-v -v –v:提供更加详细的信息。一个V为较少信息;二个为较详细信息;三个提示很详细信息。

-s 123:伪随机数生成器的seed值。如果用相同的seed值再次运行Monkey,它将生成相同的事件序列。(再次测试需要输入不同的数字,不然结果是一样的)

–throttle 300:在事件之间插入固定延迟。通过这个选项可以减缓Monkey的执行速度,如这里输入300就是为300ms,一般情况下是设置1000,为了发现更多的问题,我们加大了压力

360000:事件数设定为360000,大概可以保证晚上安心下班,明早看结果了。

0>(自定义路径):输入所有LOG记录

1>(自定义路径):输出所有LOG记录

2>(自定义路径) :输出错误LOG记录

:可以拔掉数据线再换个手机了~

四、结果分析

1、调取手机端执行结果到电脑上

adb pull 文件名 (写清楚文件在手机端的完整路径)  要储存在pc端的路径

例:

adb pull /sdcard/monkey.txt d:/  (注意这边的斜杠,反斜杠是不行,Unix使用/作为路径分隔符)

monkey07

2、查看结果

开发人员结合monkey打印的日志和系统打印的日志,结合测试中出现的问题。

  • CRASH:即崩溃,应用程序在使用过程中,非正常退出。(Exception)
  • ANR:Application Not Responding,等待时间过长,程序无响应
  • oom:out of memory 超出内存(一般来说是图片过大或内存泄漏引起的,大部分情况是图片问题)

一个完整的基本流程已经结束了,如果还想深入的小伙伴可以继续研究,可参看其他文档。

 

小企业如何最大限度提高测试质量?

众所周知,小企业肯定人数不会多,很多能精简则精简。甚至很多小企业都没有测试人员,当我们有幸加入到一个不是很大的企业的测试部门,如何能更好的进行测试呢?

现在敏捷开发被炒的很热,其实,我觉得现在还没有一个完全正确的工作流程能去阐述清楚敏捷开发,基本都是每家小企业拿着个文档不全的理去美化自己是敏捷开发,1000个企业就有1000个敏捷开发流程。敏捷开发里是弱化了文档的重要性,更着重讯息的及时沟通,需求变更也平常。所以,敏捷开发里的每一环的人员自身能力都要很靠谱。而对于测试人员的挑战与压力无非是巨大的。因为没有统一的文档,我们要时时刻刻关注所有聊天群组、站立会议、邮件等探讨出的新需求,漏掉哪一个,就彻底漏掉了,没有根源可寻。但是一出现问题,你没有测到,某某这时就会站出来说,我明明在之前说过,说没说过没人知道,因为你不是对着测试说的,我们已经尽力去搜寻散落的需求,但是这种遗漏还是会存在,发生这种情况总会比较尴尬。

  但是如何能避免呢?

你需要一个记事本,新版本的所有需求,反正你知道的,无论何种途径,立马同步更新到你的记事本里,开发过程中的新增需求、修改的需求,删减的需求,都及时同步,这样就会最大化保证需求的同步,好记性不如烂笔头,这样在最后验收的时候才能确保万无一失。记事本可以考虑印象笔记、onenote,都还不错。

需求已经尽量得到了同步,接下来如何去进行高质量、高效的测试呢?

从高效的角度来说,敏捷开发完全可以摒弃测试用例。那种详细的、繁杂的描述也是就是耗费时间,没等你写完,就已经到了开测的时间。这时候的测试用例基本成了鸡肋,用也用不上。而且慢慢看测试用例的时间已经够我测完一个需求点了。但是我们又不能什么都不写,那我们和那些不懂测试,拿到手就开始随便点点点的人又有何不同?不写测试用例是节约了时间,但是如何保证质量呢?其实我们可以根据现有的需求列出checklist,这样即节约了时间成本,又给我们真正测试时提供了测试思维的提醒,不至于漏测一些常规路径,从而可以保证质量。

也许其他人会有更好的想法,我目前是这样安排的:


解释:

1、需求编号:有些录入到禅道或者excel中的需求是有编号的,为了方便我们查看,可以写出编号;有些是临时加的,我们可以直接写出需求点;另外如果有删减的,可以直接添加删除线。

2、checklist:即是需要测试的检查点,对应的A、B、C其实是测试人员。checklist由C写出后,给与A一些参考,A可继续完善补充checklist再给B参考,B测试过程中也可继续完善和补充checklist,这样最终返回到C手中的checklist已经丰富了好多。

3、系统测试:系统测试其实是很重要的一个缓解,需要测试好几轮,确保bug收敛到最低,然后交给B去交叉。

4、交叉测试:交给B交叉是为了发散出更多的路径,毕竟每个人看东西的角度都是不一样的,这样能更大限度的去保证质量。

5、验收测试:从写checklist到现在,C其实一直没有参与到测试,而这时,bug基本已经没有,C根据补充完善后的checklist进行最后的验收。

6、常规测试:这是我自己分化的功能模块,每个测试人员都有自己负责的模块功能。这样没有新增需求的模块、线上的应用、反馈的问题,都能对应到具体模块负责人,比如首页就是A一直负责的,所以最终新增需求都测试结束后,首页整个模块都需要A最后再去验收。

7、α测试:除去参与此需求从产生到结束的人员,找一些公司其他人员,充当用户,给与15分钟的快速体验,测试只需在一旁记录下体验期间提的所有建议就可以。这些建议也许不是bug,仅仅是操作上的不爽,这些也应该记录,之后汇总、讨论,哪些是必要解决,哪些是可以延期处理的,哪些是可以忽略的。

8、β测试:不一定每次的版本都需要执行,可以在重大需求,或者发布有风险的前提下实行。增加一些灰度测试,取一些真实用户去体验,及时收集用户的反馈,并可根据第三方查看日志,是否有崩溃等问题出现。

 

表格解释完了之后,明眼人都能看出,这样一层层测试下来,质量绝对是有保障的,而且能利用的资源基本都被高效利用了,已经实现了利益的最大化。针对于小型企业、测试部门人数不足的情况,我目前只能想到这样去安排工作,如果我之后发现有更好的工作方式,会及时更新的。

希望对你有作用。

如何更好的测试移动端app总结

测试移动端与测试web或者其他还是有些许差异的,为了方便大家能够快速的掌握测试移动端app的要点,下面根据自己的切身经验进行了一些总结。希望能够对大家有所帮助。

测试前的思考

我们这个产品主要是做什么的?市场上有那些同类型的产品?我们的产品所具有的优势?

测试前的准备

1、使用同类型的产品,在接触到自己产品之前,就已经对大致的主体功能有测试方向。

2、熟悉我们产品的需求设计文档,模糊的地方积极和pm交流。

3、写测试用例,资源不够的话可以不写,但是需要有checklist。

功能测试注意点

1、基本功能,主要指app是否完成了设计的所有功能。

分清模块,写一份checklist,避免漏测。

详细包括:

1)安装/卸载时,系统正常安装/卸载成功(注意覆盖安装);

2)安装成功后,系统图标显示正确;

3)根据checklist进行需求点的覆盖测试;

4)对于中途中的一些返回或退出,应有相应的提示信息;

5)显示的数据与接口返回的数据一致(抓包查看,如fiddler、charles)

6)信息上传到数据库,上传的数据保持正确

 

2、系统交互:系统正在使用一些功能时,外界给与的干扰是否会影响当前功能。

1)电话短信干扰;

2)低电量提醒;

3)push提醒;

4)usb数据线插拔提醒;

5)充电提醒;

6)音乐播放器干扰等。

 

3、兼容性:android碎片化是个难题,bug也多,ios相对bug少。

需要针对不同系统及不同机型进行覆盖测试。Android可以选取一些代表性的机型。

 

性能测试注意点

1、稳定性:利用monkey在下班后进行一些伪随机用户事件的执行,会发现一些ANR及CRASH的问题。

2、app运行的内存消耗和cpu消耗。

3、app后台长时间运行的耗流量,耗电量。

2、3点等可以用Emmagee或GT进行Android端的测试,iOS端可以直接利用xcode自带的插件进行分析

4、不同网络下的响应速度测试(可以利用charles工具实现)。

5、服务端的压力测试(可以使用jmeter),高用户的并发都要要考虑的问题。

 

易用性测试注意点

1、路径短,用户操作简单

2、界面是否吸引人、容易理解。

3、界面整洁、简单,色调统一。

4、无错别字,字体格式统一。

5、点击范围确定,利于用户操作等。

这部分测试很多,可以参照易用性-界面测试规范,如果认为有不合理的地方通常会提交需求bug-设计问题。

 

自动化测试注意点

如果不是敏捷开发,可以执行自动化测试(robotium,monkeyrunner,androidjunit),这样在回归的时候会节约很多资源。但是面对经常变更UI的敏捷开发,自动化测试的维护成本就较高,这时候并不合适加入自动化测试。但可以加入monkey自动化随机测试,还可以对接口进行自动化测试。

另外,敏捷开发中,一定要有持续集成的环境,这样可以节省很多时间。

 

其他测试注意点

1、网络切换下的app运行情况及功能正常(wifi/4G/3G/2G)。

2、网络信号强、弱甚至无网络情况下的app运行情况。

 

暂时就总结这么多了,以我目前的眼界也只能囊括这么多,如果以后发现了更多的注意点,会逐步更新的。