一.常用的abd命令有哪些
1.什么是 ADB？
通俗解釋：
ADB 就像一個橋梁，讓電腦能控制連接的手機，比如安裝APP、抓日志、重啟設備等。
專業術語總結：
ADB（Android Debug Bridge）是 Android SDK 提供的命令行工具，允許開發者通過 USB 或網絡方式與 Android 設備交互，執行調試、安裝、日志查看等操作。
2.常用 ADB 命令（通俗講解 + 專業術語）
| 編號 | 命令 | 通俗解釋 | 面試術語總結 |
|---|---|---|---|
| 1 | adb devices | 查看連接到電腦的手機 | 查看當前已連接并授權調試的設備列表 |
| 2 | adb install xxx.apk | 把 APK 裝到手機上 | 向設備推送并安裝指定 APK 應用 |
| 3 | adb uninstall 包名 | 卸載 APP | 從設備中卸載指定包名的應用 |
| 4 | adb shell | 進入手機命令行模式 | 啟動與設備交互的 Linux shell 環境 |
| 5 | adb logcat | 看手機日志 | 實時輸出系統或應用日志信息 |
| 6 | adb pull /sdcard/xxx.txt | 把手機文件拷到電腦 | 從設備復制文件到本地電腦 |
| 7 | adb push local.txt /sdcard/ | 把電腦文件拷到手機 | 從本地電腦復制文件到設備 |
| 8 | adb reboot | 讓手機重啟 | 重啟設備 |
| 9 | adb reboot recovery | 進 recovery 模式 | 重啟設備并進入恢復模式 |
| 10 | adb logcat > log.txt | 把日志保存到文件 | 將日志輸出保存到本地文件，便于分析 |
| 11 | adb shell pm list packages | 查看手機裝了哪些包 | 列出設備中安裝的所有應用包名 |
| 12 | adb shell am start -n 包名/類名 | 啟動一個 App 頁面 | 通過 ActivityManager 啟動指定組件 |
| 13 | adb shell input tap x y | 模擬點擊屏幕 | 通過坐標模擬用戶點擊事件 |
| 14 | adb shell input text "hello" | 輸入文本 | 模擬用戶輸入字符 |
| 15 | adb shell screencap /sdcard/screen.png | 手機截圖 | 在設備端截圖并保存到指定路徑 |
| 16 | adb shell screenrecord /sdcard/demo.mp4 | 錄制屏幕 | 在設備端錄制屏幕內容為視頻 |
| 17 | adb shell dumpsys | 獲取系統信息（超詳細） | 調用系統服務獲取當前狀態、配置、性能等信息（常用于ANR、內存分析） |
| 18 | adb bugreport | 導出完整 bug 報告 | 收集系統診斷信息，生成 bugreport.zip，常用于故障復現分析 |
二.用過monkey嗎？用monkey來做什么？發現過什么問題?
1.通俗解釋
Monkey 是 Android 自帶的一個小工具，它可以“像個調皮的小猴子一樣”，隨機地點擊屏幕、滑動、輸入等，模擬用戶的亂操作，來看看 App 會不會崩潰或卡住。
我們常常用它來做穩定性測試（就像你不停地狂點 APP，看它會不會出問題）。
Monkey 是用來測試 APP 在“被亂點”的時候會不會崩潰、ANR（無響應）或者卡住。就像你把手機交給小孩子亂玩，看 APP 會不會掛掉。
比如：我設置 Monkey 連續點 1 萬次，如果在這過程中 APP 崩了、卡了，那就說明代碼還有 bug。
2.monkey來做什么
Monkey 是 Android SDK 自帶的命令行工具，可用于對應用進行隨機事件壓力測試，通過模擬用戶點擊、滑動、旋轉、按鍵等操作，驗證應用在高壓環境下的穩定性與健壯性。Monkey 常用于：
穩定性回歸測試
發現 ANR（Application Not Responding）
崩潰（Crash）
看門狗錯誤（Watchdog）
內存泄漏相關的問題
3.?用 Monkey 發現過哪些問題
以前跑 Monkey，APP 被亂點幾千次之后就崩了，后來發現是某個頁面的按鈕點太快會導致空指針異常。
還發現過頁面卡死，點來點去卡在 loading 頁面一直轉圈，發現是網絡請求超時沒做兜底。
?4.面試總結
用過 Monkey 工具，它是 Android 自帶的隨機事件測試工具，主要用于穩定性測試。我曾用它對項目進行過 10,000 次事件壓力測試，發現過由于按鈕快速重復點擊導致的空指針崩潰，也遇到過因網絡請求未限流導致界面卡死的問題。通過 logcat 和 crash 報告進行分析后修復，增強了 APP 的穩定性。
三.APP崩潰/閃退，一般是什么原因造成的？
“APP 崩潰或閃退的常見原因主要包括以下幾類：
空指針引用（NullPointerException）：未初始化對象即調用方法。
數組越界或集合下標異常（IndexOutOfBoundsException）。
主線程阻塞：如網絡請求或 I/O 操作未異步處理，導致 ANR 或 watchdog 殺死進程。
內存溢出（OOM）：例如加載大圖、頻繁創建對象未釋放。
權限缺失：如未申請相機、定位權限直接調用 API，系統攔截后崩潰。
系統兼容性問題：Android/iOS 系統升級導致某些 API 或行為變化。
第三方 SDK 異常：集成不當或版本不兼容引發崩潰。
并發訪問異常：如多線程同時訪問同一資源未加鎖，出現 race condition。
遇到這類問題，我會第一時間查看 logcat（Android）或 Xcode控制臺日志（iOS）獲取異常堆棧，然后結合崩潰監控工具如 Firebase Crashlytics、Bugly 等分析定位并復現問題。”
四.ISO系統和Andriod系統的區別?
| 對比維度 | iOS（蘋果） | Android（安卓） |
|---|---|---|
| 是誰的系統？ | 蘋果自家的，只給 iPhone/iPad 用 | Google 開發的，手機廠商都能用 |
| 開源嗎？ | 不開源（只有 Apple 自己能改） | 開源，誰都可以拿去改（MIUI、華為鴻蒙其實都是 Android 魔改） |
| 界面統一嗎？ | 非常統一，幾乎每臺 iPhone 用起來都差不多 | 很碎片化，不同廠商界面差很多（小米、三星、華為各不一樣） |
| App 安裝方式？ | 只能從 App Store 裝，限制嚴 | 可以用第三方市場，甚至直接安裝 APK |
| 安全性高嗎？ | 高，權限限制多，審核嚴格 | 相對低，有風險 APP 更容易安裝進系統 |
| 通知欄/后臺機制？ | 管控非常嚴格，省電但限制多 | 靈活，但后臺容易耗電、掉消息 |
| 用戶量？ | 高端用戶多、付費能力強 | 用戶基數大，覆蓋廣 |
| 適配難度？ | 少數幾個設備，適配容易 | 屏幕尺寸五花八門，適配很難 |
總結：iOS 是封閉、安全、統一的蘋果自研系統，而 Android 是開源、靈活、適配復雜的谷歌系統。
五.怎么測試APP的兼容性
?APP 兼容性測試是指在不同軟硬件環境下驗證應用是否能正確安裝、運行、顯示和交互，確保功能一致性與穩定性。
| 方法 | 簡述 |
|---|---|
| 真機測試 | 在多品牌多型號手機上逐一測試，穩定性高，成本大 |
| 云真機測試 | 如阿里云測、百度 MTC、騰訊 WeTest 等云平臺遠程調試 |
| 模擬器測試（輔助） | Android Studio / Xcode 模擬器模擬不同設備，效率高但不穩定 |
| 自動化測試結合 | 使用 Appium + 多設備運行，提高覆蓋效率 |
總結：APP 兼容性測試主要是通過在不同品牌、不同系統版本、不同分辨率和網絡環境下驗證應用的功能、UI 和性能是否一致，常用真機測試、云測平臺與自動化測試相結合，確保廣泛用戶的使用體驗穩定可靠。
六.APP的性能測試如何做？?
APP 性能測試是指評估移動應用在不同負載、操作或環境下的運行效率、響應速度、資源消耗和穩定性，確保其在實際使用中具備良好用戶體驗。
1.通俗易懂地解釋
性能測試就是看 APP 有沒有卡頓、耗不耗電、用不用太多內存、網絡快不快。
舉幾個例子你就明白了：
你打開 APP 是不是很慢？👉 就要測“啟動耗時”
滑動頁面會不會卡？👉 就要測“幀率”
用久了手機發熱嚴重？👉 就要測“CPU 和電量”
看視頻會不會卡頓？👉 就要測“網絡延遲”
用得時間長 APP 會不會越來越卡？👉 就要測“內存占用”
測試時可以通過真機 + 工具來一起測，比如 Android 可以用 adb、systrace、perfetto，iOS 可以用 Instruments。
2.常見性能測試維度
| 測試維度 | 說明 |
|---|---|
| 啟動時間 | 冷啟動、熱啟動時間是否滿足業務要求（<3s） |
| CPU 使用率 | 高負載是否造成手機發熱、卡頓 |
| 內存使用（RAM） | 是否存在內存泄漏、頻繁 GC 等問題 |
| 幀率（FPS） | 頁面滑動或動畫是否流暢（安卓應 ≥60fps） |
| 電量消耗 | 后臺/前臺運行是否耗電異常 |
| 網絡性能 | 請求延遲、丟包率、上傳/下載速度等 |
| 磁盤讀寫 | 是否頻繁或大量讀寫導致系統卡頓 |
| Crash/ANR 概率 | 高并發/高操作是否導致崩潰或無響應 |
3.測試方法?
| 方法 | 舉例 |
|---|---|
| 手動測試 + 真機監控 | 使用開發者工具查看內存、CPU、幀率等 |
| 借助工具監控 | Android 使用 adb、systrace、Android Profiler；iOS 使用 Instruments |
| 自動化采集指標 | 使用 PerfDog、GT（騰訊）、Firebase、Bugly 性能面板 |
| 持續集成集成測試 | 將性能測試接入 CI 流水線做持續監控 |
| 壓測/弱網測試 | 模擬極端場景下的性能表現（弱網、低電量、多任務等） |
4.總結
APP 的性能測試主要包括啟動時間、CPU/內存占用、幀率、耗電、網絡請求等維度，我通常通過真機測試結合工具（如 Android Profiler、Instruments、PerfDog 等）監控關鍵指標，結合自動化或持續集成，發現卡頓、耗電或內存泄漏等問題，從而優化用戶體驗。
七.手機APP更新測試，說一下測試點
APP 更新測試，就是在用戶已經裝了舊版本的情況下，我們發了一個新版本，用戶從應用市場、彈窗提示、自動下載等方式更新了之后：
你要驗證的核心是：
更新完能不能用？數據會不會丟？界面會不會錯？功能有沒有崩？兼容有沒有問題？
總結：APP 更新測試主要包含 5 個方面：更新流程驗證、數據保留、功能回歸、界面顯示、特殊場景兼容性。我通常會覆蓋手動更新、市場更新、強制/非強制升級場景，同時重點驗證更新后用戶數據遷移是否正常、功能是否穩定，以及弱網/中斷/空間不足等邊界情況，確保升級過程穩定可靠。?
八.如何模型弱網測試
弱網測試就是模擬手機在網絡不好的情況下（比如地鐵、山區、信號差的地下車庫）使用 APP，觀察它有沒有：
頁面加載超時？
網絡斷了有沒有提示？
上傳/下載失敗了會不會重試？
彈窗卡住？轉圈圈不消失？
所以我們要人為“制造”這些糟糕的網絡，比如：
變慢（比如速度只有 50kb/s）
丟包（有一半數據發不出去）
延遲高（點按鈕后3秒才響應）
斷連、頻繁切換網絡
APP弱網測試是通過工具或腳本模擬網絡延遲、丟包、限速、斷網等環境，驗證應用在異常網絡下的穩定性、加載表現和容錯能力。
1.如何模擬弱網環境
1. 使用系統自帶模擬工具（推薦）
? Android 設備：
開發者選項 > 網絡限制
可選擇：無網絡
僅限 2G、3G、4G
模擬高延遲（Android 11+）
? iOS 設備（需 Mac）：
使用 Mac 上的 Network Link Conditioner（網絡鏈路調節器）
選項如：Edge、3G、High Latency DNS、Very Bad Network 等
安裝路徑：Xcode > Additional Tools
2. 使用專業弱網模擬工具（功能最強）
| 工具名稱 | 平臺 | 功能簡介 |
|---|---|---|
| Charles | Win/Mac | 抓包 + 弱網模擬（限速、丟包、斷連） |
| Network Link Conditioner | Mac / iOS | 蘋果官方網絡模擬器（延遲、丟包、帶寬） |
| Clumsy | Windows | 模擬丟包、延遲、限速等 |
| NetEm（Linux） | Linux | 命令行模擬網絡質量，非常靈活 |
| 騰訊 GT / PerfDog | Android | 性能 + 網絡模擬一體工具 |
3. 使用真機切換網絡測試
| 方法 | 描述 |
|---|---|
| 物理切換網絡 | 手動切換 WiFi ? 4G ? 飛行模式 |
| 信號屏蔽 | 使用屏蔽盒、地下室、地鐵等物理弱網環境 |
| 熱點共享限速 | 用路由器/AP 控制熱點限速（限上傳/下載） |
4. 自動化 + 弱網腳本結合
可以通過腳本在測試中動態切換網絡、限速、模擬斷連，例如：
adb shell "svc data disable" # 模擬斷網 adb shell "svc data enable" # 恢復聯網
2.測試重點場景建議：
| 場景 | 建議關注 |
|---|---|
| 首次打開 APP | 啟動慢、接口失敗是否兜底 |
| 圖片/視頻加載 | 是否有加載占位圖、加載失敗提示 |
| 表單提交 | 網絡斷掉后是否重試/提示用戶 |
| 登錄注冊 | 異常網絡下是否提示明確錯誤 |
| 上傳文件 | 是否支持斷點續傳、失敗后提示 |
| IM/消息類 | 消息是否延遲/丟失/亂序 |
| 網絡切換 | WiFi ? 4G 是否會斷流、卡住、重連失敗 |
九.針對App的安裝功能，寫出測試點??
1.App 安裝功能測試點（分類整理）
① 安裝流程測試
| 測試點 | 說明 |
|---|---|
| 正常安裝是否成功 | 在常見設備上下載安裝是否順利 |
| 是否彈出權限/授權提示 | 如安裝來源、安全提醒是否正常出現 |
| 應用圖標是否顯示在桌面 | 安裝完成后是否能在主屏找到 APP 圖標 |
| 安裝后是否能正常啟動 | 安裝完成后點擊是否能打開主頁 |
| 安裝包簽名一致性 | 升級/重裝時簽名是否一致，防止安裝失敗 |
| 安裝路徑是否正確 | 檢查是否默認安裝到系統路徑（特別是支持 SD 卡時） |
② 安裝異常場景測試
| 測試點 | 說明 |
|---|---|
| 空間不足是否提示 | 安裝過程中手機空間不足是否提示清晰，是否失敗后恢復正常 |
| 安裝中斷后是否能恢復 | 安裝一半斷電、拔數據線，重新安裝是否正常 |
| 多次點擊安裝是否沖突 | 連續點擊多次安裝包是否導致異常 |
| 多版本覆蓋安裝是否兼容 | 從舊版本到新版本安裝，或降級安裝是否提示/阻止 |
| 非官方渠道安裝是否受限 | 非市場 APK 是否可安裝、是否彈出風險提示 |
③ 系統版本與兼容性測試
| 測試點 | 說明 |
|---|---|
| 不同 Android/iOS 系統安裝是否正常 | Android 814 / iOS 1317 是否均可安裝 |
| 不同 ROM（MIUI/EMUI/ColorOS）適配 | 是否因系統安全策略被限制安裝 |
| 是否支持快速安裝 | 如 Android 使用 split APK、iOS 是否支持 TestFlight |
④ 安裝后行為驗
| 測試點 | 說明 |
|---|---|
| 安裝后是否自動啟動 | 是否在某些廠商系統下自動拉起（需判斷是否合規） |
| 是否能被桌面搜索到 | 安裝完成后桌面是否能正確檢索 |
| 是否能正常卸載 | 卸載是否徹底，是否殘留數據或圖標 |
2.面試總結術語?
針對 App 的安裝功能，我會從安裝流程、異常場景、系統兼容性和安裝后行為四方面進行測試，包括正常安裝、簽名驗證、空間不足、覆蓋安裝、系統適配等，確保用戶在各種條件下都能順利、安全地完成安裝并正常使用 App。
十.做兼容性測試時，如何選擇機型
在兼容性測試中，我會結合市場占有率、操作系統版本、分辨率、性能層級和廠商定制系統等五個維度，選取具有代表性的機型進行覆蓋測試，確保功能和顯示在主流與邊緣用戶場景下都能穩定運行。
十一.測過APP的push推送嗎，需要考慮哪些點
Push（消息推送）就是讓 APP 在沒打開的情況下也能收到消息，比如：
微信來消息了、
支付寶到賬提醒、
淘寶雙11給你發促銷通知
測試的時候要關注的核心點就是：
消息推得過來嗎？推得準嗎？推的時候 APP 是不是在前臺/后臺/被殺死都能正常彈出？點了推送能不能跳到指定頁面？
總結：我測試過 APP 的 Push 推送功能，主要從 通道配置、多場景狀態（前臺/后臺/殺進程）、通知內容展示、跳轉邏輯、用戶設置控制、消息頻率與多設備同步 等維度進行覆蓋測試，確保推送消息在各類設備和系統狀態下都能準確送達、合理展示并跳轉無誤。還結合了 廠商推送統計平臺（如極光后臺）與客戶端日志（推送 token、收達時間） 做推送鏈路的驗證，確保消息從服務端發出到客戶端展示全鏈路可控。?
十二.APP冷啟動和熱啟動的區別
我們拿“打開 APP”來打比方：
| 類型 | 通俗理解 |
|---|---|
| ?? 冷啟動（Cold Start） | 第一次打開 APP，或者 APP 完全被關閉了，重新啟動，相當于“從頭開始啟動” |
| 🔥 熱啟動（Hot Start） | APP 只是“退到后臺”，你再切回來，就像是“把它從后臺喚醒” |
?舉個例子：
你剛開機，點微信 → 冷啟動
微信退到后臺沒關 → 你再點回來 → 熱啟動
你把微信從后臺滑掉（徹底殺死）再點開 → 冷啟動
| 對比項 | 冷啟動（Cold Start） | 熱啟動（Hot Start） |
|---|---|---|
| 啟動時機 | 應用未運行或進程被殺死 | 應用仍在后臺，未被系統殺死 |
| 系統行為 | 創建新進程、初始化 Application、Activity 生命周期全走一遍 | 直接從后臺恢復，Activity 可能只走 onRestart/onResume |
| 加載時間 | 啟動慢，耗時長（初始化多） | 啟動快，幾乎秒開 |
| 用戶體驗 | 黑屏/白屏階段明顯，啟動動畫完整顯示 | 恢復速度快，直接進入上次狀態 |
| 性能優化點 | Application 初始化、首幀渲染優化 | 恢復現場、后臺保活等策略 |
| 常見觸發方式 | 開機后首次打開 / 手動結束進程后 | 切后臺再切回前臺 |
總結：冷啟動是指應用完全未運行時的首次啟動，需要重新創建進程并初始化所有組件；熱啟動則是應用處于后臺時重新進入前臺，系統保留進程狀態，啟動更快。兩者在生命周期觸發、啟動耗時和用戶體驗上有明顯差異。
十三.有做過H5的測試嗎
H5 就是嵌在 App 或瀏覽器中的“網頁頁面”，比如：
公眾號打開的活動頁
App 內的“會員中心”“登錄頁”（是個 WebView 頁面）
微信小程序中打開的 web 頁面
瀏覽器訪問的網頁
你做 H5 測試的時候，其實就要測：
頁面在不同手機上加載快不快？排版亂不亂？能不能正常跳轉？按鈕好不好點？前后端數據是否一致？微信打開有沒有問題？
?十四.APP的某個功能失效了，如何排查是客戶端還是服務端的問題
1.通俗易懂地解釋：怎么判斷問題到底出在客戶端還是服務端？
你可以把客戶端想成“手機App”，服務端想成“后臺處理中心”。
比如你在 App 點了“提交訂單”沒反應，那你就要分析到底是：
手機 App 自己沒發請求？（客戶端問題）
請求發出去了，后臺沒響應或者報錯？（服務端問題）
2.常用排查邏輯如下：
📍 第一步：看 App 有沒有“報錯提示”
? 什么都沒彈？→ 客戶端可能根本沒發請求
? 一直轉圈？→ 有可能是等服務端沒回應
📍 第二步：抓日志（logcat 或 Charles/Fiddler）
看有沒有發送 HTTP 請求？請求成功了嗎？狀態碼是多少？
狀態碼 200 → 說明服務端響應了，看返回數據對不對
狀態碼 5xx / 4xx → 多半是服務端異常（比如接口報錯、鑒權失敗）
根本沒請求 → 多半是客戶端邏輯問題（前端條件判斷失敗、按鈕沒響應）
📍 第三步：換網絡/換手機/重新登錄試試
如果換手機后功能正常，那很可能是客戶端緩存問題或兼容問題
如果所有手機都不行，那可能是服務端宕機或接口變更
📍 第四步：對照接口文檔、Postman 手動調接口
直接用 Postman 發同樣的請求試試看服務端返回什么
如果 Postman 正常返回，那就是客戶端請求方式有問題
如果 Postman 也失敗，那就是服務端接口有問題
📍 第五步：問一下開發/聯調日志
查看后端日志、API 網關日志，看請求有沒有打到后端，有沒有異常棧
?3.面試術語總結
“遇到 APP 某個功能失效時，我通常會從客戶端與服務端兩方面排查：
① 首先查看客戶端日志，確認是否發起了請求、狀態碼、返回內容等；
② 再抓包（如使用 Charles、Fiddler、Wireshark 等）驗證是否正常請求并收到響應；
③ 同時用 Postman 等工具復現接口調用，驗證服務端邏輯是否正常；
④ 如服務端返回正常，再定位客戶端處理邏輯是否異常，如數據解析失敗、UI未更新等；
⑤ 若接口也異常，則配合后端查看日志判斷是否接口改動、部署失敗或參數錯誤。”
舉列子：之前我們遇到一個‘訂單無法提交’的問題，初步以為是服務端故障。但通過 Charles 抓包發現，客戶端并沒有發出接口請求，最終定位是客戶端邏輯判斷失敗未觸發提交事件，修復條件判斷后恢復正常。
十五.工作中都用到什么抓包工具的什么功能，分別在什么場景下使用的
“工作中常用的抓包工具主要包括 Charles、Fiddler 和 Wireshark。
其中 Charles 是使用最頻繁的，主要用于抓取 App 的 HTTP/HTTPS 請求，調試請求參數、響應數據；結合 Rewrite 和 Map Local 功能，我們可以模擬服務端返回不同場景，便于客戶端功能驗證和異常處理測試；
在弱網場景測試中，我們會使用 Charles 的 Throttle 功能模擬帶寬延遲；
而 Wireshark 多用于底層網絡問題排查，比如分析音視頻傳輸、DNS 解析失敗等。
對于自動化場景，我們也使用過 Mitmproxy 結合腳本分析請求是否達標。”
?
))
