我的版整理APP測試流程

 2016.1.5 個人筆記

一 、APP測試基本流程

 1.1 測試周期

測試周期可按項目的開發週期來肯定測試時間，通常測試時間爲兩三週（即15個工做日），根據項目狀況以及版本質量可適當縮短或延長測試時間。正式測試前先向主管確認項目排期。

 1.2 測試資源

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

--產品功能需求文檔

--產品原型圖

--產品效果圖

--行爲統計分析定義文檔

--測試設備

--其餘

 

1.3日報及產品上線報告

這裏具體看狀況---可是我的以爲，在測試周天天提交的bug數，開發解決狀況在次日的晨會要有彙總，至少要保證APP的封包發版是否會受到影響，是否存在一些風險。

若真的有這個【日報】，能夠參考下面通用的模板喔~

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的用戶受權級別、數據泄漏、非法受權訪問等

 

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）不一樣的應用程序的我的身份證或密碼長度必需至少在4一8 個數字長度之間

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）軟件在不一樣操做系統下安裝是否正常。

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的各個功能實現：

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的現有規則，一個賬戶只容許登陸一臺機器。因此，須要檢查一個賬戶登陸多臺手機的狀況。原手機裏的用戶須要被踢出，給出友好提示。

補充：TOP原則——總的來講，着裝要規範、得體，就要牢記並嚴守TPO原則。TPO原則，是有關服飾禮儀的基本原則之一。 「tpo」原則，即着裝要考慮到時間「time」、地點「place」、場合「Occasion」

5) app切換到後臺，再切回前臺的校驗

6) 切換到後臺，再切換回前臺的測試

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

8) 支持自動登陸的應用在進行數據交換時，檢查系統是否能自動登陸成功而且數據操做無誤。

9) 檢查用戶主動退出登陸後，下次啓動app，應停留在登陸界面

2.4.4數據更新 

根據應用的業務規則，以及數據更新量的狀況，來肯定最優的數據更新方案。

1) 須要肯定哪些地方須要提供手動刷新，哪些地方須要自動刷新，哪些地方須要手動+自動刷新。

2) 肯定哪些地方從後臺切換回前臺時須要進行數據更新。

3) 根據業務、速度及流量的合理分配，肯定哪些內容須要實時更新，哪些須要定時更新。

4) 肯定數據展現部分的處理邏輯，是每次從服務端請求，仍是有緩存到本地，這樣纔能有針對性的進行相應測試。

5) 檢查有數據交換的地方，均有相應的異常處理。 

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時，須要採用真機進行測試。

6）也可使用特有的APPuser等進行測試

2.5性能測試 

評估App的時間和空間特性 ：

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

--內存滿時安裝App

--運行App時手機斷電

--運行App時斷掉網絡

2)響應能力測試：測試App中的各種操做是否知足用戶響應時間要求 。

--App安裝、卸載的響應時間

--App各種功能性操做的影響時間

3)壓力測試：反覆/長期操做下、系統資源是否佔用異常。

--App反覆進行安裝卸載，查看系統資源是否正常

--其餘功能反覆進行操做，查看系統資源是否正常

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

2.6交叉事件測試 

針對智能終端應用的服務等級劃分方式及實時特性所提出的測試方法。交叉測試又叫事件或衝突測試，是指一個功能正在執行過程當中，同時另一個事件或操做對該過程進行干擾的測試。如；App在前/後臺運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互狀況測試等。交叉事件測試很是重要，能發現不少應用中潛在的性能問題。

1） 多個App同時運行是否影響正常功能

2） App運行時前/後臺切換是否影響正常功能

3） App運行時撥打/接聽電話

4） App運行時發送/接收信息

5） App運行時發送/收取郵件

6） App運行時切換網絡（2G、3G、4G、wifi、5G）

7） App運行時瀏覽網絡

8） App運行時使用藍牙傳送/接收數據

9） 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）不一樣操做系統間的升級測試

補充：版本升級分爲兩種：

1.手動升級    2.自動升級

版本升級應該注意的事項：

版本升級當然帶來了新的功能，使部分漏洞及缺陷得以修復，但並不表明升級是好事。

版本升級時需注意：

1.升級後，硬件是否支持；<如，512M內存，（升級後）運行需1G內存的程序>

2.升級後，軟環境是否支持；<如，原先只須要.net2.0支持，如今最低.net3.5支持>

2.新的功能是否確實須要；<如，新增微博功能，本身可能從不使用微博>

3.是否會和其它軟件產生不兼容；<如，同時裝兩個不兼容的軟件，可能致使一個軟件或多個軟件沒法正常使用>

4.升級可能帶來的費用；<如，免費版到付費版>等等。

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服務器宕機或出現40四、502等狀況下的測試

後臺服務牽涉到DNS、空間服務商的狀況下會影響其穩定性，如：當出現域名解析故障時，你對後臺API的請求極可能就會出現404錯誤，拋出異常。這時須要對異常進行正確的處理，不然可能會致使程序不能正常工做。

2.12接口測試

（主要是使用Charles抓包看返回數據是否正確） 

服務端通常會提供JSON格式的數據給客戶端，因此咱們在服務端須要進行接口測試，確保服務端提供的接口並轉換的JSON內容正確，對分支、異常流有相應的返回值。此塊測試能夠採用itest框架進行測試。最方便的是採用httpclient進行接口測試。

進行服務端測試時，須要開發提供一份接口文檔。

3、測試用例總結

主要是經過面試遇到的一種問題經過不一樣的場景分析彙總整理如下

3.1 紙杯測試

一、基本功能測試

硬度——是否達到設計的標準；

裝載能力——在被子內分別裝入少許的、半杯的、滿杯的，查看七裝載量是否達到了設計的標準

裝載種類——開水（是否會產生異味）、溫水、冷水、茶、咖啡……

個人補充：

1.須要考慮杯子的材質，好比：玻璃的，陶瓷的，鐵的，塑料的等等

2.用途—— 養花，裝飾，兇器，摔，澆花，拔火罐，菸灰缸，罩子，作遊戲，討飯，養魚，反光，帽子，量器，筆筒，切餃子皮（每一種用途下是否對人體帶來危險）

3.材質——陶瓷、玻璃、鐵（是否引發生鏽，會不會給人的生命帶來危害）、塑料、紙質……

二、UI測試

 形狀、大小是否符合人方便拿起

 外觀是否吸引人（賞心悅目）

帶廣告的圖案沾水後是否會掉色、圖案變模糊

有蓋——擰緊蓋子後，倒立，會不會漏水

無蓋——盛水是否方便

三、易用性測試

形狀、大小是否符合人方便拿起

殘疾人拿此杯喝水的難易程度

杯子的設計是否符合上大下小，是否支持在運輸過程當中有效利用空間疊在（套在）一塊兒，是否會致使杯子摔碎等

四、穩定性測試

24*7測試——裝入液體以後，其過多久會出現漏水狀況

補充一下下 24*7 

24/7 是一天24小時，一星期7天的縮寫，即全天候提供服務的意思(也有寫作7*24的,都是同一個意思)。

五、安全性測試

杯子所用的材料（紙基、圖層、廣告顏料）是否符合食品衛生標準，在內外溫度等環境因素下是否會與所盛各類液體反應，而產生對人體有害的物質

六、本地化測試（具體狀況具體分析）

 廣告圖案、文字是否在政治、宗教、文化等方面具備普遍的適用性

補充------個人親身體驗

本地化測試中，主要考慮

1.翻譯問題,好比：翻譯是否得體，語句是否有截斷，是否出現重複內容；

2.顏色

3.商標or產品名不該該翻譯

七、對設計的改進與建議

如果一次性杯子，可否標識已使用（好比變色）

杯子是否有使用者標籤

 

3.2、如何作好APP測試

①　功能測試

②　非功能測試

③　客戶端性能測試：一個App作的好很差，不只僅只反應在功能上。被測的app在中低端機上的性能表現也很重要。好比：一個很好玩的遊戲或應用，只能在高端機上流暢運行，在中低端機上卡的不行，也不會取得好的口碑。關注的參數有：CPU，內存，耗電量，流量，FPS。同時也需關注一下App的安裝耗時和啓動耗時。

④　適配兼容測試：App在通過功能測試後，也需對其進行適配兼容測試須要檢查的項主要有如下幾點：

(a) 在不一樣品牌的機型上的安裝、拉起、點擊和卸載是否正常；

(b) 在不一樣的操做系統上的安裝、拉起、點擊和卸載是否正常；

咱們在實際測試中，經常會遇到下列問題：

(a)  在某品牌某系統上，app安裝不上；

(b)  在某品牌某系統上，app沒法拉起；

(c)  在某品牌某系統上，app拉起後無響應或拉起後黑屏、花屏；

(d)  在某品牌某系統上，app沒法順利卸載；

⑤　耗電量測試：app在手機上的表現，除了功能外，app是否耗電，也是測試過程當中重點要關注的一項。手機設備在滿電的時候，這個App能玩多久；App每小時的耗電是多少；App在某個場景掛機10分鐘耗電量是多少；這些都是咱們平時在耗電量測試中比較關注的點。

⑥　弱網絡測試：具體可參考here：http://www.javashuo.com/article/p-efuspilq-ht.html

⑦　安全測試：主要爲了檢測應用是否容易被外界破解；是否存在被惡意代碼注入的風險；上線後外掛的風險高不高等。

⑧　中斷測試：App在前臺和後臺運行狀態時與來電、文件下載、音樂收聽等關鍵運用的交互狀況測試等。測試電話，短信，彩信，微博或其餘通知進來時app的反應

⑨　協議測試：主要是爲了處理用戶發送惡意協議到服務器，騙過服務器的校驗

⑩　上線後問題跟蹤：新的app上線後，用戶對此應用的評價，存在哪些測試期間未察覺的Bug，論壇上對於該應用熱門的帖子有哪些，應用商店中該應用的口碑如何等，都是app在上線後，測試人員須要關注的點。若須要測試期間未發現的Bug，須要新測試服進行確認並根據該問題的修復。