1嘱腥、 APP測試基本流程

1.1流程圖

1.2測試周期

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

1.3測試資源

測試任務開始前边灭，檢查各項測試資源异希。

--產品功能需求文檔；

--產品原型圖绒瘦；

--產品效果圖称簿；

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

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

--其他授药。

1.4日報及產品上線報告

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

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

--對當前測試版本質量進行分級呜魄；

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

--對版本的整體情況進行評估爵嗅。

3）產品上線前娇澎，測試人員發(fā)送產品上線報告。

4）上線報告所包含的內容為：

---對當前版本質量進行分級睹晒；

---附上測試報告（功能測試報告趟庄、兼容性測試報告、性能測試報告以及app可用性能標準結果）伪很；

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

2 App測試點

2.1安全測試

2.1.1軟件權限

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ù)泄漏昨忆、非法授權訪問等

2.1.2安裝與卸載安全性

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

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

3）是否包含數(shù)字簽名信息

4）JAD文件和JAR包中包含的所有托管屬性及其值必需是正確的

5）JAD文件顯示的資料內容與應用程序顯示的資料內容應一致

6）安裝路徑應能指定

7）沒有用戶的允許，應用程序不能預先設定自動啟動

8）卸載是否安全杉允，其安裝進去的文件是否全部卸載

9）卸載用戶使用過程中產生的文件是否有提示

10）其修改的配置信息是否復原

11）卸載是否影響其他軟件的功能

12）卸載應該移除所有的文件

2.1.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）備份應該加密鸣哀，恢復數(shù)據(jù)應考慮恢復過程的異常通訊中斷等架忌，數(shù)據(jù)恢復后再使用前應該經(jīng)過校驗

8）應用程序應考慮系統(tǒng)或者虛擬機器產生的用戶提示信息或安全替告

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

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

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

12）應用程序應當能夠處理當不允許應用軟件連接到個人信息管理的情況

13）當進行讀或寫用戶信息操作時低飒，應用程序將會向用戶發(fā)送一個操作錯誤的提示信息

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

15）應用程序讀和寫數(shù)據(jù)正確许昨。

16）應用程序應當有異常保護。

17）如果數(shù)據(jù)庫中重要的數(shù)據(jù)正要被重寫褥赊，應及時告知用戶

18）能合理地處理出現(xiàn)的錯誤

19）意外情況下應提示用戶

2.1.4通訊安全性

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異常作捕獲處理。

2.1.5人機接口安全性

1）返回菜單總保持可用

2）命令有優(yōu)先權順序

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

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

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

2.2安裝幕帆、卸載測試

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

2.2.1安裝

1）軟件在不同操作系統(tǒng)（Palm OS蜓肆、Symbian颜凯、Linux谋币、Android、iOS症概、Black BerryOS 6.0蕾额、Windows Phone 7）下安裝是否正常。

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

3）軟件安裝各個選項的組合是否符合概要設計說明

4)）軟件安裝向導的UI測試

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

6）軟件安裝過程中意外情況的處理是否符合需求（如死機调炬，重啟，斷電）

7）安裝空間不足時是否有相應提示

8）安裝后沒有生成多余的目錄結構和文件

9）對于需要通過網(wǎng)絡驗證之類的安裝舱馅，在斷網(wǎng)情況下嘗試一下

10）還需要對安裝手冊進行測試缰泡，依照安裝手冊是否能順利安裝

2.2.2卸載

1）直接刪除安裝文件夾卸載是否有提示信息。

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

3）測試卸載后文件是否全部刪除所有的安裝文件夾棘钞。

4）卸載過程中出現(xiàn)的意外情況的測試（如死機、斷電干毅、重啟）宜猜。

5）卸載是否支持取消功能，單擊取消后軟件卸載的情況?硝逢。

6）系統(tǒng)直接卸載UI測試姨拥，是否有卸載狀態(tài)進度條提示?绅喉。

2.3 UI測試

測試用戶界面(如菜單、對話框叫乌、窗口和其它可規(guī)控件)布局霹疫、風格是否滿足客戶要求、文字是否正確综芥、頁面是否美觀丽蝎、文字、圖片組合是否完美膀藐、操作是否友好等屠阻。

UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覓功能。確保用戶界面符合公司或行業(yè)的標準额各。包括用戶友好性国觉、人性化、易操作性測試虾啦。

2.3.1導航測試

1）按鈕麻诀、對話框、列表和窗口等傲醉；或在不同的連接頁面之間需要導航

2）是否易于導航蝇闭，導航是否直觀

3）是否需要搜索引擎

4）導航幫助是否準確直觀

5）導航與頁面結構、菜單硬毕、連接頁面的風格是否一致

2.3.2圖形測試

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

2）自適應界面設計，內容根據(jù)窗口大小自適應

3）頁面標簽風格是否統(tǒng)一

4）頁面是否美觀

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

6）圖片質量要高且圖片尺寸在設計符合要求的情況下應盡量小

7）界面整體使用的顏色不宜過多

2.3.3內容測試

1）輸入框說明文字的內容與系統(tǒng)功能是否一致

2）文字長度是否加以限制

3）文字內容是否表意不明

4）是否有錯別字

5）信息是否為中文顯示

6）是否有敏感性詞匯吐咳、關鍵詞

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

2.4功能測試

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

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

2)根據(jù)被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋外盯，如；涉及輸入的地方需要考慮等價翼雀、邊界饱苟、負面、異忱窃ǎ或非法箱熬、場景回滾、關聯(lián)測試等測試類型對其進行覆蓋狈邑。

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

2.4.1運行

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)能否正確處理卤恳。

--使用錯誤的賬號、口令寒矿、無權限的被禁用的賬號進行注銷

2.4.2應用的前后臺切換

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)崩潰萤厅。

2.4.3免登錄

很多應用提供免登錄功能，當應用開啟時自動以上一次登錄的用戶身份來使用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，應停留在登錄界面

2.4.4數(shù)據(jù)更新

根據(jù)應用的業(yè)務規(guī)則检吆，以及數(shù)據(jù)更新量的情況舒萎，來確定最優(yōu)的數(shù)據(jù)更新方案。

1)?需要確定哪些地方需要提供手動刷新蹭沛，哪些地方需要自動刷新臂寝，哪些地方需要手動+自動刷新。

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

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

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

5)?檢查有數(shù)據(jù)交換的地方怜珍，均有相應的異常處理端蛆。

2.4.5離線瀏覽

很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數(shù)據(jù)供用戶查看酥泛。

1)?在無網(wǎng)絡情況可以瀏覽本地數(shù)據(jù)

2)?退出app再開啟app時能正常瀏覽

3)?切換到后臺再切回前臺可以正常瀏覽

4)?鎖屏后再解屏回到應用前臺可以正常瀏覽

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

2.4.6 App更新

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

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

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

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

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

6)?當客戶端有新版本時脐供，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本借跪。如果以上無法更新成功的政己，也都屬于缺陷。

2.4.7定位掏愁、照相機服務

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

2)?有用到定位服務托猩、照相機服務的地方印蓖，需要進行前后臺的切換測試，檢查應用是否正常京腥。

3)?當定位服務沒有開啟時赦肃，使用定位服務，會友好性彈出是否允許設置定位提示公浪。當確定允許開啟定位時他宛，能自動跳轉到定位設置中開啟定位服務。

4)?測試定位欠气、照相機服務時厅各，需要采用真機進行測試。

2.4.8時間測試

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

--中國為東8區(qū)宜鸯，所以當手機設置的時間非東8區(qū)時憔古，查看需要顯示時間的地方，時間是否展示正確淋袖，應用功能是否正常鸿市。時間一般需要根據(jù)服務器時間再轉換成客戶端對應的時區(qū)來展示，這樣的用戶體驗比較好。比如發(fā)表一篇微博在服務端記錄的是10：00焰情，此時陌凳，華盛頓時間為22：00，客戶端去瀏覽時内舟，如果設置的是華盛頓時間,則顯示的發(fā)表時間即為22:00,當時間設回東8區(qū)時間時合敦，再查看則顯示為10：00。

2.4.9 PUSH測試

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

2)?檢查不接受推送消息時谒获，檢查用戶不會再接收到push.

3)?如果用戶設置了免打擾的時間段蛤肌，檢查在免打擾時間段內，用戶接收不到PUSH批狱。

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

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

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

2.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測試（基線測試）：與競爭產品的Benchmarking怔檩，產品演變對比測試等。

2.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運行時使用相機趋箩、計算器等手機自帶設備

2.7兼容測試

主要測試內部和外部兼容性

1）與本地及主流App是否兼容

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

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

--不同操作系統(tǒng)的兼容性票腰，是否適配

--不同手機屏幕分辨率的兼容性

--不同手機品牌的兼容性

2.8回歸測試

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

2）Bug修復后的回歸測試在交付前、要進行全量用例的回歸測試杏慰。

2.9升級测柠、更新測試

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

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

2）測試與升級模塊相關的模塊的功能是否與需求一致

3）升級安裝意外情況的測試（如死機、斷電吟税、重啟）

4）升級界面的UI測試

5）不同操作系統(tǒng)間的升級測試

2.10用戶體驗測試

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

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

2）是否濫用用戶引導。

3）是否有不可點擊的效果荤崇，如：你的按鈕此時處于不可用狀態(tài)拌屏，那么一定要灰掉，或者拿掉按鈕术荤，否則會給用戶誤導

4）菜單層次是否太深

5）交互流程分支是否太多

6）相關的選項是否離得很遠

7）一次是否載入太多的數(shù)據(jù)

8）界面中按鈕可點擊范圍是否適中

9）標簽頁是否跟內容沒有從屬關系倚喂，當切換標簽的時候，內容跟著切換

10）操作應該有主次從屬關系

11）是否定義Back的邏輯瓣戚。涉及軟硬件交互時端圈，Back鍵應具體定義

12）是否有橫屏模式的設計，應用一般需要支持橫屏模式子库，即自適應設計

2.11硬件環(huán)境測試

2.11.1手勢操作測試

1）手機開鎖屏對運行中的App的影響

2）切換網(wǎng)絡對運行中的App的影響

3）運行中的App前后臺切換的影響

4）多個運行中的App的切換

5）App運行時關機

6）App運行時重啟系統(tǒng)

7）App運行時充電

8）App運行時kill掉進程再打開

2.11.2網(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率寡。

2.11.3服務器宕機或出現(xiàn)404迫卢、502等情況下的測試

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

2.12接口測試

服務端一般會提供JSON格式的數(shù)據(jù)給客戶端命咐，所以我們在服務端需要進行接口測試篡九，確保服務端提供的接口并轉換的JSON內容正確，對分支醋奠、異常流有相應的返回值榛臼。此塊測試可以采用itest框架進行測試。最方便的是采用httpclient進行接口測試窜司。

進行服務端測試時沛善，需要開發(fā)提供一份接口文檔。

2.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ù)進行了修改液肌、刪除后挟炬，客戶端和服務端是否會有相應的更新。

3app測試工具

輔助工具的尋找矩屁，可以試一下華為MobileTest辟宗、Material Design Icon Generator、JSONSchema2POJO等等吝秕。