1 APP測試基本流程 2
1.1流程圖 2
1.2測試周期 3
1.3測試資源 3
1.4日報及產品上線報告 3
2 App測試點 3
2.1安全測試 3
2.1.1軟件權限 3
2.1.2安裝與卸載安全性 4
2.1.3數據安全性 4
2.1.4通訊安全性 5
2.1.5人機接口安全性 5
2.2安裝、卸載測試 5
2.2.1安裝 6
2.2.2卸載 6
2.3 UI測試 6
2.3.1導航測試 7
2.3.2圖形測試 7
2.3.3內容測試 7
2.4功能測試 7
2.4.1運行 8
2.4.2應用的前後臺切換 8
2.4.3免登錄 9
2.4.4數據更新 9
2.4.5離線瀏覽 10
2.4.6 App更新 10
2.4.7定位、照相機服務 10
2.4.8時間測試 11
2.4.9 PUSH測試 11
2.5性能測試 11
2.6交叉事件測試 12
2.7兼容測試 12
2.8迴歸測試 12
2.9升級、更新測試 12
2.10用戶體驗測試 13
2.11 硬件環境測試 13
2.11.1手勢操作測試 13
2.11.2網絡環境 13
2.11.3服務器宕機或出現404、502等情況下的測試 14
2.12接口測試 14
2.13客戶端數據庫測試 14
2.14服務端數據庫測試2
2.15系統升級測試
2.16 系統資源佔用釋放
1 APP測試基本流程
1.2測試周期
測試周期可按項目的開發週期來確定測試時間，一般測試時間爲兩三週（即15個工作日），根據項目情況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管確認項目排期。
1.3測試資源
測試任務開始前，檢查各項測試資源。
–產品功能需求文檔；
–產品原型圖；
–產品效果圖；
–行爲統計分析定義文檔；
–測試設備（ios6.1.3-ios8.1；Android3.0-Android5.0）
–其他。
1.4日報及產品上線報告
1）測試人員每天需對所測項目發送測試日報。
2）測試日報所包含的內容爲：
–對當前測試版本質量進行分級；
–對較嚴重的問題進行例舉，提示開發人員優先修改；
–對版本的整體情況進行評估。
3）產品上線前，測試人員發送產品上線報告。
4）上線報告所包含的內容爲：
—對當前版本質量進行分級；
—附上測試報告（功能測試報告、兼容性測試報告、性能測試報告以及app可用性能標準結果）；
–總結上線版本的基本情況。若有遺留問題必須列出並記錄解決方案。
2 App測試點
2.1安全測試
2.1.1軟件權限
1）扣費風險：包括髮送短信、撥打電話、連接網絡等
2）隱私泄露風險：包括訪問手機信息、訪問聯繫人信息等
3）對App的輸入有效性校驗、認證、授權、敏感數據存儲、數據加密等方面進行檢測
4）限制/允許使用手機功能接入互聯網
5）限制/允許使用手機發送接受信息功能
6）限制/允許應用程序來註冊自動啓動應用程序
7）限制或使用本地連接
8）限制/允許使用手機拍照或錄音
9）限制/允許使用手機讀取用戶數據
10) 限制/允許使用手機寫入用戶數據
11) 檢測App的用戶授權級別、數據泄漏、非法授權訪問等
個人總結：原則
1 權限申請最好控制在最小權限申請，需要什麼申請什麼，多餘的權限申請都是bug，有些只需要申請查看聯繫人權限就不要申請刪除和修改聯繫人權限，過多的權限申請用戶體驗很不好。
2.1.2安裝與卸載安全性
1）應用程序應能正確安裝到設備驅動程序上
2）能夠在安裝設備驅動程序上找到應用程序的相應圖標
3）是否包含數字簽名信息
4）JAD文件和JAR包中包含的所有託管屬性及其值必需是正確的
5）JAD文件顯示的資料內容與應用程序顯示的資料內容應一致
6）安裝路徑應能指定
7）沒有用戶的允許, 應用程序不能預先設定自動啓動
8）卸載是否安全, 其安裝進去的文件是否全部卸載
9）卸載用戶使用過程中產生的文件是否有提示
10）其修改的配置信息是否復原
11）卸載是否影響其他軟件的功能
12）卸載應該移除所有的文件
2.1.3數據安全性
1）當將密碼或其他的敏感數據輸人到應用程序時, 其不會被儲存在設備中, 同時密碼也不會被解碼
2）輸人的密碼將不以明文形式進行顯示
3）密碼, 信用卡明細, 或其他的敏感數據將不被儲存在它們預輸人的位置上
4）不同的應用程序的個人身份證或密碼長度必需至少在6-12 個數字長度之間
5）當應用程序處理信用卡明細, 或其他的敏感數據時, 不以明文形式將數據寫到其它單獨的文件或者臨時文件中。
6）防止應用程序異常終止而又沒有刪除它的臨時文件, 文件可能遭受入侵者的襲擊, 然後讀取這些數據信息。
7）當將敏感數據輸人到應用程序時, 其不會被儲存在設備中
8）備份應該加密, 恢復數據應考慮恢復過程的異常、通訊中斷等, 數據恢復後再使用前應該經過校驗
9）應用程序應考慮系統或者虛擬機器產生的用戶提示信息或安全警告
10）應用程序不能忽略系統或者虛擬機器產生的用戶提示信息或安全警告, 更不能在安全警告顯示前,，利用顯示誤導信息欺騙用戶，應用程序不應該模擬進行安全警告誤導用戶
11）在數據刪除之前，應用程序應當通知用戶或者應用程序提供一個“取消”命令的操作
12）“ 取消” 命令操作能夠按照設計要求實現其功能
13）應用程序應當能夠處理當不允許應用軟件連接到個人信息管理的情況
14）當進行讀或寫用戶信息操作時, 應用程序將會向用戶發送一個操作錯誤的提示信息
15）在沒有用戶明確許可的前提下不損壞側除個人信息管理應用程序中的任何內容Μ
16）應用程序讀和寫數據正確。
17）應用程序應當有異常保護。
18）如果數據庫中重要的數據正要被重寫, 應及時告知用戶
19）能合理地處理出現的錯誤
20）意外情況下應提示用戶
2.1.4通訊安全性
1）在運行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍牙、紅外等通訊或充電時, 是否能暫停程序，優先處理通信, 並在處理完畢後能正常恢復軟件, 繼續其原來的功能
2）當創立連接時, 應用程序能夠處理因爲網絡連接中斷, 進而告訴用戶連接中斷的情況
3）應能處理通訊延時或中斷
4）應用程序將保持工作到通訊超時, 進而發送給用戶一個錯誤信息指示有連接錯誤
5）應能處理網絡異常和及時將異常情況通報用戶
6）應用程序關閉或網絡連接不再使用時應及時關閉) 斷開
7) HTTP、HTTPS覆蓋測試
–App和後臺服務一般都是通過HTTP來交互的，驗證HTTP環境下是否正常；
–公共免費網絡環境中（如：麥當勞、星巴克等）都要輸入用戶名和密碼，通過SSL認證來訪問網絡，需要對使用HTTP Client的library異常作捕獲處理。
2.1.5人機接口安全性
1）返回菜單總保持可用
2）命令有優先權順序
3）聲音的設置不影響應用程序的功能
4）應用程序必需利用目標設備適用的全屏尺寸來顯示上述內容
5）應用程序必需能夠處理不可預知的用戶操作, 例如錯誤的操作和同時按下多個鍵
2.2安裝、卸載測試
驗證App是否能正確安裝、運行、卸載以及操作過程和操作前後對系統資源的使用情況
2.2.1安裝
1）軟件在不同操作系統（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安裝是否正常。
2）軟件安裝後的是否能夠正常運行，安裝後的文件夾及文件是否寫到了指定的目錄裏。
3）軟件安裝各個選項的組合是否符合概要設計說明
4)）軟件安裝嚮導的UI測試
5）軟件安裝過程是否可以取消，點擊取消後，寫入的文件是否如概要設計說明處理
6）軟件安裝過程中意外情況的處理是否符合需求（如死機，重啓，斷電）
7）安裝空間不足時是否有相應提示
8）安裝後沒有生成多餘的目錄結構和文件
9）對於需要通過網絡驗證之類的安裝，在斷網情況下嘗試一下
10）還需要對安裝手冊進行測試，依照安裝手冊是否能順利安裝
2.2.2卸載
1）直接刪除安裝文件夾卸載是否有提示信息。
2）測試系統直接卸載程序是否有提示信息。
3）測試卸載後文件是否全部刪除所有的安裝文件夾。
4）卸載過程中出現的意外情況的測試（如死機、斷電、重啓）。
5）卸載是否支持取消功能，單擊取消後軟件卸載的情況 。
6）系統直接卸載UI測試，是否有卸載狀態進度條提示 。
2.3 UI測試
測試用戶界面(如菜單、對話框、窗口和其它可規控件)佈局、風格是否滿足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操作是否友好等。
UI測試的目標是確保用戶界面會通過測試對象的功能來爲用戶提供相應的訪問或瀏覓功能。確保用戶界面符合公司或行業的標準。包括用戶友好性、人性化、易操作性測試。
個人總結：
界面佈局
內容顯示是否得體
圖形在不同的機器上面加載情況，尤其是不同屏幕大小的手機
彈窗提示信息是否正確，有些馬虎的開發經常拷貝過來別人代碼，並不修改內容
文字內容的正確性，有些人都不看需求，直接按自己的意思寫了文字內容
文字內容很多時頁面顯示，符號，數字都很多的時候頁面顯示。經常文字內容比較多時會導致頁面出現一些問題
頁面是否有多餘的監控，控件。對於複製代碼的人來其他頁面的控件也會被複制過來，其實沒有什麼用
公共控件，日期選擇空間，年份轉換的地方也有可能經常會出問題
2.3.1導航測試
1）按鈕、對話框、列表和窗口等；或在不同的連接頁面之間需要導航
2）是否易於導航，導航是否直觀
3）是否需要搜索引擎
4）導航幫助是否準確直觀
5）導航與頁面結構、菜單、連接頁面的風格是否一致
2.3.2圖形測試
1）橫向比較。各控件操作方式統一
2）自適應界面設計，內容根據窗口大小自適應
3）頁面標籤風格是否統一
4）頁面是否美觀
5）頁面的圖片應有其實際意義而要求整體有序美觀
6）圖片質量要高且圖片尺寸在設計符合要求的情況下應儘量小
7）界面整體使用的顏色不宜過多
2.3.3內容測試
1）輸入框說明文字的內容與系統功能是否一致
2）文字長度是否加以限制
3）文字內容是否表意不明
4）是否有錯別字
5）信息是否爲中文顯示
6）是否有敏感性詞彙、關鍵詞
7）是否有敏感性圖片，如：涉及版權、專利、隱私等圖片
2.4功能測試
根據軟件說明或用戶需求驗證App的各個功能實現，採用如下方法實現並評估功能測試過程：
1)採用時間、地點、對象、行爲和背景五元素或業務分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內在、外在及非功能直接相關的需求，構建測試點，並明確測試標準，若用戶需求中無明確標準遵循，則需要參考行業或相關國際標準或準則。
2)根據被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負面、異常或非法、場景回滾、關聯測試等測試類型對其進行覆蓋。
3)在測試實現的各個階段跟蹤測試實現與需求輸入的覆蓋情況，及時修正業務或需求理解錯誤。
2.4.1運行
1）App安裝完成後的試運行，可正常打開軟件。
2）App打開測試，是否有加載狀態進度提示。
3）App打開速度測試，速度是否可觀。
4）App頁面間的切換是否流暢，邏輯是否正確
5）註冊
–同表單編輯頁面–用戶名密碼長度–註冊後的提示頁面–前臺註冊頁面和後臺的管理頁面數據是否一致–註冊後，在後臺管理中頁面提示
6）登錄
–使用合法的用戶登錄系統。–系統是否允許多次非法的登陸，是否有次數限制。–使用已經登陸的賬號登陸系統是否正確處理。–使用禁用的賬號登陸系統是否正確處理。–用戶名、口令（密碼）錯誤或漏填時能否登陸。–刪除或修改後的用戶，原用戶登陸。–不輸入用戶口令和用戶、重複點（確定或取消按鈕）是否允許登陸。–登陸後，頁面中登陸信息。–頁面中有註銷按鈕。–登陸超時的處理。
7）註銷
–註銷原模塊，新的模塊系統能否正確處理。–終止註銷能否返回原模塊，原用戶。–註銷原用戶，新用戶系統能否正確處理。–使用錯誤的賬號、口令、無權限的被禁用的賬號進行註銷
2.4.2應用的前後臺切換
1) APP切換到後臺，再回到app，檢查是否停留在上一次操作界面。
2) APP切換到後臺，再回到app，檢查功能及應用狀態是否正常，IOS4和IOS5的版本的處理機制有的不一樣。
3) app切換到後臺，再回到前臺時，注意程序是否崩潰，功能狀態是否正常，尤其是對於從後臺切換回前臺數據有自動更新的時候。
4) 手機鎖屏解屏後進入app注意是否會崩潰，功能狀態是否正常，尤其是對於從後臺切換回前臺數據有自動更新的時候。
5) 當App使用過程中有電話進來中斷後再切換到app，功能狀態是否正常
6) 當殺掉app進程後，再開啓app，app能否正常啓動。
7) 出現必須處理的提示框後，切換到後臺，再切換回來，檢查提示框是否還存在，有時候會出現應用自動跳過提示框的缺陷。
8) 對於有數據交換的頁面，每個頁面都必需要進行前後臺切換、鎖屏的測試，這種頁面最容易出現崩潰。
2.4.3免登錄
很多應用提供免登錄功能，當應用開啓時自動以上一次登錄的用戶身份來使用app.
1) app有免登錄功能時，需要考慮IOS版本差異。
2) 考慮無網絡情況時能否正常進入免登錄狀態。
3) 切換用戶登錄後，要校驗用戶登錄信息及數據內容是否相應更新，確保原用戶退出。
4) 根據MTOP的現有規則，一個帳戶只允許登錄一臺機器。所以，需要檢查一個帳戶登錄多臺手機的情況。原手機裏的用戶需要被踢出，給出友好提示。
5) app切換到後臺，再切回前臺的校驗
6) 切換到後臺，再切換回前臺的測試
7) 密碼更換後，檢查有數據交換時是否進行了有效身份的校驗
8) 支持自動登錄的應用在進行數據交換時，檢查系統是否能自動登錄成功並且數據操作無誤。
9) 檢查用戶主動退出登錄後，下次啓動app，應停留在登錄界面
2.4.4數據更新
根據應用的業務規則，以及數據更新量的情況，來確定最優的數據更新方案。
個人總結：
數據更新是經常出問題的地方，涉及到本地緩存數據和服務器數據不一致的情況，不一致經常導致出現bug，模擬這種數據更新的中間過程經常使用防火牆，模擬網絡異常，導致服務端數據不能同步到本地。查看同步之前和同步之後的數據變化情況
列表刷新，先讀取本地緩存，獲取到服務器數據再使用直接刷新；
問題點：1 經常出現，網絡異常，本地緩存數據也未能正常顯示；2 網絡恢復時並不去更新數據；3 有些先顯示了本地緩存，多點擊幾次，本地緩存數據就不顯示了
分頁請求，一次性只加載部分數據，下拉刷新更多的數據。大數據量時測試，如果是一次性加載所有數據，則會非常的緩慢
控件顯示，有些控件顯示需要等服務器返回結果在顯示。
網絡異常時，點擊經常會導致程序crash掉。模擬：先網絡正常，讓控件顯示出來，在模擬場景，使得控件不應該顯示，再點擊控件。看程序的處理
網絡異常時，每個有數據交互的地方都要測試一下
有些地方沒有網絡超時機制，更有些人能網絡異常處理也不做
本地時間和服務器時間不一致的時候，需要重點測試
經常會出現，顯示和實際不一致。有些app只在建立連接的時候去獲取服務端的時間，其他情況並不去獲取服務端的時間。如果其他的操作需要用到最新的服務器時間則會出問題。。重新建立連接的時候才獲取服務端的時間。
有些需要刷新數據的地方，因爲有了本地緩存並不去刷新，需要增加去獲取服務端數據
自動刷新和手動刷新
1 創建了新的內容後應該觸發自動刷新
2 一些不是很重要的數據可以手動刷新，數據量很大的時候，手動刷新。網絡異常刷新失敗後，再次刷新需要手動刷新；IOS和安卓的有點區別
清除本地緩存後，是否從服務端重新加載數據
賬號切換，切換到別的賬號，不應該能看到別人的本地數據，這個也經常出問題
2) 確定哪些地方從後臺切換回前臺時需要進行數據更新。
3) 根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要定時更新。
4) 確定數據展示部分的處理邏輯，是每次從服務端請求，還是有緩存到本地，這樣纔能有針對性的進行相應測試。
2.4.5離線瀏覽
很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數據供用戶查看。
1) 在無網絡情況可以瀏覽本地數據
2) 退出app再開啓app時能正常瀏覽
3) 切換到後臺再切回前臺可以正常瀏覽
4) 鎖屏後再解屏回到應用前臺可以正常瀏覽
5) 在對服務端的數據有更新時會給予離線的相應提示
2.4.6 App更新
1) 當客戶端有新版本時，有更新提示。
2) 當版本爲非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啓動app時，仍能出現更新提示。
3) 當版本爲強制升級版時，當給出強制更新後用戶沒有做更新時，退出客戶端。下次啓動app時，仍出現強制升級提示。
4) 當客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新。
5) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新後的客戶端功能是否是新版本。
6) 當客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬於缺陷。
2.4.7定位、照相機服務
1) App有用到相機，定位服務時，需要注意系統版本差異
2) 有用到定位服務、照相機服務的地方，需要進行前後臺的切換測試，檢查應用是否正常。
3) 當定位服務沒有開啓時，使用定位服務，會友好性彈出是否允許設置定位提示。當確定允許開啓定位時，能自動跳轉到定位設置中開啓定位服務。
4) 測試定位、照相機服務時，需要採用真機進行測試。
2.4.8時間測試
客戶端可以自行設置手機的時區、時間，因此需要校驗該設置對app的影響。
–中國爲東8區，所以當手機設置的時間非東8區時，查看需要顯示時間的地方，時間是否展示正確，應用功能是否正常。時間一般需要根據服務器時間再轉換成客戶端對應的時區來展示，這樣的用戶體驗比較好。比如發表一篇微博在服務端記錄的是10：00，此時，華盛頓時間爲22：00，客戶端去瀏覽時，如果設置的是華盛頓時間,則顯示的發表時間即爲22:00,當時間設回東8區時間時，再查看則顯示爲10：00。
2.4.9 PUSH測試
1) 檢查push消息是否按照指定的業務規則發送
2) 檢查不接受推送消息時，檢查用戶不會再接收到push.
3) 如果用戶設置了免打擾的時間段，檢查在免打擾時間段內，用戶接收不到PUSH。
在非免打擾時間段，用戶能正常收到push。
4) 當push消息是針對登錄用戶的時候，需要檢查收到的push與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。一般情況下，只對手機上最後一個登錄用戶進行消息推送。
5) 測試push時，需要採用真機進行測試。
2.5性能測試
評估App的時間和空間特性 ：
1)極限測試：在各種邊界壓力情況下，如電池、存儲、網速等，驗證App是否能正確響應。
–內存滿時安裝App
–運行App時手機斷電
–運行App時斷掉網絡
2)響應能力測試：測試App中的各類操作是否滿足用戶響應時間要求 。
–App安裝、卸載的響應時間
–App各類功能性操作的影響時間
3)壓力測試：反覆/長期操作下、系統資源是否佔用異常。
–App反覆進行安裝卸載，查看系統資源是否正常
–其他功能反覆進行操作，查看系統資源是否正常
4)性能評估：評估典型用戶應用場景下，系統資源的使用情況。
5)Benchmark測試（基線測試）：與競爭產品的Benchmarking, 產品演變對比測試等。
2.6交叉事件測試
針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法。交叉測試又叫事件或衝突測試，是指一個功能正在執行過程中，同時另外一個事件或操作對該過程進行干擾的測試。如；App在前/後臺運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互情況測試等。交叉事件測試非常重要，能發現很多應用中潛在的性能問題。
多個App同時運行是否影響正常功能
App運行時前/後臺切換是否影響正常功能
App運行時撥打/接聽電話
App運行時發送/接收信息
App運行時發送/收取郵件
App運行時切換網絡（2G、3G、wifi）
App運行時瀏覽網絡
App運行時使用藍牙傳送/接收數據
App運行時使用相機、計算器等手機自帶設備
2.7兼容測試
主要測試內部和外部兼容性
1）與本地及主流App是否兼容
2）基於開發環境和生產環境的不同，檢驗在各種網絡連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數據和運用是否正確
3）與各種設備是否兼容，若有跨系統支持則需要檢驗是否在各系統下，各種行爲是否一致
–不同操作系統的兼容性，是否適配
–不同手機屏幕分辨率的兼容性
–不同手機品牌的兼容性
2.8迴歸測試
1）Bug修復後且在新版本發佈後需要進行迴歸測試。
2）Bug修復後的迴歸測試在交付前、要進行全量用例的迴歸測試。
2.9升級、更新測試
新版版發佈後，配合不同網絡環境的自勱更新提示及下載、安裝、更新、啓勱、運行的驗證測試。
1）測試升級後的功能是否與需求說明一樣
2）測試與升級模塊相關的模塊的功能是否與需求一致
3）升級安裝意外情況的測試（如死機、斷電、重啓）
4）升級界面的UI測試
5）不同操作系統間的升級測試
2.10用戶體驗測試
以主觀的普通消費者的角度去感知產品或服務的舒適、有用、易用、友好親切程度。 通過不同個體、獨立空間和非經驗的統計複用方式去有效評價產品的體驗特性提出修改意見提升產品的潛在客戶滿意度。
1）是否有空數據界面設計，引導用戶去執行操作。
2）是否濫用用戶引導。
3）是否有不可點擊的效果，如：你的按鈕此時處於不可用狀態，那麼一定要灰掉，或者拿掉按鈕，否則會給用戶誤導
4）菜單層次是否太深
5）交互流程分支是否太多
6）相關的選項是否離得很遠
7）一次是否載入太多的數據
8）界面中按鈕可點擊範圍是否適中
9）標籤頁是否跟內容沒有從屬關係，當切換標籤的時候，內容跟着切換
10）操作應該有主次從屬關係
11）是否定義Back的邏輯。涉及軟硬件交互時，Back鍵應具體定義
12）是否有橫屏模式的設計，應用一般需要支持橫屏模式，即自適應設計
2.11 硬件環境測試
2.11.1手勢操作測試
1）手機開鎖屏對運行中的App的影響
2）切換網絡對運行中的App的影響
3）運行中的App前後臺切換的影響
4）多個運行中的App的切換
5）App運行時關機
6）App運行時重啓系統
7）App運行時充電
8）App運行時kill掉進程再打開
2.11.2網絡環境
手機的網絡目前主要分爲2G、3G、wifi。目前2G的網絡相對於比較慢，測試時尤其要注意此塊的測試。
1) 無網絡時，執行需要網絡的操作，給予友好提示，確保程序不出現crash。
2) 內網測試時，要注意選擇到外網操作時的異常情況處理。
3) 在網絡信號不好時，檢查功能狀態是否正常，確保不因提交數據失敗而造成crash。
4) 在網絡信號不好時，檢查數據是否會一直處於提交中的狀態，有無超時限制。如遇數據交換失敗時要給予提示。
5) 在網絡信號不好時，執行操作後，在回調沒有完成的情況下，退出本頁面或者執行其他操作的情況，有無異常情況。此問題也會經常出現程序crash。
2.11.3服務器宕機或出現404、502等情況下的測試
後臺服務牽涉到DNS、空間服務商的情況下會影響其穩定性，如：當出現域名解析故障時，你對後臺API的請求很可能就會出現404錯誤，拋出異常。這時需要對異常進行正確的處理，否則可能會導致程序不能正常工作。
模擬404錯誤
模擬503錯誤
考慮一下，後面補充，順便學習更多的網絡知識
2.12接口測試
服務端一般會提供JSON格式的數據給客戶端，所以我們在服務端需要進行接口測試，確保服務端提供的接口並轉換的JSON內容正確，對分支、異常流有相應的返回值。此塊測試可以採用itest框架進行測試。最方便的是採用httpclient進行接口測試。
進行服務端測試時，需要開發提供一份接口文檔。
個人總結：
不能單純的模擬接口發送報文，驗證接口的返回結果，最好是能夠模擬業務場景進行測試，結合數據庫，驗證接口邏輯和數據處理是否有問題。
接口數據處理，每個字段的正常異常情況，邊界值，等價類。最好是瞭解每個字段的含義再去測試
接口的調用權限，經常會出現直接調用，缺少權限驗證
接口的業務邏輯和作用
接口與數據庫數據的結合驗證，可以說服務端接口所有的操作都是對數據的增、刪、改、查。所以知道接口每個字段的含義和作用，還要知道數據庫每個字段的作用，以及與接口的對應關係。知道接口與數據之間的邏輯關係，進行邏輯驗證
接口設計的合理性，功能是否完整，擴展性，安全性，容錯性
接口的異常處理
接口是否和其他模塊共用，共用是否會影響到其他模塊功能
2.13客戶端數據庫測試
1）一般的增、刪、改、查測試。
2） 當表不存在時是否能自動創建，當數據庫表被刪除後能否再自建，數據是否還能自動從服務端中獲取回來並保存。
3） 在業務需要從服務端取回數據保存到客戶端的時候，客戶端能否將數據保存到本地。
4） 當業務需要從客戶端取數據時，檢查客戶端數據存在時，app數據是否能自動從客戶端數據中取出，還是仍然會從服務器端獲取？檢查客戶端數據不存在時，app數據能否自動從服務器端獲取到並保存到客戶端
5） 當業務對數據進行了修改、刪除後，客戶端和服務端是否會有相應的更新。
個人總結：
2.14服務端數據庫測試
數據庫的驗證非常重要，有時通過數據庫的驗證可以發現很多前端可能很容易忽略的問題。當然有時通過數據驗證也可以很大的方便我們的測試工作，提高效率
個人總結部分：
1 數據完整性，業務需要的必須字段，在每種場景下是否保存完整
2 數據正確性，字段保存的值和用戶輸入的值一致，模擬一些異常情況，3 數據保存的是否正常，例如：圖片，數組
4 數據表格之間的數據關聯驗證
5 版本號驗證，一般數據庫會保存版本信息，更新時注意版本號對業務的影響。版本號是否會及時更新
6 是否有多餘參數值，主要是mongodb這種非結構化數據庫，如果客戶端對這個值有判斷，則可能出現錯誤，容錯性不好。
7 垃圾數據對業務的影響，有時數據庫有垃圾數據導致客戶端的正常數據都無法顯示了，容錯性很差，客戶端需要對這些情況做適當處理
8 無用數據清理，有些實例已經刪除，但是詳情或者評論卻還保存在數據庫中，這些都是bug，會佔用數據空間，同時作爲垃圾數據會影響服務端查詢的性能
2.15 系統升級測試
測試軟件的兼容性，我們經常要測試各種android系統或者IOS系統下軟件的使用情況。
正常的情況，系統升級並不會影響我們的app運行。但是下面這些地方確實容易出現問題的
1 權限，不同的系統對權限的控制可能不一樣，有些是安裝時統一申請，有些則是用到的時候才申請的。
2 禁止獲取某一項權限，不應該導致app崩潰，有時候我們測試時禁止其獲取系統的某一項權限，經常會導致程序出現crash
3 控件，彈窗控件，時間、日期選擇空間，這些地方也是非常容易出現bug的地方。
4 不同顯示屏幕下，輸入框，屏幕顯示。有些輸入框在低版本的系統中顯示沒有問題，到了高版本就會顯示亂了
5 系統通知，第三方推送，這個不同的機器，不同的系統最容易出現不一樣結果的地方。有些系統可能就無法收到推送。
6 桌面紅點顯示
7 上傳，下載功能
2.16 系統資源佔用釋放
1 使用了錄音功能佔用了話筒和聽筒，使用完以後應該立刻釋放，測試方式就是邊聽歌邊測，使用完以後，音樂播放器能夠繼續播放，如果一直佔用，則無法在使用app的時候後臺聽歌了
2 使用了照相機功能沒有釋放，這個問題還沒有遇到
其他：
client
1 重複調用接口
2 請求多餘參數(有些頁面上不顯示的參數就沒有必要顯示)
3 未修改任何字段，點擊保存，發送了請求（浪費資源，沒有必要）
4 分頁請求（限制分頁，數據量大的話必須做分頁加載）
5 調用多餘的接口，有些操作不需要調用接口，但是卻做了接口調用
6 傳遞多餘參數，IOS和安卓經常出現沒有協調好，導致傳遞了多餘參數，導致一方無法解析
backend
1 調用頻率，沒有限制可能被惡意刷屏，惡意工具（有些需要做這種限制）
2 安全性，無session調用（防止直接調用，每個接口都需要身份驗證）
3 返回隱私信息
4 返回多餘信息（浪費網絡資源，是的client的時間增長）
併發場景也是經常出問題的場景
數據服務端已經刪除，客戶端仍有緩存，通過客戶端進行操作。驗證返回結果
數據庫數據已經刪除，本地仍有緩存，直接更新時，應該將本地垃圾緩存清理掉，不應該還顯示
用戶同時操作某一時間，後臺是否有先後判斷
個人總結：
有時需要跳出慣性思維，條理邏輯清晰
---------------------
作者：測試小卒子
來源：CSDN
原文：https://blog.csdn.net/g695144224/article/details/51655116
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！