大家好，我是溫大大。
最近溫大大的讀者們問我有沒有app相關(guān)的面試題，
作為「平易近人」的大大怎么能忍心說沒有呢，
這不繼續(xù)爆肝 輸出app測試工程師專項(xiàng)面試題，
本篇從：app測試基礎(chǔ)、app 測試場景（覆蓋7大場景 + 100 多個(gè)測試點(diǎn)，直接可以拿來用）、app工具 Appium/ Fiddler/ Monkey 介紹、app 常見問答定位、app 環(huán)境安裝 這些個(gè)緯度大家全面解析app面試題。
配合前面三篇八股文，無敵...
網(wǎng)絡(luò) 100道高頻面試題再次拜托各位同學(xué)～爆肝不易，一鍵三連：點(diǎn)贊、收藏、轉(zhuǎn)發(fā)
同時(shí)溫大大還需要提醒 從事 app測試的同學(xué)一定要重視1個(gè)問題，
因?yàn)閍pp測試入行容易，門檻也比較低，只要你測試常見覆蓋了第1章節(jié)里面那些測試點(diǎn)，基本上問題不大，難的是如何能從「質(zhì)量」與「效率」這2個(gè)方向去深入下去，
「效率」無非是掌握一些app自動(dòng)化測試工具 appium / selenium 能快速有效的對(duì)用例進(jìn)行執(zhí)行
「質(zhì)量」就需要去模擬一些特殊場景來驗(yàn)證app的性能、兼容性（瀏覽器、手機(jī)兼容）也是需要掌握一些app壓測工具 monkey 以及 弱網(wǎng)測試工具 Fiddler的一些運(yùn)用，最重要的是你能去定位性能瓶頸，更甚者能幫研發(fā)去解決這些問題。
如果你「效率」與「質(zhì)量」任何1個(gè)方面做的不錯(cuò)都能拿高薪。
如果你有以上的煩惱，建議找到溫大大，讓我?guī)湍阋?guī)劃下學(xué)習(xí)線路 & 職業(yè)規(guī)劃線路，幫你升職加薪。
目錄
0 app 測試基礎(chǔ)
0.1 Android 和 IOS 系統(tǒng)有什么區(qū)別？
0.2 Android 測試與 web 測試有什么區(qū)別？
0.3 APP 這么多主流機(jī)型你們公司是如何覆蓋的？
1 app 測試場景（重點(diǎn)）
1.1 軟件權(quán)限
1.2 安裝與卸載安全性
1.3 數(shù)據(jù)安全性
1.4 通訊安全性
1.5 人機(jī)接口安全性
1.6 安裝、卸載測試
1.7 UI測試
1.8 導(dǎo)航測試
1.9 圖形測試
1.10 內(nèi)容測試
1.11 功能測試
1.12 運(yùn)行測試
1.13 應(yīng)用的前后臺(tái)切換
1.14 免登錄
1.15 數(shù)據(jù)更新
1.16 離線瀏覽
1.17 App更新
1.18 定位、照相機(jī)服務(wù)
1.19 時(shí)間測試
1.20 PUSH測試
1.21 性能測試
1.22 交叉事件測試
1.23 兼容測試
1.24 回歸測試
1.25 用戶體驗(yàn)測試
2 app 工具篇
2.1 介紹一下 Appium 工具
2.2 Appium 與 Selenium的關(guān)系
2.3 Appium 原理（重點(diǎn)!）
2.4 常見的 adb 命令
2.5 什么是POM模式？
2.6 抓包工具 Fiddler 道常見面試題
2.7 壓力工具 Monkey 道常見面試題
3 app 問題定位篇
3.1 App奔潰或閃退時(shí)如何定位原因？
3.2 Android 內(nèi)存不足的幾種情況？
3.3 Android 的Generational Heap Memory的模型你了解嗎？
3.4 如何判斷 app 的 bug 是客戶端問題還是后臺(tái)問題
3.5 安卓中如何取出日志信息？
4 app 環(huán)境定位篇
4.1 app 測試有哪幾種環(huán)境？
4.2 Android SDK 的安裝步驟說一下
0 app 測試基礎(chǔ)
0.1 Android 和 IOS 系統(tǒng)有什么區(qū)別？
運(yùn)行機(jī)制不同：IOS 采用的是沙盒運(yùn)行機(jī)制，安卓采用的是虛擬機(jī)運(yùn)行機(jī)制。
后臺(tái)制度不同：IOS 中任何第三方程序都不能在后臺(tái)運(yùn)行；安卓中任何程序都 能在后臺(tái)運(yùn)行，直到?jīng)]有內(nèi)存才會(huì)關(guān)閉。
IOS 中用于 UI 指令權(quán)限最高，安卓中數(shù)據(jù)處理指令權(quán)限最高。
0.2 Android 測試與 web 測試有什么區(qū)別？
相同點(diǎn)：測試原理相同；
1.設(shè)計(jì)測試用例均依據(jù)等價(jià)類、邊界值等方法
2.大多數(shù)都采用黑盒測試方法來驗(yàn)證業(yè)務(wù)功能；
3.需要檢查界面布局、風(fēng)格和按鈕是否美觀、統(tǒng)一等（UI 測試）；
4.測試頁面載入和翻頁的速度、登錄時(shí)長是否溢出等問題（性能測試）
5.測試應(yīng)用系統(tǒng)的穩(wěn)定性；
不同點(diǎn)1：通訊方式、測試工具
1.手機(jī)作為通信工具，通信等一些行為會(huì)對(duì) APP 產(chǎn)生(中斷測試)
2.手機(jī)用戶對(duì) app 產(chǎn)品的安裝卸載操作：從上一版本/上兩個(gè)版本直接升級(jí)到最新 版本（安裝卸載測試）；
3.web 自動(dòng)化測試使用的工具較常用的是 selenium,而 android 手機(jī)自動(dòng)化測試比 較常用的自動(dòng)化工具是 monkey、monkeyrunner、Appium（測試工具不一樣）
不同點(diǎn)2: 特性不同
Web端特性
首先從系統(tǒng)架構(gòu)來看的話，web測試只要更新了服務(wù)器端，客戶端就會(huì)同步會(huì)更新。而且客戶端是可以保證每一個(gè)用戶的客戶端完全一致的。
其次性能方面，web頁面可能只會(huì)關(guān)注響應(yīng)時(shí)間。
最后兼容性方面，web是基于瀏覽器的，所以更傾向于瀏覽器和電腦硬件，電腦系統(tǒng)的方向的兼容，不過一般還是以瀏覽器的為主。而瀏覽器的兼容則是一般是選擇不同的瀏覽器內(nèi)核進(jìn)行測試（IE、chrome、Firefox）。
App端特性
app端是不能夠保證完全一致的，除非用戶更新客戶端。如果是app下修改了服務(wù)端，意味著客戶端用戶所使用的核心版本都需要進(jìn)行回歸測試一遍。
app則還需要關(guān)心流量、電量、CPU、GPU、Memory。
app的測試則必須依賴手機(jī)或者平板，不僅要看分辨率，屏幕尺寸，還要看設(shè)備系統(tǒng)。系統(tǒng)總的來說也就分為Android和iOS，不過國內(nèi)的Android的定制系統(tǒng)太多，也是比較容易出現(xiàn)問題的。
0.3 APP 這么多主流機(jī)型你們公司是如何覆蓋的？
通過真機(jī)模擬平臺(tái)進(jìn)行覆蓋：
百度移動(dòng)云測試中心簡稱MTC
該中心為開發(fā)者提供了上百種主流廠商的移動(dòng)終端設(shè)備及增強(qiáng)模擬器，涵蓋了Top 100 Android真機(jī)和各種配置的模擬器，方便開發(fā)者進(jìn)行實(shí)時(shí)的手機(jī)應(yīng)用開發(fā)和測試工作。MTC，針對(duì)開發(fā)者和廠商的不同需求，開放出多種云服務(wù)，包括：云測試、云調(diào)試、云審核等。
六種測試：1）安裝卸載測試 ? ?2）UI適配測試 ? ?3）穩(wěn)定性測試 ? 4）遍歷測試 ? ?5）性能測試6）錄制回放功能測試
WeTest騰訊質(zhì)量開放平臺(tái)
WeTest騰訊質(zhì)量開放平臺(tái)(wetest.qq.com),是由騰訊游戲官方推出的一站式游戲測試平臺(tái)?？梢赃h(yuǎn)程調(diào)試app。
其他平臺(tái)
MQC阿里移動(dòng)測試平臺(tái)
TestBird
Testin
1 App 測試場景
1.1 軟件權(quán)限
1）扣費(fèi)風(fēng)險(xiǎn)：包括發(fā)送短信、撥打電話、連接網(wǎng)絡(luò)等
2）隱私泄露風(fēng)險(xiǎn)：包括訪問手機(jī)信息、訪問聯(lián)系人信息等
3）對(duì)App的輸入有效性校驗(yàn)、認(rèn)證、授權(quán)、敏感數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)加密等方面進(jìn)行檢測
4）限制/允許使用手機(jī)功能接人互聯(lián)網(wǎng)
5）限制/允許使用手機(jī)發(fā)送接受信息功能
6）限制/允許應(yīng)用程序來注冊自動(dòng)啟動(dòng)應(yīng)用程序
7）限制或使用本地連接
8）限制/允許使用手機(jī)拍照或錄音
9）限制/允許使用手機(jī)讀取用戶數(shù)據(jù)
10）限制/允許使用手機(jī)寫人用戶數(shù)據(jù)
11）檢測App的用戶授權(quán)級(jí)別、數(shù)據(jù)泄漏、非法授權(quán)訪問等
1.2 安裝與卸載安全性
1）應(yīng)用程序應(yīng)能正確安裝到設(shè)備驅(qū)動(dòng)程序上
2）能夠在安裝設(shè)備驅(qū)動(dòng)程序上找到應(yīng)用程序的相應(yīng)圖標(biāo)
3）是否包含數(shù)字簽名信息
4）沒有用戶的允許, 應(yīng)用程序不能預(yù)先設(shè)定自動(dòng)啟動(dòng)
5）卸載是否安全, 其安裝進(jìn)去的文件是否全部卸載
6）卸載用戶使用過程中產(chǎn)生的文件是否有提示
7）其修改的配置信息是否復(fù)原
8）卸載是否影響其他軟件的功能
9）卸載應(yīng)該移除所有的文件
1.3 數(shù)據(jù)安全性
1）當(dāng)將密碼或其他的敏感數(shù)據(jù)輸人到應(yīng)用程序時(shí), 其不會(huì)被儲(chǔ)存在設(shè)備中, 同時(shí)密碼也不會(huì)被解碼
2）輸人的密碼將不以明文形式進(jìn)行顯示
3）密碼, 信用卡明細(xì), 或其他的敏感數(shù)據(jù)將不被儲(chǔ)存在它們預(yù)輸人的位置上
4）不同的應(yīng)用程序的個(gè)人身份證或密碼長度必需至少在4一8 個(gè)數(shù)字長度之間
5）當(dāng)應(yīng)用程序處理信用卡明細(xì), 或其他的敏感數(shù)據(jù)時(shí), 不以明文形式將數(shù)據(jù)寫到其它單獨(dú)的文件或者臨時(shí)文件中。以6）防止應(yīng)用程序異常終止而又沒有側(cè)除它的臨時(shí)文件, 文件可能遭受人侵者的襲擊, 然后讀取這些數(shù)據(jù)信息。
7）當(dāng)將敏感數(shù)據(jù)輸人到應(yīng)用程序時(shí), 其不會(huì)被儲(chǔ)存在設(shè)備中
8）備份應(yīng)該加密, 恢復(fù)數(shù)據(jù)應(yīng)考慮恢復(fù)過程的異常?通訊中斷等, 數(shù)據(jù)恢復(fù)后再使用前應(yīng)該經(jīng)過校驗(yàn)
9）應(yīng)用程序應(yīng)考慮系統(tǒng)或者虛擬機(jī)器產(chǎn)生的用戶提示信息或安全替告
10）應(yīng)用程序不能忽略系統(tǒng)或者虛擬機(jī)器產(chǎn)生的用戶提示信息或安全警告, 更不能在安全警告顯示前,，利用顯示誤導(dǎo)信息欺騙用戶，應(yīng)用程序不應(yīng)該模擬進(jìn)行安全警告誤導(dǎo)用戶
11）在數(shù)據(jù)刪除之前，應(yīng)用程序應(yīng)當(dāng)通知用戶或者應(yīng)用程序提供一個(gè)“取消”命令的操作
12）“ 取消” 命令操作能夠按照設(shè)計(jì)要求實(shí)現(xiàn)其功能
13）應(yīng)用程序應(yīng)當(dāng)能夠處理當(dāng)不允許應(yīng)用軟件連接到個(gè)人信息管理的情況
14）當(dāng)進(jìn)行讀或?qū)懹脩粜畔⒉僮鲿r(shí), 應(yīng)用程序?qū)?huì)向用戶發(fā)送一個(gè)操作錯(cuò)誤的提示信息
15）在沒有用戶明確許可的前提下不損壞側(cè)除個(gè)人信息管理應(yīng)用程序中的任何內(nèi)容Μ
16）應(yīng)用程序讀和寫數(shù)據(jù)正確。
17）應(yīng)用程序應(yīng)當(dāng)有異常保護(hù)。
18）如果數(shù)據(jù)庫中重要的數(shù)據(jù)正要被重寫, 應(yīng)及時(shí)告知用戶
19）能合理地處理出現(xiàn)的錯(cuò)誤
20）意外情況下應(yīng)提示用戶
1.4 通訊安全性
1）在運(yùn)行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍(lán)牙、紅外等通訊或充電時(shí), 是否能暫停程序，優(yōu)先處理通信, 并在處理完畢后能正?；謴?fù)軟件, 繼續(xù)其原來的功能
2）當(dāng)創(chuàng)立連接時(shí), 應(yīng)用程序能夠處理因?yàn)榫W(wǎng)絡(luò)連接中斷, 進(jìn)而告訴用戶連接中斷的情況
3）應(yīng)能處理通訊延時(shí)或中斷
4）應(yīng)用程序?qū)⒈３止ぷ鞯酵ㄓ嵆瑫r(shí), 進(jìn)而發(fā)送給用戶一個(gè)錯(cuò)誤信息指示有連接錯(cuò)誤
5）應(yīng)能處理網(wǎng)絡(luò)異常和及時(shí)將異常情況通報(bào)用戶
6）應(yīng)用程序關(guān)閉或網(wǎng)絡(luò)連接不再使用時(shí)應(yīng)及時(shí)關(guān)閉) 斷開
7）HTTP、HTTPS覆蓋測試
--App和后臺(tái)服務(wù)一般都是通過HTTP來交互的，驗(yàn)證HTTP環(huán)境下是否正常；
--公共免費(fèi)網(wǎng)絡(luò)環(huán)境中（如：麥當(dāng)勞、星巴克等）都要輸入用戶名和密碼，通過SSL認(rèn)證來訪問網(wǎng)絡(luò)，需要對(duì)使用HTTP Client的library異常作捕獲處理。
1.5 人機(jī)接口安全性
1）返回菜單總保持可用
2）命令有優(yōu)先權(quán)順序
3）聲音的設(shè)置不影響應(yīng)用程序的功能
4）應(yīng)用程序必需利用目標(biāo)設(shè)備適用的全屏尺寸來顯示上述內(nèi)容
5）應(yīng)用程序必需能夠處理不可預(yù)知的用戶操作, 例如錯(cuò)誤的操作和同時(shí)按下多個(gè)鍵
1.6 安裝、卸載測試
安裝
1）軟件在不同操作系統(tǒng)下安裝是否正常。
2）軟件安裝后的是否能夠正常運(yùn)行，安裝后的文件夾及文件是否寫到了指定的目錄里。
3）軟件安裝各個(gè)選項(xiàng)的組合是否符合概要設(shè)計(jì)說明
4)）軟件安裝向?qū)У腢I測試
5）軟件安裝過程是否可以取消，點(diǎn)擊取消后，寫入的文件是否如概要設(shè)計(jì)說明處理
6）軟件安裝過程中意外情況的處理是否符合需求（如死機(jī)，重啟，斷電）
7）安裝空間不足時(shí)是否有相應(yīng)提示
8）安裝后沒有生成多余的目錄結(jié)構(gòu)和文件
9）對(duì)于需要通過網(wǎng)絡(luò)驗(yàn)證之類的安裝，在斷網(wǎng)情況下嘗試一下
10）還需要對(duì)安裝手冊進(jìn)行測試，依照安裝手冊是否能順利安裝
卸載
1）直接刪除安裝文件夾卸載是否有提示信息。
2）測試系統(tǒng)直接卸載程序是否有提示信息。
3）測試卸載后文件是否全部刪除所有的安裝文件夾。
4）卸載過程中出現(xiàn)的意外情況的測試（如死機(jī)、斷電、重啟）。
5）卸載是否支持取消功能，單擊取消后軟件卸載的情況 。
6）系統(tǒng)直接卸載UI測試，是否有卸載狀態(tài)進(jìn)度條提示 。
1.7 UI測試
測試用戶界面(如菜單、對(duì)話框、窗口和其它可規(guī)控件)布局、風(fēng)格是否滿足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操作是否友好等。
UI測試的目標(biāo)是確保用戶界面會(huì)通過測試對(duì)象的功能來為用戶提供相應(yīng)的訪問或?yàn)g覓功能。確保用戶界面符合公司或行業(yè)的標(biāo)準(zhǔn)。包括用戶友好性、人性化、易操作性測試。
1.8 導(dǎo)航測試
1）按鈕、對(duì)話框、列表和窗口等；或在不同的連接頁面之間需要導(dǎo)航
2）是否易于導(dǎo)航，導(dǎo)航是否直觀
3）是否需要搜索引擎
4）導(dǎo)航幫助是否準(zhǔn)確直觀
5）導(dǎo)航與頁面結(jié)構(gòu)、菜單、連接頁面的風(fēng)格是否一致
1.9 圖形測試
1）橫向比較。各控件操作方式統(tǒng)一
2）自適應(yīng)界面設(shè)計(jì)，內(nèi)容根據(jù)窗口大小自適應(yīng)
3）頁面標(biāo)簽風(fēng)格是否統(tǒng)一
4）頁面是否美觀
5）頁面的圖片應(yīng)有其實(shí)際意義而要求整體有序美觀
6）圖片質(zhì)量要高且圖片尺寸在設(shè)計(jì)符合要求的情況下應(yīng)盡量小
7）界面整體使用的顏色不宜過多
1.10 內(nèi)容測試
1）輸入框說明文字的內(nèi)容與系統(tǒng)功能是否一致
2）文字長度是否加以限制
3）文字內(nèi)容是否表意不明
4）是否有錯(cuò)別字
5）信息是否為中文顯示
6）是否有敏感性詞匯、關(guān)鍵詞
7）是否有敏感性圖片，如：涉及版權(quán)、專利、隱私等圖片
1.11 功能測試
根據(jù)軟件說明或用戶需求驗(yàn)證App的各個(gè)功能實(shí)現(xiàn)，采用如下方法實(shí)現(xiàn)并評(píng)估功能測試過程：
1)采用時(shí)間、地點(diǎn)、對(duì)象、行為和背景五元素或業(yè)務(wù)分析等方法分析、提煉App的用戶使用場景，對(duì)比說明或需求，整理出內(nèi)在、外在及非功能直接相關(guān)的需求，構(gòu)建測試點(diǎn)，并明確測試標(biāo)準(zhǔn)，若用戶需求中無明確標(biāo)準(zhǔn)遵循，則需要參考行業(yè)或相關(guān)國際標(biāo)準(zhǔn)或準(zhǔn)則。
2)根據(jù)被測功能點(diǎn)的特性列丼出相應(yīng)類型的測試用例對(duì)其進(jìn)行覆蓋，如；涉及輸入的地方需要考慮等價(jià)、邊界、負(fù)面、異常或非法、場景回滾、關(guān)聯(lián)測試等測試類型對(duì)其進(jìn)行覆蓋。
3)在測試實(shí)現(xiàn)的各個(gè)階段跟蹤測試實(shí)現(xiàn)與需求輸入的覆蓋情況，及時(shí)修正業(yè)務(wù)或需求理解錯(cuò)誤。
1.12 運(yùn)行測試
1）App安裝完成后的試運(yùn)行，可正常打開軟件。
2）App打開測試，是否有加載狀態(tài)進(jìn)度提示。
3）App打開速度測試，速度是否可觀。
4）App頁面間的切換是否流暢，邏輯是否正確
5）注冊
--同表單編輯頁面
--用戶名密碼長度
--注冊后的提示頁面
--前臺(tái)注冊頁面和后臺(tái)的管理頁面數(shù)據(jù)是否一致
--注冊后，在后臺(tái)管理中頁面提示
6）登錄
--使用合法的用戶登錄系統(tǒng)。
--系統(tǒng)是否允許多次非法的登陸，是否有次數(shù)限制。
--使用已經(jīng)登陸的賬號(hào)登陸系統(tǒng)是否正確處理。
--使用禁用的賬號(hào)登陸系統(tǒng)是否正確處理。
--用戶名、口令（密碼）錯(cuò)誤或漏填時(shí)能否登陸。
--刪除或修改后的用戶，原用戶登陸。
--不輸入用戶口令和用戶、重復(fù)點(diǎn)（確定或取消按鈕）是否允許登陸。
--登陸后，頁面中登陸信息。
--頁面中有注銷按鈕。
--登陸超時(shí)的處理。
7）注銷
--注銷原模塊，新的模塊系統(tǒng)能否正確處理。
--終止注銷能否返回原模塊，原用戶。
--注銷原用戶，新用戶系統(tǒng)能否正確處理。
--使用錯(cuò)誤的賬號(hào)、口令、無權(quán)限的被禁用的賬號(hào)進(jìn)行注銷
1.13 應(yīng)用的前后臺(tái)切換
APP切換到后臺(tái)，再回到app，檢查是否停留在上一次操作界面。
APP切換到后臺(tái)，再回到app，檢查功能及應(yīng)用狀態(tài)是否正常，IOS4和IOS5的版本的處理機(jī)制有的不一樣。
app切換到后臺(tái)，再回到前臺(tái)時(shí)，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對(duì)于從后臺(tái)切換回前臺(tái)數(shù)據(jù)有自動(dòng)更新的時(shí)候。
手機(jī)鎖屏解屏后進(jìn)入app注意是否會(huì)崩潰，功能狀態(tài)是否正常，尤其是對(duì)于從后臺(tái)切換回前臺(tái)數(shù)據(jù)有自動(dòng)更新的時(shí)候。
當(dāng)App使用過程中有電話進(jìn)來中斷后再切換到app，功能狀態(tài)是否正常
當(dāng)殺掉app進(jìn)程后，再開啟app，app能否正常啟動(dòng)。
出現(xiàn)必須處理的提示框后，切換到后臺(tái)，再切換回來，檢查提示框是否還存在，有時(shí)候會(huì)出現(xiàn)應(yīng)用自動(dòng)跳過提示框的缺陷。
對(duì)于有數(shù)據(jù)交換的頁面，每個(gè)頁面都必需要進(jìn)行前后臺(tái)切換、鎖屏的測試，這種頁面最容易出現(xiàn)崩潰。
1.14 免登錄
很多應(yīng)用提供免登錄功能，當(dāng)應(yīng)用開啟時(shí)自動(dòng)以上一次登錄的用戶身份來使用app.
app有免登錄功能時(shí)，需要考慮IOS版本差異。
考慮無網(wǎng)絡(luò)情況時(shí)能否正常進(jìn)入免登錄狀態(tài)。
切換用戶登錄后，要校驗(yàn)用戶登錄信息及數(shù)據(jù)內(nèi)容是否相應(yīng)更新，確保原用戶退出。
根據(jù)MTOP的現(xiàn)有規(guī)則，一個(gè)帳戶只允許登錄一臺(tái)機(jī)器。所以，需要檢查一個(gè)帳戶登錄多臺(tái)手機(jī)的情況。原手機(jī)里的用戶需要被踢出，給出友好提示。
app切換到后臺(tái)，再切回前臺(tái)的校驗(yàn)
切換到后臺(tái)，再切換回前臺(tái)的測試
密碼更換后，檢查有數(shù)據(jù)交換時(shí)是否進(jìn)行了有效身份的校驗(yàn)
支持自動(dòng)登錄的應(yīng)用在進(jìn)行數(shù)據(jù)交換時(shí)，檢查系統(tǒng)是否能自動(dòng)登錄成功并且數(shù)據(jù)操作無誤。
檢查用戶主動(dòng)退出登錄后，下次啟動(dòng)app，應(yīng)停留在登錄界面
1.15 數(shù)據(jù)更新
根據(jù)應(yīng)用的業(yè)務(wù)規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。
需要確定哪些地方需要提供手動(dòng)刷新，哪些地方需要自動(dòng)刷新，哪些地方需要手動(dòng)+自動(dòng)刷新。
確定哪些地方從后臺(tái)切換回前臺(tái)時(shí)需要進(jìn)行數(shù)據(jù)更新。
根據(jù)業(yè)務(wù)、速度及流量的合理分配，確定哪些內(nèi)容需要實(shí)時(shí)更新，哪些需要定時(shí)更新。
確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請求，還是有緩存到本地，這樣才能有針對(duì)性的進(jìn)行相應(yīng)測試。
檢查有數(shù)據(jù)交換的地方，均有相應(yīng)的異常處理。
1.16 離線瀏覽
很多應(yīng)用會(huì)支持離線瀏覽，即在本地客戶端會(huì)緩存一部分?jǐn)?shù)據(jù)供用戶查看。
在無網(wǎng)絡(luò)情況可以瀏覽本地?cái)?shù)據(jù)
退出app再開啟app時(shí)能正常瀏覽
切換到后臺(tái)再切回前臺(tái)可以正常瀏覽
鎖屏后再解屏回到應(yīng)用前臺(tái)可以正常瀏覽
在對(duì)服務(wù)端的數(shù)據(jù)有更新時(shí)會(huì)給予離線的相應(yīng)提示
1.17 App更新
當(dāng)客戶端有新版本時(shí)，有更新提示。
當(dāng)版本為非強(qiáng)制升級(jí)版時(shí)，用戶可以取消更新，老版本能正常使用。用戶在下次啟動(dòng)app時(shí)，仍能出現(xiàn)更新提示。
當(dāng)版本為強(qiáng)制升級(jí)版時(shí)，當(dāng)給出強(qiáng)制更新后用戶沒有做更新時(shí)，退出客戶端。下次啟動(dòng)app時(shí)，仍出現(xiàn)強(qiáng)制升級(jí)提示。
當(dāng)客戶端有新版本時(shí)，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。
當(dāng)客戶端有新版本時(shí)，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本。
當(dāng)客戶端有新版本時(shí)，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。
1.18 定位、照相機(jī)服務(wù)
App有用到相機(jī)，定位服務(wù)時(shí)，需要注意系統(tǒng)版本差異
有用到定位服務(wù)、照相機(jī)服務(wù)的地方，需要進(jìn)行前后臺(tái)的切換測試，檢查應(yīng)用是否正常。
當(dāng)定位服務(wù)沒有開啟時(shí)，使用定位服務(wù)，會(huì)友好性彈出是否允許設(shè)置定位提示。當(dāng)確定允許開啟定位時(shí)，能自動(dòng)跳轉(zhuǎn)到定位設(shè)置中開啟定位服務(wù)。
測試定位、照相機(jī)服務(wù)時(shí)，需要采用真機(jī)進(jìn)行測試。
1.19 時(shí)間測試
客戶端可以自行設(shè)置手機(jī)的時(shí)區(qū)、時(shí)間，因此需要校驗(yàn)該設(shè)置對(duì)app的影響。
--中國為東8區(qū)，所以當(dāng)手機(jī)設(shè)置的時(shí)間非東8區(qū)時(shí)，查看需要顯示時(shí)間的地方，時(shí)間是否展示正確，應(yīng)用功能是否正常。時(shí)間一般需要根據(jù)服務(wù)器時(shí)間再轉(zhuǎn)換成客戶端對(duì)應(yīng)的時(shí)區(qū)來展示，這樣的用戶體驗(yàn)比較好。比如發(fā)表一篇微博在服務(wù)端記錄的是10：00，此時(shí)，華盛頓時(shí)間為22：00，客戶端去瀏覽時(shí)，如果設(shè)置的是華盛頓時(shí)間,則顯示的發(fā)表時(shí)間即為22:00,當(dāng)時(shí)間設(shè)回東8區(qū)時(shí)間時(shí)，再查看則顯示為10：00。
1.20 PUSH測試
檢查push消息是否按照指定的業(yè)務(wù)規(guī)則發(fā)送
檢查不接受推送消息時(shí)，檢查用戶不會(huì)再接收到push.
如果用戶設(shè)置了免打擾的時(shí)間段，檢查在免打擾時(shí)間段內(nèi)，用戶接收不到PUSH。
在非免打擾時(shí)間段，用戶能正常收到push。
當(dāng)push消息是針對(duì)登錄用戶的時(shí)候，需要檢查收到的push與用戶身份是否相符，沒有錯(cuò)誤地將其它人的消息推送過來。一般情況下，只對(duì)手機(jī)上最后一個(gè)登錄用戶進(jìn)行消息推送。
測試push時(shí)，需要采用真機(jī)進(jìn)行測試。
1.21 性能測試
評(píng)估App的時(shí)間和空間特性 ：
1)極限測試：在各種邊界壓力情況下，如電池、存儲(chǔ)、網(wǎng)速等，驗(yàn)證App是否能正確響應(yīng)。
--內(nèi)存滿時(shí)安裝App
--運(yùn)行App時(shí)手機(jī)斷電
--運(yùn)行App時(shí)斷掉網(wǎng)絡(luò)
2)響應(yīng)能力測試：測試App中的各類操作是否滿足用戶響應(yīng)時(shí)間要求 。（安裝包放到云測上可以測試）
--App安裝、卸載的響應(yīng)時(shí)間
--App各類功能性操作的影響時(shí)間
3)壓力測試：反復(fù)/長期操作下、系統(tǒng)資源是否占用異常。（itestin）
--App反復(fù)進(jìn)行安裝卸載，查看系統(tǒng)資源是否正常
--其他功能反復(fù)進(jìn)行操作，查看系統(tǒng)資源是否正常
4)性能評(píng)估：評(píng)估典型用戶應(yīng)用場景下，系統(tǒng)資源的使用情況。（Jmeter）
1.22 交叉事件測試
針對(duì)智能終端應(yīng)用的服務(wù)等級(jí)劃分方式及實(shí)時(shí)特性所提出的測試方法。交叉測試又叫事件或沖突測試，是指一個(gè)功能正在執(zhí)行過程中，同時(shí)另外一個(gè)事件或操作對(duì)該過程進(jìn)行干擾的測試。如；App在前/后臺(tái)運(yùn)行狀態(tài)時(shí)與來電、文件下載、音樂收聽等關(guān)鍵運(yùn)用的交互情況測試等。交叉事件測試非常重要，能發(fā)現(xiàn)很多應(yīng)用中潛在的性能問題。
1） 多個(gè)App同時(shí)運(yùn)行是否影響正常功能
2） App運(yùn)行時(shí)前/后臺(tái)切換是否影響正常功能
3） App運(yùn)行時(shí)撥打/接聽電話
4） App運(yùn)行時(shí)發(fā)送/接收信息
5） App運(yùn)行時(shí)發(fā)送/收取郵件
6） App運(yùn)行時(shí)切換網(wǎng)絡(luò)（2G、3G、wifi）
7） App運(yùn)行時(shí)瀏覽網(wǎng)絡(luò)
8） App運(yùn)行時(shí)使用藍(lán)牙傳送/接收數(shù)據(jù)
9） App運(yùn)行時(shí)使用相機(jī)、計(jì)算器等手機(jī)自帶設(shè)備
1.23 兼容測試
主要測試內(nèi)部和外部兼容性
1）與本地及主流App是否兼容
2）基于開發(fā)環(huán)境和生產(chǎn)環(huán)境的不同，檢驗(yàn)在各種網(wǎng)絡(luò)連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數(shù)據(jù)和運(yùn)用是否正確
3）與各種設(shè)備是否兼容，若有跨系統(tǒng)支持則需要檢驗(yàn)是否在各系統(tǒng)下，各種行為是否一致
--不同操作系統(tǒng)的兼容性，是否適配
--不同手機(jī)屏幕分辨率的兼容性
--不同手機(jī)品牌的兼容性
1.24 回歸測試
1）Bug修復(fù)后且在新版本發(fā)布后需要進(jìn)行回歸測試。
2）Bug修復(fù)后的回歸測試在交付前、要進(jìn)行全量用例的回歸測試。
2.9升級(jí)、更新測試
新版版發(fā)布后，配合不同網(wǎng)絡(luò)環(huán)境的自勱更新提示及下載、安裝、更新、啟勱、運(yùn)行的驗(yàn)證測試。
1）測試升級(jí)后的功能是否與需求說明一樣
2）測試與升級(jí)模塊相關(guān)的模塊的功能是否與需求一致
3）升級(jí)安裝意外情況的測試（如死機(jī)、斷電、重啟）
4）升級(jí)界面的UI測試
5）不同操作系統(tǒng)間的升級(jí)測試
1.25 用戶體驗(yàn)測試
以主觀的普通消費(fèi)者的角度去感知產(chǎn)品或服務(wù)的舒適、有用、易用、友好親切程度。 通過不同個(gè)體、獨(dú)立空間和非經(jīng)驗(yàn)的統(tǒng)計(jì)復(fù)用方式去有效評(píng)價(jià)產(chǎn)品的體驗(yàn)特性提出修改意見提升產(chǎn)品的潛在客戶滿意度。
1）是否有空數(shù)據(jù)界面設(shè)計(jì)，引導(dǎo)用戶去執(zhí)行操作。
2）是否濫用用戶引導(dǎo)。
3）是否有不可點(diǎn)擊的效果，如：你的按鈕此時(shí)處于不可用狀態(tài)，那么一定要灰掉，或者拿掉按鈕，否則會(huì)給用戶誤導(dǎo)
4）菜單層次是否太深
5）交互流程分支是否太多
6）相關(guān)的選項(xiàng)是否離得很遠(yuǎn)
7）一次是否載入太多的數(shù)據(jù)
8）界面中按鈕可點(diǎn)擊范圍是否適中
9）標(biāo)簽頁是否跟內(nèi)容沒有從屬關(guān)系，當(dāng)切換標(biāo)簽的時(shí)候，內(nèi)容跟著切換
10）操作應(yīng)該有主次從屬關(guān)系
11）是否定義Back的邏輯。涉及軟硬件交互時(shí)，Back鍵應(yīng)具體定義
12）是否有橫屏模式的設(shè)計(jì)，應(yīng)用一般需要支持橫屏模式，即自適應(yīng)設(shè)計(jì)
2 App工具篇
2.1 介紹一下 Appium 工具
appium 是一個(gè)自動(dòng)化測試開源工具，支持 iOS 平臺(tái)和 Android 平臺(tái)上的原生應(yīng)用，web應(yīng)用和混合應(yīng)用。
“移動(dòng)原生應(yīng)用”是指那些用iOS或者 Android SDK 寫的應(yīng)用(Application簡稱app)。
“移動(dòng)web應(yīng)用”是指使用移動(dòng)瀏覽器訪問的應(yīng)用(appium支持iOS上的Safari和Android上的 Chrome)。
“混合應(yīng)用”是指原生代碼封裝網(wǎng)頁視圖——原生代碼和 web 內(nèi)容交互。比如，像 Phonegap，可以幫助開發(fā)者使用網(wǎng)頁技術(shù)開發(fā)應(yīng)用，然后用原生代碼封裝，這些就是混合應(yīng)用。
重要的是，appium是一個(gè)跨平臺(tái)的工具：它允許測試人員在不同的平臺(tái)(iOS，Android)使用同一套API來寫自動(dòng)化測試腳本，這樣大大增加了iOS和Android測試套件間代碼的復(fù)用性。
2.2 Appium 與 Selenium的關(guān)系
selenium是web端的自動(dòng)化，appium是app端的自動(dòng)化，appium繼承了webdriver(也就是selenium 2)
2.3? Appium 原理（加載流程，重點(diǎn)！）
1）調(diào)用Andorid adb完成基本的系統(tǒng)操作
2）向Andriod上部署bootstrap.jar包并啟動(dòng)
3）Forward Android 的端口到PC的機(jī)器上
4）PC上監(jiān)聽端口接受請求，使用webdriver協(xié)議
5）分析命令并轉(zhuǎn)通過forward的端口發(fā)給bootstrap.jar包
6）bootstrap接受請求并把命令發(fā)給UiAutomator或插樁體系
2.4 常見的 adb 命令
查看當(dāng)前連接的設(shè)備： adb devices
安裝軟件： adb install 路徑\xx.apk
卸載軟件： adb uninstall <包名>
從電腦上發(fā)送文件到設(shè)備： adb push <本地路徑> <遠(yuǎn)程路徑> adb push C:\test1.txt /sdcard/
從設(shè)備上下載文件到電腦： adb pull <遠(yuǎn)程路徑> <本地路徑> adb pull /sdcard/test1.txt D:
實(shí)時(shí)獲取日志： adb logcat -v time > D:\mylog.log
登錄終端設(shè)備 shell： adb shell
查找包名/活動(dòng)名： adb logcat | findstr START （腳本中， cmp= 后面的值就是 包名/activity 名稱）
啟動(dòng) APP 啟動(dòng) 測碼學(xué)院
adb shell am start -n packageName/activity
關(guān)閉 app 語法： adb shell am force-stop 包名
監(jiān)控 APP 啟動(dòng)時(shí)間 adb shell am start -W packageName/activity
Monkey 命令： adb shell monkey -v -p mypackage 50
2.5 什么是POM模式？
Page Object模式是Selenium中的一種測試設(shè)計(jì)模式，主要是將每一個(gè)頁面設(shè)計(jì)為一個(gè)Class，其中包含頁面中需要測試的元素（按鈕，輸入框，標(biāo)題 等），這樣在Selenium測試頁面中可以通過調(diào)用頁面類來獲取頁面元素，這樣巧妙的避免了當(dāng)頁面元素id或者位置變化時(shí)，需要改測試頁面代碼的情況。 當(dāng)頁面元素id變化時(shí)，只需要更改測試頁Class中頁面的屬性即可。Page Object模式是一種自動(dòng)化測試設(shè)計(jì)模式，將頁面定位和業(yè)務(wù)操作分開，分離測試對(duì)象（元素對(duì)象）和測試腳本（用例腳本），提高用例的可維護(hù)性。
POM 的優(yōu)勢
POM 提供了一種在 UI 層操作、業(yè)務(wù)流程與驗(yàn)證分離的模式，這使得測試代碼變得更加清晰和高可讀性
對(duì)象庫與用例分離，使得我們更好的復(fù)用對(duì)象，甚至能與不同的工具進(jìn)行深度結(jié)合應(yīng)用
可復(fù)用的頁面方法代碼會(huì)變得更加優(yōu)化
更加有效的命名方式使得我們更加清晰的知道方法所操作的 UI 元素。例如我們要回到首頁，方法名命名為: gotoHomePage(),通過方法名即可
2.6 抓包工具 Fiddler 道常見面試題
1.什么叫斷點(diǎn)？
Break Point：進(jìn)行接口測試時(shí)，為了測試后端功能而設(shè)置的。
2.斷點(diǎn)有哪些方式？
Before Requests：在請求時(shí)，沒有達(dá)到服務(wù)器之前設(shè)置斷點(diǎn)。? ? -- 全局?jǐn)帱c(diǎn)（中斷fiddler捕獲的所有請求）
After responses：服務(wù)器響應(yīng)之后，在fiddler將響應(yīng)傳回給客戶端之前。? -- 全局?jǐn)帱c(diǎn)（中斷fiddler捕獲的所有服務(wù)器返回?cái)?shù)據(jù)）
取消斷點(diǎn)：Disabled
3.為什么要設(shè)置斷點(diǎn)
進(jìn)行接口測試時(shí)，攔截和修改數(shù)據(jù)，測后端功能。比如：圖書網(wǎng)的某本小說的售價(jià)是100元，進(jìn)行網(wǎng)頁前端的功能測試時(shí)，只能輸入100元進(jìn)行購買！但是通過fiddler抓包工具可以攔截，修改數(shù)據(jù)。萬一有些別有用心的人跳過前端輸入框驗(yàn)證，然后修改數(shù)據(jù)，輸入-100元進(jìn)行購買。這樣的話，不僅買到了小說，賬戶余額還增加了100元。這就說明后端接口不對(duì)。
4.怎么設(shè)置斷點(diǎn)？（全局?jǐn)帱c(diǎn)和單個(gè)斷點(diǎn)）
Rules>>Automatic Breakpoints>>Before Requests(After Responses)? ? -- 全局?jǐn)帱c(diǎn)
在命令行輸入：（單個(gè)斷點(diǎn)）
bpu 接口的url地址? eg:bpu https://passport.cnblogs.com/user/signin 然后按回車? ? -- before request
bafter 接口的url地址? eg:bpafter https://passport.cnblogs.com/user/signin? 然后按回車? -- after response
5.攔截來自某個(gè)網(wǎng)址所有請求
1.在命令行輸入：bpu www.cnblogs.com
2.打開博客園任意網(wǎng)頁，發(fā)現(xiàn)都被攔截到了
3.打開博客園其他網(wǎng)站，其它網(wǎng)站可以正常請求
4.說明只攔截了來自部落論壇（www.cnblogs.com）的請求
5.清除輸入bpu回車即可
6.PC上如何設(shè)置代理獲取app上的數(shù)據(jù)？
參考：Fiddler實(shí)操對(duì)app進(jìn)行抓包
2.7 壓力工具 Monkey 道常見面試題
1 Monkey簡介
Monkey是一款app的自動(dòng)化測試工具，monkey是猴子的意思，所以從原理上說，它的自動(dòng)化測試就類似猴子一樣在軟件上亂敲按鍵，猴子什么都不懂，就愛搗亂。Monkey原理也是類似，通過向系統(tǒng)發(fā)送偽隨機(jī)的用戶事件流（如按鍵輸入、觸摸屏輸入、滑動(dòng)Trackball、手勢輸入等操作），來對(duì)設(shè)備上的程序進(jìn)行測試，檢測程序長時(shí)間的穩(wěn)定性，多久的時(shí)間會(huì)發(fā)生異常。
Monkey工具存在Android系統(tǒng)中，使用Java語言寫成，jar包在Android文件系統(tǒng)中的存放路徑是：/system/framework/monkey.jar；Monkey.jar程序是由一個(gè)名為“monkey”的Shell腳本來啟動(dòng)執(zhí)行，shell腳本在Android文件系統(tǒng)中的存放路徑是：/system/bin/monkey；
monkey需要通過adb來喚醒，即通過在cmd窗口中執(zhí)行: adb shell monkey ｛+命令參數(shù)｝來進(jìn)行Monkey測試;
2 Monkey 工作原理
在Monkey運(yùn)行的時(shí)候，它會(huì)生成事件，并把它們發(fā)給系統(tǒng)。同時(shí)，Monkey還對(duì)測試中的系統(tǒng)進(jìn)行監(jiān)測，對(duì)下列三種情況進(jìn)行特殊處理：
(1) 如果限定了Monkey運(yùn)行在一個(gè)或幾個(gè)特定的包上，那么它會(huì)監(jiān)測試圖轉(zhuǎn)到其它包的操作，并對(duì)其進(jìn)行阻止；
(2) 如果應(yīng)用程序崩潰或接收到任何失控異常，Monkey將停止并報(bào)錯(cuò)；
(3) 如果應(yīng)用程序產(chǎn)生了應(yīng)用程序不響應(yīng)ANR(application not responding)的錯(cuò)誤，Monkey將會(huì)停止并報(bào)錯(cuò)；
按照選定的不同級(jí)別的反饋信息，在Monkey中還可以看到其執(zhí)行過程報(bào)告和生成的事件。
3 Monkey命令詳解
Monkey需要通過adb來運(yùn)行，查看Monkey，monkey屬于android系統(tǒng)自帶的：
在system的bin目錄下可以看到Monkey
在通過monkey進(jìn)行測試前，需要知道待測試app的包名，
可以通過使用“uiautomatorviewer.bat”工具來獲取，也可以直接詢問提供app的開發(fā)小哥 或者直接使用adb命令獲取包名。
以下簡單介紹兩種通過adb命令獲取包名的方法。
方法一：首先要先運(yùn)行手機(jī)中需要獲取包名的app，然后分別輸入命令即可。
//獲取APP包名方法一
cmd狀態(tài)下：?adb?shell?dumpsys?activity?|?findstr?mFocusedActivity
或者進(jìn)入shell狀態(tài)下查看：
adb?shell
dumpsys?activity?|?findstr?mFocusedActivity
如圖所示：
方法二：查看設(shè)備中所有的包，在cmd 窗口中執(zhí)行以下命令：
//獲取APP包名方法二
adb?shell
cddata/data
ls
之后輸入一些Monkey命令，就可以開始測試。
//獲取Monkey命令自帶的幫助，在cmd中執(zhí)行命令：
adb?shell?monkey?–help
Monkey命令的參數(shù)大致分為三大類：
（1）基本配置參數(shù) –v -s --throttle -p;
（2）發(fā)送的事件類型,總共11種事件類型，包括點(diǎn)擊，觸摸，縮放等
（3）調(diào)試選項(xiàng)
3 App定位篇
3.1 App奔潰或閃退時(shí)如何定位原因？
當(dāng)iOS設(shè)備上的App應(yīng)用閃退時(shí)，操作系統(tǒng)會(huì)生成一個(gè)crash日志，保存在設(shè)備上。crash日志上有很多有用的信息，比如每個(gè)正在執(zhí)行線程的完整堆棧跟蹤信息和內(nèi)存映像，這樣就能夠通過解析這些信息進(jìn)而定位crash發(fā)生時(shí)的代碼邏輯，從而找到App閃退的原因。通常來說，crash產(chǎn)生來源于兩種問題：違反iOS系統(tǒng)規(guī)則導(dǎo)致的crash和App代碼邏輯BUG導(dǎo)致的crash，下面分別對(duì)他們進(jìn)行分析。
違反iOS系統(tǒng)規(guī)則產(chǎn)生crash的三種類型
(1) 內(nèi)存報(bào)警閃退
當(dāng)iOS檢測到內(nèi)存過低時(shí)，它的VM系統(tǒng)會(huì)發(fā)出低內(nèi)存警告通知，嘗試回收一些內(nèi)存；如果情況沒有得到足夠的改善，iOS會(huì)終止后臺(tái)應(yīng)用以回收更多內(nèi)存；最后，如果內(nèi)存還是不足，那么正在運(yùn)行的應(yīng)用可能會(huì)被終止掉。在Debug模式下，可以主動(dòng)將客戶端執(zhí)行的動(dòng)作邏輯寫入一個(gè)log文件中，這樣程序童鞋可以將內(nèi)存預(yù)警的邏輯寫入該log文件，當(dāng)發(fā)生如下截圖中的內(nèi)存報(bào)警時(shí)，就是提醒當(dāng)前客戶端性能內(nèi)存吃緊，可以通過Instruments工具中的Allocations和 Leaks模塊庫來發(fā)現(xiàn)內(nèi)存分配問題和內(nèi)存泄漏問題。
(2) 響應(yīng)超時(shí)
當(dāng)應(yīng)用程序?qū)σ恍┨囟ǖ氖录ū热鐔?dòng)、掛起、恢復(fù)、結(jié)束）響應(yīng)不及時(shí)，蘋果的Watchdog機(jī)制會(huì)把應(yīng)用程序干掉，并生成一份相應(yīng)的crash日志。這些事件與下列UIApplicationDelegate方法相對(duì)應(yīng)，當(dāng)遇到Watchdog日志時(shí)，可以檢查上圖中的幾個(gè)方法是否有比較重的阻塞UI的動(dòng)作。
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate:
(3) 用戶強(qiáng)制退出
一看到“用戶強(qiáng)制退出”，首先可能想到的雙擊Home鍵，然后關(guān)閉應(yīng)用程序。不過這種場景一般是不會(huì)產(chǎn)生crash日志的，因?yàn)殡p擊Home鍵后，所有的應(yīng)用程序都處于后臺(tái)狀態(tài)，而iOS隨時(shí)都有可能關(guān)閉后臺(tái)進(jìn)程，當(dāng)應(yīng)用阻塞界面并停止響應(yīng)時(shí)這種場景才會(huì)產(chǎn)生crash日志。這里指的“用戶強(qiáng)制退出”場景，是稍微比較復(fù)雜點(diǎn)的操作：先按住電源鍵，直到出現(xiàn)“滑動(dòng)關(guān)機(jī)”的界面時(shí)，再按住Home鍵，這時(shí)候當(dāng)前應(yīng)用程序會(huì)被終止掉，并且產(chǎn)生一份相應(yīng)事件的crash日志。
應(yīng)用邏輯的Bug
大多數(shù)閃退崩潰日志的產(chǎn)生都是因?yàn)閼?yīng)用中的Bug，這種Bug的錯(cuò)誤種類有很多，比如
SEGV：（Segmentation Violation，段違例），無效內(nèi)存地址，比如空指針，未初始化指針，棧溢出等；
SIGABRT：收到Abort信號(hào)，可能自身調(diào)用abort()或者收到外部發(fā)送過來的信號(hào)；
SIGBUS：總線錯(cuò)誤。與SIGSEGV不同的是，SIGSEGV訪問的是無效地址（比如虛存映射不到物理內(nèi)存），而SIGBUS訪問的是有效地址，但總線訪問異常（比如地址對(duì)齊問題）；
SIGILL：嘗試執(zhí)行非法的指令，可能不被識(shí)別或者沒有權(quán)限；
SIGFPE：Floating Point Error，數(shù)學(xué)計(jì)算相關(guān)問題（可能不限于浮點(diǎn)計(jì)算），比如除零操作；
SIGPIPE：管道另一端沒有進(jìn)程接手?jǐn)?shù)據(jù)；
常見的崩潰原因基本都是代碼邏輯問題或資源問題，比如數(shù)組越界，訪問野指針或者資源不存在，或資源大小寫錯(cuò)誤等。
crash的收集
在Mac 系統(tǒng)上，只需要打開xcode->windows->devices，選擇device logs進(jìn)行查看，如下圖，這些crash文件都可以導(dǎo)出來，然后再單獨(dú)對(duì)這個(gè)crash文件做處理分析。
3.2 Android 內(nèi)存不足的幾種情況？
對(duì)于 Android 設(shè)備來說，我們每打開一個(gè) APP，它的內(nèi)存都是彈性分配的，并且其分配值與最大值是受具體設(shè)備而定的。
此外，我們需要注意區(qū)分如下兩種 OOM 場景：
1）、內(nèi)存真正不足：例如 APP 當(dāng)前進(jìn)程最大內(nèi)存上限為 512 MB，當(dāng)超過這個(gè)值就表明內(nèi)存真正不足了。
2）、可用內(nèi)存不足：手機(jī)系統(tǒng)內(nèi)存極度緊張，就算 APP 當(dāng)前進(jìn)程最大內(nèi)存上限為 512 MB，我們只分配了 200 MB，也會(huì)產(chǎn)生內(nèi)存溢出，因?yàn)橄到y(tǒng)的可用內(nèi)存不足了。
3.3 Android 的Generational Heap Memory的模型你了解嗎？
在Android的高級(jí)系統(tǒng)版本中，針對(duì)Heap空間有一個(gè)Generational Heap Memory的模型，其中將整個(gè)內(nèi)存分為三個(gè)區(qū)域：
Young Generation（年輕代）
Old Generation（年老代）
Permanent Generation（持久代）
模型示意圖如下所示：
1、Young Generation
由一個(gè)Eden區(qū)和兩個(gè)Survivor區(qū)組成，程序中生成的大部分新的對(duì)象都在Eden區(qū)中，當(dāng)Eden區(qū)滿時(shí)，還存活的對(duì)象將被復(fù)制到其中一個(gè)Survivor區(qū)，當(dāng)此Survivor區(qū)滿時(shí)，此區(qū)存活的對(duì)象又被復(fù)制到另一個(gè)Survivor區(qū)，當(dāng)這個(gè)Survivor區(qū)也滿時(shí)，會(huì)將其中存活的對(duì)象復(fù)制到年老代。
2、Old Generation
一般情況下，年老代中的對(duì)象生命周期都比較長。
3、Permanent Generation
用于存放靜態(tài)的類和方法，持久代對(duì)垃圾回收沒有顯著影響。（在 JDK 1.8 及之后的版本，在本地內(nèi)存中實(shí)現(xiàn)的元空間（Meta-space）已經(jīng)代替了永久代）
4、內(nèi)存對(duì)象的處理過程小結(jié)
1、對(duì)象創(chuàng)建后在Eden區(qū)。
2、執(zhí)行GC后，如果對(duì)象仍然存活，則復(fù)制到S0區(qū)。
3、當(dāng)S0區(qū)滿時(shí)，該區(qū)域存活對(duì)象將復(fù)制到S1區(qū)，然后S0清空，接下來S0和S1角色互換。
4、當(dāng)?shù)?步達(dá)到一定次數(shù)（系統(tǒng)版本不同會(huì)有差異）后，存活對(duì)象將被復(fù)制到Old Generation。
5、當(dāng)這個(gè)對(duì)象在Old Generation區(qū)域停留的時(shí)間達(dá)到一定程度時(shí)，它會(huì)被移動(dòng)到Old Generation，最后累積一定時(shí)間再移動(dòng)到Permanent Generation區(qū)域。
3.4 如何判斷 app 的 bug 是客戶端問題還是后臺(tái)問題
先抓包確定服務(wù)器接口返回的數(shù)據(jù)是否正確
返回報(bào)錯(cuò)若是服務(wù)器的報(bào)錯(cuò)，就是服務(wù)器問題
返回的數(shù)據(jù)與接口文檔不符那麼就是接口問題, 就是客戶端問題.
3.5 安卓中如何取出日志信息？
把安卓系統(tǒng)日志信息實(shí)時(shí)導(dǎo)入到本地：
adb logcat -v time > d:\mylog.log
運(yùn)行使用某個(gè) app
實(shí)時(shí)獲取該 app 的日志信息（cmd 里面的返回信息） ： adb shell monkey -p com.android.calendar -v 1000 > d:\mylog2.log
4 App環(huán)境篇
4.1 app 測試有哪幾種環(huán)境？
本地環(huán)境：app 安裝的手機(jī)環(huán)境和電腦搭建的自動(dòng)化測試環(huán)境（比如安卓 SDK 等
服務(wù)器環(huán)境：war 包部署的服務(wù)器，服務(wù)器可以通過瀏覽器訪問，訪問的是 web 程序的接口
4.2 Android SDK 的安裝步驟說一下
下載 jdk 和 安卓 Android sdk.
安裝 jdk 配置環(huán)境變量（java_home、 classpath、 path）
關(guān)注我，加我好友拉你進(jìn)面試群，一起討論面試干貨 / 套路，大家一起升職加薪
點(diǎn)擊鏈接：溫大大
讓我?guī)湍阋?guī)劃下學(xué)習(xí)線路 & 職業(yè)規(guī)劃線路，幫你升職加薪。
關(guān)注公眾號(hào)：「測試猿溫大大」
