如何测试设备内置的apk

『壹』 robotium 如何测试预装apk

Robotium 测试Android apk安装包

介绍
要测试apk程序必须和我们编写的测试程序拥有相同的签名（signature）。如果没有apk程序的签名秘钥，就要去除apk程序的签名，然后再使用自己的key对其签名(这一步中，我们可以使用debug key），已经有现成的工具可用，下载地址re-sign.jar，这个工具可以去掉apk程序的原签名，然后使用我们自己的debug key对其签名。
详细
编写测试用例之前，我们需要知道apk程序的包名（package name）和启动页面名称（launcher activity name），这两个名称我们可以通过程序启动时的日志（adb logcat）来获取。程序日志会打印出包名和activity名称。 日志格式类似于：Starting activity: Intent { act=android.intent.action.MAIN cat=android.intent.category.LAUNCHER? flg=0x10200000 cmp=com.example.android.notepad/.NotesList。
上面的日志表明程序包名为：com.example.android.notepad、启动activity名为:com.example.android.notepad.NotesList，这里的activity name就是下面代码中的LAUNCHER_ACTIVITYFULLCLASSNAME。
下面是测试代码的例子：
package com.yourcompany.yourtestname;

import com.jayway.android.robotium.solo.Solo;

import android.test.;

@SuppressWarnings("rawtypes")
public class ReallyBlackboxTest extends {

private static final String LAUNCHER_ACTIVITY_FULL_CLASSNAME = "com.newsrob.DashboardListActivity";

private static Class<?> launcherActivityClass;
static{
try {
launcherActivityClass = Class.forName(LAUNCHER_ACTIVITY_FULL_CLASSNAME);
} catch (ClassNotFoundException e) {
throw new RuntimeException(e);
}
}

@SuppressWarnings("unchecked")
public ReallyBlackboxTest() throws ClassNotFoundException {
super(launcherActivityClass);
}

private Solo solo;

@Override
protected void setUp() throws Exception {
solo = new Solo(getInstrumentation(), getActivity());
}

public void testCanOpenSettings(){
solo.pressMenuItem(0);
}

@Override
public void tearDown() throws Exception {
solo.finishOpenedActivities();

}
}

『贰』 android 怎么获取系统内置的apk

按说应该由api提供，但是确实是没有官方的方法。查询mnt文件下的目录是一个方法。还有就是使用使用查询linux文件，来查找设备目录，由此判断外设，u盘等

『叁』 如何测试APK兼容性

2 CTS简介
CTS拥有兼容性测试包。CTS是一个自动化的测试工具，其中包括两个主要的软件组件：CTS测试工具可以运行在您的台式机和管理测试执行。连接的移动设备或模拟器上执行个别测试案例。作为JUnit测试，并打包为Android是用Java编写测试用例。apk文件运行在实际设备上的目标。手机设备需要通过Android的兼容性测试(CTS)，以确保在android上开发的程序在手机设备上都能运行。你的设备只有满足CDD的规定并且通过CTS，才有可能获得Android的商标和享受Android Market的权限。这里有可能指的是需要你自己去向google申请的。

3 CTS在android软件兼容性测试的意义
通过CTS测试之后便允许在设备上使用Android商标，它标志着该设备能够良好兼容软件市场中的数十万应用程序。

4 CTS在终端上的测试详解

5 CTS 终端需求
Android 2.1 的 Compatibility Definition,它定义了一些需求：
数据：必须实现一种无线连接， 速率达到 200Kbit/Sec
Camera: 至少 2M pixels
重力加速: 必须有， 3维， >50Hz
指南针：必须有， 3纬， >10Hz
GPS: 必须有
内存：至少 92M （不包括专用内容）
Nand: /data 分区至少 290M
性能：启动时间： 浏览器 < 1300ms
MMS/SMS < 700ms
AlarmClock < 650ms
第二次启动一个应用的时间不能超过第一次启动时间。
CTS 测试： 必须通过最新的 CTS
升级：必须有一种办法可以升级全系统。
可以为：OTA USB SD卡

6 运行CTS方法的步骤（linux环境下）
1进入目录android-cts，该目录是通过上面那两种方法获得的。在android-cts目录下会有3个文件夹，其中一个是tools。

2进入tools目录，输入./startcts来启动CTS。
3如果运行成功会出现Android CTS version 2.3_r1的字样（我的android的版本是2.3的）。如果有连接设备到PC上还会出现Device(设备ID)connected的字样。这里设备可以是连接PC的android的机器，也可以是模拟器。

7 CTS测试的方法（linux环境下）
1在cts_host>下敲入help，会显示cts下的许多命令。ls –-plan命令显示google自带的测试方案，如：Java、Signature、Android、CTS、VM、RefApp、Performance、 AppSecurity。其中Performance这个方案是google暂不要求的。Java、Signature、Android、VM、 RefApp、Appsecurity方案都是CTS方案的子集。
2用命令ls --d来查看已连接的设备，CTS测试之前我们必须保证至少有一个设备连接上。
3输入命令start –-plan CTS来执行CTS测试方案，该方案有两万多条测试项目，需要很长时间，因此除了第一次测试之外，不建议这么做。我做的都是针对某些包的测试。如果连接了多个设备的话需加上-d参数，后面跟上设备id来告诉CTS需要测试的设备。
4对单独一个包进行测试的方法：start –-plan CTS –p 包名；推荐用这种方法来进行针对性的测试。需要知道有哪些包名，可以输入命令：ls –plan CTS
start --plan CTS -p android.content.cts.ContextWrapperTest

5也可以针对单独一个case进行测试：start –plan CTS –test 类名#方法名
start --plan CTS -t android.media.cts.MediaPlayerStreamingTest#testRTSP_MPEG4SP_AAC_Video2

『肆』 app测试环境中怎么安装apk

这几天Android 4.1和4.1.1的升级，对于不少Galaxy Nexus用户来说是个即兴奋又稍显麻烦的过程，刷机并不麻烦，麻烦在于刷机之后恢复自己习惯的试用环境。 钛备份是不少刷机用户必备工具，这款应用可以备份自己应用及数据、系统应用数据以及各种系统设置数据，不过有两点会比较麻烦。 第一是，在刷机之后恢复时需要一个一个的确认安装第三方程序，不能无人值守恢复。第二是，如果你刷的ROM和之前ROM不是同一系列，恢复之前的系统数据时容易出问题，比如新刷ROM中某个系统应用与之前ROM相比有过改动，数据不能通用，如果强行恢复就可能造成卡界面、卡加载等等。 我们换一种思路，如果能把第三方应用和数据打包，制作成一个没有系统文件只是第三方应用和相关数据的update.zip升级包，然后通过recovery直接刷到系统里面去，这样就能实现快速无人值守恢复应用，并且保留之前的使用数据和进度等信息。 同理，系统应用和数据也可以通过这种方式进行备份和恢复，会比钛备份的方式更加安全，因为只是涉及系统应用和对应数据的恢复，如果新刷ROM中的系统APP和之前ROM有冲突，刷机方式会直接覆盖这个APP并恢复对应的正确数据。 这种方式的缺点是无法备份系统设置数据，比如WiFi密码、书签等等。 App2zip 自制应用刷机包就是这样一款新工具，安装之后授予ROOT。程序列表显示为第三方应用和系统应用两种，可以自行选择多选或者全选，然后确认开始打包，工具会自动生成update.zip，可以自命名，压包之后会自动签名，成功签名的zip包才能试用recovery刷入。 目前这款工具APP刷机包制作工具刚刚推出，不能保证支持所有设备，所以想使用的用户可以在安装之后进行测试，选择一个不经常使用的软件进行备份，然后删除掉，再进入recovery模式将它刷回来，这样就能确认自己的设备是否可以使用这个工具。

『伍』 monkey命令怎么测试所有的apk应用

1、 通过eclipse启动一个Android的emulator ...
2、 在命令行中输入：adb devices查看设备连接情况 ...
3、 在有设备连接的前提下，在命令行中输入：adb shell 进入shell界面 ...
4、 查看data/data文件夹下的应用程序包。

『陆』 安卓系统如何测试 系统APK覆盖之后能正常使用用电脑能测试吗

只要你把系统的apk权限改对了基本上就可以了。无需测试，如果在卡刷包改的根本不用测试！望采纳。

『柒』 如何检测手机中是否有apk安装器

没有apk安装器是无法打包安装软件的。你若想找安装包，到设置中，找（从sd卡中安装apk）这个选项就行了，不过花费的时间会较长。除此之外，还可以在文件管理器里ss搜索apk

『捌』 如何通过cmd传自定义参数到测试apk中

像你所说的是不可能的！nbsp;给add_test.exe传递参数，这个很简单！只要得到应用程序对象App，(用AfxGetApp()函数得到),App类有个成员变量m_lpCmdLine，m_lpCmdLine是个数组，他就是传递过来的参数！nbsp;而要给CMD传递回去参数，那个是不可能的！假如一个程序要接受参数，要么就传递命令行参数，就像刚刚给你说的！要么就使用消息循环，给窗口发送以个消息！而CMD是没有消息循环也不会动态的接收命令行参数的！！nbsp;但是LZ可以考虑做以个控制台程序，就是和CMD框一样的程序！你可以在CMD里调用，那个只是CMD暂时转向你写的控制台程序执行！你就在你自己写的控制台程序里显示结果，然后Exit就可以了！

『玖』 设备内的apk如何用adb命令安装

adb是从pc找安装包的，如果已经传到设备里了，应该使用pm安装，比如
adb shell pm install /system/xxx.apk
或者
adb shell
pm install /system/xxx.apk

『拾』 如何测试安卓（Android）系统的流畅度

测试方法一：系统自带-开发者模式

实际上，为了方便开发者测试，安卓本身就内置了流畅度检测的功能。不过，这需要我们开启隐藏的开发者选项。如果你在用原生系统，那么开启开发者选项的方法很简单，进入到设置菜单“关于手机”页面，点击数次“版本号”，即可开启开发者选项。如果用的是其他ROM，方法也许有所不同，比如说魅族的Flyme开启开发者选项的方法是在拨号界面输入“*#*#6961#*#*”，其他机器方法也各有不同，大家可以参照厂商的说明。

进入到开发者选项，可以看到有“GPU呈现模式分析”的选项，开启后即可以条形图和线形图的方法显示系统的界面响应速度，可以用以观察系统流畅度。那么要如何根据曲线判断系统是否流畅呢？实际上这个曲线表达的是GPU绘制每一帧界面的时间，只要不超过顶部绿线，都可以视为足够流畅。

开启GPU呈现模式分析

FPS Meter可以显示最大最小帧数以及平均帧数

FPS Meter可以测试界面帧数，不过某些手机如果界面静止，帧数会为0。FPS Meter除了测量系统界面帧数外，还可以用来测量游戏的帧数，所以用FPS Meter来测试某部安卓机游戏性能多强也是个很好的选择。

当然，FPS Meter也并非十全十美。由于属于第三方App，所以可能会有一些兼容性问题。某些安卓机或者ROM使用FPS Meter可能会不兼容，即使成功开启了帧数显示也没法测量到准确数值，而某些设备使用FPS Meter甚至会死机。不过在大多数情况下，这款App还是相当值得信任的。

安卓在多个版本中都通过新技术提升了流畅度，比如说安卓2.3引入Dalvik、安卓4.0引入GPU界面绘制、安卓4.1引入黄油计划、安卓4.3引入Trim以及安卓4.4引入ART等等。

H5页面加载速度：window.performance.timing

Android以上测试方法不适用h5页面

如何分析页面整体加载速度：

主要是查看指标值PAGET_页面加载时间,此指标指的是页面整体加载时间但不含(onload事件和redirect), 此指标值可直接反应用户体验, 从此项指标可以知道指定某时间段的页面加载速度值,以及和天,周,月的对比状况.也可以查询指标ALLT_页面完全加载时间, 可以查询到从浏览器开始导航(用户点击链接或在地址栏输入url或点刷新,后退按钮)到页面onload 事件js完全跑完的所有时间.如果发现页面加载速度有增加或减少,则可以分项查询前面表格中的每个指标值,总的来说他们的关系如下:

dom开始加载前所有花费时间=重定向时间+域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间

pageLoadTime页面加载时间=域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间+解析dom花费时间+加载dom花费时间

allLoadTime页面完全加载时间=重定向时间+域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间+解析dom花费时间+加载dom花费时间+执行onload事件花费时间

resourcesLoadedTime资源加载时间=解析dom花费时间+加载dom花费时间

流畅度暂时没有发现好用的测试衡量工具，开发层面了解，主要是根据log分析