目錄：

一、簡介 4

備註：引用整理別人作品，非本群原版作品，只提供個人學習，任何商業行為與本群無關。

一、簡介 

     移動應用App已經滲透到每個人的生活、娛樂、學習、工作當中，令人激動、興奮且具有創造性的各種App猶如雨後春筍般交付到使用者手中。各類智慧終端也在快速釋出，而開發者對於全球移動裝置的質量和效能卻掌握甚少，App與裝置的相容性問題常常導致使用者投訴，令開發者十分沮喪，App測試與服務質量保證矛盾十分突出。 

移動開發的一個重要難題，就是應用在開發過程中，必須使用手機真實環境進行系統測試，才有可能進入商用。由於手機作業系統的不同，以及作業系統版本之間的差異，使得真機系統測試這個過程尤其複雜，涉及終端、人員、工具、時間、管理等方面的問題。

 首先必須購買足夠多的手機，包括不同作業系統，不同版本，不同解析度，甚至不同廠商，目前市場上的手機平臺有iOS、Android、Symbian、WP、Blackberry、Linux等（集中度較高的是iOS、Android和WP系統），平臺之間存在較大差異，語言和標準完全不同。以Android為例，就需要面對Android 1.5、2.0、2.1、2.2、2.3、3.0、4.0七個以上的版本，約十幾種不同的解析度，HTC、摩托、三星、LG、索愛、聯想、中興、華為…等數十個廠商。一個商業化運作的開發團隊，一般至少需要幾十部手機、終端，才能完成必要的適配工作。如果缺失這個真機系統測試環節，極大可能會給應用的推廣和使用埋下了一個隱患，一旦出問題將直接招致使用者的投訴或拋棄。  

 其次在拿到不同手機進行測試的時候，還將面臨不同手機廠商的系統版本差異問題，即便是標準統一的Android系統，手機廠商的版本也並非完全相同，MIUI、LePhone、MEIZU，這些Android系統已經加入了很多個性化的東西，導致Android應用必須進行單獨適配。這過程中出現的很多問題，往往沒有資料可查，使開發者雪上加霜。 

 終端問題之後，就是人員工資的高漲使得很多開發團隊在緊張的預算下優先向產品、運營、技術傾斜，很多成規模的網際網路企業通常只有幾個人的小測試團隊。  

 另外，App的真機系統測試在全球範圍內還停留在刀耕火種的純人工狀態，沒有有效的工具可以利用，測試人員發現的Bug很難復現，開發人員因此也很難定位、快速修改Bug。  

接下來的問題是，為了滿足使用者旺盛的需求、適應激烈的市場競爭，所有的移動網際網路企業都在拼命地趕工期，開發人員下班前完成的版本、至少希望第二天上班的時候能夠被測試完成，這就要求測試人員連夜工作，於是我們可以看到很多歐美的軟體公司會把測試工作交給中國的外包企業進行。 

最後，終端、人員、流程等管理問題也非常突出，終端、Bug、人員要在測試、開發、產品、客服、運營等不同的部門之前交錯。 

如何進行卓有成效的App系統測試，以及協調好與之相關的計劃、管理、人員、資源、終端等各個環節，一直是困擾各個App開發企業的問題。   

IEEE定義：使用人工或自動化來測試某個程式，來驗證它是否滿足規定的需求或者實際結果和預期結果之間的差別。 

 App是基於移動網際網路軟體、及軟硬體環境的應用軟體。App測試就是要找出App中的BUG，通過各種手段和測試工具，判斷App系統是否能夠滿足預期標準。移動App，由於增加了終端、外設和網路等多項元素，因而測試內容和專案也相應增加了。 

在App開發過程中容易出現缺乏有效溝通，功能複雜、程式設計錯誤、需求不斷變更、時間壓力、缺乏文件的程式碼、App開發工具、SDK和人員的疏忽等原因引發的錯誤，通過測試能夠發現、找出其中的錯誤，解決錯誤，從而提高App的質量

1.2.1  白盒測試 

依據被測App分析程式內部構造，並根據內部構造設計用例，來對內部控制流程進行測試。

黑盒測試（Black-Box Testing）是基於系統需求規格，在不知道系統或元件的內部結構的情況下進行的測試，把測試物件看作一個黑盒，只考慮整體特性，不考慮內部具體實現。  通常又將黑盒測試叫做：基於規格的測試（Specification-Based Testing）、輸入輸出測試（Input/Output Testing）、功能測試（Functional Testing）。 

測試活動由人來完成，狹義上指測試執行由人工完成。

通過計算機模擬人的測試行為，替代人的測試活動，狹義上指測試執行由計算機來完成。

1.3.1  Unit Testing單元測試 

定義：對App的基本組成單元來進行正確性檢驗。集中對用原始碼實現的每一個程式單元 進行測試，檢查各個程式模組是否正確地實現了規定的功能。  目的：檢測App模組對App產品設計說明書的符合程度。  型別：白盒測試，測試範圍為單元內部的資料結構，邏輯控制，異常處理。 評估標準：邏輯覆蓋率。 

1.3.2  Integrate Testing整合測試 

定義：測試模組或子系統組裝後功能以及模組間介面是否正確，把已測試過的模組組裝起來，主要對與設計相關的App體系結構的構造進行測試。  目的：在於檢測App模組對App產品概要設計說明書的符合程度。  型別：灰盒測試，測試範圍為模組之間介面與介面資料傳遞的關係，以及模組組合後的功能。  評估標準：介面覆蓋率。

定義：App系統測試（App System Testing），是將已經確認的App程式、移動終端、外設、網路等其他元素結合在一起，進行資訊系統的各種組裝測試和確認測試，系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。App系統測試發現問題之後要經過除錯找出錯誤原因和位置，然後進行改正。 

App系統測試是基於系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件。物件不僅僅包括需測試的App軟體，還要包含App軟體所依賴的硬體、外設甚至包括某些資料、某些支援軟體及其介面等，基於本地及不同地區、網路等真實終端，測試、檢查已實現的App是否滿足了需求規格說明中確定了的各種需求，以及App配置是否完全、正確。 

 目的：驗證最終App系統是否滿足使用者規定的需求。 

型別：黑盒測試，測試範圍為整個系統。

評估標準：測試用例對需求規格的覆蓋率。

系統測試過程：

二、移動App的系統測試    

目前主流的iOS、Android和WP等OS系統以及各平臺，都相應地提供了不同程度的單元、整合測試工具，可以在模擬器、沙箱環境下進行白盒、灰盒測試、除錯。 

但App存在著大量的軟硬體互動，而這些都需要通過真實的終端通過黑盒測試方法進行系統測試，需要將經過整合測試的軟體，作為移動終端的一個部分，與系統中其他部分結合起來，在實際執行環境下對移動終端系統進行一系列嚴格有效地測試，以發現軟體潛在的問題，保證系統的正常執行，驗證最終軟體系統是否滿足使用者規定的需求。 

然而，由於OS版本、硬體異常迅猛的發展速度，平臺始終沒有有效地提供符合App黑盒系統測試的工具與方法，大量的移動App測試還停留在純人工狀態，效率十分低下。終端、版本的碎片化，更加劇了這一問題的嚴重性。 

自己開發、或藉助第三方工具、平臺，進行自動化的移動網際網路App系統黑盒測試，是提升效率和測試質量的有效方法。 

移動網際網路是極快速發展的新興產業，沒有成功經驗可循，只有市場和使用者才是檢驗你產品是否好壞的終極標準。藉助傳統軟體測試方法和規律，可以有效地提升App的程式質量和使用者體驗。 

 冒煙測試（Smoke Testing）的物件是每一個新編譯的需要正式測試的App版本，目的是確認軟體基本功能正常，可進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。     

App程式在編寫開發過程中，內部需要多個版本(Builds)，但是隻有有限的幾個版本需要執行正式測試（根據專案開發計劃），這些需要執行的中間測試版本。在剛剛編譯出來後，開發人員需要進行基本效能確認測試，驗證App是否能正確安裝、解除安裝，以及操作過程和操作前後對系統資源的使用情況，針對終端硬體及ROM版本的各維度，與App安裝、解除安裝不適配情況、隱患原因分析報告，最終確認是否可以正確安裝/解除安裝，主要功能是否實現，是否存在嚴重宕機、意外崩潰等Bug。  

如果通過了該測試，則可以根據正式測試文件進行正式測試。否則，就需要重新編譯版本，再次執行版本可接收確認測試，直到成功。  

如果發現問題，就要有效地發現導致問題出現的原因，例如在Android App測試中，某些終端、有時會出現應用程式錯誤需要強行關閉的提示，但又找不到重現這個問題的步驟，這個是App的問題還是系統的問題呢，應該怎麼判斷呢？這通常需要有Log日誌才可以判斷，Andriod App出現Crash的情況，一般有兩方面的原因，如果Log日誌中出現System_server，則為系統問題；如果Log中出現Shutdown VM，代表應用程式的問題；還有一種情況是出現Died，這個是程序死掉導致，包含系統主動殺死的情況。

【Testin Tips】  當一個單元、或程式整體開發編譯完成，開發人員、或測試人員可以在PC上選取被測的App，通過iTestin連線的原型測試終端，自動進行快速的冒煙測試，以驗證App安裝、啟動、基本操作執行、解除安裝等是否正常，測試報告包括各測試項是否成功、特徵截圖、Log日誌、CPU/記憶體等引數等。

2.2    功能測試（Functional Testing）  

功能測試是移動App測試最關鍵的環節，根據產品的需求規格說明書和測試需求列表，驗證產品的功能實現是否符合產品需求規格；  

功能測試的目標主要包括：  ü

 是否有遺漏需求；  ü

是否正確的實現所有功能； ü

隱示需求在系統是否實現； ü

輸入、輸出是否正確。  

移動App的功能測試應側重於所有可直接追蹤到用例、或業務功能和業務規則的測試需求。這種測試的目標是核實資料的接受、處理和檢索是否正確，以及業務規則的實施是否恰當。  

功能測試基於黑盒技術，通過圖形使用者介面 (GUI) 與應用程式進行互動，並對互動的輸出或結果進行分析，以此來核實應用程式及其內部程序。  

【Testin Tips】  通過iTestin Suite連線的本地終端，測試人員可以非常方便地按照測試用例、在終端上進行操作，所有的操作過程、軌跡都會被自動記錄為指令碼，所有操作目標、特徵點的螢幕截圖、Log日誌、CPU/記憶體/網路和其他系統資源引數也都會被詳細的記錄下來，最後形成測試報告。  當功能測試要求涉及到不同地區、不同網路的時候，可以釋出任務到mTestin社群，要求特定地區、特定網路的測試者按照功能測試用例要求進行測試，然後通過報告彙總測試結果

2.3    使用者介面測試（GUI Testing）  

使用者介面 (GUI) 測試用於核實使用者與App之間的互動，包括使用者友好性，人性化測試。  一個好的App要有一個極佳的解析度，而在其他解析度下也都能可以執行。GUI 測試的目標是確保使用者介面會通過測試物件的功能來為使用者提供相應的訪問或瀏覽功能。另外，GUI 測試還可確保 GUI 中的物件按照預期的方式執行，並符合公司或行業的標準。  

GUI測試主要測試在不同解析度下，測試使用者介面(如選單、對話方塊、視窗和其它可視控制元件)佈局、風格是否滿足客戶要求，文字是否正確，頁面是否美觀，文字，圖片組合是否完美，操作是否友好等。  

GUI測試的目標是確保使用者介面會通過測試物件的功能來為使用者提供相應的訪問或瀏覽功能。確保使用者介面符合公司或行業的標準，包括使用者友好性、人性化、易操作性測試。  

【Testin Tips】  通過iTestin Suite完成冒煙測試和功能測試，所有特徵點的截圖都可以快速反饋UI是否正常。 同時，為了更好地測試普通使用者對UI的反饋，可以進行使用者UI測試，找一組人(1組12人，軍隊一個班的建制)，試用你的原型UI，記錄他們的操作軌跡，當然包括嚴重的Bug：  1） 邀請外部使用者在現場通過iTestin Suite連線的終端進行操作。  2） 釋出測試任務到mTestin社群，要求n組使用者按照UI測試要求，通過使用者自己的終端 連線到iTestin進行操作，將完成的任務提交到mTestin社群。  通過此類測試，可以有效地發現不同使用者操作UI上的行為軌跡差異，以判斷UI是否存在設計不恰當、或許要改進的地方。   

2.4     使用者體驗可用性測試（UE Testing）  

使用者體驗可用性測試主要是檢測使用者在理解和使用系統方面到底有多好，是否存在障礙或難以理解的部分。  

使用者體驗可用性的測試方法，一般是通過使用者訪談，或邀請內測、小範圍公測等方式進行，通過不同實驗組的運營結果來判斷是否存在可用性缺陷。但由於缺乏有效的測試工具，必須要大量的測試樣本才能獲得比較真實的測試資料，投入資源較多，測試周期較長。     

【Testin Tips】  參考GUI測試方法，為了更好地測試普通使用者對App UE的反饋，可以進行使用者可用性測試，找n組測試者（1組12人——軍隊一個班的建制，UE測試建議選取最大12組測試者、144人），試用App的原型UE可用性，記錄測試者的操作軌跡，當然包括嚴重的Bug。  1） 邀請外部使用者在現場通過iTestin Suite連線的終端進行操作。  2） 釋出測試任務到mTestin社群，要求n組使用者按照可用性測試要求，通過使用者自己的終 端連線到iTestin進行操作，將完成的任務提交到mTestin社群。  通過此類測試，可以有效地發現不同使用者操作App UE行為軌跡差異，以判斷App的UE是否存在設計不恰當、或許要改進的地方。    

2.5    安全性、訪問控制測試（Security Testing）  

安全性和訪問控制測試側重於安全性的兩個關鍵方面：  

1) 應用程式級別的安全性，包括對資料或業務功能的訪問。

 應用程式級別的安全性可確保：在預期的安全性情況下，主角只能訪問特定的功能或用例，或者只能訪問有限的資料。例如，可能會允許所有人輸入資料，建立新賬戶，但只有管理員才能刪除這些資料或賬戶。如果具有資料級別的安全性，測試就可確保“使用者型別一” 能夠看到所有客戶訊息（包括財務資料），而“使用者二”只能看見同一客戶的統計資料。  

2) 系統級別的安全性，包括對系統的登入或遠端訪問。  系統級別的安全性可確保只有具備系統訪問許可權的使用者才能訪問應用程式，而且只能通過相應的閘道器來訪問。

2.6    效能測試（Performance Testing）  

效能測試用來測試App在真實環境中的執行效能，以及與硬體、網路資源的匹配度，最終度量系統相對於預定義目標的差距，通過極限測試方法，發現系統在極限或惡劣的環境中自我保護能力，主要驗證系統的可靠性。  效能測試測試主要通過以下幾項測試完成。

2.6.1  負載測試（Load Testing）  

負載測試是在一定的軟硬體及網路環境下，通過模擬不同的使用者，執行一種或多種業務，觀察系統在不同負載下的效能表現。在這種測試中，將使測試物件承擔不同的工作量，以評測和評估測試物件在不同工作量條件下的效能行為，以及持續正常執行的能力。  負載測試的目標是確定並確保系統在超出最大預期工作量的情況下仍能正常執行。 此外，負載測試還要評估效能特徵，例如，響應時間、事務處理速率和其他與時間相關的方面。

【Testin Tips】  效能測試可以通過iTestin錄製指令碼，在本地的原型終端上單機進行，也可以在iTestin組成的企業私有云、或Testin終端雲上發起任務。  

2.6.2  強度測試（Stress Testing）  

強度測試是一種效能測試，實施和執行此類測試的目的是找出因資源不足或資源爭用而導致的錯誤。如果記憶體或磁碟空間不足，測試物件就可能會表現出一些在正常條件下並不明顯的缺陷。而其他缺陷則可能由於爭用共享資源（如資料庫鎖或網路頻寬）而造成的。強度測試還可用於確定測試物件能夠處理的最大工作量。  

【Testin Tips】  強度測試可以根據測試要求，通過iTestin錄製指令碼，本地、或通過企業私有云、甚至Testin公有云的終端，非常方便、有效地設定多次執行的次數，自動進行測試，例如選99件商品、加999個好友、上傳9999張照片、支付99999次等等。   

2.6.3  穩定性測試（Stability Testing）  

穩定性測試評價系統在一定負荷情況下，長時間的執行情況。在一定的軟硬體及網路環境中，通過模擬大量的使用者執行多種業務處理大量資料，使系統在極限環境下長時間執行，目的在於尋找系統的失效點。  

【Testin Tips】  穩定性測試可以根據App的產品特徵，非常方便地錄製指令碼，通過本地、私有云、公有云和mTestin群測，快速、有效地完成測試。

2.6.4 基準測試 

基準測試的目的主要是進行與已知系統的比較，包括App之前的版本、參照版本、競品等。 

【Testin Tips】  根據基準測試要求，可以通過iTestin在本地通過同類指令碼的執行，可以有效地判斷不同App基準測試的結果。  

2.6.5  競爭測試 

競爭測試是判斷App競爭使用各種資源（資料紀錄，記憶體等）的情況。 

【Testin Tips】  通過iTestin Suite進行App測試時，所有相關的CPU、記憶體、網路等資源資料都會被記錄下來，用於競爭測試分析。  

2.7 故障轉移和恢復測試（Recovery Testing） 

通過人工干預手段使系統發生軟、硬體異常，通過驗證系統異常前後的功能和執行狀態，達到檢驗系統容錯，排錯和恢復的能力。可確保測試物件能成功完成故障轉移，並能從導致意外資料損失或資料完整性破壞的各種硬體、App或網路故障中恢復。  

故障轉移測試可確保：對於必須持續執行的系統，一旦發生故障，備用系統就將不失時機地“頂替”發生故障的系統，以避免丟失任何資料或事務。  恢復測試是一種對抗性的測試過程。在這種測試中，將把應用程式或系統置於極端的條件下（或者是模擬的極端條件下），以產生故障（例如裝置輸入/輸出 (I/O) 故障或無效的資料庫指標和關健字）。然後呼叫恢復程序並監測和檢查應用程式和系統，核實應用程式或系統和資料已得到了正確的恢復。 

【Testin Tips】  在不涉及電源終端或開關機等狀態下的故障轉移和恢復測試，可以通過iTestin對測試App及終端在測試過程中的各項引數進行記錄，幫助分析、判斷測試結果。   

2.8 相容適配性測試（配置測試Configuration Testing）  

相容適配性測試（配置測試），是核實測試物件在不同的App、硬體配置中的執行情況，測試系統在各種軟硬體配置，不同的引數配置下系統具有的功能和效能。  

在大多數環境中，不同終端、螢幕、OS版本、網路連線的規格都會有所不同，而這些因素都可能執行許多不同的配置環境組合，從而佔用不同的資源（如CPU、記憶體、瀏覽器版本、OS版本等）。  

目標：驗證全部配置的可操作性、有效性，特別需要對最大配置，最小配置和特殊配置進行測試。  ü 

l 作業系統版本的相容性：測試App在不同作業系統版本下是否能夠正確顯示與執行；  ü 

l 硬體相容性：測試與硬體密切相關的App產品與其他硬體產品的相容性，是否可以正 確使用；  ü 

l 瀏覽器相容性：測試App在不同產商的瀏覽器下是否能夠正確顯示與執行。 

2.9 解析度測試  

測試在不同解析度下，介面是否匹配。  

【Testin Tips】  解析度測試可以上傳App到Testin平臺，選取不同解析度的終端，自動進行。  

2.10   網路測試  

在網路環境下和其他裝置對接，進行系統功能，效能與指標方面的測試，保證裝置對接正常。

【Testin Tips】  可以按照網路要求，將測試任務釋出到mTestin社群，測試者通過符合要求網路的測試終端完成測試任務，並上報測試結果到mTestin

2.11   本地化測試  

是指為各個地方開發產品的測試，如英文版、中文版等等，包括程式是否能夠正常執行，介面是否符合當地習俗，快捷鍵是否正常起作用等等，特別測試在A語言環境下執行B語言App（比如在英文環境下執行中文版App）是否正常。  

【Testin Tips】  可以按照本地化語言要求，將測試任務釋出到mTestin社群，測試者通過符合要求語言要求的測試終端完成測試任務，並上報測試結果到mTestin。  

2.12   文字測試  

測試文字是否拼寫正確，是否易懂，不存在二義性，沒有語法錯誤；文字與內容是否由出入等等，包括圖片文字。  

【Testin Tips】  可以按照文字測試的要求，將測試任務釋出到mTestin社群，選取合格的測試者分A/B組進行測試，測試者通過符合要求素質要求的測試終端完成測試任務，並上報測試結果到mTestin。  

此類釋出到mTestin的App測試，存在明顯的“殺蟲劑現象”，即由於測試人員的思路不盡相同，每個人測試的側重點不同，由於都按照測試用例進行測試，但是測試用例一般僅描述系統的一些基本測試項，不會將所有的測試用例方方面面都寫到，有時還需要測試人員的經驗和素質。所以A測試某個產品用了七個工作日，第一天到第四天報出許多bug，但從第五天開始幾乎報不出啥 bug了。七天後換了B，B一下子又測試出一堆bug，不能說A的水平差，只能說該App已經對A產生了抗藥性，這就是測試學中的殺蟲劑現象。所以在測試中每次輪流測試最好安排不同的測試人員進行不同模組測試工作，以避免殺蟲劑現象產生。  

2.13   釋出測試  

主要在App釋出前對說明書、廣告稿等進行測試。  

【Testin Tips】  釋出測試可以由App產品、客服團隊內部測試，或釋出測試任務到mTestin進行測試。

2.13.1 說明書測試  

主要為語言檢查、功能檢查、圖片檢查。  ü 

語言檢查：檢查說明書語言是否正確，用詞是否易於理解； ü 

功能檢查：功能是否描述完全，或者描述了並沒有的功能等； ü 圖片檢查：檢查圖片是否正確。

 2.13.2  宣傳材料測試  

主要測試產品中的附帶的宣傳材料中的語言，描述功能、圖片等。

 2.13.3  幫助檔案測試  

幫助檔案是否正確，易懂，是否人性化 

2.15迴歸測試  

迴歸測試是以上所有測試完成後的一個最為重要的環節，是App釋出、維護階段，對缺陷進行修復後的測試。  

目的是驗證缺陷已經得到修復，檢測是否引入新的缺陷； 流程： 

1）在測試策略制定階段，制定迴歸測試策略； 

2）確定需要回歸測試的版本； 

3）測試版本釋出後，按照迴歸測試策略來執行迴歸測試； 

4）迴歸測試通過，關閉缺陷跟蹤單； 

5）迴歸測試不通過，缺陷跟蹤單返回給開發人員，開發人員重新修改BUG。再次提交給測試人員迴歸測試 

測試策略： 

1）完全重複測試：重新執行前期設計的用例，來確認問題修改的真確性和修改的擴散區域性影響性； 

2）選擇性重複測試： 

a) 覆蓋修改法：針對被修改的部分，選取或重新構造測試用例驗證沒有錯誤再次發 生的選擇方法； 

b) 周邊影響法：該方法包括覆蓋修改法，還要分析修改後對擴散的影響； 

c) 指標達成法：先確定一個達成的指標，基於這種要求選擇一個最小的測試用例集 合。 

【Testin Tips】  由於迴歸測試是各項系統測試的重複，所以通過Testin所提供的各種測試工具與方法仍然是適合的，之前測試錄製的指令碼可以繼續使用。根據迴歸測試的終端、可以分解任務執行。