app測試移動應用測試 （功能測試）适合0基礎學習

文章目錄

• app測試移動應用測試 （功能測試）0基礎
• • 一、背景介紹
  • • • app生命周期圖
      • 移動應用與傳統PC應用的差別
  • 二、App項目流程
  • • • 市場分析
      • 需求調研
      • 産品制造
      • • 互動設計
        • 産品開發
        • 系統測試
        • 産品上線
      • 産品營運
      • • 1、APP資料
        • 2、使用者回報和評論
        • 3、需求提取
        • 4、持續疊代
  • 三、APP測試流程
  • • 移動APP測試分類
    • 移動測試與傳統測試的差別
    • 什麼是移動APP測試？
    • 移動APP測試的考慮要點
    • ***移動應用測試的重點
    • App測試管理流程
    • • 1.測試計劃
      • • 影響項目成功的要素
        • 測試方案
      • 2.軟體測試流程--測試設計
      • 3.測試準備
      • 4.測試執行
      • • 缺陷處理過程
        • 測試報告
      • 5.線上監測
    • APP測試實施流程
  • 四、APP測試方法
  • • App測試層級體系
    • App測試類型
    • 功能測試
    • UI測試
    • • UI測試之導航測試
      • UI測試之圖形測試
      • UI測試之内容測試
    • 業務測試的分類
    • • 運作APP
      • 應用的前背景切換
      • 免登入
      • 資料更新
      • 離線浏覽
      • App更新
      • 定位、照相機服務
      • 時間測試
      • PUSH測試
    • 非功能測試
    • • 性能測試
      • 安全性
      • 軟體權限的安全測試
      • 安裝與解除安裝的安全性測試
      • 資料安全性的安全性測試
      • 安裝測試
      • 相容性測試
      • 相容性測試—分辨率
      • 如何做相容測試
      • 相容性測試自動化
    • 異常測試
    • 專項測試
    • 弱網測試
    • 網絡逾時測試
    • 網絡切換測試
    • 操作類型測試
    • 其他手勢操作測試
    • 交叉事件測試
    • 第三方推送測試
    • PUSH消息推送原理
    • 更新測試
    • * 使用者體驗測試
    • 接口測試
    • 用戶端資料庫測試.
  • 五、APP用例編寫
  • • APP測試例編寫原則
    • APP測試例編寫要求
    • 測試用例的常見問題

app測試移動應用測試 （功能測試）0基礎

一、背景介紹

• 随着科學技術的飛速發展，當今的計算機發展已進入了移動互

聯網時代。在我國，随着3G 、4G網絡和智能手機的快速發展，

人們已經逐漸養成通過智能手機進行上網的習慣，由智能手機

帶動的新興應用正在開辟一個新的計算機時代-移動網際網路時代。

• 移動網際網路無疑是目前世界最關注的領域之一，以蘋果、

Google等領銜的智能手機和平闆電腦正在悄然改變人們對手機

和電腦的傳統觀念。可見随着各種有價值、實用的應用軟體的

不斷産生，一個更加龐大和快速發展的使用者市場正在形成，面

對如此龐大的移動網際網路應用市場，基于移動網際網路的軟體測

試也越來越重要。基于移動網際網路的軟體測試，從技術上來講

應該是傳統軟體測試的一個繼承和發展。

• 移動終端種類

• 終端OS

• 移動平台兩分天下

• 主流移動終端作業系統

• IOS介紹

• IOS是由蘋果公司開發的手持裝置作業系統。蘋果公司最早

于2007年1月9日的Macworld大會上公布這個系統，最初是設

計給iPhone使用的，後來陸續套用到iPod touch、iPad以及

Apple TV等蘋果産品上。iOS與蘋果的Mac OS X作業系統一

樣，它也是以Darwin為基礎的，是以同樣屬于類Unix的商業

作業系統。原本這個系統名為iPhone OS，直到2010年6月7

日WWDC大會上宣布改名為iOS。截止至2011年11月，根據

Canalys的資料顯示，iOS已經占據了全球智能手機系統市場

份額的30%，在美國的市場占有率為43% 。

出色的觸控體驗

強大的APP Store

安全性及擴充性強

• Android介紹

• Android是一種以Linux為基礎的開放源代碼作業系統，主要

使用于便攜裝置。尚未有統一中文名稱，中國大陸地區較多

人使用“安卓”或“安緻”。Android作業系統最初由Andy

Rubin開發，最初主要支援手機。2005年由Google收購注資，

并組建開放手機聯盟開發改良，逐漸擴充到平闆電腦及其他

領域上。Android的主要競争對手是蘋果公司的iOS以及RIM

的Blackberry OS。2011年第一季度，Android在全球的市場

份額首次超過塞班系統，躍居全球第一。 2012年7月資料，

Android占據全球智能手機作業系統市場59%的份額，中國市

場占有率為76.7%

全新開源系統

自由度高

安全性低

• Android架構

app生命周期圖

移動應用與傳統PC應用的差別

• 移動端成為主戰場

• 移動應用份額增長強勁

二、App項目流程

市場分析

• 産品在投入研發之前，企業高層決策評估項目的必要性。其

内容涉及市場分析，銷售政策，盈利預測等。

• 輸出産物：商業需求文檔（BRD）

• BRD的文檔結構主要包括：

– 1.方案形成背景

– 2.方案價值（經濟類和非經濟類的）

– 3.産品規劃

– 4.盈利模式

– 5.收益與成本評估

– 6.風險和對策

需求調研

• 經過一系列的分析後，拿出一套你認為最合理的幹某個事情的方法

，調研采用什麼樣的方式獲得BRD裡面的商業目标。

• 輸入産物：市場需求文檔（MRD）

• MRD的文檔結構主要包括：

– 1.文檔說明

– 2.市場分析

– 3.使用者分析

– 4.産品說明

産品制造

• 産品項目由“概念化”階段進入到“具體化”階段的最主要的階段。

該階段通過産品需求文檔（PRD）指導産品的開發實作。

• 産品需求文檔（PRD），就像建築設計師的設計圖紙，是整個設計和

思考的結晶；同時，也是思考過程呈現。

• 廣義上來講，産品需求的描述，應該包含有産品的戰略和戰術，戰略

是指：産品定位、目标市場、目标使用者、競争對手等。戰術是指産品

的結構、核心業務流程、具體用例描述、功能&内容描述等，本文主

要讨論的是戰術部分。

互動設計

• 業務模型架構化

– 在産品的概念階段時期，互動設計師需要基關注使用者界面和整體

結構，這個過程被稱作“架構設計”

– 架構設計就是一種基于使用者目标的導航架構和流程設計。

– 這個階段互動的産出物主要有導航架構圖，流程圖和低保真線框

圖。

• 架構界面化

– 在定義完功能子產品的頁面結構和流程後，互動設計師還需要設計

規劃使用者的操作，這些包括頁面元素的主次關系，小部件的處

理，元素的組織，界面的引導等等。

– 這個階段互動設計師需要提供原型demo

産品開發

系統測試

• 1.測試準入

• 2.功能測試

• 3.性能測試

• 4.相容性測試

• 5.上線步驟測試

• 6.聯調測試

産品上線

• 上線及線上檢查

– 1.上線前發出測試報告，主要包括結論，存在的問題和風險等

– 2.上線後發出線上驗證報告

– 3.添加必要的監控和事故處理預案

• 項目總結

– 1.典型bug分析（建議發現方式）

– 2.項目問題以及與目标比對程度

– 3.項目經驗分享

産品營運

一是APP資料，二是使用者回報，三是需求提取。

1、APP資料

新增使用者：第一次啟動應用的使用者；

新增獨立使用者：全體應用的新增使用者的總和（去重）

活躍使用者：當天啟動一次的使用者即為活躍使用者，含新使用者和老使用者；

活躍獨立使用者：當天應用的活躍使用者總和（去重）

MAU：MAU（monthly active users）月活躍使用者人數。

DAU: DAU(Daily Active User)日活躍使用者數量。常用于反映網站、網際網路應用或網絡遊戲的營運情況。

使用者留存率：在網際網路行業中，使用者在某段時間内開始使用應用，經過一段時間後，仍然繼續使用該應用的使用者，被認作是留存使用者。這部分使用者占當時新增使用者的比例即是留存率，會按照每隔1機關時間（例日、周、月）來進行統計。

使用者留存率中的40-20-10法則：如果你想讓遊戲、應用的DAU超過100萬，那麼日留存率應該大于40%，周留存率和月留存率分别大于20%和10%。

次日留存率：（當天新增的使用者中，在往後的第1天還活躍的使用者數）/第一天新增總使用者數；

第2日留存率：（第一天新增使用者中，在往後的第2天還有活躍的使用者數）/第一天新增總使用者數；

第7日留存率：（第一天新增的使用者中，在往後的第7天還有活躍的使用者數）/第一天新增總使用者數；

第30日留存率：（第一天新增的使用者中，在往後的第30天還有活躍的使用者數）/第一天新增總使用者數。

另外就是APP的埋點資料，這個功能的點選率是多少？這個功能有多少人打開，又有多少人使用了？有多少人在頻繁使用這個功能？等等，這些埋點資料要時常關注。結合資料變化來反思功能設計的問題，進而優化産品。

2、使用者回報和評論

産品上線後，使用者的回報和評論對于産品人員來講是尤為珍貴的材料，一方面這是你的真實使用者的直覺感受，另一方面他們再表達直接的需求。那麼，怎麼樣處理使用者的意見就顯得格外重要。使用者回報什麼我們就做什麼，這是肯定不行的。很多情況下使用者表達的隻是一種表面現象，要學會去挖掘使用者背後的需求本質。多去研究世界上一些革命性的産品，多去了解人。

當看到四處飛來的意見時，我們要學會思考，而不是全盤接受、全盤照抄。

是不是我們的目标？想想我們的目标使用者是誰。

使用場景是否成立？還是這隻是極個别人的場景需求。

使用者目标是否正确？我們的APP是不是用來滿足使用者這個需求的？

産品定位還正确嗎？如果做了這個功能，還符合我們産品的定位嗎？

如果要做這個功能，那麼自身的項目資源是否能夠滿足？如果需要舉全部資源來做這件事情，那就要慎重再慎重。

3、需求提取

也許使用者的意見是個圓形，但經過分析之後，很有可能得到需求是個三角形。

“如果我最初問消費者他們想要什麼，他們應該是會告訴我，‘要一匹更快的馬！’”

——這是亨利·福特的一句經典名言，如今我們在《喬布斯傳》裡又見到了它。

100多年前，福特公司的創始人亨利·福特先生到處跑去問客戶：“您需要一個什麼樣的更好的交通工具？”幾乎所有人的答案都是：“我要一匹更快的馬”。很多人聽到這個答案，于是立馬跑到馬場去選馬配種，以滿足客戶的需求。但是福特先生卻沒有立馬往馬場跑，而是接着往下問。

福特：“你為什麼需要一匹更快的馬？”

客戶：“因為可以跑得更快！”

福特：“你為什麼需要跑得更快？”

客戶：“因為這樣我就可以更早的到達目的地。”

福特：“是以，你要一匹更快的馬的真正用意是？”

客戶：“用更短的時間、更快地到達目的地！”

于是，福特并沒有往馬場跑去，而是選擇了制造汽車去滿足客戶的需求。

客戶需求有顯性需求和隐性需求兩大類。我們通過市場調查得知的往往都是一些諸如“我要一匹更快的馬”這類顯性需求。客戶的顯性需求并不是客戶真正的需求。企業需要根據所收集的顯性需求資訊進行深度挖掘和捕獲，以了解客戶的隐性需求是什麼，進而分析出客戶的真正需求是什麼（例如：用更短的時間、更快地到達目的地）。這就是一個需求分析的過程。

喬布斯所言：“我們的任務是讀懂還沒落到紙面上的東西。”實際上就是使用者隐性需求的深度挖掘。

4、持續疊代

三、APP測試流程

移動APP測試分類

移動測試與傳統測試的差別

什麼是移動APP測試？

移動APP測試定義：

移動APP測試就是符合多

種網絡，不同系統不同分辨

率下發現軟體缺陷，并保證

提高軟體品質的過程。

移動APP測試的考慮要點

終端資源有限（CPU、記憶體、磁盤）

環境特殊（移動空間、網絡環境、應用五花八門）

使用者為核心（文化背景、操作習慣）

什麼操作都有可能

使用者體驗至關重要

***移動應用測試的重點

使用者體驗是移動應用成敗的關鍵，是以也是移動應用測試需要

高度關注的地方。

結合移動應用軟體的特性, 測試的重點有：

① 操作方式: 觸摸是否符合作業系統本身的要求, 一指觸摸

和兩指觸摸是否沖突; 操作步驟是否符合使用者習慣, 不同功

能的觸摸操作是否存在沖突等；

② 使用者界面布局: 對使用者是否友好，界面設計是否符合手機平

台的設計規範, 動作按鈕和導航按鈕安排是否合理, 界面色

調是否統一, 文本字型大小是否合理等；

③ 功能操作流程: 主要功能和次要功能銜接是否合理, 并列

功能之間是否可以平滑過渡, 是否符合使用者操作習慣等；

④ 相容系統平台的限制：功能設計是否考慮到移動裝置有限的

存儲空間；與網絡相關的功能設計是；

⑤ 否考慮到移動裝置帶寬限制：資料互動設計是否考慮容錯處

理: 移動裝置的移動性, 3G/Wi-Fi 之間的切換導緻的連接配接不穩

定, 資料過大, 使用者頻繁操作等導緻軟體出錯是否給出友好的

提示.，以及使用者能否承受流量的消耗速度；

⑥ 是否考慮到使用該應用時對電量的消耗程度對于使用者能否忍

受。

● 網絡連接配接及安全性檢查和使用者體驗高度相關，是移動應用測試

需要高度關注的另一個重點。

移動開發平台通常開放了擷取裝置ID、位置、所連接配接的網絡等資訊,使用者在

下載下傳應用的時候最關心的是此款應用是否會盜取個人資訊,尤其是基于

LBS(Location Based Service)的軟體應用;

有的開發平台像Google Android開發平台還提供了下載下傳量統計的功

(GoogleAnalytics),如何合理利用而不過度消耗網絡流量也是測試的重要檢

查點;

基于移動網際網路的移動應用更是離不開網絡連結,與網絡相關的功能也是測

試的重點;

網絡連接配接及安全性檢查主要有以下功能點：

①使用者注冊登陸資訊的安全性：與個人财務賬戶相關的資訊要及時退出,比

如銀行賬戶、支付寶賬戶等, 防止手機丢失而造成更大的損失;

②位置資訊提供啟動關閉機制:使用者可以随時關閉自己的位置資訊而不是一

直暴露資訊；

③檢測目前網絡連接配接:提示使用者目前所用網絡是3G還是Wi-Fi以便使用者選擇是

否繼續進行大資料量下載下傳(比如使用3G網絡時候打開視訊而造成流量費用激

增)；

④産品資料跟蹤:檢查所跟蹤的資料資訊是否符合開發平台規範、是否違反

法律、是否占用帶寬甚至導緻資料流量過大；

⑤資料流量監測:監測所有功能使用的資料流量; 測試同一份資料是否重複

下載下傳上傳；是否采取逐次下載下傳而不是全部下載下傳。

App測試管理流程

1.測試計劃

– 計劃是指用文字和名額等形式所表述的組織以及組織内不同部門和

不同成員，在未來一定時期内關于行動方向、内容和方式安排的管

理事件。

– 測試計劃是對系統測試全過程的組織、資源、原則等進行規定和約

束，并制定系統測試全過程各個階段的任務以及時間進度安排，并

提出對各項任務的評估、風險分析和管理需求。

– 測試計劃的要點：

– 确定測試範圍和資源安排

– 制定進度安排

– 風險及對策

– 準入标準和準出标準

影響項目成功的要素

• 範圍

• 時間

• 成本

• 品質

• 風險

• 人力資源

• 溝通

• 采購

測試方案

2.軟體測試流程–測試設計

3.測試準備

• 測試用機準備

– 根據适配測試政策準備測試用機

• 測試資料準備

– 測試團隊安排專人進行測試資料的生成

– 測試組提出資料申請要求，由其他項目組配合完成

• 版本提測

– 版本部署

– 冒煙測試

4.測試執行

• 第一輪測試：

– 冒煙測試通過後，開始執行系統測試用例，即進行詳細的功能

測試，在功能測試過程中主要以黑盒測試為主，同時執行操作

類型測試。

– 功能測試過程中，若發現大量Bug，在開發Fix bug過程中，快

速執行弱網測試等。

• 第二輪測試：

– 主要為了發現深層次的Bug，除了驗證bug fix外，還加入了适

配測試，弱網絡測試等非功能測試

缺陷處理過程

測試報告

• 測試的最終成果物，其主要内容包括：

– 1.測試的過程說明（測試實際所花費的時間、人員、所測試的内

容說明：包含執行了多少用例，發現了多少缺陷）

– 2.對系統的品質進行分析與度量（通過缺陷的發現率和修複率）

– 3.測試結論（是否通過，上線是否還存在哪些風險，如何規避）

5.線上監測

• 線上檢測是改進APP使用者體驗的重要手段；

• 主要收集釋出後的使用者回報，有無異常情況，排查問題，統計分析等.

APP測試實施流程

四、APP測試方法

App測試層級體系

App測試類型

功能測試

• 功能測試就是對産品的各功能進行驗證，根據功能測試用

例，逐項測試，檢查産品是否達到使用者要求的功能。

• 功能測試也稱行為測試，測試一個産品的特性和可操作行

為是否滿足其使用者需求。是以測試人員要考慮到軟體的用

戶類型，以及在不同的資料場景下如何進行測試。

根據軟體說明或使用者需求驗證App的各個功能實作，采用如下方

法實作并評估功能測試過程：

• 1)采用時間、地點、對象、行為和背景五元素或業務分析等方

法分析、提煉App的使用者使用場景，對比說明或需求，整理出

内在、外在及非功能直接相關的需求，建構測試點，并明确測

試标準，若使用者需求中無明确标準遵循，則需要參考行業或相

關國際标準或準則。

• 2)根據被測功能點的特性列丼出相應類型的測試用例對其進行

覆寫，如；涉及輸入的地方需要考慮等價、邊界、負面、異常

或非法、場景復原、關聯測試等測試類型對其進行覆寫。

• 3)在測試實作的各個階段跟蹤測試實作與需求輸入的覆寫情況

，及時修正業務或需求了解錯誤。

可能的測試場景：

• 測試使用者可輸入的極限值；

• 用重複的資料進行測試；

• 在全新無資料的手機裡測試；

• 在老手機上測試；

• 預先安裝不同類型的資料；

• 用一些超出預期的資料去測試，看它是怎麼處理的；

• 分析資訊和資料是怎麼影響使用者體驗的；

功能測試主要是程式邏輯及相關業務點測試

• 一、應充分考慮各種邊緣情況，邊界狀态

• 二、應多站在使用者的角度考慮程式的設計是否合理，是否

充分滿足使用者的需求

UI測試

• 確定手頭的原型圖與效果圖為目前最新版本。

• 確定産品UI符合産品經理制定的原型圖與效果圖。

• 測試使用者界面(如菜單、對話框、視窗和其它可規控件)布局、風格是

否滿足客戶要求、文字是否正确、頁面是否美觀、文字、圖檔組合是

否完美、操作是否友好等。

• UI測試的目标是確定使用者界面會通過測試對象的功能來為使用者提供相

應的通路或浏覓功能。確定使用者界面符合公司或行業的标準。包括用

戶友好性、人性化、易操作性測試。

UI測試之導航測試

• 按鈕、對話框、清單和視窗等；或在不同的連接配接頁面之間需要導航

• 是否易于導航，導航是否直覺

• 是否需要搜尋引擎

• 導航幫助是否準确直覺

• 導航與頁面結構、菜單、連接配接頁面的風格是否一緻

UI測試之圖形測試

• 橫向比較。各控件操作方式統一

• 自适應界面設計，内容根據視窗大小自适應

• 頁面标簽風格是否統一

• 頁面是否美觀

• 頁面的圖檔應有其實際意義而要求整體有序美觀

• 圖檔品質要高且圖檔尺寸在設計符合要求的情況下應盡量小

• 界面整體使用的顔色不宜過多

UI測試之内容測試

• 輸入框說明文字的内容與系統功能是否一緻

• 文字長度是否加以限制

• 文字内容是否表意不明

• 是否有錯别字

• 資訊是否為中文顯示

• 是否有敏感性詞彙、關鍵詞

• 是否有敏感性圖檔，如：涉及版權、專利、隐私等圖檔

業務測試的分類

運作APP

• 1）App安裝完成後的試運作，可正常打開軟體。

• 2）App打開測試，是否有加載狀态進度提示。

• 3）App打開速度測試，速度是否可觀。

• 4）App頁面間的切換是否流暢，邏輯是否正确

• 5）注冊

–同表單編輯頁面

–使用者名密碼長度

–注冊後的提示頁面

–前台注冊頁面和背景的管理頁面資料是否一緻

–注冊後，在背景管理中頁面提示

• 6）登入

–使用合法的使用者登入系統。

–系統是否允許多次非法的登陸，是否有次數限制。

–使用已經登陸的賬号登陸系統是否正确處理。

–使用禁用的賬号登陸系統是否正确處理。

–使用者名、密碼（密碼）錯誤或漏填時能否登陸。

–删除或修改後的使用者，原使用者登陸。

–不輸入使用者密碼和使用者、重複點（确定或取消按鈕）是否允許登陸。

–登陸後，頁面中登陸資訊。

–頁面中有登出按鈕。

–登陸逾時的處理。

• 7）登出

–登出原子產品，新的子產品系統能否正确處理。

–終止登出能否傳回原子產品，原使用者。

–登出原使用者，新使用者系統能否正确處理。

–使用錯誤的賬号、密碼、無權限的被禁用的賬号進行登出

應用的前背景切換

• 1) APP切換到背景，再回到app，檢查是否停留在上一次

操作界面。

• 2) APP切換到背景，再回到app，檢查功能及應用狀态是

否正常，IOS4和IOS5的版本的處理機制有的不一樣。

• 3) app切換到背景，再回到前台時，注意程式是否崩潰

，功能狀态是否正常，尤其是對于從背景切換回前台資料

有自動更新的時候。

• 4) 手機鎖屏解屏後進入app注意是否會崩潰，功能狀态

是否正常，尤其是對于從背景切換回前台資料有自動更新

的時候。

• 5) 當App使用過程中有電話進來中斷後再切換到app，功

能狀态是否正常

• 6) 當殺掉app程序後，再開啟app，app能否正常啟動。

• 7) 出現必須處理的提示框後，切換到背景，再切換回來

，檢查提示框是否還存在，有時候會出現應用自動跳過提

示框的缺陷。

• 8) 對于有資料交換的頁面，每個頁面都必需要進行前後

台切換、鎖屏的測試，這種頁面最容易出現崩潰

免登入

很多應用提供免登入功能，當應用開啟時自動以上一次登入

的使用者身份來使用app.

• 1) app有免登入功能時，需要考慮IOS版本差異。

• 2) 考慮無網絡情況時能否正常進入免登入狀态。

• 3) 切換使用者登入後，要校驗使用者登入資訊及資料内容是

否相應更新，確定原使用者退出。

• 4) 根據MTOP的現有規則，一個帳戶隻允許登入一台機

器。是以，需要檢查一個帳戶登入多台手機的情況。原手

機裡的使用者需要被踢出，給出友好提示。

• 5) app切換到背景，再切回前台的校驗

• 6) 切換到背景，再切換回前台的測試

• 7) 密碼更換後，檢查有資料交換時是否進行了有效身份

的校驗

• 8) 支援自動登入的應用在進行資料交換時，檢查系統是

否能自動登入成功并且資料操作無誤

• 9) 檢查使用者主動登出後，下次啟動app，應停留在

登入界面

資料更新

根據應用的業務規則，以及資料更新量的情況，來确定最優的數

據更新方案。

• 1) 需要确定哪些地方需要提供手動重新整理，哪些地方需要自動刷

新，哪些地方需要手動+自動重新整理。

• 2) 确定哪些地方從背景切換回前台時需要進行資料更新。

• 3) 根據業務、速度及流量的合理配置設定，确定哪些内容需要實時

更新，哪些需要定時更新。

• 4) 确定資料展示部分的處理邏輯，是每次從服務端請求，還是

有緩存到本地，這樣才能有針對性的進行相應測試。

• 5) 檢查有資料交換的地方，均有相應的異常處理。

離線浏覽

很多應用會支援離線浏覽，即在本地用戶端會緩存一部分數

據供使用者檢視。

• 1) 在無網絡情況可以浏覽本地資料

• 2) 退出app再開啟app時能正常浏覽

• 3) 切換到背景再切回前台可以正常浏覽

• 4) 鎖屏後再解屏回到應用前台可以正常浏覽

• 5) 在對服務端的資料有更新時會給予離線的相應提示

App更新

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

• 2) 當版本為非強制更新版時，使用者可以取消更新，老版本能正

常使用。使用者在下次啟動app時，仍能出現更新提示。

• 3) 當版本為強制更新版時，當給出強制更新後使用者沒有做更新

時，退出用戶端。下次啟動app時，仍出現強制更新提示。

• 4) 當用戶端有新版本時，在本地不删除用戶端的情況下，直接

更新檢查是否能正常更新。

• 5) 當用戶端有新版本時，在本地不删除用戶端的情況下，檢查

更新後的用戶端功能是否是新版本。

• 6) 當用戶端有新版本時，在本地不删除用戶端的情況下，檢查

資源同名檔案如圖檔是否能正常更新成最新版本。如果以上無

法更新成功的，也都屬于缺陷。

定位、照相機服務

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

• 2) 有用到定位服務、照相機服務的地方，需要進行前背景的切換測

試，檢查應用是否正常。

• 3) 當定位服務沒有開啟時，使用定位服務，會友好性彈出是否允許

設定定位提示。當确定允許開啟定位時，能自動跳轉到定位設定中開

啟定位服務。

• 4) 測試定位、照相機服務時，需要采用真機進行測試。

時間測試

• 用戶端可以自行設定手機的時區、時間，是以需要校驗該設定

對app的影響。

• --中國為東8區，是以當手機設定的時間非東8區時，檢視需要

顯示時間的地方，時間是否展示正确，應用功能是否正常。時

間一般需要根據伺服器時間再轉換成用戶端對應的時區來展示

，這樣的使用者體驗比較好。比如發表一篇微網誌在服務端記錄的

是10：00，此時，華盛頓時間為22：00，用戶端去浏覽時，

如果設定的是華盛頓時間,則顯示的發表時間即為22:00,當時間

設回東8區時間時，再檢視則顯示為10：00。

PUSH測試

• 1) 檢查push消息是否按照指定的業務規則發送

• 2) 檢查不接受推送消息時，檢查使用者不會再接收到push.

• 3) 如果使用者設定了免打擾的時間段，檢查在免打擾時間

段内，使用者接收不到PUSH。

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

• 4) 當push消息是針對登入使用者的時候，需要檢查收到的

push與使用者身份是否相符，沒有錯誤地将其它人的消息

推送過來。一般情況下，隻對手機上最後一個登入使用者進

行消息推送。

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

非功能測試

性能測試

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

– App安裝、解除安裝的響應時間

– App各類功能性操作的影響時間

• 壓力測試：反複/長期操作下、系統資源是否占用異常。

– App反複進行安裝解除安裝，檢視系統資源是否正常

– 其他功能反複進行操作，檢視系統資源是否正常

• 性能評估：評估典型使用者應用場景下，系統資源的使用情況。

• Benchmark測試（基線測試）：與競争産品的Benchmarking, 産品

演變對比測試等。

安全性

• 軟體測試的依據：需求規則說明書

• 軟體安全實作依據：業務需求文檔和系統設計文檔

• 程式編碼安全設計

– 權限控制算法（Private類）

– 資料庫視圖的引用

– 密鑰和加密算法

• 技術方案安全設計

– 驗證碼

– 多重驗證（登入與支付分離、多次密碼輸入）

– 逾時原理（Session、Cookie逾時）

– 密碼安全（密碼鍵盤 ，簡單提示，多重加密）

– *安全證書（CFCA憑證等）

– 關鍵資訊屏蔽（銀行卡号和證件号屏蔽）

– 背景日志管理

軟體權限的安全測試

• 1）扣費風險：包括發送短信、撥打電話、連接配接網絡等

• 2）隐私洩露風險：包括通路手機資訊、通路聯系人資訊等

• 3）對App的輸入有效性校驗、認證、授權、敏感資料存儲、資料加

密等方面進行檢測

• 4）限制/允許使用手機功能接人網際網路

• 5）限制/允許使用手機發送接受資訊功能

• 6）限制/允許應用程式來注冊自動啟動應用程式

• 7）限制或使用本地連接配接

• 8）限制/允許使用手機拍照或錄音

• 9）限制/允許使用手機讀取使用者資料

• 10) 限制/允許使用手機寫人使用者資料

• 11) 檢測App的使用者授權級别、資料洩漏、非法授權通路等

安裝與解除安裝的安全性測試

• 1）應用程式應能正确安裝到裝置驅動程式上

• 2）能夠在安裝裝置驅動程式上找到應用程式的相應圖示

• 3）是否包含數字簽名資訊

• 4）JAD檔案和JAR包中包含的所有托管屬性及其值必需是正确的

• 5）JAD檔案顯示的資料内容與應用程式顯示的資料内容應一緻

• 6）安裝路徑應能指定

• 7）沒有使用者的允許, 應用程式不能預先設定自動啟動

• 8）解除安裝是否安全, 其安裝進去的檔案是否全部解除安裝

• 9）解除安裝使用者使用過程中産生的檔案是否有提示

• 10）其修改的配置資訊是否複原

• 11）解除安裝是否影響其他軟體的功能

• 12）解除安裝應該移除所有的檔案

資料安全性的安全性測試

• 1）當将密碼或其他的敏感資料輸人到應用程式時, 其不會被儲存在裝置中,

同時密碼也不會被解碼

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

• 3）密碼, 信用卡明細, 或其他的敏感資料将不被儲存在它們預輸人的位置上

• 4）不同的應用程式的個人身份證或密碼長度必需至少在4一8 個數字長度之

間

• 5）當應用程式處理信用卡明細, 或其他的敏感資料時, 不以明文形式将資料

寫到其它單獨的檔案或者臨時檔案中。以防止應用程式異常終止而又沒有側

除它的臨時檔案, 檔案可能遭受人侵者的襲擊, 然後讀取這些資料資訊。

• 6）當将敏感資料輸人到應用程式時, 其不會被儲存在裝置中

• 7）備份應該加密, 恢複資料應考慮恢複過程的異常ٯ 通訊中斷等, 資料恢複

後再使用前應該經過校驗

• 8）應用程式應考慮系統或者虛拟機器産生的使用者提示資訊或安全替告

• 9）應用程式不能忽略系統或者虛拟機器産生的使用者提示資訊或安全警告, 更

不能在安全警告顯示前,，利用顯示誤導資訊欺騙使用者，應用程式不應該模

拟進行安全警告誤導使用者

• 10）在資料删除之前，應用程式應當通知使用者或者應用程式提供一個“取

消”指令的操作

• 11）“ 取消” 指令操作能夠按照設計要求實作其功能

• 12）應用程式應當能夠處理當不允許應用軟體連接配接到個人資訊管理的情況

• 13）當進行讀或寫使用者資訊操作時, 應用程式将會向使用者發送一個操作錯誤

的提示資訊

• 14）在沒有使用者明确許可的前提下不損壞側除個人資訊管理應用程式中的

任何内容Μ

• 15）應用程式讀和寫資料正确。

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

• 17）如果資料庫中重要的資料正要被重寫, 應及時告知使用者

• 18）能合理地處理出現的錯誤

• 19）意外情況下應提示使用者

安裝測試

• 1.軟體安裝後的是否能夠正常運作，安裝後的檔案夾及檔案是否寫到

了指定的目錄裡。 （結果檢查）

• 2.軟體安裝各個選項的組合是否正确 （操作）

• 3.安裝過程中進行取消和意外情況處理（當機、重新開機、斷電等）

• 4.安裝後沒有生成多餘的目錄和檔案

• 5.安裝路徑能指定：手機、SD卡

• 6.解除安裝、更新、重複安裝

相容性測試

相容性測試—分辨率

需注意：

• 1.不同公司出的系統：MIUI、Flyme等

• 2.現在比較流行做第三方Launcher，需考慮不同公司出的

Launcher相容性

• 3.與防毒軟體的相容

• 4.注意最新系統與以前版本的差別

測試時可以考慮雲測

如何做相容測試

• 1.多選擇手機排行榜、機型、分辨率、系統來進行綜合考慮

• 2.盡可能多的在不同的機器上測試

– 三星華為魅族小米四大廠商的機器肯定是要過到的，使用者量比較大

• 3.測試在真機下進行，挑選大功能類用例并執行

相容性裝置選擇：市場主流手機裝置

相容性測試自動化

• 1.谷歌是如何做相容性測試自動化的？

– 工具：Android Compatibility Test Suite（簡稱Android CTS

）

– 缺點：局限于官方出的系統

• 2.Emulator（Android-sdk自帶：AVD Manager）

– 缺點：比較理想環境，測試結果僅供參考，價值不大

• 3.雲測平台：testin

– 優點：測試機型很多，可以給出很詳細測試報告

– 缺點：測試結果僅供參考，意義不大

• 總結：工具測試隻能起到一定輔助作用，無法解決真實用

戶場景。

異常測試

• 伺服器異常時穩定性

• 外部事件影響（電話，短信等）

• 記憶體是否有溢出或者洩漏

• 多線程問題

• 是否存在閃退

• 不放SIM卡、不聯網

• 放置不同參數和seed值

• 附：Monkey測試可以測試出80%的崩潰。

專項測試

弱網測試

• 無網絡測試，需要在頁面作請求前關閉移動裝置網絡，觀

察程式是否作友好提示。

• 弱網絡測試要複雜得多，存在以下三種類型：

– 1.頁面等待請求資料，資料傳回後，頁面呈現是否正常；

– 2.頁面在送出請求後，離開該頁面，資料傳回後，程式是否正常處

理，是否會發生crash

– 3.頁面等待請求資料，造成逾時，頁面是否作友好提示

網絡逾時測試

網絡逾時可通過以下方式來實作，根據實際需要來選擇：

• 1.綁定未知伺服器，構成網絡逾時，适用所有類型

• 2.對某類域名作host綁定，适用于越獄機器

• 3.綁定代理伺服器，延時某個請求的時間

• 4.修改程式代碼，改變某個請求的連結

網絡切換測試

• 實際應用場景中，還需要考慮網絡之間的切換，具體切換類型如下：

操作類型測試

• 操作類型測試，應根據自身app的應用場景來進行，比如對于有攝像頭的

app，應根據使用場景來決定掃描、拍攝角度等；對于支援橫豎屏的場景，

要考慮橫豎切換的情況。下表給出了操作類型的測試要點：

其他手勢操作測試

• 手機開鎖屏對運作中的App的影響

• 切換網絡對運作中的App的影響

• 運作中的App前背景切換的影響

• 多個運作中的App的切換

• App運作時關機

• App運作時重新開機系統

• App運作時充電

• App運作時kill掉程序再打開

交叉事件測試

交叉測試又叫事件或沖突測試，是指一個功能正在執行過程

中，同時另外一個事件或操作對該過程進行幹擾的測試。

如：App在前/背景運作狀态時與來電、檔案下載下傳、音樂收聽等關鍵運用

的互動情況測試等。交叉事件測試非常重要，能發現很多應用中潛在的

性能問題。

測試要點：

1、多個App同時運作是否影響正常功能

2、App運作時前/背景切換是否影響正常功能

3、App運作時撥打/接聽電話

4、App運作時發送/接收資訊

5、App運作時發送/收取郵件

6、App運作時切換網絡（2G、3G、4G、WIFI）

7、App運作時浏覽網絡

8、App運作時使用藍牙傳送/接收資料

9、App運作時使用相機、電腦等手機自帶裝置

第三方推送測試

• APP消息推送指的是APP開發者通過第三方工具将自己想要推的消息

推送給使用者，讓使用者被動的接收。

PUSH消息推送原理

更新測試

• 當用戶端有新版本時，有更新提示。

• 當版本為非強制更新版時，使用者可以取消更新，老版本能正常使用。使用者在

下次啟動app時，仍能出現更新提示。

• 當版本為強制更新版時，當給出強制更新後使用者沒有做更新時，退出用戶端

。下次啟動app時，仍出現強制更新提示。

• 當用戶端有新版本時，在本地不删除用戶端的情況下，直接更新檢查是否能

正常更新。

• 當用戶端有新版本時，在本地不删除用戶端的情況下，檢查更新後的用戶端

功能是否是新版本。

• 更新完成之後，使用者資訊是否被清除了。

* 使用者體驗測試

以主觀的普通消費者的角度去感覺産品或服務的舒适、有用、易用、友好親切程

度。通過不同個體、獨立空間和非經驗的統計複用方式去有效評價産品的體驗特性

提出修改意見提升産品的潛在客戶滿意度。

接口測試

服務端一般會提供JSON格式的資料給用戶端，是以我們在服務端需

要進行接口測試，確定服務端提供的接口并轉換的JSON内容正确，對分

支、異常流有相應的傳回值。此塊測試可以采用itest架構進行測試。最

友善的是采用httpclient進行接口測試。

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

(JavaScript Object Notation) 是一種輕量 級的資料交換格

Itest測試架構是 TaoBao測試部門開發的 一套單元測試架構

HttpClient 是 Apache Jakarta Common 下的子項目，可以用來 提供高效的、最新的、功能豐富的 支援 HTTP 協定的用戶端程式設計工 具包，并且它支援 HTTP 協定最 新的版本和建議。

用戶端資料庫測試.

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

• 2） 當表不存在時是否能自動建立，當資料庫表被删除後能否再自建，資料是否還能自動從

服務端中擷取回來并儲存。

• 3） 在業務需要從服務端取回資料儲存到用戶端的時候，用戶端能否将資料儲存到本地。

• 4） 當業務需要從用戶端取資料時，檢查用戶端資料存在時，app資料是否能自動從用戶端

資料中取出，還是仍然會從伺服器端擷取？檢查用戶端資料不存在時，app資料能否自動從

伺服器端擷取到并儲存到用戶端

• 5） 當業務對資料進行了修改、删除後，用戶端和服務端是否會有相應的更新

五、APP用例編寫

APP測試例編寫原則

• 熟悉需求,設計,了解業務

• 測試例命名規則清晰,明了.

• 子產品劃分,測試例編寫具有較強的通用性測試例

• 有明确的測試目的,測試前提條件，優先級别,預期結果

• 好的測試例的要求能夠盡量的覆寫典型的，常用的，異常的場景

– 盡量避免重複測試

– 測試例并非越多越好，測試例的數量應該是，盡可能的發現問題

與盡可能的覆寫功能的最小公倍數

– 測試例的編寫與測試本身一樣，需要不斷完善

APP測試例編寫要求

• 1. 準确:

按所設計的去測試.對需求及設計了解準确,了解軟體及功能特點,積極設想軟體

如何才能失敗,做到盡可能發現錯誤

• 2.不備援:

好的測試例子沒有不必要的步驟,每一個測試都應該有不同的用途, 不會太簡單

，也不會太複雜。通常每個測試例應獨立執行。多個測試例組合，有可能屏

蔽錯誤。最大操作步驟最好控制在10-15步之間,每個測試步驟應該有一個清

晰的輸入或者測試任務,不排除單個測試例子有多個邏輯輸入,需要逐一列舉

輸出結果.

• 3.清晰:

描述清晰,步驟條理清晰,測試層次清晰(由簡而繁,從基本功能測試到破壞性測

試).

• 4.可複用:

無論何時何人測試都能得到同樣的結論,友善移植。

• 5.可追溯性:

針對特定的需求測試.

• 6.适 當:

測試例應該适合特定的測試環境 以及符合整個團隊的測試水準

• 7.可維護性:

好的測試用例應該是可維護的,維護包括添加,删除,更改,特别是對應

需求及功能等變更的維護.象代碼一樣,不需要維護的測試例是不存在

的,在變更過程中未做維護的測試例将失去它應有價值,甚至帶來危害。

測試用例的常見問題

• 單個測試例太長

• 不完善,錯誤,或者雜亂無端的操作步驟

• 關鍵步驟遺漏

• 命名域改變或者不再存在

• 描述不清,測試員或者測試系統不清楚實際要測試的步驟及内容

• 不清楚什麼樣的結果是通過和出錯

• 不友善維護(添加,删除,更改等)

</div><div data-report-view="{&quot;mod&quot;:&quot;1585297308_001&quot;,&quot;dest&quot;:&quot;https://blog.csdn.net/qq646642124/article/details/93370085&quot;,&quot;extend1&quot;:&quot;pc&quot;,&quot;ab&quot;:&quot;new&quot;}"><div></div></div>
            <link href="https://csdnimg.cn/release/phoenix/mdeditor/markdown_views-60ecaf1f42.css" target="_blank" rel="external nofollow"  rel="stylesheet">
                                <div data-report-view="{&quot;mod&quot;:&quot;popu_387&quot;,&quot;dest&quot;:&quot;https://blog.csdn.net/qq646642124/article/details/93370085&quot;,&quot;extend1&quot;:&quot;pc&quot;,&quot;ab&quot;:&quot;new&quot;}"></div>
                    
        <div class="person-messagebox">
            <div class="left-message"><a href="https://blog.csdn.net/qq646642124" target="_blank" rel="external nofollow"  target="_blank" rel="external nofollow" >
                <img src="https://profile.csdnimg.cn/4/1/7/3_qq646642124" class="avatar_pic" username="qq646642124">
            </a></div>
            <div class="middle-message">
                                    <div class="title"><span class="tit "><a href="https://blog.csdn.net/qq646642124" target="_blank" rel="external nofollow"  target="_blank" rel="external nofollow"  data-report-click="{&quot;mod&quot;:&quot;popu_379&quot;,&quot;ab&quot;:&quot;new&quot;}" target="_blank">@流浪地球</a></span>
                    <!-- 等級，level -->
                                            <img class="identity-icon" src="https://csdnimg.cn/identity/blog3.png">                                            </div>
                <div class="text"><span>原創文章 21</span><span>獲贊 9</span><span>通路量 2萬+</span></div>
            </div>
                            <div class="right-message">
                                        <a class="btn btn-sm  bt-button personal-watch" data-report-click="{&quot;mod&quot;:&quot;popu_379&quot;,&quot;ab&quot;:&quot;new&quot;}">關注</a>
                                                            <a href="https://im.csdn.net/im/main.html?userName=qq646642124" target="_blank" rel="external nofollow"  target="_blank" class="btn btn-sm bt-button personal-letter">私信
                    </a>
                                </div>
                        </div>
                    
    </div>
           

文章目錄

• app測試移動應用測試 （功能測試）0基礎
• • 一、背景介紹
  • • • app生命周期圖
      • 移動應用與傳統PC應用的差別
  • 二、App項目流程
  • • • 市場分析
      • 需求調研
      • 産品制造
      • • 互動設計
        • 産品開發
        • 系統測試
        • 産品上線
      • 産品營運
      • • 1、APP資料
        • 2、使用者回報和評論
        • 3、需求提取
        • 4、持續疊代
  • 三、APP測試流程
  • • 移動APP測試分類
    • 移動測試與傳統測試的差別
    • 什麼是移動APP測試？
    • 移動APP測試的考慮要點
    • ***移動應用測試的重點
    • App測試管理流程
    • • 1.測試計劃
      • • 影響項目成功的要素
        • 測試方案
      • 2.軟體測試流程--測試設計
      • 3.測試準備
      • 4.測試執行
      • • 缺陷處理過程
        • 測試報告
      • 5.線上監測
    • APP測試實施流程
  • 四、APP測試方法
  • • App測試層級體系
    • App測試類型
    • 功能測試
    • UI測試
    • • UI測試之導航測試
      • UI測試之圖形測試
      • UI測試之内容測試
    • 業務測試的分類
    • • 運作APP
      • 應用的前背景切換
      • 免登入
      • 資料更新
      • 離線浏覽
      • App更新
      • 定位、照相機服務
      • 時間測試
      • PUSH測試
    • 非功能測試
    • • 性能測試
      • 安全性
      • 軟體權限的安全測試
      • 安裝與解除安裝的安全性測試
      • 資料安全性的安全性測試
      • 安裝測試
      • 相容性測試
      • 相容性測試—分辨率
      • 如何做相容測試
      • 相容性測試自動化
    • 異常測試
    • 專項測試
    • 弱網測試
    • 網絡逾時測試
    • 網絡切換測試
    • 操作類型測試
    • 其他手勢操作測試
    • 交叉事件測試
    • 第三方推送測試
    • PUSH消息推送原理
    • 更新測試
    • * 使用者體驗測試
    • 接口測試
    • 用戶端資料庫測試.
  • 五、APP用例編寫
  • • APP測試例編寫原則
    • APP測試例編寫要求
    • 測試用例的常見問題

app測試移動應用測試 （功能測試）0基礎

一、背景介紹

• 随着科學技術的飛速發展，當今的計算機發展已進入了移動互

聯網時代。在我國，随着3G 、4G網絡和智能手機的快速發展，

人們已經逐漸養成通過智能手機進行上網的習慣，由智能手機

帶動的新興應用正在開辟一個新的計算機時代-移動網際網路時代。

• 移動網際網路無疑是目前世界最關注的領域之一，以蘋果、

Google等領銜的智能手機和平闆電腦正在悄然改變人們對手機

和電腦的傳統觀念。可見随着各種有價值、實用的應用軟體的

不斷産生，一個更加龐大和快速發展的使用者市場正在形成，面

對如此龐大的移動網際網路應用市場，基于移動網際網路的軟體測

試也越來越重要。基于移動網際網路的軟體測試，從技術上來講

應該是傳統軟體測試的一個繼承和發展。

• 移動終端種類

• 終端OS

• 移動平台兩分天下

• 主流移動終端作業系統

• IOS介紹

• IOS是由蘋果公司開發的手持裝置作業系統。蘋果公司最早

于2007年1月9日的Macworld大會上公布這個系統，最初是設

計給iPhone使用的，後來陸續套用到iPod touch、iPad以及

Apple TV等蘋果産品上。iOS與蘋果的Mac OS X作業系統一

樣，它也是以Darwin為基礎的，是以同樣屬于類Unix的商業

作業系統。原本這個系統名為iPhone OS，直到2010年6月7

日WWDC大會上宣布改名為iOS。截止至2011年11月，根據

Canalys的資料顯示，iOS已經占據了全球智能手機系統市場

份額的30%，在美國的市場占有率為43% 。

出色的觸控體驗

強大的APP Store

安全性及擴充性強

• Android介紹

• Android是一種以Linux為基礎的開放源代碼作業系統，主要

使用于便攜裝置。尚未有統一中文名稱，中國大陸地區較多

人使用“安卓”或“安緻”。Android作業系統最初由Andy

Rubin開發，最初主要支援手機。2005年由Google收購注資，

并組建開放手機聯盟開發改良，逐漸擴充到平闆電腦及其他

領域上。Android的主要競争對手是蘋果公司的iOS以及RIM

的Blackberry OS。2011年第一季度，Android在全球的市場

份額首次超過塞班系統，躍居全球第一。 2012年7月資料，

Android占據全球智能手機作業系統市場59%的份額，中國市

場占有率為76.7%

全新開源系統

自由度高

安全性低

• Android架構

app生命周期圖

移動應用與傳統PC應用的差別

• 移動端成為主戰場

• 移動應用份額增長強勁

二、App項目流程

市場分析

• 産品在投入研發之前，企業高層決策評估項目的必要性。其

内容涉及市場分析，銷售政策，盈利預測等。

• 輸出産物：商業需求文檔（BRD）

• BRD的文檔結構主要包括：

– 1.方案形成背景

– 2.方案價值（經濟類和非經濟類的）

– 3.産品規劃

– 4.盈利模式

– 5.收益與成本評估

– 6.風險和對策

需求調研

• 經過一系列的分析後，拿出一套你認為最合理的幹某個事情的方法

，調研采用什麼樣的方式獲得BRD裡面的商業目标。

• 輸入産物：市場需求文檔（MRD）

• MRD的文檔結構主要包括：

– 1.文檔說明

– 2.市場分析

– 3.使用者分析

– 4.産品說明

産品制造

• 産品項目由“概念化”階段進入到“具體化”階段的最主要的階段。

該階段通過産品需求文檔（PRD）指導産品的開發實作。

• 産品需求文檔（PRD），就像建築設計師的設計圖紙，是整個設計和

思考的結晶；同時，也是思考過程呈現。

• 廣義上來講，産品需求的描述，應該包含有産品的戰略和戰術，戰略

是指：産品定位、目标市場、目标使用者、競争對手等。戰術是指産品

的結構、核心業務流程、具體用例描述、功能&内容描述等，本文主

要讨論的是戰術部分。

互動設計

• 業務模型架構化

– 在産品的概念階段時期，互動設計師需要基關注使用者界面和整體

結構，這個過程被稱作“架構設計”

– 架構設計就是一種基于使用者目标的導航架構和流程設計。

– 這個階段互動的産出物主要有導航架構圖，流程圖和低保真線框

圖。

• 架構界面化

– 在定義完功能子產品的頁面結構和流程後，互動設計師還需要設計

規劃使用者的操作，這些包括頁面元素的主次關系，小部件的處

理，元素的組織，界面的引導等等。

– 這個階段互動設計師需要提供原型demo

産品開發

系統測試

• 1.測試準入

• 2.功能測試

• 3.性能測試

• 4.相容性測試

• 5.上線步驟測試

• 6.聯調測試

産品上線

• 上線及線上檢查

– 1.上線前發出測試報告，主要包括結論，存在的問題和風險等

– 2.上線後發出線上驗證報告

– 3.添加必要的監控和事故處理預案

• 項目總結

– 1.典型bug分析（建議發現方式）

– 2.項目問題以及與目标比對程度

– 3.項目經驗分享

産品營運

一是APP資料，二是使用者回報，三是需求提取。

1、APP資料

新增使用者：第一次啟動應用的使用者；

新增獨立使用者：全體應用的新增使用者的總和（去重）

活躍使用者：當天啟動一次的使用者即為活躍使用者，含新使用者和老使用者；

活躍獨立使用者：當天應用的活躍使用者總和（去重）

MAU：MAU（monthly active users）月活躍使用者人數。

DAU: DAU(Daily Active User)日活躍使用者數量。常用于反映網站、網際網路應用或網絡遊戲的營運情況。

使用者留存率：在網際網路行業中，使用者在某段時間内開始使用應用，經過一段時間後，仍然繼續使用該應用的使用者，被認作是留存使用者。這部分使用者占當時新增使用者的比例即是留存率，會按照每隔1機關時間（例日、周、月）來進行統計。

使用者留存率中的40-20-10法則：如果你想讓遊戲、應用的DAU超過100萬，那麼日留存率應該大于40%，周留存率和月留存率分别大于20%和10%。

次日留存率：（當天新增的使用者中，在往後的第1天還活躍的使用者數）/第一天新增總使用者數；

第2日留存率：（第一天新增使用者中，在往後的第2天還有活躍的使用者數）/第一天新增總使用者數；

第7日留存率：（第一天新增的使用者中，在往後的第7天還有活躍的使用者數）/第一天新增總使用者數；

第30日留存率：（第一天新增的使用者中，在往後的第30天還有活躍的使用者數）/第一天新增總使用者數。

另外就是APP的埋點資料，這個功能的點選率是多少？這個功能有多少人打開，又有多少人使用了？有多少人在頻繁使用這個功能？等等，這些埋點資料要時常關注。結合資料變化來反思功能設計的問題，進而優化産品。

2、使用者回報和評論

産品上線後，使用者的回報和評論對于産品人員來講是尤為珍貴的材料，一方面這是你的真實使用者的直覺感受，另一方面他們再表達直接的需求。那麼，怎麼樣處理使用者的意見就顯得格外重要。使用者回報什麼我們就做什麼，這是肯定不行的。很多情況下使用者表達的隻是一種表面現象，要學會去挖掘使用者背後的需求本質。多去研究世界上一些革命性的産品，多去了解人。

當看到四處飛來的意見時，我們要學會思考，而不是全盤接受、全盤照抄。

是不是我們的目标？想想我們的目标使用者是誰。

使用場景是否成立？還是這隻是極個别人的場景需求。

使用者目标是否正确？我們的APP是不是用來滿足使用者這個需求的？

産品定位還正确嗎？如果做了這個功能，還符合我們産品的定位嗎？

如果要做這個功能，那麼自身的項目資源是否能夠滿足？如果需要舉全部資源來做這件事情，那就要慎重再慎重。

3、需求提取

也許使用者的意見是個圓形，但經過分析之後，很有可能得到需求是個三角形。

“如果我最初問消費者他們想要什麼，他們應該是會告訴我，‘要一匹更快的馬！’”

——這是亨利·福特的一句經典名言，如今我們在《喬布斯傳》裡又見到了它。

100多年前，福特公司的創始人亨利·福特先生到處跑去問客戶：“您需要一個什麼樣的更好的交通工具？”幾乎所有人的答案都是：“我要一匹更快的馬”。很多人聽到這個答案，于是立馬跑到馬場去選馬配種，以滿足客戶的需求。但是福特先生卻沒有立馬往馬場跑，而是接着往下問。

福特：“你為什麼需要一匹更快的馬？”

客戶：“因為可以跑得更快！”

福特：“你為什麼需要跑得更快？”

客戶：“因為這樣我就可以更早的到達目的地。”

福特：“是以，你要一匹更快的馬的真正用意是？”

客戶：“用更短的時間、更快地到達目的地！”

于是，福特并沒有往馬場跑去，而是選擇了制造汽車去滿足客戶的需求。

客戶需求有顯性需求和隐性需求兩大類。我們通過市場調查得知的往往都是一些諸如“我要一匹更快的馬”這類顯性需求。客戶的顯性需求并不是客戶真正的需求。企業需要根據所收集的顯性需求資訊進行深度挖掘和捕獲，以了解客戶的隐性需求是什麼，進而分析出客戶的真正需求是什麼（例如：用更短的時間、更快地到達目的地）。這就是一個需求分析的過程。

喬布斯所言：“我們的任務是讀懂還沒落到紙面上的東西。”實際上就是使用者隐性需求的深度挖掘。

4、持續疊代

三、APP測試流程

移動APP測試分類

移動測試與傳統測試的差別

什麼是移動APP測試？

移動APP測試定義：

移動APP測試就是符合多

種網絡，不同系統不同分辨

率下發現軟體缺陷，并保證

提高軟體品質的過程。

移動APP測試的考慮要點

終端資源有限（CPU、記憶體、磁盤）

環境特殊（移動空間、網絡環境、應用五花八門）

使用者為核心（文化背景、操作習慣）

什麼操作都有可能

使用者體驗至關重要

***移動應用測試的重點

使用者體驗是移動應用成敗的關鍵，是以也是移動應用測試需要

高度關注的地方。

結合移動應用軟體的特性, 測試的重點有：

① 操作方式: 觸摸是否符合作業系統本身的要求, 一指觸摸

和兩指觸摸是否沖突; 操作步驟是否符合使用者習慣, 不同功

能的觸摸操作是否存在沖突等；

② 使用者界面布局: 對使用者是否友好，界面設計是否符合手機平

台的設計規範, 動作按鈕和導航按鈕安排是否合理, 界面色

調是否統一, 文本字型大小是否合理等；

③ 功能操作流程: 主要功能和次要功能銜接是否合理, 并列

功能之間是否可以平滑過渡, 是否符合使用者操作習慣等；

④ 相容系統平台的限制：功能設計是否考慮到移動裝置有限的

存儲空間；與網絡相關的功能設計是；

⑤ 否考慮到移動裝置帶寬限制：資料互動設計是否考慮容錯處

理: 移動裝置的移動性, 3G/Wi-Fi 之間的切換導緻的連接配接不穩

定, 資料過大, 使用者頻繁操作等導緻軟體出錯是否給出友好的

提示.，以及使用者能否承受流量的消耗速度；

⑥ 是否考慮到使用該應用時對電量的消耗程度對于使用者能否忍

受。

● 網絡連接配接及安全性檢查和使用者體驗高度相關，是移動應用測試

需要高度關注的另一個重點。

移動開發平台通常開放了擷取裝置ID、位置、所連接配接的網絡等資訊,使用者在

下載下傳應用的時候最關心的是此款應用是否會盜取個人資訊,尤其是基于

LBS(Location Based Service)的軟體應用;

有的開發平台像Google Android開發平台還提供了下載下傳量統計的功

(GoogleAnalytics),如何合理利用而不過度消耗網絡流量也是測試的重要檢

查點;

基于移動網際網路的移動應用更是離不開網絡連結,與網絡相關的功能也是測

試的重點;

網絡連接配接及安全性檢查主要有以下功能點：

①使用者注冊登陸資訊的安全性：與個人财務賬戶相關的資訊要及時退出,比

如銀行賬戶、支付寶賬戶等, 防止手機丢失而造成更大的損失;

②位置資訊提供啟動關閉機制:使用者可以随時關閉自己的位置資訊而不是一

直暴露資訊；

③檢測目前網絡連接配接:提示使用者目前所用網絡是3G還是Wi-Fi以便使用者選擇是

否繼續進行大資料量下載下傳(比如使用3G網絡時候打開視訊而造成流量費用激

增)；

④産品資料跟蹤:檢查所跟蹤的資料資訊是否符合開發平台規範、是否違反

法律、是否占用帶寬甚至導緻資料流量過大；

⑤資料流量監測:監測所有功能使用的資料流量; 測試同一份資料是否重複

下載下傳上傳；是否采取逐次下載下傳而不是全部下載下傳。

App測試管理流程

1.測試計劃

– 計劃是指用文字和名額等形式所表述的組織以及組織内不同部門和

不同成員，在未來一定時期内關于行動方向、内容和方式安排的管

理事件。

– 測試計劃是對系統測試全過程的組織、資源、原則等進行規定和約

束，并制定系統測試全過程各個階段的任務以及時間進度安排，并

提出對各項任務的評估、風險分析和管理需求。

– 測試計劃的要點：

– 确定測試範圍和資源安排

– 制定進度安排

– 風險及對策

– 準入标準和準出标準

影響項目成功的要素

• 範圍

• 時間

• 成本

• 品質

• 風險

• 人力資源

• 溝通

• 采購

測試方案

2.軟體測試流程–測試設計

3.測試準備

• 測試用機準備

– 根據适配測試政策準備測試用機

• 測試資料準備

– 測試團隊安排專人進行測試資料的生成

– 測試組提出資料申請要求，由其他項目組配合完成

• 版本提測

– 版本部署

– 冒煙測試

4.測試執行

• 第一輪測試：

– 冒煙測試通過後，開始執行系統測試用例，即進行詳細的功能

測試，在功能測試過程中主要以黑盒測試為主，同時執行操作

類型測試。

– 功能測試過程中，若發現大量Bug，在開發Fix bug過程中，快

速執行弱網測試等。

• 第二輪測試：

– 主要為了發現深層次的Bug，除了驗證bug fix外，還加入了适

配測試，弱網絡測試等非功能測試

缺陷處理過程

測試報告

• 測試的最終成果物，其主要内容包括：

– 1.測試的過程說明（測試實際所花費的時間、人員、所測試的内

容說明：包含執行了多少用例，發現了多少缺陷）

– 2.對系統的品質進行分析與度量（通過缺陷的發現率和修複率）

– 3.測試結論（是否通過，上線是否還存在哪些風險，如何規避）

5.線上監測

• 線上檢測是改進APP使用者體驗的重要手段；

• 主要收集釋出後的使用者回報，有無異常情況，排查問題，統計分析等.

APP測試實施流程

四、APP測試方法

App測試層級體系

App測試類型

功能測試

• 功能測試就是對産品的各功能進行驗證，根據功能測試用

例，逐項測試，檢查産品是否達到使用者要求的功能。

• 功能測試也稱行為測試，測試一個産品的特性和可操作行

為是否滿足其使用者需求。是以測試人員要考慮到軟體的用

戶類型，以及在不同的資料場景下如何進行測試。

根據軟體說明或使用者需求驗證App的各個功能實作，采用如下方

法實作并評估功能測試過程：

• 1)采用時間、地點、對象、行為和背景五元素或業務分析等方

法分析、提煉App的使用者使用場景，對比說明或需求，整理出

内在、外在及非功能直接相關的需求，建構測試點，并明确測

試标準，若使用者需求中無明确标準遵循，則需要參考行業或相

關國際标準或準則。

• 2)根據被測功能點的特性列丼出相應類型的測試用例對其進行

覆寫，如；涉及輸入的地方需要考慮等價、邊界、負面、異常

或非法、場景復原、關聯測試等測試類型對其進行覆寫。

• 3)在測試實作的各個階段跟蹤測試實作與需求輸入的覆寫情況

，及時修正業務或需求了解錯誤。

可能的測試場景：

• 測試使用者可輸入的極限值；

• 用重複的資料進行測試；

• 在全新無資料的手機裡測試；

• 在老手機上測試；

• 預先安裝不同類型的資料；

• 用一些超出預期的資料去測試，看它是怎麼處理的；

• 分析資訊和資料是怎麼影響使用者體驗的；

功能測試主要是程式邏輯及相關業務點測試

• 一、應充分考慮各種邊緣情況，邊界狀态

• 二、應多站在使用者的角度考慮程式的設計是否合理，是否

充分滿足使用者的需求

UI測試

• 確定手頭的原型圖與效果圖為目前最新版本。

• 確定産品UI符合産品經理制定的原型圖與效果圖。

• 測試使用者界面(如菜單、對話框、視窗和其它可規控件)布局、風格是

否滿足客戶要求、文字是否正确、頁面是否美觀、文字、圖檔組合是

否完美、操作是否友好等。

• UI測試的目标是確定使用者界面會通過測試對象的功能來為使用者提供相

應的通路或浏覓功能。確定使用者界面符合公司或行業的标準。包括用

戶友好性、人性化、易操作性測試。

UI測試之導航測試

• 按鈕、對話框、清單和視窗等；或在不同的連接配接頁面之間需要導航

• 是否易于導航，導航是否直覺

• 是否需要搜尋引擎

• 導航幫助是否準确直覺

• 導航與頁面結構、菜單、連接配接頁面的風格是否一緻

UI測試之圖形測試

• 橫向比較。各控件操作方式統一

• 自适應界面設計，内容根據視窗大小自适應

• 頁面标簽風格是否統一

• 頁面是否美觀

• 頁面的圖檔應有其實際意義而要求整體有序美觀

• 圖檔品質要高且圖檔尺寸在設計符合要求的情況下應盡量小

• 界面整體使用的顔色不宜過多

UI測試之内容測試

• 輸入框說明文字的内容與系統功能是否一緻

• 文字長度是否加以限制

• 文字内容是否表意不明

• 是否有錯别字

• 資訊是否為中文顯示

• 是否有敏感性詞彙、關鍵詞

• 是否有敏感性圖檔，如：涉及版權、專利、隐私等圖檔

業務測試的分類

運作APP

• 1）App安裝完成後的試運作，可正常打開軟體。

• 2）App打開測試，是否有加載狀态進度提示。

• 3）App打開速度測試，速度是否可觀。

• 4）App頁面間的切換是否流暢，邏輯是否正确

• 5）注冊

–同表單編輯頁面

–使用者名密碼長度

–注冊後的提示頁面

–前台注冊頁面和背景的管理頁面資料是否一緻

–注冊後，在背景管理中頁面提示

• 6）登入

–使用合法的使用者登入系統。

–系統是否允許多次非法的登陸，是否有次數限制。

–使用已經登陸的賬号登陸系統是否正确處理。

–使用禁用的賬号登陸系統是否正确處理。

–使用者名、密碼（密碼）錯誤或漏填時能否登陸。

–删除或修改後的使用者，原使用者登陸。

–不輸入使用者密碼和使用者、重複點（确定或取消按鈕）是否允許登陸。

–登陸後，頁面中登陸資訊。

–頁面中有登出按鈕。

–登陸逾時的處理。

• 7）登出

–登出原子產品，新的子產品系統能否正确處理。

–終止登出能否傳回原子產品，原使用者。

–登出原使用者，新使用者系統能否正确處理。

–使用錯誤的賬号、密碼、無權限的被禁用的賬号進行登出

應用的前背景切換

• 1) APP切換到背景，再回到app，檢查是否停留在上一次

操作界面。

• 2) APP切換到背景，再回到app，檢查功能及應用狀态是

否正常，IOS4和IOS5的版本的處理機制有的不一樣。

• 3) app切換到背景，再回到前台時，注意程式是否崩潰

，功能狀态是否正常，尤其是對于從背景切換回前台資料

有自動更新的時候。

• 4) 手機鎖屏解屏後進入app注意是否會崩潰，功能狀态

是否正常，尤其是對于從背景切換回前台資料有自動更新

的時候。

• 5) 當App使用過程中有電話進來中斷後再切換到app，功

能狀态是否正常

• 6) 當殺掉app程序後，再開啟app，app能否正常啟動。

• 7) 出現必須處理的提示框後，切換到背景，再切換回來

，檢查提示框是否還存在，有時候會出現應用自動跳過提

示框的缺陷。

• 8) 對于有資料交換的頁面，每個頁面都必需要進行前後

台切換、鎖屏的測試，這種頁面最容易出現崩潰

免登入

很多應用提供免登入功能，當應用開啟時自動以上一次登入

的使用者身份來使用app.

• 1) app有免登入功能時，需要考慮IOS版本差異。

• 2) 考慮無網絡情況時能否正常進入免登入狀态。

• 3) 切換使用者登入後，要校驗使用者登入資訊及資料内容是

否相應更新，確定原使用者退出。

• 4) 根據MTOP的現有規則，一個帳戶隻允許登入一台機

器。是以，需要檢查一個帳戶登入多台手機的情況。原手

機裡的使用者需要被踢出，給出友好提示。

• 5) app切換到背景，再切回前台的校驗

• 6) 切換到背景，再切換回前台的測試

• 7) 密碼更換後，檢查有資料交換時是否進行了有效身份

的校驗

• 8) 支援自動登入的應用在進行資料交換時，檢查系統是

否能自動登入成功并且資料操作無誤

• 9) 檢查使用者主動登出後，下次啟動app，應停留在

登入界面

資料更新

根據應用的業務規則，以及資料更新量的情況，來确定最優的數

據更新方案。

• 1) 需要确定哪些地方需要提供手動重新整理，哪些地方需要自動刷

新，哪些地方需要手動+自動重新整理。

• 2) 确定哪些地方從背景切換回前台時需要進行資料更新。

• 3) 根據業務、速度及流量的合理配置設定，确定哪些内容需要實時

更新，哪些需要定時更新。

• 4) 确定資料展示部分的處理邏輯，是每次從服務端請求，還是

有緩存到本地，這樣才能有針對性的進行相應測試。

• 5) 檢查有資料交換的地方，均有相應的異常處理。

離線浏覽

很多應用會支援離線浏覽，即在本地用戶端會緩存一部分數

據供使用者檢視。

• 1) 在無網絡情況可以浏覽本地資料

• 2) 退出app再開啟app時能正常浏覽

• 3) 切換到背景再切回前台可以正常浏覽

• 4) 鎖屏後再解屏回到應用前台可以正常浏覽

• 5) 在對服務端的資料有更新時會給予離線的相應提示

App更新

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

• 2) 當版本為非強制更新版時，使用者可以取消更新，老版本能正

常使用。使用者在下次啟動app時，仍能出現更新提示。

• 3) 當版本為強制更新版時，當給出強制更新後使用者沒有做更新

時，退出用戶端。下次啟動app時，仍出現強制更新提示。

• 4) 當用戶端有新版本時，在本地不删除用戶端的情況下，直接

更新檢查是否能正常更新。

• 5) 當用戶端有新版本時，在本地不删除用戶端的情況下，檢查

更新後的用戶端功能是否是新版本。

• 6) 當用戶端有新版本時，在本地不删除用戶端的情況下，檢查

資源同名檔案如圖檔是否能正常更新成最新版本。如果以上無

法更新成功的，也都屬于缺陷。

定位、照相機服務

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

• 2) 有用到定位服務、照相機服務的地方，需要進行前背景的切換測

試，檢查應用是否正常。

• 3) 當定位服務沒有開啟時，使用定位服務，會友好性彈出是否允許

設定定位提示。當确定允許開啟定位時，能自動跳轉到定位設定中開

啟定位服務。

• 4) 測試定位、照相機服務時，需要采用真機進行測試。

時間測試

• 用戶端可以自行設定手機的時區、時間，是以需要校驗該設定

對app的影響。

• --中國為東8區，是以當手機設定的時間非東8區時，檢視需要

顯示時間的地方，時間是否展示正确，應用功能是否正常。時

間一般需要根據伺服器時間再轉換成用戶端對應的時區來展示

，這樣的使用者體驗比較好。比如發表一篇微網誌在服務端記錄的

是10：00，此時，華盛頓時間為22：00，用戶端去浏覽時，

如果設定的是華盛頓時間,則顯示的發表時間即為22:00,當時間

設回東8區時間時，再檢視則顯示為10：00。

PUSH測試

• 1) 檢查push消息是否按照指定的業務規則發送

• 2) 檢查不接受推送消息時，檢查使用者不會再接收到push.

• 3) 如果使用者設定了免打擾的時間段，檢查在免打擾時間

段内，使用者接收不到PUSH。

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

• 4) 當push消息是針對登入使用者的時候，需要檢查收到的

push與使用者身份是否相符，沒有錯誤地将其它人的消息

推送過來。一般情況下，隻對手機上最後一個登入使用者進

行消息推送。

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

非功能測試

性能測試

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

– App安裝、解除安裝的響應時間

– App各類功能性操作的影響時間

• 壓力測試：反複/長期操作下、系統資源是否占用異常。

– App反複進行安裝解除安裝，檢視系統資源是否正常

– 其他功能反複進行操作，檢視系統資源是否正常

• 性能評估：評估典型使用者應用場景下，系統資源的使用情況。

• Benchmark測試（基線測試）：與競争産品的Benchmarking, 産品

演變對比測試等。

安全性

• 軟體測試的依據：需求規則說明書

• 軟體安全實作依據：業務需求文檔和系統設計文檔

• 程式編碼安全設計

– 權限控制算法（Private類）

– 資料庫視圖的引用

– 密鑰和加密算法

• 技術方案安全設計

– 驗證碼

– 多重驗證（登入與支付分離、多次密碼輸入）

– 逾時原理（Session、Cookie逾時）

– 密碼安全（密碼鍵盤 ，簡單提示，多重加密）

– *安全證書（CFCA憑證等）

– 關鍵資訊屏蔽（銀行卡号和證件号屏蔽）

– 背景日志管理

軟體權限的安全測試

• 1）扣費風險：包括發送短信、撥打電話、連接配接網絡等

• 2）隐私洩露風險：包括通路手機資訊、通路聯系人資訊等

• 3）對App的輸入有效性校驗、認證、授權、敏感資料存儲、資料加

密等方面進行檢測

• 4）限制/允許使用手機功能接人網際網路

• 5）限制/允許使用手機發送接受資訊功能

• 6）限制/允許應用程式來注冊自動啟動應用程式

• 7）限制或使用本地連接配接

• 8）限制/允許使用手機拍照或錄音

• 9）限制/允許使用手機讀取使用者資料

• 10) 限制/允許使用手機寫人使用者資料

• 11) 檢測App的使用者授權級别、資料洩漏、非法授權通路等

安裝與解除安裝的安全性測試

• 1）應用程式應能正确安裝到裝置驅動程式上

• 2）能夠在安裝裝置驅動程式上找到應用程式的相應圖示

• 3）是否包含數字簽名資訊

• 4）JAD檔案和JAR包中包含的所有托管屬性及其值必需是正确的

• 5）JAD檔案顯示的資料内容與應用程式顯示的資料内容應一緻

• 6）安裝路徑應能指定

• 7）沒有使用者的允許, 應用程式不能預先設定自動啟動

• 8）解除安裝是否安全, 其安裝進去的檔案是否全部解除安裝

• 9）解除安裝使用者使用過程中産生的檔案是否有提示

• 10）其修改的配置資訊是否複原

• 11）解除安裝是否影響其他軟體的功能

• 12）解除安裝應該移除所有的檔案

資料安全性的安全性測試

• 1）當将密碼或其他的敏感資料輸人到應用程式時, 其不會被儲存在裝置中,

同時密碼也不會被解碼

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

• 3）密碼, 信用卡明細, 或其他的敏感資料将不被儲存在它們預輸人的位置上

• 4）不同的應用程式的個人身份證或密碼長度必需至少在4一8 個數字長度之

間

• 5）當應用程式處理信用卡明細, 或其他的敏感資料時, 不以明文形式将資料

寫到其它單獨的檔案或者臨時檔案中。以防止應用程式異常終止而又沒有側

除它的臨時檔案, 檔案可能遭受人侵者的襲擊, 然後讀取這些資料資訊。

• 6）當将敏感資料輸人到應用程式時, 其不會被儲存在裝置中

• 7）備份應該加密, 恢複資料應考慮恢複過程的異常ٯ 通訊中斷等, 資料恢複

後再使用前應該經過校驗

• 8）應用程式應考慮系統或者虛拟機器産生的使用者提示資訊或安全替告

• 9）應用程式不能忽略系統或者虛拟機器産生的使用者提示資訊或安全警告, 更

不能在安全警告顯示前,，利用顯示誤導資訊欺騙使用者，應用程式不應該模

拟進行安全警告誤導使用者

• 10）在資料删除之前，應用程式應當通知使用者或者應用程式提供一個“取

消”指令的操作

• 11）“ 取消” 指令操作能夠按照設計要求實作其功能

• 12）應用程式應當能夠處理當不允許應用軟體連接配接到個人資訊管理的情況

• 13）當進行讀或寫使用者資訊操作時, 應用程式将會向使用者發送一個操作錯誤

的提示資訊

• 14）在沒有使用者明确許可的前提下不損壞側除個人資訊管理應用程式中的

任何内容Μ

• 15）應用程式讀和寫資料正确。

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

• 17）如果資料庫中重要的資料正要被重寫, 應及時告知使用者

• 18）能合理地處理出現的錯誤

• 19）意外情況下應提示使用者

安裝測試

• 1.軟體安裝後的是否能夠正常運作，安裝後的檔案夾及檔案是否寫到

了指定的目錄裡。 （結果檢查）

• 2.軟體安裝各個選項的組合是否正确 （操作）

• 3.安裝過程中進行取消和意外情況處理（當機、重新開機、斷電等）

• 4.安裝後沒有生成多餘的目錄和檔案

• 5.安裝路徑能指定：手機、SD卡

• 6.解除安裝、更新、重複安裝

相容性測試

相容性測試—分辨率

需注意：

• 1.不同公司出的系統：MIUI、Flyme等

• 2.現在比較流行做第三方Launcher，需考慮不同公司出的

Launcher相容性

• 3.與防毒軟體的相容

• 4.注意最新系統與以前版本的差別

測試時可以考慮雲測

如何做相容測試

• 1.多選擇手機排行榜、機型、分辨率、系統來進行綜合考慮

• 2.盡可能多的在不同的機器上測試

– 三星華為魅族小米四大廠商的機器肯定是要過到的，使用者量比較大

• 3.測試在真機下進行，挑選大功能類用例并執行

相容性裝置選擇：市場主流手機裝置

相容性測試自動化

• 1.谷歌是如何做相容性測試自動化的？

– 工具：Android Compatibility Test Suite（簡稱Android CTS

）

– 缺點：局限于官方出的系統

• 2.Emulator（Android-sdk自帶：AVD Manager）

– 缺點：比較理想環境，測試結果僅供參考，價值不大

• 3.雲測平台：testin

– 優點：測試機型很多，可以給出很詳細測試報告

– 缺點：測試結果僅供參考，意義不大

• 總結：工具測試隻能起到一定輔助作用，無法解決真實用

戶場景。

異常測試

• 伺服器異常時穩定性

• 外部事件影響（電話，短信等）

• 記憶體是否有溢出或者洩漏

• 多線程問題

• 是否存在閃退

• 不放SIM卡、不聯網

• 放置不同參數和seed值

• 附：Monkey測試可以測試出80%的崩潰。

專項測試

弱網測試

• 無網絡測試，需要在頁面作請求前關閉移動裝置網絡，觀

察程式是否作友好提示。

• 弱網絡測試要複雜得多，存在以下三種類型：

– 1.頁面等待請求資料，資料傳回後，頁面呈現是否正常；

– 2.頁面在送出請求後，離開該頁面，資料傳回後，程式是否正常處

理，是否會發生crash

– 3.頁面等待請求資料，造成逾時，頁面是否作友好提示

網絡逾時測試

網絡逾時可通過以下方式來實作，根據實際需要來選擇：

• 1.綁定未知伺服器，構成網絡逾時，适用所有類型

• 2.對某類域名作host綁定，适用于越獄機器

• 3.綁定代理伺服器，延時某個請求的時間

• 4.修改程式代碼，改變某個請求的連結

網絡切換測試

• 實際應用場景中，還需要考慮網絡之間的切換，具體切換類型如下：

操作類型測試

• 操作類型測試，應根據自身app的應用場景來進行，比如對于有攝像頭的

app，應根據使用場景來決定掃描、拍攝角度等；對于支援橫豎屏的場景，

要考慮橫豎切換的情況。下表給出了操作類型的測試要點：

其他手勢操作測試

• 手機開鎖屏對運作中的App的影響

• 切換網絡對運作中的App的影響

• 運作中的App前背景切換的影響

• 多個運作中的App的切換

• App運作時關機

• App運作時重新開機系統

• App運作時充電

• App運作時kill掉程序再打開

交叉事件測試

交叉測試又叫事件或沖突測試，是指一個功能正在執行過程

中，同時另外一個事件或操作對該過程進行幹擾的測試。

如：App在前/背景運作狀态時與來電、檔案下載下傳、音樂收聽等關鍵運用

的互動情況測試等。交叉事件測試非常重要，能發現很多應用中潛在的

性能問題。

測試要點：

1、多個App同時運作是否影響正常功能

2、App運作時前/背景切換是否影響正常功能

3、App運作時撥打/接聽電話

4、App運作時發送/接收資訊

5、App運作時發送/收取郵件

6、App運作時切換網絡（2G、3G、4G、WIFI）

7、App運作時浏覽網絡

8、App運作時使用藍牙傳送/接收資料

9、App運作時使用相機、電腦等手機自帶裝置

第三方推送測試

• APP消息推送指的是APP開發者通過第三方工具将自己想要推的消息

推送給使用者，讓使用者被動的接收。

PUSH消息推送原理

更新測試

• 當用戶端有新版本時，有更新提示。

• 當版本為非強制更新版時，使用者可以取消更新，老版本能正常使用。使用者在

下次啟動app時，仍能出現更新提示。

• 當版本為強制更新版時，當給出強制更新後使用者沒有做更新時，退出用戶端

。下次啟動app時，仍出現強制更新提示。

• 當用戶端有新版本時，在本地不删除用戶端的情況下，直接更新檢查是否能

正常更新。

• 當用戶端有新版本時，在本地不删除用戶端的情況下，檢查更新後的用戶端

功能是否是新版本。

• 更新完成之後，使用者資訊是否被清除了。

* 使用者體驗測試

以主觀的普通消費者的角度去感覺産品或服務的舒适、有用、易用、友好親切程

度。通過不同個體、獨立空間和非經驗的統計複用方式去有效評價産品的體驗特性

提出修改意見提升産品的潛在客戶滿意度。

接口測試

服務端一般會提供JSON格式的資料給用戶端，是以我們在服務端需

要進行接口測試，確定服務端提供的接口并轉換的JSON内容正确，對分

支、異常流有相應的傳回值。此塊測試可以采用itest架構進行測試。最

友善的是采用httpclient進行接口測試。

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

(JavaScript Object Notation) 是一種輕量 級的資料交換格

Itest測試架構是 TaoBao測試部門開發的 一套單元測試架構

HttpClient 是 Apache Jakarta Common 下的子項目，可以用來 提供高效的、最新的、功能豐富的 支援 HTTP 協定的用戶端程式設計工 具包，并且它支援 HTTP 協定最 新的版本和建議。

用戶端資料庫測試.

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

• 2） 當表不存在時是否能自動建立，當資料庫表被删除後能否再自建，資料是否還能自動從

服務端中擷取回來并儲存。

• 3） 在業務需要從服務端取回資料儲存到用戶端的時候，用戶端能否将資料儲存到本地。

• 4） 當業務需要從用戶端取資料時，檢查用戶端資料存在時，app資料是否能自動從用戶端

資料中取出，還是仍然會從伺服器端擷取？檢查用戶端資料不存在時，app資料能否自動從

伺服器端擷取到并儲存到用戶端

• 5） 當業務對資料進行了修改、删除後，用戶端和服務端是否會有相應的更新

五、APP用例編寫

APP測試例編寫原則

• 熟悉需求,設計,了解業務

• 測試例命名規則清晰,明了.

• 子產品劃分,測試例編寫具有較強的通用性測試例

• 有明确的測試目的,測試前提條件，優先級别,預期結果

• 好的測試例的要求能夠盡量的覆寫典型的，常用的，異常的場景

– 盡量避免重複測試

– 測試例并非越多越好，測試例的數量應該是，盡可能的發現問題

與盡可能的覆寫功能的最小公倍數

– 測試例的編寫與測試本身一樣，需要不斷完善

APP測試例編寫要求

• 1. 準确:

按所設計的去測試.對需求及設計了解準确,了解軟體及功能特點,積極設想軟體

如何才能失敗,做到盡可能發現錯誤

• 2.不備援:

好的測試例子沒有不必要的步驟,每一個測試都應該有不同的用途, 不會太簡單

，也不會太複雜。通常每個測試例應獨立執行。多個測試例組合，有可能屏

蔽錯誤。最大操作步驟最好控制在10-15步之間,每個測試步驟應該有一個清

晰的輸入或者測試任務,不排除單個測試例子有多個邏輯輸入,需要逐一列舉

輸出結果.

• 3.清晰:

描述清晰,步驟條理清晰,測試層次清晰(由簡而繁,從基本功能測試到破壞性測

試).

• 4.可複用:

無論何時何人測試都能得到同樣的結論,友善移植。

• 5.可追溯性:

針對特定的需求測試.

• 6.适 當:

測試例應該适合特定的測試環境 以及符合整個團隊的測試水準

• 7.可維護性:

好的測試用例應該是可維護的,維護包括添加,删除,更改,特别是對應

需求及功能等變更的維護.象代碼一樣,不需要維護的測試例是不存在

的,在變更過程中未做維護的測試例将失去它應有價值,甚至帶來危害。

測試用例的常見問題

• 單個測試例太長

• 不完善,錯誤,或者雜亂無端的操作步驟

• 關鍵步驟遺漏

• 命名域改變或者不再存在

• 描述不清,測試員或者測試系統不清楚實際要測試的步驟及内容

• 不清楚什麼樣的結果是通過和出錯

• 不友善維護(添加,删除,更改等)

</div><div data-report-view="{&quot;mod&quot;:&quot;1585297308_001&quot;,&quot;dest&quot;:&quot;https://blog.csdn.net/qq646642124/article/details/93370085&quot;,&quot;extend1&quot;:&quot;pc&quot;,&quot;ab&quot;:&quot;new&quot;}"><div></div></div>
            <link href="https://csdnimg.cn/release/phoenix/mdeditor/markdown_views-60ecaf1f42.css" target="_blank" rel="external nofollow"  rel="stylesheet">
                                <div data-report-view="{&quot;mod&quot;:&quot;popu_387&quot;,&quot;dest&quot;:&quot;https://blog.csdn.net/qq646642124/article/details/93370085&quot;,&quot;extend1&quot;:&quot;pc&quot;,&quot;ab&quot;:&quot;new&quot;}"></div>
                    
        <div class="person-messagebox">
            <div class="left-message"><a href="https://blog.csdn.net/qq646642124" target="_blank" rel="external nofollow"  target="_blank" rel="external nofollow" >
                <img src="https://profile.csdnimg.cn/4/1/7/3_qq646642124" class="avatar_pic" username="qq646642124">
            </a></div>
            <div class="middle-message">
                                    <div class="title"><span class="tit "><a href="https://blog.csdn.net/qq646642124" target="_blank" rel="external nofollow"  target="_blank" rel="external nofollow"  data-report-click="{&quot;mod&quot;:&quot;popu_379&quot;,&quot;ab&quot;:&quot;new&quot;}" target="_blank">@流浪地球</a></span>
                    <!-- 等級，level -->
                                            <img class="identity-icon" src="https://csdnimg.cn/identity/blog3.png">                                            </div>
                <div class="text"><span>原創文章 21</span><span>獲贊 9</span><span>通路量 2萬+</span></div>
            </div>
                            <div class="right-message">
                                        <a class="btn btn-sm  bt-button personal-watch" data-report-click="{&quot;mod&quot;:&quot;popu_379&quot;,&quot;ab&quot;:&quot;new&quot;}">關注</a>
                                                            <a href="https://im.csdn.net/im/main.html?userName=qq646642124" target="_blank" rel="external nofollow"  target="_blank" class="btn btn-sm bt-button personal-letter">私信
                    </a>
                                </div>
                        </div>
                    
    </div>