如何測試設備內置的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分析