第一篇：APP測試流程

APP測試基本流程 1.流程圖

盡快申請到正式環(huán)境下測試 接收版本 不符

App測試版本送測規(guī)范 用戶行為統(tǒng)計測試 后臺訂單統(tǒng)計測試 盡快申請到正式環(huán)境下測試 兼容性測試、性能壓力測試 功能測試：核對需求文檔 UI測試：核對rp/效果圖 符合 回歸測試 仍然為測試環(huán)境 進入正式環(huán)境 發(fā)送上線報告 Fail Pass

2.測試周期 測試周期可按項目的開發(fā)周期來確定測試時間，一般測試時間為兩三周（即15個工作日），根據(jù)項目情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管確認項目排期。3.測試資源

測試任務開始前，檢查各項測試資源。--產(chǎn)品功能需求文檔；--產(chǎn)品原型圖；--產(chǎn)品效果圖；

--行為統(tǒng)計分析定義文檔；

--測試設備（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）；--其他。

4.日報及產(chǎn)品上線報告

1）測試人員每天需對所測項目發(fā)送測試日報。2）測試日報所包含的內容為：--對當前測試版本質量進行分級；

--對較嚴重的問題進行例舉，提示開發(fā)人員優(yōu)先修改；--對版本的整體情況進行評估。

3）產(chǎn)品上線前，測試人員發(fā)送產(chǎn)品上線報告。4）上線報告所包含的內容為：---對當前版本質量進行分級；---附上測試報告（功能測試報告、兼容性測試報告、性能測試報告以及app可用性能標準結果）；

--總結上線版本的基本情況。若有遺留問題必須列出并記錄解決方案。

App測試

1.安全測試

a.軟件權限

1）扣費風險：包括發(fā)送短信、撥打電話、連接網(wǎng)絡等 2）隱私泄露風險：包括訪問手機信息、訪問聯(lián)系人信息等

3）對App的輸入有效性校驗、認證、授權、敏感數(shù)據(jù)存儲、數(shù)據(jù)加密等方面進行檢測

4）限制/允許使用手機功能接人互聯(lián)網(wǎng) 5）限制/允許使用手機發(fā)送接受信息功能 6）限制/允許應用程序來注冊自動啟動應用程序 7）限制或使用本地連接

8）限制/允許使用手機拍照或錄音 9）限制/允許使用手機讀取用戶數(shù)據(jù) 10)限制/允許使用手機寫人用戶數(shù)據(jù)

11)檢測App的用戶授權級別、數(shù)據(jù)泄漏、非法授權訪問等 b.安裝與卸載安全性

1）應用程序應能正確安裝到設備驅動程序上 2）能夠在安裝設備驅動程序上找到應用程序的相應圖標 3）是否包含數(shù)字簽名信息

4）JAD文件和JAR包中包含的所有托管屬性及其值必需是正確的 5）JAD文件顯示的資料內容與應用程序顯示的資料內容應一致 6）安裝路徑應能指定

7）沒有用戶的允許, 應用程序不能預先設定自動啟動 8）卸載是否安全, 其安裝進去的文件是否全部卸載 9）卸載用戶使用過程中產(chǎn)生的文件是否有提示 10）其修改的配置信息是否復原 11）卸載是否影響其他軟件的功能 12）卸載應該移除所有的文件 c.數(shù)據(jù)安全性

1）當將密碼或其他的敏感數(shù)據(jù)輸人到應用程序時, 其不會被儲存在設備中, 同時密碼也不會被解碼

2）輸人的密碼將不以明文形式進行顯示

3）密碼, 信用卡明細, 或其他的敏感數(shù)據(jù)將不被儲存在它們預輸人的位置上 4）不同的應用程序的個人身份證或密碼長度必需至少在4一8 個數(shù)字長度之間

5）當應用程序處理信用卡明細, 或其他的敏感數(shù)據(jù)時, 不以明文形式將數(shù)據(jù)寫到其它單獨的文件或者臨時文件中。以6）防止應用程序異常終止而又沒有側除它的臨時文件, 文件可能遭受人侵者的襲擊, 然后讀取這些數(shù)據(jù)信息。7）當將敏感數(shù)據(jù)輸人到應用程序時, 其不會被儲存在設備中 8）備份應該加密, 恢復數(shù)據(jù)應考慮恢復過程的異常訊中斷等, 數(shù)據(jù)恢復后再使用前應該經(jīng)過校驗

9）應用程序應考慮系統(tǒng)或者虛擬機器產(chǎn)生的用戶提示信息或安全替告 10）應用程序不能忽略系統(tǒng)或者虛擬機器產(chǎn)生的用戶提示信息或安全警告, 更不能在安全警告顯示前,，利用顯示誤導信息欺騙用戶，應用程序不應該模擬進行安全警告誤導用戶

11）在數(shù)據(jù)刪除之前，應用程序應當通知用戶或者應用程序提供一個“取消”命令的操作

12）“ 取消” 命令操作能夠按照設計要求實現(xiàn)其功能

13）應用程序應當能夠處理當不允許應用軟件連接到個人信息管理的情況 14）當進行讀或寫用戶信息操作時, 應用程序將會向用戶發(fā)送一個操作錯誤的提示信息

15）在沒有用戶明確許可的前提下不損壞側除個人信息管理應用程序中的任何內容Μ

16）應用程序讀和寫數(shù)據(jù)正確。17）應用程序應當有異常保護。

18）如果數(shù)據(jù)庫中重要的數(shù)據(jù)正要被重寫, 應及時告知用戶 19）能合理地處理出現(xiàn)的錯誤 20）意外情況下應提示用戶 d.通訊安全性 1）在運行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍牙、紅外等通訊或充電時, 是否能暫停程序，優(yōu)先處理通信, 并在處理完畢后能正?；謴蛙浖? 繼續(xù)其原來的功能

2）當創(chuàng)立連接時, 應用程序能夠處理因為網(wǎng)絡連接中斷, 進而告訴用戶連接中斷的情況

3）應能處理通訊延時或中斷

4）應用程序將保持工作到通訊超時, 進而發(fā)送給用戶一個錯誤信息指示有連接錯誤

5）應能處理網(wǎng)絡異常和及時將異常情況通報用戶 6）應用程序關閉或網(wǎng)絡連接不再使用時應及時關閉)斷開 7)HTTP、HTTPS覆蓋測試

--App和后臺服務一般都是通過HTTP來交互的，驗證HTTP環(huán)境下是否正常；--公共免費網(wǎng)絡環(huán)境中（如：麥當勞、星巴克等）都要輸入用戶名和密碼，通過SSL認證來訪問網(wǎng)絡，需要對使用HTTP Client的library異常作捕獲處理。e.人機接口安全性

1）返回菜單總保持可用 2）命令有優(yōu)先權順序

3）聲音的設置不影響應用程序的功能

4）應用程序必需利用目標設備適用的全屏尺寸來顯示上述內容

5）應用程序必需能夠處理不可預知的用戶操作, 例如錯誤的操作和同時按下多個鍵

2.安裝、卸載測試 驗證App是否能正確安裝、運行、卸載以及操作過程和操作前后對系統(tǒng)資源的使用情況 a.安裝

1）軟件在不同操作系統(tǒng)（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安裝是否正常。

2）軟件安裝后的是否能夠正常運行，安裝后的文件夾及文件是否寫到了指定的目錄里。

3）軟件安裝各個選項的組合是否符合概要設計說明 4)）軟件安裝向導的UI測試

5）軟件安裝過程是否可以取消，點擊取消后，寫入的文件是否如概要設計說明處理

6）軟件安裝過程中意外情況的處理是否符合需求（如死機，重啟，斷電）7）安裝空間不足時是否有相應提示 8）安裝后沒有生成多余的目錄結構和文件

9）對于需要通過網(wǎng)絡驗證之類的安裝，在斷網(wǎng)情況下嘗試一下 10）還需要對安裝手冊進行測試，依照安裝手冊是否能順利安裝 b.卸載

1）直接刪除安裝文件夾卸載是否有提示信息。2）測試系統(tǒng)直接卸載程序是否有提示信息。3）測試卸載后文件是否全部刪除所有的安裝文件夾。

4）卸載過程中出現(xiàn)的意外情況的測試（如死機、斷電、重啟）。5）卸載是否支持取消功能，單擊取消后軟件卸載的情況。6）系統(tǒng)直接卸載UI測試，是否有卸載狀態(tài)進度條提示。

3.UI測試

測試用戶界面(如菜單、對話框、窗口和其它可規(guī)控件)布局、風格是否滿足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操作是否友好等。UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覓功能。確保用戶界面符合公司或行業(yè)的標準。包括用戶友好性、人性化、易操作性測試。a.導航測試

1）按鈕、對話框、列表和窗口等；或在不同的連接頁面之間需要導航 2）是否易于導航，導航是否直觀 3）是否需要搜索引擎 4）導航幫助是否準確直觀

5）導航與頁面結構、菜單、連接頁面的風格是否一致 b.圖形測試

1）橫向比較。各控件操作方式統(tǒng)一

2）自適應界面設計，內容根據(jù)窗口大小自適應 3）頁面標簽風格是否統(tǒng)一 4）頁面是否美觀

5）頁面的圖片應有其實際意義而要求整體有序美觀

6）圖片質量要高且圖片尺寸在設計符合要求的情況下應盡量小 7）界面整體使用的顏色不宜過多 c.內容測試 1）輸入框說明文字的內容與系統(tǒng)功能是否一致 2）文字長度是否加以限制 3）文字內容是否表意不明 4）是否有錯別字 5）信息是否為中文顯示 6）是否有敏感性詞匯、關鍵詞

7）是否有敏感性圖片，如：涉及版權、專利、隱私等圖片

4.功能測試

根據(jù)軟件說明或用戶需求驗證App的各個功能實現(xiàn)，采用如下方法實現(xiàn)并評估功能測試過程：

1)采用時間、地點、對象、行為和背景五元素或業(yè)務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，并明確測試標準，若用戶需求中無明確標準遵循，則需要參考行業(yè)或相關國際標準或準則。

2)根據(jù)被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負面、異?；蚍欠ā鼍盎貪L、關聯(lián)測試等測試類型對其進行覆蓋。

3)在測試實現(xiàn)的各個階段跟蹤測試實現(xiàn)與需求輸入的覆蓋情況，及時修正業(yè)務或需求理解錯誤。a.運行

1）App安裝完成后的試運行，可正常打開軟件。2）App打開測試，是否有加載狀態(tài)進度提示。3）App打開速度測試，速度是否可觀。4）App頁面間的切換是否流暢，邏輯是否正確 5）注冊

--同表單編輯頁面--用戶名密碼長度--注冊后的提示頁面

--前臺注冊頁面和后臺的管理頁面數(shù)據(jù)是否一致--注冊后，在后臺管理中頁面提示 6）登錄

--使用合法的用戶登錄系統(tǒng)。

--系統(tǒng)是否允許多次非法的登陸，是否有次數(shù)限制。--使用已經(jīng)登陸的賬號登陸系統(tǒng)是否正確處理。--使用禁用的賬號登陸系統(tǒng)是否正確處理。--用戶名、口令（密碼）錯誤或漏填時能否登陸。--刪除或修改后的用戶，原用戶登陸。

--不輸入用戶口令和用戶、重復點（確定或取消按鈕）是否允許登陸。--登陸后，頁面中登陸信息。--頁面中有注銷按鈕。--登陸超時的處理。7）注銷

--注銷原模塊，新的模塊系統(tǒng)能否正確處理。--終止注銷能否返回原模塊，原用戶。--注銷原用戶，新用戶系統(tǒng)能否正確處理。

--使用錯誤的賬號、口令、無權限的被禁用的賬號進行注銷 b.應用的前后臺切換

1)APP切換到后臺，再回到app，檢查是否停留在上一次操作界面。2)APP切換到后臺，再回到app，檢查功能及應用狀態(tài)是否正常，IOS4和IOS5的版本的處理機制有的不一樣。

3)app切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。

4)手機鎖屏解屏后進入app注意是否會崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。

5)當App使用過程中有電話進來中斷后再切換到app，功能狀態(tài)是否正常 6)當殺掉app進程后，再開啟app，app能否正常啟動。

7)出現(xiàn)必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現(xiàn)應用自動跳過提示框的缺陷。

8)對于有數(shù)據(jù)交換的頁面，每個頁面都必需要進行前后臺切換、鎖屏的測試，這種頁面最容易出現(xiàn)崩潰。c.免登錄

很多應用提供免登錄功能，當應用開啟時自動以上一次登錄的用戶身份來使用app.1)app有免登錄功能時，需要考慮IOS版本差異。2)考慮無網(wǎng)絡情況時能否正常進入免登錄狀態(tài)。3)切換用戶登錄后，要校驗用戶登錄信息及數(shù)據(jù)內容是否相應更新，確保原用戶退出。

4)根據(jù)MTOP的現(xiàn)有規(guī)則，一個帳戶只允許登錄一臺機器。所以，需要檢查一個帳戶登錄多臺手機的情況。原手機里的用戶需要被踢出，給出友好提示。5)app切換到后臺，再切回前臺的校驗 6)切換到后臺，再切換回前臺的測試

7)密碼更換后，檢查有數(shù)據(jù)交換時是否進行了有效身份的校驗

8)支持自動登錄的應用在進行數(shù)據(jù)交換時，檢查系統(tǒng)是否能自動登錄成功并且數(shù)據(jù)操作無誤。

9)檢查用戶主動退出登錄后，下次啟動app，應停留在登錄界面 d.數(shù)據(jù)更新

根據(jù)應用的業(yè)務規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。1)需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新。

2)確定哪些地方從后臺切換回前臺時需要進行數(shù)據(jù)更新。

3)根據(jù)業(yè)務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新。

4)確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地，這樣才能有針對性的進行相應測試。

5)檢查有數(shù)據(jù)交換的地方，均有相應的異常處理。e.離線瀏覽

很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數(shù)據(jù)供用戶查看。1)在無網(wǎng)絡情況可以瀏覽本地數(shù)據(jù) 2)退出app再開啟app時能正常瀏覽 3)切換到后臺再切回前臺可以正常瀏覽 4)鎖屏后再解屏回到應用前臺可以正常瀏覽 5)在對服務端的數(shù)據(jù)有更新時會給予離線的相應提示 f.App更新

1)當客戶端有新版本時，有更新提示。

2)當版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現(xiàn)更新提示。

3)當版本為強制升級版時，當給出強制更新后用戶沒有做更新時，退出客戶端。下次啟動app時，仍出現(xiàn)強制升級提示。

4)當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。

5)當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本。

6)當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬于缺陷。g.定位、照相機服務

1)App有用到相機，定位服務時，需要注意系統(tǒng)版本差異

2)有用到定位服務、照相機服務的地方，需要進行前后臺的切換測試，檢查應用是否正常。3)當定位服務沒有開啟時，使用定位服務，會友好性彈出是否允許設置定位提示。當確定允許開啟定位時，能自動跳轉到定位設置中開啟定位服務。4)測試定位、照相機服務時，需要采用真機進行測試。h.時間測試

客戶端可以自行設置手機的時區(qū)、時間，因此需要校驗該設置對app的影響。--中國為東8區(qū)，所以當手機設置的時間非東8區(qū)時，查看需要顯示時間的地方，時間是否展示正確，應用功能是否正常。時間一般需要根據(jù)服務器時間再轉換成客戶端對應的時區(qū)來展示，這樣的用戶體驗比較好。比如發(fā)表一篇微博在服務端記錄的是10：00，此時，華盛頓時間為22：00，客戶端去瀏覽時，如果設置的是華盛頓時間,則顯示的發(fā)表時間即為22:00,當時間設回東8區(qū)時間時，再查看則顯示為10：00。i.PUSH測試

1)檢查push消息是否按照指定的業(yè)務規(guī)則發(fā)送 2)檢查不接受推送消息時，檢查用戶不會再接收到push.3)如果用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到PUSH。

在非免打擾時間段，用戶能正常收到push。

4)當push消息是針對登錄用戶的時候，需要檢查收到的push與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。一般情況下，只對手機上最后一個登錄用戶進行消息推送。

5)測試push時，需要采用真機進行測試。

5.性能測試 評估App的時間和空間特性 ：

1)極限測試：在各種邊界壓力情況下，如電池、存儲、網(wǎng)速等，驗證App是否能正確響應。

--內存滿時安裝App--運行App時手機斷電--運行App時斷掉網(wǎng)絡

2)響應能力測試：測試App中的各類操作是否滿足用戶響應時間要求。--App安裝、卸載的響應時間--App各類功能性操作的影響時間

3)壓力測試：反復/長期操作下、系統(tǒng)資源是否占用異常。--App反復進行安裝卸載，查看系統(tǒng)資源是否正常--其他功能反復進行操作，查看系統(tǒng)資源是否正常

4)性能評估：評估典型用戶應用場景下，系統(tǒng)資源的使用情況。

5)Benchmark測試（基線測試）：與競爭產(chǎn)品的Benchmarking, 產(chǎn)品演變對比測試等。6.交叉事件測試

針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法。交叉測試又叫事件或沖突測試，是指一個功能正在執(zhí)行過程中，同時另外一個事件或操作對該過程進行干擾的測試。如；App在前/后臺運行狀態(tài)時與來電、文件下載、音樂收聽等關鍵運用的交互情況測試等。交叉事件測試非常重要，能發(fā)現(xiàn)很多應用中潛在的性能問題。

1）多個App同時運行是否影響正常功能 2）App運行時前/后臺切換是否影響正常功能 3）App運行時撥打/接聽電話 4）App運行時發(fā)送/接收信息 5）App運行時發(fā)送/收取郵件

6）App運行時切換網(wǎng)絡（2G、3G、wifi）7）App運行時瀏覽網(wǎng)絡

8）App運行時使用藍牙傳送/接收數(shù)據(jù)

9）App運行時使用相機、計算器等手機自帶設備 7.兼容測試

主要測試內部和外部兼容性 1）與本地及主流App是否兼容

2）基于開發(fā)環(huán)境和生產(chǎn)環(huán)境的不同，檢驗在各種網(wǎng)絡連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數(shù)據(jù)和運用是否正確

3）與各種設備是否兼容，若有跨系統(tǒng)支持則需要檢驗是否在各系統(tǒng)下，各種行為是否一致

--不同操作系統(tǒng)的兼容性，是否適配--不同手機屏幕分辨率的兼容性--不同手機品牌的兼容性 8.回歸測試

1）Bug修復后且在新版本發(fā)布后需要進行回歸測試。

2）Bug修復后的回歸測試在交付前、要進行全量用例的回歸測試。9.升級、更新測試

新版版發(fā)布后，配合不同網(wǎng)絡環(huán)境的自勱更新提示及下載、安裝、更新、啟勱、運行的驗證測試。

1）測試升級后的功能是否與需求說明一樣

2）測試與升級模塊相關的模塊的功能是否與需求一致 3）升級安裝意外情況的測試（如死機、斷電、重啟）4）升級界面的UI測試 5）不同操作系統(tǒng)間的升級測試 10.用戶體驗測試

以主觀的普通消費者的角度去感知產(chǎn)品或服務的舒適、有用、易用、友好親切程度。通過不同個體、獨立空間和非經(jīng)驗的統(tǒng)計復用方式去有效評價產(chǎn)品的體驗特性提出修改意見提升產(chǎn)品的潛在客戶滿意度。

1）是否有空數(shù)據(jù)界面設計，引導用戶去執(zhí)行操作。2）是否濫用用戶引導。

3）是否有不可點擊的效果，如：你的按鈕此時處于不可用狀態(tài)，那么一定要灰掉，或者拿掉按鈕，否則會給用戶誤導 4）菜單層次是否太深 5）交互流程分支是否太多 6）相關的選項是否離得很遠 7）一次是否載入太多的數(shù)據(jù) 8）界面中按鈕可點擊范圍是否適中

9）標簽頁是否跟內容沒有從屬關系，當切換標簽的時候，內容跟著切換 10）操作應該有主次從屬關系

11）是否定義Back的邏輯。涉及軟硬件交互時，Back鍵應具體定義 12）是否有橫屏模式的設計，應用一般需要支持橫屏模式，即自適應設計 11.硬件環(huán)境測試

a.手勢操作測試

1）手機開鎖屏對運行中的App的影響 2）切換網(wǎng)絡對運行中的App的影響 3）運行中的App前后臺切換的影響 4）多個運行中的App的切換 5）App運行時關機 6）App運行時重啟系統(tǒng) 7）App運行時充電

8）App運行時kill掉進程再打開 b.網(wǎng)絡環(huán)境

手機的網(wǎng)絡目前主要分為2G、3G、wifi。目前2G的網(wǎng)絡相對于比較慢，測試時尤其要注意此塊的測試。

1)無網(wǎng)絡時，執(zhí)行需要網(wǎng)絡的操作，給予友好提示，確保程序不出現(xiàn)crash。2)內網(wǎng)測試時，要注意選擇到外網(wǎng)操作時的異常情況處理。

3)在網(wǎng)絡信號不好時，檢查功能狀態(tài)是否正常，確保不因提交數(shù)據(jù)失敗而造成crash。

4)在網(wǎng)絡信號不好時，檢查數(shù)據(jù)是否會一直處于提交中的狀態(tài)，有無超時限制。如遇數(shù)據(jù)交換失敗時要給予提示。5)在網(wǎng)絡信號不好時，執(zhí)行操作后，在回調沒有完成的情況下，退出本頁面或者執(zhí)行其他操作的情況，有無異常情況。此問題也會經(jīng)常出現(xiàn)程序crash。c.服務器宕機或出現(xiàn)404、502等情況下的測試

后臺服務牽涉到DNS、空間服務商的情況下會影響其穩(wěn)定性，如：當出現(xiàn)域名解析故障時，你對后臺API的請求很可能就會出現(xiàn)404錯誤，拋出異常。這時需要對異常進行正確的處理，否則可能會導致程序不能正常工作。

12.接口測試

服務端一般會提供JSON格式的數(shù)據(jù)給客戶端，所以我們在服務端需要進行接口測試，確保服務端提供的接口并轉換的JSON內容正確，對分支、異常流有相應的返回值。此塊測試可以采用itest框架進行測試。最方便的是采用httpclient進行接口測試。進行服務端測試時，需要開發(fā)提供一份接口文檔。13.客戶端數(shù)據(jù)庫測試

1）一般的增、刪、改、查測試。

2）當表不存在時是否能自動創(chuàng)建，當數(shù)據(jù)庫表被刪除后能否再自建，數(shù)據(jù)是否還能自動從服務端中獲取回來并保存。

3）在業(yè)務需要從服務端取回數(shù)據(jù)保存到客戶端的時候，客戶端能否將數(shù)據(jù)保存到本地。

4）當業(yè)務需要從客戶端取數(shù)據(jù)時，檢查客戶端數(shù)據(jù)存在時，app數(shù)據(jù)是否能自動從客戶端數(shù)據(jù)中取出，還是仍然會從服務器端獲取？檢查客戶端數(shù)據(jù)不存在時，app數(shù)據(jù)能否自動從服務器端獲取到并保存到客戶端

5）當業(yè)務對數(shù)據(jù)進行了修改、刪除后，客戶端和服務端是否會有相應的更新。

第二篇：APP測試基本流程

APP測試基本流程

一、測試周期

app測試周期一般為兩周，根據(jù)項目情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管或產(chǎn)品經(jīng)理確認項目排期。

二、測試資源

測試任務開始前，檢查各項測試資源。

產(chǎn)品功能需求文檔

產(chǎn)品原型圖

產(chǎn)品效果圖

行為統(tǒng)計分析定義文檔

測試設備（ios3.1.3-ios5.0.1；Android1.6-Android4.0；Winphone7.1及以上；Symbian v3/v5/Nokia Belle等）

其他（例如有秒殺專題的項目，需要規(guī)劃秒殺時間表；有優(yōu)惠券使用的項目，需要申請?zhí)砑觾?yōu)惠券數(shù)據(jù)；支付寶/銀聯(lián)支付功能的項目，需要提前申請支付寶/銀聯(lián)賬戶等等）

二、測試要點 接收版本

本人覺得，這個過程可以直接略過。非專業(yè)測試著，不喜勿拍。

UI測試

A）確保手頭的原型圖與效果圖為當前最新版本。

B）確保產(chǎn)品UI符合產(chǎn)品經(jīng)理制定的原型圖與效果圖。

C）一切界面問題以效果圖為準，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理。

D）由于測試環(huán)境中的數(shù)據(jù)為模擬數(shù)據(jù)，測試時必須預先想到正式環(huán)境中可能出現(xiàn)的數(shù)據(jù)類型。

功能測試

A）確保手頭的功能需求文檔為當前最新版本。

B）確保所有的軟件功能都已實現(xiàn)且邏輯正常。

C）一切功能問題以需求文檔為準，若有用戶體驗方面的建議，必須先以郵件或口頭的形式詢問產(chǎn)品經(jīng)理。個人建議，用戶體驗方面的建議，優(yōu)先級放在修復bug之后。

D）若有些功能在技術上難以實現(xiàn)或者由于排期的原因無法在短時間內實現(xiàn)，必須得到產(chǎn)品經(jīng)理的確認，而不是單單只聽開發(fā)人員的技術解釋。此處確認最好以郵件形式存在。

E）所有的“外部原因”問題，都需要盡早地督促開發(fā)人員與客戶服務端人員聯(lián)系協(xié)調解決。并在之后的測試報告中予以體現(xiàn)。

F）所有的“設計如此”、“延期處理”問題，都需要和產(chǎn)品經(jīng)理確認后再進行驗證。并在之后的測試報告中予以體現(xiàn)。

G）測試下單時，注冊的測試賬號必須符合公司規(guī)范；收貨地址必須包含“測試”關鍵字，最好每次下單的名稱中含有日期，以便查詢；在正式環(huán)境中下單后必須取消該訂單等。

兼容測試/性能測試

A）確保軟件在所有兼容機型上都能正常使用（ios一般需要兼容7或者6，ios5可以不用，用戶使用率已經(jīng)低于5%以下）

B）對于低端性能兼容機上獨有的問題（例如ios5以下、Android1.6以下），若在技術上難以修改或者由于排期的原因無法在短時間內改進，必須在測試日報中注明，并得到技術平臺主管、產(chǎn)品經(jīng)理以及運營人員的確認，最好以郵件的形式得到確認）

C）性能測試方面必須滿足硬件壓力條件下的測試需要（例如多線程，用戶常用的app都要后臺運行的環(huán)境中測試。）

D）網(wǎng)絡響應用戶體驗方面的性能測試，需要保證在wifi、3g、2g網(wǎng)絡下的切換效果。比如wifi切換到2g，網(wǎng)絡響應的速度以及切換界面。

后臺訂單統(tǒng)計測試

A）核對“客戶端相關啟動查詢”項，此項數(shù)據(jù)就是經(jīng)常說的“激活量”，非常重要。測試時必須保證該項中的各數(shù)據(jù)均正確，且每次啟動軟件都會有相應的統(tǒng)計記錄。

B）核對“訂單查詢”項，測試時必須保證各數(shù)據(jù)均正確，且每次成功下單后都會有相應的統(tǒng)計記錄。

C）需要注意的是，在成功下單之后，后臺會做判斷將該訂單劃到測試訂單范圍，測試人員必須到“訂單查詢（測試）”模塊中核對訂單統(tǒng)計記錄信息。

用戶行為統(tǒng)計測試

A）確保手頭的行為統(tǒng)計分析定義文檔為最新版本，且與開發(fā)人員手中的文檔一致。

B）確保產(chǎn)品經(jīng)理在文檔中所定義的頁面在該產(chǎn)品中都是存在的。

C）盡可能真實地模擬用戶行為。D）核對統(tǒng)計日志，確保各項操作所對應的頁面ID以及操作ID都是正確的。

回歸測試

A）軟件最終上線前，需對產(chǎn)品進行回歸測試，測試內容包含之前所有的測試項目

B）回歸測試不再對細節(jié)進行測試，而是類似于對產(chǎn)品進行驗收，從客戶正常使用的角度對產(chǎn)品進行再一輪的整體測試。

C）只有在回歸測試通過之后，才對產(chǎn)品進行提交。

三、測試日報及產(chǎn)品上線報告

測試人員每天需對所測項目發(fā)送測試日報。

測試日報所包含的內容為：

A）對當前測試版本質量進行分級。

B）對較嚴重的問題進行例舉，提示開發(fā)人員優(yōu)先修改。

C）對版本的整體情況進行評估。

產(chǎn)品上線前，測試人員發(fā)送產(chǎn)品上線報告

現(xiàn)使用Testbird進行app自動化測試，省時省事省錢~~~

第三篇：app測試總結

App測試總結

一、App測試流程與web項目流程區(qū)別

1.對UI要求比較高，需要更加注重用戶體驗。對于一個小小的屏幕，如何讓用戶使用更加輕便、簡介、易用。

2.App是調用服務端接口展示數(shù)據(jù)。我們測試需要可以判斷問題是客戶端還是服務端接口返回數(shù)據(jù)錯誤。

3.App網(wǎng)絡測試。手機對網(wǎng)絡要求比較特別，網(wǎng)絡分2G，3G，wifi。有條件的話，可以分別測試下。

4.App需要版本升級功能。（非常重要）

5.Push推送測試（現(xiàn)在客戶基本都挺重視此功能）

二、服務端測試

服務端一般會提供JSON格式的數(shù)據(jù)給客戶端，所以我們在服務端需要進行接口測試，確保服務端提供的接口并轉換的JSON內容正確，對分支、異常流有相應的放置。我們可以用RESTClient進行接口測試（接口需要開發(fā)提供文檔，如何調用接口）安裝方法

1.安裝Firefox-附件組件-擴展

2.安裝成功后，點擊restclient圖標

根據(jù)開發(fā)提供文檔編輯url如圖，可以獲取json數(shù)據(jù)。通過這個我們可以測試接口返回數(shù)據(jù)是否正確

三、客戶端測試

1.網(wǎng)絡

1）無網(wǎng)絡，執(zhí)行需要網(wǎng)絡的操作，要有友好的提示，確保程序不出現(xiàn)crash。由于網(wǎng)絡出現(xiàn)crash都屬于bug。

2）內網(wǎng)測試時，要注意選擇到外網(wǎng)操作時的異常處理。

3）網(wǎng)絡信號不好時，檢查功能狀態(tài)是否正常，確保不因提交數(shù)據(jù)失敗而造成crash 4）網(wǎng)絡信號不好時，檢查數(shù)據(jù)是否會一直處于提交中的狀態(tài)，有無超時限制。如遇數(shù)據(jù)交換失敗時要給予提示

5）網(wǎng)絡信號不好時，執(zhí)行操作后，在回調沒有完成的情況下，退出本頁面或者執(zhí)行其他操作的情況，有無異常情況。此問題也會經(jīng)常出現(xiàn)程序crash

2.應用的前后臺切換

1）app切換到后臺，再回到app，檢查是否停留在上一次操作界面 2）app切換到后臺，再回到app，檢查功能及應用狀態(tài)是否正常

3）app切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換前臺數(shù)據(jù)有自動更新的時候。

4）手機鎖屏解屏后進入app注意是否會崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換前臺數(shù)據(jù)有自動更新的時候。

5）當app使用過程中有電話進來中斷后再切換到app，功能狀態(tài)是否正常 6）當殺掉app進程后，再開啟app，app能否正常啟動

7）出現(xiàn)必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在（譬如強制更新提示框）。有時候會出現(xiàn)應用自動跳過提示框的缺陷

8）對于有數(shù)據(jù)交換的頁面，每個頁面都必須要進行后臺切換、鎖屏測試。這種頁面最容易出現(xiàn)崩潰

3.數(shù)據(jù)更新

根據(jù)應用的業(yè)務規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。1）需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新

2）確定哪些地方從后臺切換回前臺時需要進行數(shù)據(jù)更新 4.5.6.7.8.3）根據(jù)業(yè)務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新

4）確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地，這樣才能有針對性的進行相應測試

5）檢查有數(shù)據(jù)交換的地方，均有相應的異常處理 Push測試

1）檢查push消息是否按照指定的業(yè)務規(guī)則發(fā)送

2）檢查不接受推送消息時，檢查用戶不會再接收到push 3）如果用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到push。再非免打擾時間段，用戶能正常收到push 4）需要注意的是，Ios如果是開發(fā)刷上來的app，是沒有推送的。需要自己網(wǎng)頁上下載或者拿到ipa安裝包自己使用手機助手安裝的才有推送 客戶端更新

客戶端更新一般是通過與服務器返回的當前版本號比較來判斷是否有更新。我們測試模擬更新時，首先要了解到服務端當前版本號(1.0)，然后讓客戶端打高版本的安裝包(2.0)，通知服務端改服務端版本號也改成2.0，把2.0安裝包放服務端后。即可開始升級測試。

1）當客戶端有新版本時，有更新提示

2）當版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現(xiàn)更新提示。如果是正式app已經(jīng)上線，那么升級時一定要考慮老版本是否能正常使用。

3）當版本為強制升級版時，當給出強制更新后用戶沒有做更新時，退出客戶端或者切換到后臺，下次啟動app時，仍出現(xiàn)強制升級提示

4）可以不刪除客戶端，覆蓋安裝。覆蓋安裝后，登錄信息都應該保存的。5）更新成功后，檢查是否是新版本。并且不能再提示升級 免登錄

很多應用提供免登錄功能，當應用開啟時自動以上一次登錄的用戶身份來使用app 1）考慮無網(wǎng)絡情況時能否正常進入免登錄狀態(tài)

2）切換用戶登錄后，要校驗用戶登錄信息及數(shù)據(jù)內容是否相應更新，確保原用戶退出

3）App切換到后臺再切換到前臺的校驗

4）密碼更換后，檢查有數(shù)據(jù)交換時是否進行了有效身份的校驗 5）檢查用戶主動退出登錄后，下次啟動app，應停留在登錄頁面 離線瀏覽

很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數(shù)據(jù)供用戶查看。1）在無網(wǎng)絡情況可以本地瀏覽本地數(shù)據(jù) 2）退出app再開啟app時能正常瀏覽 3）切換到后臺再切回前臺可以正常瀏覽 4）鎖屏后再解屏回到應用前臺可以正常瀏覽

5）在對服務端的數(shù)據(jù)有更新時會給予離線的相應提示 時間測試

客戶端可以自行設置手機的時區(qū)、時間因此需要校驗該設置對app的影響。

時間一般需要根據(jù)服務器時間再轉換成客戶端對應的時區(qū)來展示，這樣的用戶體驗比較好。譬如發(fā)表一篇微博在服務端記錄是10:00，此時，華盛頓時間為22:00，客戶端去瀏覽時，如果設置的是華盛頓時間，則顯示發(fā)表時間為22：00.四、零散通用內容測試

1.對模擬鍵盤的處理，例如鍵盤展開后，點擊其他位置是否正常首期，鍵盤使用完成后，能否正常收起

2.同事或者快速點擊不同的兩個按鍵，檢查程序是否正常，此問題經(jīng)常會crash，或者出現(xiàn)兩個功能界面并存的情況 3.較快速點擊同一按鈕多次，檢查程序是否正常，一般情況下需要對按鈕做置灰處理，在響應成功之前，只允許操作一次，否則可能會產(chǎn)生重復數(shù)據(jù)

4.文字特殊符號的展示顯示能正常輸入，不轉義顯示，如<>不會顯示成<> 5.考慮界面的完整性，在界面數(shù)據(jù)顯示寬度上，我們要考慮是自適應，還是自動換行，當自適應的時候，程序會在顯示不全的時候自動顯示…,此時，就要考慮哪些內容是可以…,哪些內容是必須要完整顯示的。

6.字體，顏色，視覺搭配的感觀測試也是很重要的一點，如果你感覺看上去很模糊，或者看著很累，說明設計上肯定是存在一定問題

五、問題排查

我們在客戶端測試時，經(jīng)常會碰到程序crash，有的是可以重現(xiàn)的。有的是莫名其妙的閃退

可以找開發(fā)debug，譬如ios。連上xcode運行，debug。Ios的話，你的應用的歷史crash都是可以在蘋果mac機器上看到crash的日志的。

第四篇：App測試方法總結

一、安全測試 1.軟件權限

1）扣費風險：包括短信、撥打電話、連接網(wǎng)絡等。

2）隱私泄露風險：包括訪問手機信息、訪問聯(lián)系人信息等。

3）對App的輸入有效性校驗、認證、授權、數(shù)據(jù)加密等方面進行檢測 4）限制/允許使用手機功能接入互聯(lián)網(wǎng) 5）限制/允許使用手機發(fā)送接收信息功能 6）限制或使用本地連接

7）限制/允許使用手機拍照或錄音 8）限制/允許使用手機讀取用戶數(shù)據(jù) 9）限制/允許使用手機寫入用戶數(shù)據(jù)

10）限制/允許應用程序來注冊自動啟動應用程序 2.安裝與卸載安全性

1）應用程序應能正確安裝到設備驅動程序上

2）能夠在安裝設備驅動程序上找到應用程序的相應圖標 3）安裝路徑應能指定

4）沒有用戶的允許，應用程序不能預先設定自動啟動 5）卸載是否安全，其安裝進去的文件是否全部卸載 6）卸載用戶使用過程中產(chǎn)生的文件是否有提示 7）其修改的配置信息是否復原 8）卸載是否影響其他軟件的功能 9）卸載應該移除所有的文件 3.數(shù)據(jù)安全性

1）當將密碼或其它的敏感數(shù)據(jù)輸入到應用程序時，其不會被存儲在設備中，同時密碼也不會被解碼。2）輸入的密碼將不以明文形式進行顯示。

3）密碼、信用卡明細或其他的敏感數(shù)據(jù)將不被存儲在它們預輸入的位置上。4）不同的應用程序的個人身份證或密碼長度必須至少在4-8個數(shù)字長度之間。

5）當應用程序處理信用卡明細或其它的敏感數(shù)據(jù)時，不以明文形式將數(shù)據(jù)寫到其他單獨的文件或者臨時文件中。以防止應用程序異常終止而又沒有刪除它的臨時文件，文件可能遭受入侵者的襲擊，然后讀取這些數(shù)據(jù)信息。

6）黨建敏感數(shù)據(jù)輸入到應用程序時，其不會被存儲在設備中。7）應用程序應考慮或者虛擬機器產(chǎn)生的用戶提示信息或安全警告

8）應用程序不能忽略系統(tǒng)或者虛擬機器產(chǎn)生的用戶提示信息或安全警告，更不能在安全警告顯示前，利用顯示誤導信息欺騙用戶，應用程序不應該模擬進行安全警告誤導用戶。

9）在數(shù)據(jù)刪除之前，應用程序應當通知用戶或者應用程序提供一個“取消”命令的操作。10）應用程序應當能夠處理當不允許應用軟件連接到個人信息管理的情況。

11）當進行讀或寫用戶信息操作時，應用程序將會向用戶發(fā)送一個操作錯誤的提示信息。12）在沒有用戶明確許可的前提下不損壞刪除個人信息管理應用程序中的任何內容。13）如果數(shù)據(jù)庫中重要的數(shù)據(jù)正要被重寫，應及時告知用戶。14）能合理的處理出現(xiàn)的錯誤。15）意外情況下應提示用戶。4.通訊安全性

1）在運行軟件過程中，如果有來電、SMS、藍牙等通訊或充電時，是否能暫停程序，優(yōu)先處理通信，并在處理完畢后能正?；謴蛙浖^續(xù)其原來的功能。2）當創(chuàng)立連接時，應用程序能夠處理因為網(wǎng)絡連接中斷，進而告訴用戶連接中斷的情況。3）應能處理通訊延時或中斷。

4）應用程序將保持工作到通訊超時，進而給用戶一個錯誤信息指示有鏈接錯誤。5）應能處理網(wǎng)絡異常和及時將異常情況通報用戶。6）應用程序關閉網(wǎng)絡連接不再使用時應及時關閉，斷開。5.人機接口安全測試

1）返回菜單應總保持可用。2）命令有優(yōu)先權順序。

3）聲音的設置不影響使用程序的功能。4）聲音的設置不影響應用程序的功能

5）應用程序必須能夠處理不可預知的用戶操作，例如錯誤的操作和同時按下多個鍵。

二、安裝、卸載測試

驗證App是否能正確安裝、運行、卸載、以及操作過程和操作前后對系統(tǒng)資源的使用情況 1.安裝

1）軟件安裝后是否能夠正常運行，安裝后的文件夾以及文件是否寫到了指定的目錄里。2）軟件安裝各個選項的組合是否符合概要設計說明。3）軟件安裝向導的UI測試

4）安裝后沒有生成多余的目錄結構和文件。2.卸載

1）測試系統(tǒng)直接卸載程序是否有提示信息。

2）測試卸載后文件是否全部刪除所有的安裝文件夾。3）卸載是否支持取消功能，單擊取消后軟件卸載的情況。4）系統(tǒng)直接卸載UI測試，是否有卸載狀態(tài)進度條提示。

三、UI測試

1）測試用戶界面（如菜單、對話框、窗口和其他控件）布局、風格是否滿足要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操作是否友好等。

2）UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能。確保用戶界面符合公司或行業(yè)的標準。包括用戶友好性、人性化、易操作性測試。1.導航測試

1）按鈕、對話框、列表和窗口等；或在不同的連接頁面之間需要導航。2）是否易于導航，導航是否直觀。3）是否需要搜索引擎。4）導航幫助是否準確直觀。

5）導航與頁面結構、菜單、連接頁面的風格是否一致。2.圖形測試

1）橫向比較，各控件操作方式統(tǒng)一。

2）自適應界面設計，內容根據(jù)窗口大小自適應。3）頁面標簽風格是否統(tǒng)一。4）頁面是否美觀。

5）頁面的圖片應有其實際意義而要求整體有序美觀。3.內容測試

1）輸入框說明文字的內容與系統(tǒng)功能是否一致。2）文字長度是否加以限制。3）文字內容是否表意不明。4）是否有錯別字。5）信息是否為中文顯示。

四、功能測試

根據(jù)軟件說明或用戶需求驗證App的各個功能實現(xiàn)，采用如下方法實現(xiàn)并評估功能測試過程： 1）采用時間、地點、對象、行為和背景五元素或業(yè)務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，并明確測試標準。2）根據(jù)被測功能點的特性列出相應類型的測試用例對其進行覆蓋，如：設計輸入的地方需要考慮等價、邊界、負面、異常、非法、場景回滾、關聯(lián)測試等測試類型對其進行覆蓋。

3）在測試實現(xiàn)的各個階段跟蹤測試實現(xiàn)與需求輸入的覆蓋情況，及時修正業(yè)務或需求理解錯誤。1.運行

1）App安裝完成后的試運行，可正常打開軟件。2）App打開測試，是否有加載狀態(tài)進度提示。3）App頁面間的切換是否流暢，邏輯是否正確。4）注冊

? ? ? ? ? 同表單編輯頁面 用戶名密碼長度 注冊后的提示頁面

前臺注冊頁面和后臺的管理頁面數(shù)據(jù)是否一致 注冊后，在后臺管理中頁面提示

5）登錄

? ? 使用合法的用戶登錄系統(tǒng)

系統(tǒng)是否允許多次非法的登錄，是否有次數(shù)限制 ? ? ? ? ? ? ? 使用已經(jīng)登錄的賬號登錄系統(tǒng)是否正確處理 用戶名、口令（密碼）錯誤或漏填時能否登陸 刪除或修改后的用戶，原用戶名登陸

不輸入用戶口令和重復點“確定/取消”按鈕，是否允許登錄 登陸后，頁面中登錄信息 頁面中有注銷按鈕 登錄超時的處理

2.應用的前后臺切換

1）App切換到后臺，再回到App，檢查是否停留在上一次操作界面。2）App切換到后臺，再回到App，檢查功能及應用狀態(tài)是否正常。

3）App切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。

4）手機鎖屏解鎖后進入App注意是否會崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候。

5）當App使用過程中有電話進來中斷后再切換到App，功能狀態(tài)是否正常。6）當殺掉App進城后，再開啟App，App能否正常啟動。

7）出現(xiàn)必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現(xiàn)應用自動跳過提示框的缺陷。

8）對于有數(shù)據(jù)交換的頁面，每個頁面都必須要進行前后臺切換、鎖屏的測試，這種頁面最容易出現(xiàn)崩潰。3.免登陸

很多應用提供免登陸功能，當應用開啟時自動以上一次登錄的用戶身份來使用App。1）考慮無網(wǎng)絡情況時能否正常進入免登錄狀態(tài)。

2）切換用戶登陸后，要校驗用戶登錄信息以及數(shù)據(jù)內容是否相應更新，確保原用戶退出。

3）根據(jù)Mtop的現(xiàn)有規(guī)則，一個賬戶只允許登陸一臺機器。所以，需要檢查一個賬戶登錄多臺手機的情況。原手機里的用戶需要被退出，給出友好提示。4）App切換到后臺，在切換回前臺的校驗。5）切換到后臺，再切換回到前臺的測試。

6）密碼更換后，檢查有數(shù)據(jù)交換時是否進行了有效身份的校驗。

7）支持自動登錄的應用在進行數(shù)據(jù)校驗時，檢查系統(tǒng)是否能自動登錄成功并且數(shù)據(jù)操作無誤。8）檢查用戶主動退出登錄后，下次啟動App，應停留在登錄界面。4.離線瀏覽

很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數(shù)據(jù)供用戶查看。1）在無線網(wǎng)絡情況可以瀏覽本地數(shù)據(jù)。2）退出App再開啟App時能正常瀏覽。3）切換到后臺再回到前臺可以正常瀏覽。4）鎖屏后再解鎖回到應用前臺可以正常瀏覽。

5）在對服務器段的數(shù)據(jù)有更新時回給予離線的相應提示。5.App更新

1）當客戶端有新版本時，有更新提示。

2）當版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動App時，仍出現(xiàn)更新提示。

3）當版本為強制升級版時，但給出強制更新后用戶沒有做更新時，退出客戶端。下次啟動App時，仍出現(xiàn)強制升級提示。4）當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。

5）當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本。6）當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬于缺陷。6.定位、照相機服務

1）App有用到相機，定位服務時，需要注意系統(tǒng)版本差異。

2）有用到照相機服務的地方，需要進行前后臺的切換測試，檢查應用是否正常。3）測試照相機服務時，需要采用真機進行測試。7.PUSH測試

1）檢查Push消息是否按照指定的業(yè)務規(guī)則發(fā)送。

2）檢查不接收推送消息時，用戶不會在接收到Push消息。

3）如果用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到Push。在非免打擾時間段內，用戶能正常收到Push。

4）當Push消息是針對登錄用戶的時候，需要檢查收到的Push與用戶身份是否相符，沒有錯誤的將其他人的消息推送過來。一般情況下，只對手機上最后一個登錄用戶進行消息推送。5）測試Push時，需要采用真機進行測試。

五、性能測試

1）響應能力測試：測試App中的各類操作是否滿足用戶響應時間要求。

? ? App安裝、卸載的響應時間 App各類功能性操作的響應時間

2）壓力測試，反復/長期操作下，系統(tǒng)資源是否占用異常。

? App反復進行安裝卸載，檢查系統(tǒng)資源是否正常 ? 其他功能反復進行操作，檢查系統(tǒng)資源是否正常

六、交叉事件測試

針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法。交叉測試又叫事件或沖突測試，是指一個功能正在執(zhí)行過程中，同時另外一個事件或操作對該過程進行干擾的測試。如：App在前/后臺運行狀態(tài)時與來電、文件下載、音樂收聽等關鍵運用的交互情況測試等。交叉事件測試非常重要，能發(fā)現(xiàn)很多應用中潛在的性能問題。1）多個App同時運行是否影響正常功能。2）App運行時前/后臺切換是否影響正常功能。3）App運行時撥打/接聽電話。4）App運行時發(fā)送/接收信息。5）App運行時發(fā)送/收取郵件。6）App運行時瀏覽網(wǎng)絡。

7）App運行時使用藍牙傳送/接收數(shù)據(jù)。

8）App運行時使用相機、計算器等手機自帶設備。

七、兼容測試

主要測試內部和外部兼容性 1）與本地及主流App是否兼容

2）與各種設備是否兼容，若有跨系統(tǒng)支持則需要檢驗是否在個系統(tǒng)下，各種行為是否一致。

? ? 不同手機屏幕分標率的兼容性 不同手機品牌的兼容性

八、回歸測試

1）Bug修復后且在新版本發(fā)布后需要進行回歸測試。2）Bug修復后的回歸測試在交付前、要進行大量用例的回歸測試。

九、用戶體驗測試

以主觀的普通消費者的角度去感知產(chǎn)品或服務的舒適、有用、易用、友好親切程度。通過不同個體、獨立空間和非經(jīng)驗的統(tǒng)計復用方式去有效評價產(chǎn)品的體驗特性，提出修改意見提升產(chǎn)品的潛在客戶滿意度。

1）是否有空數(shù)據(jù)界面設計，引導用戶去執(zhí)行操作。2）是否濫用用戶引導。

3）是否有不可點擊的效果，如：你的按鈕此時處于不可用狀態(tài)，那么一定要灰掉，或者拿掉按鈕，否則會給用戶誤導。4）菜單層次是否太深。5）交互流程分支是否太多。6）相關的選項是否離的很遠。7）一次是否載入太多的數(shù)據(jù)。8）界面中按鈕可點擊范圍是否適中。

9）標簽頁是否跟內容沒有從屬關系，當切換標簽的時候，內容跟著切換。10）操作應該有主次從屬關系。

11）是否定義Back的邏輯。涉及軟硬件交互時，Back鍵應具體定義。12）是否有橫屏模式的設計，應用一般需要支持橫屏模式，即自適應設計。

十、手勢操作測試

1）手機開鎖屏對運行中的App的影響。2）運行中的App前后臺切換的影響。3）多個運行中的App的切換。4）App運行時關機。5）App運行時重啟系統(tǒng)。6）App運行時充電

7）App運行時Kill掉進程再打開

十一、客戶端數(shù)據(jù)庫測試 1）一般的增、刪、改、查測試。

2）當表不存在時是否能自動創(chuàng)建，當數(shù)據(jù)庫表被刪除后能否再自建，數(shù)據(jù)是否還能自動從服務器中獲取回來并保存。

3）在業(yè)務需要從服務器端取回數(shù)據(jù)保存到客戶端的時候，客戶端能否將數(shù)據(jù)保存到本地。

4）當業(yè)務需要從客戶端取數(shù)據(jù)時，檢查客戶端數(shù)據(jù)存在時，App數(shù)據(jù)是否能自動從客戶端數(shù)據(jù)中取出，還是仍然會從服務器端獲取？檢查客戶端數(shù)據(jù)不存在時，App數(shù)據(jù)能否自動從服務器端獲取到并保存到服務器端。

5）當業(yè)務對數(shù)據(jù)進行了修改、刪除后，客戶端和服務器端是否會有相應的更新。

第五篇：蘋果App提交流程

一、證書的導出

1.1、前期工作

首先你需要有一個蘋果的開發(fā)者帳號，一個Mac系統(tǒng)。

如果沒有帳號可以在打開http://developer.apple.com/申請加入蘋果的開發(fā)者計劃。支付99美元每年，怎么申請網(wǎng)上有詳細的介紹，在此不多做介紹。

如果你已經(jīng)有了一個IDP，打開http://developer.apple.com/并登錄到蘋果MemberCenter，見下：

登錄以后可以看到下面這個界面，列出了你開發(fā)需要的一些工具，支持，itunes app管理等內容。

選擇第二項:Ios provisioning Portal，進入，所有證書相關的都在這里進行。

1.2、申請AppId

在下圖的左邊選擇 App IDs，我們先創(chuàng)建一個AppId，對于要發(fā)布到Appstore上的程序，都有一個唯一的AppId，下面會列出你當前所有的AppId。

我們點擊右上角的New App ID：

其中有兩項需要你自己填：

第一個Description，用來描述你的AppId，這個隨便填，沒有什么限制； 第二項Bundle Identifier(App ID Suffix)，這是你appid的后綴，這個需要仔細。

因為這個內容和你的程序直接相關，后面很多地方要用到，最好是com.yourcompany.yourappname的格式，當然沒有公司名的個人開發(fā)者，第二項可以用你自己的英文名字或者拼音，如下圖：

appcan.cn在線ipa包編譯時需要填寫的iapp IDs就是你在此輸入的第二項內容。

填完后submit，如下圖，可以看見我們已經(jīng)生成的appid：ebook appid。想要支持推送服務和iCould等也可以在這兒配置：

1.3、申請發(fā)布證書

1.3.1、先創(chuàng)建一個證書請求文件 這兒需要一個Mac系統(tǒng)。以下內容以雪豹系統(tǒng)為例，其他版本差別不是很大。首先打開應用程序-實用工具-鑰匙串訪問（KEY CHAIN）,在證書助理中，選擇“從證書頒發(fā)機構求證書”，如下圖：

在下圖所示的界面，你的電子郵件地址：填你申請idp的電子郵件地址，常用名稱，默認就好，CA空，選擇存貯到磁盤，點擊“繼續(xù)”：

選擇保存的位置，比如選擇桌面。

下一步點擊完成，你就可以看到你的桌面多了一個CertificateSigningRequest.certSigningRequest的證書請求文件。

1.3.2、安裝WWDR證書

繼續(xù)登錄到你的MEMBER CENTER,選擇左邊的certificates項，可以看到它右邊有四個選項，我們選擇Distribution，點擊下面的click here to download now.下載完成后，雙擊安裝，安裝成功后，可以在你的鑰匙串里面的證書下面看到這個中級證書。1.3.3、請求一個發(fā)布證書

OK，現(xiàn)在來請求一個真正的發(fā)布證書，還是在這個頁面，點擊request certificate：

這個頁面告訴你怎么生成發(fā)布證書，點擊下面的“選取文件”，選擇你在第一步創(chuàng)建的證書請求文件，然后點擊“submit”：

OK?，F(xiàn)在你有一個證書可以下載了，如下圖（不能下載請刷新頁面）：

1.3.4、安裝和導出

點擊“download”下載你生成的證書，下載完成后雙擊安裝，如果有如下提示，選擇login，OK：

這時再查看你的鑰匙串，應該有下面這一行Iphone Distribution的證書，注意，這個證書有一個小三角可以點擊，展開后有一個對應的密鑰。如果你沒有這個鑰匙，那么請檢查上面那一步做錯了。

現(xiàn)在發(fā)布證書已經(jīng)安裝了，我們選擇這個證書，右擊，選擇，導出“xxxxxxx”，如下：

給你要導出的證書起個名字，選擇一個存的位置，注意，保存成P12的信息交換文件

輸入密碼，如果Mac系統(tǒng)有密碼，后面還會要求你輸入系統(tǒng)密碼。

現(xiàn)在你就有了發(fā)布程序需要的p12文件。

appcan.cn在線ipa包編譯時需要上傳的distribution.p12就是你導出的發(fā)布證書；certificate password就是導出證書時填寫的密碼。

1.4、生成provisioning文件

在下圖左邊選擇provisioning選項，同樣的右邊的子項中選擇distribution，來生成一個發(fā)布的準備文件：

選擇new profile，在下圖中，第一個method，選擇App Store；

Profile name，這個隨便填，下面的App ID,選擇我們開始的時候創(chuàng)建的appid，這個必須一致。確認后提交：

等待幾秒鐘，provisioning就可以下載了，點擊download，下載。我們得到了一個xxxxxx.mobileprovision

appcan.cn在線ipa包編譯時需要上傳的distribution.mobileprovision就是你生成的文件。

現(xiàn)在，我們的證書的準備工作就做完 了，我們有了一個appid，一個p12格式的證書文件，一個provisioning文件。

二、Appcan.cn在線ipa包編譯 根據(jù)流程一制作的證書及p12文件，開發(fā)者就能夠對應于進行混編，從而生成出可上傳Appstore的ipa包，其流程如下：

AppCan在線的打包方式（非IDE打包方式），用戶生成應用時需要選擇生成ios平臺，勾選后彈出下圖窗口：

需要填寫上傳Apple開發(fā)者在Apple獲得的發(fā)布應用相關資質信息（詳情請參考證書的導出），并卻確認提交。務必填寫正確否則會打包失敗的。上傳相關資質信息后，【注意】提交打出的文件包是用來上傳到蘋果App Store 用的 不能直接安裝到手機測試

Q：打包成功后我如何上傳到App Store？

A：下載.ipa文件到本地，更改文件后綴.ipa為.zip。（上傳請參看ipa包提交蘋果App Store）

Q：打包完成后我如何安裝到越獄手機上測試？

A：

1、下載.ipa文件到本地，更改文件后綴.ipa為.zip并解壓縮文件包，2、新建Payload文件夾，3、把解壓縮.zip包里面的文件夾拷到Payload文件夾里

4、壓縮Payload文件夾為.zip文件包，改.zip后綴為.ipa

5、安裝到手機

跳過后打出的安裝包可以直接安裝到越獄手機。

三、Ipa包提交蘋果App Store

通過AppCan在線與開發(fā)者證書混編后，生成的ipa包（后綴.ipa改為.zip）即可上傳至蘋果Appstore，以下是操作流程。

3.1、在itunes中創(chuàng)建程序

該部分內容繼續(xù)以雪豹系統(tǒng)為例

打開https://itunesconnect.apple.com/（membercenter中也可以找到）選擇“Manage Your Applications”：

點擊“Add New App”，填寫下面的表格。默認語言，appname，SKU Number，這是自己程序的標識，點擊后面的“？”有說明。Bundle id：這個可以選擇，必須和你申請證書時候的appid保持一致。否則會上傳失敗。

填完后，點擊“Continue”。

這個頁面設置程序的生效時間和價格，選擇后，點擊“Continue”。

下圖的頁面需要填一些程序的信息，注意“Review Notes(optional)”這個選項是對蘋果review程序的說明，如果你的程序需要登錄才可以使用，要在這里提供用戶名和密碼，如果你的程序的一些特色很 隱晦，可以在這里提供操作步驟，這是讓apple的review人員看的東西，不會在App Store里面顯示。

下圖的頁面是一些分級的說明，根據(jù)需要選擇：

下面是metadata，這個可能很重要，注意那個keywords，設置的越多你的程序被搜到的幾率越大，但是最好不超過100字，否則可能會被 蘋果認為是作弊。Large app icon 這需要一張1024x1024的icon。screenshots是屏幕截圖或者說明性的圖片。

填完后done，這樣就創(chuàng)建好了一個app，點擊“view detail”，然后選擇“Ready to Upload Binary”。這時發(fā)現(xiàn)你的app顯示一個黃色的wait for upload，表示你可以上傳你的二進制代碼了。如下圖：

3.2、上傳程序

上傳程序請在你的mac系統(tǒng)下找到application uploader工具，找不到的可以在下圖這兒下載。Xcode4.x將該工具集成到了xcode里面。

在Mac下安裝了該工具后，運行，如果是第一次，可能需要你用你自己的idp帳號登錄（以后會保存在鑰匙串中），登錄后會自動檢查你有沒有等待上傳狀態(tài)的app，選擇你創(chuàng)建好的app，如下圖：

點擊“Next”按鈕：

點擊“choose”按鈕，選擇你從AppCan在線編譯出來的ipa包，修改.ipa后綴為.zip，請不要打開修改包里面的內容（包括添加和刪除資源圖片等文件），否則會上傳失敗。

點擊“Send”按鈕，等待上傳，上傳完成后，打開itunesconnect，這時候你的程序狀態(tài)變?yōu)椤皍pload received”，程序進入蘋果第一步審核。第一步審核幾分鐘到幾小時。當通過第一步審核后，程序狀態(tài)變?yōu)椤皐ait for review”，此時程序進入等待人工審核的狀態(tài)，大概4天到2周的時間都是這個狀態(tài)，直到排隊輪到你的程序時，程序進入“in review”狀態(tài)，如果你的程序沒有內容上的問題，符合蘋果的審核標準，那么審核成功，你程序的狀態(tài)變?yōu)榫G色的“ Ready for Sale”，如果審核失敗，程序狀態(tài)變?yōu)榧t色的“ Rejected ”。

上傳過程中每一步的失敗蘋果都會發(fā)郵件給你，或者你能在Resolution Center看到詳細的失敗信息。當你的程序變?yōu)椤皉eady for sale”狀態(tài)時候，你就可以在appstore里面找到它了。至此，上傳結束。你就可以通過IOS設備在Appstore中找到你的應用了。