手機app測試要點（複製文）

時間 2019-11-25

標籤手機 app 測試要點複製简体版

原文原文鏈接

1、簡介

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

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

首先必須購買足夠多的手機，包括不一樣操做系統，不一樣版本，不一樣分辨率，甚至不一樣廠商，目前市場上的手機平臺有iOS、Android、Symbian、WP、Blackberry、Linux等（集中度較高的是iOS、Android和WP系統），平臺之間存在較大差別，語言和標準徹底不一樣。以Android爲例，就須要面對Android 1.五、2.0、2.一、2.二、2.三、3.0、4.0七個以上的版本，約十幾種不一樣的分辨率，HTC、摩托、三星、LG、索愛、聯想、中興、華爲…等數十個廠商。一個商業化運做的開發團隊，通常至少須要幾十部手機、終端，才能完成必要的適配工做。若是缺失這個真機系統測試環節，極大可能會給應用的推廣和使用埋下了一個隱患，一旦出問題將直接招致用戶的投訴或拋棄。瀏覽器

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

終端問題以後，就是人員工資的高漲使得不少開發團隊在緊張的預算下優先向產品、運營、技術傾斜，不少成規模的互聯網企業一般只有幾我的的小測試團隊。網絡

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

接下來的問題是，爲了知足用戶旺盛的需求、適應激烈的市場競爭，全部的移動互聯網企業都在拼命地趕工期，開發人員下班前完成的版本、至少但願次日上班的時候可以被測試完成，這就要求測試人員連夜工做，因而咱們能夠看到不少歐美的軟件公司會把測試工做交給中國的外包企業進行。工具

最後，終端、人員、流程等管理問題也很是突出，終端、Bug、人員要在測試、開發、產品、客服、運營等不一樣的部門以前交錯。佈局

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

1.1 什麼是App測試

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

App是基於移動互聯網軟件、及軟硬件環境的應用軟件。App測試就是要找出App中的BUG，經過各類手段和測試工具，判斷App系統是否可以知足預期標準。移動App，因爲增長了終端、外設和網絡等多項元素，於是測試內容和項目也相應增長了。

在App開發過程當中容易出現缺少有效溝通，功能複雜、編程錯誤、需求不斷變動、時間壓力、缺少文檔的代碼、App開發工具、SDK和人員的疏忽等緣由引起的錯誤，經過測試可以發現、找出其中的錯誤，解決錯誤，從而提升App的質量2.

1.2 測試方法

白盒測試

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

黑盒測試

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

人工測試

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

自動化測試

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

UT、 Unit Testing單元測試

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

IT、 Integrate Testing集成測試

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

ST 、System Testing系統測試

定義：App系統測試（App System Testing），是將已經確認的App程序、移動終端、外設、網絡等其餘元素結合在一塊兒，進行信息系統的各類組裝測試和確認測試，系統測試是針對整個產品系統進行的測試，目的是驗證系統是否知足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。App系統測試發現問題以後要通過調試找出錯誤緣由和位置，而後進行改正。

App系統測試是基於系統總體需求說明書的黑盒類測試，應覆蓋系統全部聯合的部件。對象不只僅包括需測試的App軟件，還要包含App軟件所依賴的硬件、外設甚至包括某些數據、某些支持軟件及其接口等，基於本地及不一樣地區、網絡等真實終端，測試、檢查已實現的App是否知足了需求規格說明中肯定了的各類需求，以及App配置是否徹底、正確。

目的：驗證最終App系統是否知足用戶規定的需求。

類型：黑盒測試，測試範圍爲整個系統。

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

系統測試過程：

2. 移動App的系統測試

目前主流的iOS、Android和WP等OS系統以及各平臺，都相應地提供了不一樣程度的單元、集成測試工具，能夠在模擬器、沙箱環境下進行白盒、灰盒測試、調試。

但App存在着大量的軟硬件交互，而這些都須要經過真實的終端經過黑盒測試方法進行系統測試，須要將通過集成測試的軟件，做爲移動終端的一個部分，與系統中其餘部分結合起來，在實際運行環境下對移動終端系統進行一系列嚴格有效地測試，以發現軟件潛在的問題，保證系統的正常運行，驗證最終軟件系統是否知足用戶規定的需求。

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

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

移動互聯網是極快速發展的新興產業，沒有成功經驗可循，只有市場和用戶纔是檢驗你產品是否好壞的終極標準。藉助傳統軟件測試方法和規律，能夠有效地提高App的程序質量和用戶體驗。

冒煙測試（Smoke Testing）

冒煙測試（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/內存等參數等。

功能測試（Functional Testing）

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

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

（1）是否有遺漏需求； 

（2）是否正確的實現全部功能； 

（3）隱示需求在系統是否實現； 

（4）輸入、輸出是否正確。

移動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版本等）。

目標：驗證所有配置的可操做性、有效性，特別須要對最大配置，最小配置和特殊配置進行測試。 

● 操做系統版本的兼容性：測試App在不一樣操做系統版本下是否可以正確顯示與運行； 

● 硬件兼容性：測試與硬件密切相關的App產品與其餘硬件產品的兼容性，是否能夠正確使用； 

● 瀏覽器兼容性：測試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迴歸測試