- 移動測試教程
- 移動測試 - 首頁
- 移動測試 - 概述
- 移動測試 - 平臺
- 移動測試 - 裝置型別
- 原生應用 vs 混合應用 vs 移動網頁
- 移動測試 - 裝置 vs 應用
- 模擬器 vs 模擬環境
- 移動測試 - 應用
- 移動測試 - UI
- 移動測試 - 計劃與工具
- 硬體視角
- 移動裝置測試 - 型別
- 移動測試 - 框架概述
- 移動測試 - Android 框架
- 移動測試 - IOS 框架
- Robotium 框架
- Selendroid 框架
- 移動測試 - Appium 框架
- 移動測試 - Zucchini 框架
- 移動測試有用資源
- 移動測試 - 快速指南
- 移動測試 - 有用資源
- 移動測試 - 討論
移動測試 - 快速指南
移動測試 - 概述
在我們開始實際教程之前,讓我們先來點樂趣。看看下面的列表。您可以輕鬆地將這些日常必須面對的重要事務與當今忙碌而緊張的生活方式聯絡起來:
我想支付我的電費賬單。
我需要緊急與我的經理溝通並提交我的報告。
我想為我的孩子買新衣服,但我沒有時間去商店。
哦……現在是晚上 10 點;我的航班要遲到了。我的計程車在哪裡?
我第一次來到這座城市;我應該預訂哪家酒店?
現在回答你自己。在幾秒鐘內執行這些活動需要什麼?答案是:
- 智慧手機,
- 網際網路連線,以及
- 一個可以完成工作的移動應用程式。
這讓我們認識到移動應用程式在當今時代的意義。一切都透過你的智慧手機以一種智慧的方式完成。每天,我們都會了解到有新的應用程式或工具推出,以使我們的生活更輕鬆。
有一個關於Gowalla的著名案例。數百萬人享受了這個基於位置的社交網路,該網路於 2007 年啟動,五年後關閉。多個問題阻礙了 Gowalla 達到大眾吸引力。其中一個主要原因是“簽到並不那麼使用者友好”。
要擁有一個成功的移動應用程式,我們需要了解開發一個漂亮的移動應用程式並不是唯一的需求。為了獲得使用者的喜愛,需要對移動應用程式進行徹底的測試。畢竟,是使用者體驗使任何軟體都取得成功。
移動測試 - 平臺
在開始進行移動測試之前,建議先了解移動平臺的基礎知識。它主要包括移動的作業系統、裝置型別和移動應用程式型別。充分了解這些方面將有助於我們在長遠規劃中進行穩健的測試計劃。
移動作業系統
下表概述了市場上一些流行的移動作業系統:
| 作業系統 | 開發商 | 流行度(低、中、高) | 最新可用版本 |
|---|---|---|---|
| Android | Google Inc | 高 | Lollipop,Android 5.0-5.1 |
| iOS | Apple Inc | 高 | iOS 8.X |
| Blackberry | Blackberry Ltd | 低 | Blackberry 10.2.1 |
| Windows | Microsoft Inc | 中 | Windows 10 Mobile |
| Symbian | Symbian Foundation | 低 | 已停產 |
根據一些通用調查,市場上不同作業系統的使用情況如下圖所示。
移動測試 - 裝置型別
移動裝置通常是手持式電腦。根據其特性,如物理尺寸、硬體和軟體功能、用途等,它們有許多變體。
請查看下錶。它根據平板電腦、電子書閱讀器和智慧手機的特性對它們進行了區分。
| 裝置 | 平板電腦 | 電子書閱讀器 | 智慧手機 |
|---|---|---|---|
| 是什麼 | 平板電腦是行動式電腦裝置。與傳統電腦不同,它們沒有鍵盤或滑鼠,但整個螢幕都是觸控敏感的。 | 電子書閱讀器(也稱為電子閱讀器)類似於平板電腦,但它們主要用於閱讀電子書(數字、可下載的書籍)。 | 智慧手機是一款功能強大的手機,除了提供電話服務外,還旨在執行各種應用程式。 |
| 用途 | 幾乎所有我們可以用傳統電腦或臺式電腦完成的工作。 | 閱讀電子書 | 網頁瀏覽、觀看影片、閱讀電子書和玩遊戲 |
| 示例 | 三星平板電腦 | 亞馬遜 Kindle、Barnes & Noble Nook。 | 索尼智慧手機、三星智慧手機、蘋果 iPhone。 |
原生應用 vs 混合應用 vs 移動網頁
在進行測試計劃時,您必須考慮的一個關鍵因素是檢查移動應用程式型別。您主要會遇到三種類型的移動應用程式:移動網頁、原生應用程式和混合應用程式。分類是基於開發工作和應用程式再分發策略。讓我們詳細瞭解一下每一種。
移動網頁
網頁應用程式不是真正的應用程式;它們實際上是在您的智慧手機上藉助網頁瀏覽器開啟的網站。在所有主要型別的應用程式中,移動網站的使用者範圍最廣。
示例 - 教程點
優勢 -
易於訪問。
易於開發 - 開發響應式設計並重組內容以便在較小的螢幕/硬體上正確顯示,將使任何桌面網站都對移動裝置友好。
易於更新 - 只需在一個位置更新,所有使用者都可以自動訪問網站的最新版本。
與原生應用程式或混合應用程式相比,無需安裝。
缺點 -
移動網站無法使用某些功能。例如,網站無法訪問檔案系統和本地資源。
許多現有的網站不支援離線功能。
使用者不會在其主螢幕上將應用程式圖示作為持續提醒。網站只能在網頁瀏覽器中開啟。
雖然原生應用程式和混合應用程式會出現在 App Store 和 Google Play 上,但網頁應用程式不會。因此,再分發並不那麼明智。
原生應用
原生應用程式是專門為一個平臺開發的。它可以透過應用程式商店(例如 Google Play 商店或 Apple 的 App Store)安裝。
示例 - Whatsapp、Facebook。
優勢 -
原生應用程式駐留在裝置上,並透過裝置主螢幕上的圖示訪問。
它們可以充分利用所有裝置功能 - 它們可以使用攝像頭、GPS、加速計、指南針、聯絡人列表等。它們還可以整合手勢(標準作業系統手勢或新的應用程式定義的手勢)。
原生應用程式可以使用裝置的通知系統,並且可以在離線狀態下工作。
釋出者可以使用推送通知,在釋出新內容或需要使用者注意時提醒使用者。
原生應用程式維護每個作業系統的 UI 設計,因此它們提供最佳的使用者體驗。例如,原生應用程式可以在 Android 中具有左對齊的標題,在 iOS 中具有居中對齊的標題。
易於再分發,因為它存在於應用商店中。
缺點 -
構建應用程式的成本較高:為一個平臺開發的原生應用程式不會在另一個平臺上執行。為 Android 構建的應用程式不會在 iOS 上執行。我們需要為 iOS 構建一個完全不同的應用程式。由於這個原因,我們需要維護應用程式的多個版本。
即使您可能釋出了原生應用程式,您也希望保持移動網站的良好維護,因為移動裝置帶來了更多流量。因此維護成本更高。
混合應用
混合應用程式是將現有網站內容以應用程式格式呈現的一種方式。它們可以很好地描述為網頁應用程式和原生應用程式的混合體。
示例 - Instagram、維基百科。
優勢 -
開發混合應用程式比開發原生應用程式更便宜。它可以跨平臺構建,即降低應用程式開發成本。
維護簡單,因為沒有太多版本需要維護。
它可以利用裝置中的一些可用功能。
它可以在 App Store 中找到,這使得分發變得容易。
它僅在應用程式內嵌入了瀏覽器。
缺點 -
與原生應用程式相比,圖形不太適應作業系統。
混合應用程式比原生應用程式慢。
移動測試 - 裝置 vs 應用
裝置測試
這種型別的測試通常是為了確保移動裝置的質量。測試包括移動裝置的硬體和軟體測試。這裡我們將討論通常在移動裝置上執行的不同型別的測試。
單元測試
單元測試是一個測試階段,在此階段測試移動裝置開發的部分內容,通常由開發人員進行。它可能包含硬體測試、軟體測試和機械測試。
工廠測試
工廠測試是對移動裝置進行的一種健全性檢查。它是自動執行的,以驗證製造或組裝過程中是否存在缺陷。它主要包括以下測試:
- 移動應用程式測試
- 硬體測試
- 電池(充電)測試
- 訊號接收
- 網路測試
- 協議測試
- 手機遊戲測試
- 移動軟體相容性測試
認證測試
認證測試是在移動裝置上市前的檢查。
應用測試
移動應用程式測試是一個過程,透過該過程,為手持式移動裝置開發的應用程式軟體對其功能、可用性和一致性進行測試。可以在移動裝置上執行不同型別的測試。例如,
- 功能測試
- 實驗室測試
- 效能測試
- 記憶體洩漏測試
- 中斷測試
- 可用性測試
- 安裝測試
- 認證測試
- 安全測試
要點
裝置測試通常是為了檢查移動裝置本身,而移動應用程式測試則涉及對將在所選裝置上執行的應用程式進行測試。
當我們稱之為裝置測試時,硬體測試就成為其中的一部分。在移動應用程式測試的情況下,這取決於具體情況,即如果被測應用程式需要硬體整合,則將涉及硬體測試。
移動裝置測試和移動應用程式測試都可以實現自動化。
移動測試 - 模擬器 vs 模擬環境
在移動測試的情況下,有一件事是不言而喻的。要執行移動測試,您需要一個移動裝置。這是為了瞭解我們的產品在給定的手機上將如何工作和顯示。
假設我們正在開發一個機票預訂系統的應用程式。產品完全開發完成後,作為移動測試的一部分,我們需要檢查該應用程式是否按預期在所有主要使用的裝置上工作,例如 Android 手機、iOS、Blackberry 手機以及其他不同型別的平板電腦和 iPad。
為了進行這種檢查,我們需要獲取每個此類裝置,然後才能檢查應用程式是否按預期執行。沒錯,作為產品負責人,你會發現採購如此大量的移動裝置並進行測試非常昂貴。那麼是否有任何更智慧的替代方案呢?
解決這個問題的方法是使用移動模擬器和移動模擬器。這些主要是旨在為智慧手機的重要功能提供模擬的軟體程式。它們本質上非常相似,因此有時它們可以互換使用。
讓我們比較一下在模擬器/模擬器上進行測試與在真實裝置上進行測試的不同之處:
| 真實裝置 | 模擬器/模擬器 | |
|---|---|---|
| 價格 | 獲取真實裝置的成本很高。 | 幾乎免費,我們只需要下載並安裝它們即可。 |
| 處理速度 | 它具有更快的處理速度;但是網路延遲可能是正常的。 | 與實際裝置相比,它速度較慢。觀察到它比連線到本地網路或雲中的真實裝置的延遲更低。 |
| 除錯 | 除錯並不容易。 | 它提供了應用程式的逐步除錯。此外,它還提供了一種高效的捕獲螢幕截圖的方法。 |
| Web 應用測試 | Web 應用程式可以以常規方式進行測試。 | 測試 Web 應用程式要容易得多。 |
| 可靠性 | 在真實裝置上進行測試的主要優勢在於它始終提供準確的結果。 | 它無法模擬所有型別的使用者互動;因此有時可能導致錯誤的結果。因此,在可靠性方面得分較低。 |
模擬器/模擬器無法模擬以下功能:
- 移動裝置電池
- 移動裝置的攝像頭
- 難以模擬來電和簡訊等中斷。
- 移動裝置記憶體使用情況的模擬不太真實。
現在讓我們更深入地瞭解移動模擬器和移動模擬器。兩者之間存在一些特定的差異。下表列出了模擬器和模擬器之間的主要區別。
| 模擬器 | 模擬器 | |
|---|---|---|
| 模擬物件 |
移動裝置軟體 移動裝置硬體 移動作業系統 |
裝置的內部行為。 它不模擬硬體。 |
| 獲取方式 | 通常由裝置製造商提供。 | 通常由裝置製造商或其他公司提供。 |
| 內部結構 | 它是用機器級組合語言編寫的。 | 它是用高階語言編寫的。 |
| 除錯 | 更適合於除錯。 | 不適合除錯目的。 |
| 效能 | 模擬器速度非常慢。模擬實際硬體通常會導致軟體執行速度比原生執行慢。 | 比模擬器快。 |
| 示例 | Google 的 Android SDK | Apple 的 iOS 模擬器 |
那麼,哪種選擇最適合移動測試?最佳實踐表明,在實際開發過程中,我們應該使用模擬器或模擬器。在最終確定產品之前,應該使用選定的真實裝置進行健全性檢查。例如,Android 智慧手機使用者數量眾多,因此明智的選擇是對最新的 Android 裝置進行健全性檢查,並在模擬器上進行迴歸測試。
移動測試 - 應用
移動應用程式測試的簡單定義如下:“**移動應用程式測試**是一個過程,透過該過程,為手持移動裝置開發的**應用程式軟體**將對其功能、可用性和一致性進行測試。移動應用程式測試可以是自動化或手動型別的測試。”
**注意** - 為了更好地理解,我們將假設我們正在測試一個用於線上機票預訂系統的移動應用程式。
功能測試
功能測試是任何應用程式最基本的測試,以確保它按定義的要求工作。與其他基於使用者介面的應用程式類似,移動應用程式在使用者場景中需要大量的使用者互動。
示例測試場景:
驗證僅在選定的日期顯示所選出發地目的地的航班可用性。
驗證搜尋結果中不包含過去的日期。
相容性測試
在移動應用程式測試中,相容性測試佔據了最高的位置。一般來說,移動應用程式相容性測試的目的是確保應用程式的關鍵功能在特定裝置上按預期執行。相容性測試本身只需要幾分鐘,並且可以提前做好計劃。
決定在哪些移動裝置上執行相容性測試並非易事(因為使用所有可用裝置進行測試幾乎是不可能的)。因此,請準備一個包含所有可能組合的測試矩陣,並由客戶對其進行優先順序排序。
示例測試場景:
- 驗證使用 Android 裝置是否可以成功執行航班搜尋。
- 驗證使用 Apple iPad 是否可以成功執行航班搜尋。
本地化測試
如今,大多數應用程式都設計用於全球使用,因此關注區域差異(如語言、時區等)非常重要。當有人更改時區時,驗證應用程式的功能非常重要。必須考慮到,有時西方設計可能不適合東方國家的受眾,反之亦然。
示例測試場景:
驗證當我們使用不同語言(或非英語語言)的移動應用程式時,是否存在 UI 或資料截斷問題。
驗證您的移動應用程式是否能夠優雅地處理時區更改。
實驗室測試
實驗室測試通常由網路運營商執行,方法是模擬整個無線網路。執行此測試是為了找出移動應用程式在使用語音和/或資料連線執行某些功能時是否存在任何故障。
示例測試場景:
驗證客戶與支援人員進行語音聊天時是否存在任何故障。
效能測試
移動效能測試涵蓋客戶端應用程式效能、伺服器效能和網路效能。確保效能測試場景涵蓋所有這些領域非常重要。藉助效能測試工具,在給定的預定義負載和事務組合下,識別現有網路、伺服器和伺服器端應用程式瓶頸並不困難。
示例測試場景:
驗證航班可用性檢查是否僅花費合理的時間。
驗證在檢查航班可用性期間,手機是否正常執行且不會掛起。
壓力測試
壓力測試是必不可少的,它可以發現功能和使用者介面測試期間可能未被發現的異常、掛起和死鎖。以下是壓力測試的一些標準:
儘可能多地載入應用程式資料,以嘗試達到其斷點。
重複執行相同的操作。
以不同的速度重複執行操作 - 非常快或非常慢。
讓應用程式執行很長時間,既與裝置互動,又讓它保持空閒狀態,或者執行一些需要很長時間的自動任務,例如幻燈片。
隨機嚮應用程式傳送螢幕點選和按鍵。
在裝置上執行多個應用程式,以便您可以經常在應用程式和其他裝置應用程式之間切換。
示例測試場景:
- 檢查 1000 名使用者是否正在訪問移動應用程式以搜尋國內航班。
- 檢查 1000 名使用者是否正在訪問移動應用程式以搜尋國內航班。
安全測試
駭客攻擊漏洞、身份驗證和授權策略、資料安全、會話管理和其他安全標準應作為移動應用程式安全測試的一部分進行驗證。應用程式在透過網路對使用者進行身份驗證時應加密使用者名稱和密碼。
測試與安全相關的場景的一種方法是將移動裝置的資料透過像 OWASP Zed Attack Proxy 這樣的代理伺服器路由,並查詢漏洞。
示例測試場景:
驗證應用程式是否無法在兩個不同的移動裝置上使用相同的使用者憑據進行操作。
驗證如果會話在 15 分鐘內保持不活動狀態,是否會自動過期。
記憶體洩漏測試
與其他計算機相比,移動裝置的記憶體非常有限,並且移動作業系統具有預設行為,即終止使用過量記憶體並導致使用者體驗不佳的應用程式。
記憶體測試對於移動應用程式來說非常重要,以確保每個應用程式在整個使用者旅程中都能保持最佳化的記憶體使用情況。建議我們在實際目標裝置上進行記憶體測試,因為系統架構從模擬器到實際裝置是不同的。
示例測試場景:
執行十次航班可用性檢查,並記錄每次檢查的記憶體使用情況的增加。
使應用程式執行十分鐘,並觀察記憶體使用情況是否保持穩定。
功耗測試
不同移動裝置使用多種型別的電池(即鎳鎘/鋰離子/鎳金屬混合動力)。當我們專注於功耗測試時,需要在每個活動級別測量電池的狀態。這將使我們更好地瞭解單個應用程式的功耗。
功耗測試可以手動完成;市場上也有一些免費工具可用,例如 Trepn Profiler、Power Tutor 和 Nokia Energy Profiler。這些應用程式可以在智慧手機或平板電腦上顯示即時功耗。
示例測試場景:
使用移動應用程式搜尋航班可用性,並檢查功耗是否保持在最低水平。
使移動應用程式處於理想狀態;驗證在應用程式沒有活動發生時是否存在功耗。
中斷測試
應用程式在執行過程中可能會遇到一些中斷,例如來電或網路覆蓋中斷和恢復。這可以再次區分以下情況:
- 傳入和傳出簡訊和彩信
- 傳入和傳出電話
- 傳入通知
- 電池取出
- 資料傳輸的電纜插入和拔出
示例測試場景:
驗證接收來電後航班可用性檢查是否會暫停並恢復。
驗證使用者是否可以在使用應用程式時拒絕電話,並在之後恢復使用同一應用程式。
可用性測試
可用性測試根據以下三個標準評估目標受眾的應用程式:
**效率** - 指定使用者在特定環境中實現指定目標的準確性和完整性。
**有效性** - 與實現目標的準確性和完整性相關的資源支出。
**滿意度** - 工作系統對其使用者和其他受其使用影響的人員的舒適度和可接受性。
在應用程式設計的早期階段就建立可用性測試非常重要,並且不應僅在應用程式完成後才進行。可用性測試需要大量使用者的參與,其結果可能會影響應用程式的設計,而這在專案的後期階段很難更改。
示例測試場景:
- 航班可用性檢查應在主頁上。
- 贊助廣告不應顯示在內容中間。
安裝測試
安裝測試驗證安裝過程是否順利進行,而無需使用者遇到任何困難。
示例測試場景:
- 驗證安裝過程是否流暢且耗時不長。
- 驗證透過企業應用商店安裝是否成功。
解除安裝測試
解除安裝測試的基本原理可以用一句話概括為“解除安裝應立即清除與應用相關的所有資料”。
示例測試場景:
驗證解除安裝後所有與應用程式相關的檔案是否已成功刪除。
如果應用程式儲存媒體檔案(如 WhatsApp 或 Facebook),則即使在解除安裝應用程式後也要保留這些檔案。
更新測試
我們需要注意移動應用程式更新。人們經常抱怨應用程式在更新後無法令人滿意地工作。因此,在更新測試中,我們必須確保應用程式能夠像以前一樣工作非常重要。簡而言之,它不應該破壞任何東西。移動應用程式更新可以透過兩種方式進行:**自動更新**和**手動更新**。
示例測試場景:
- 驗證自動更新後應用程式是否成功執行。
- 驗證更新進度是否正確顯示。
認證測試
要獲得合規性證書,每個移動裝置都需要根據不同移動平臺設定的指南進行測試。
示例測試場景:
驗證應用程式安裝在 iPhone 上時是否符合 iOS 手機的策略。
驗證應用程式安裝在 Android 上時是否符合 Android 手機的策略。
移動測試 - UI
假設我們正在使用一個移動應用程式,有趣的是,您遇到了以下情況:
- 按鈕對齊丟失。
- 文字被截斷。
- 日曆控制元件被裁剪。
這確實是任何使用者都不愉快的體驗。為了確保我們為使用者提供卓越的體驗,強烈建議進行移動 UI 測試。
測試計劃中首先要探索的領域是使用者介面。作為測試人員,您的工作是確認您的應用程式是否滿足某些期望,例如:
- 裝置的整體配色方案/主題
- 圖示的樣式和顏色
- 頁面載入時的進度指示器
- 選單及其呼叫方式以及它們通常包含的專案
- 此裝置上應用程式的整體響應能力
讓我們更深入地討論移動 UI 測試的基礎知識。
螢幕方向/解析度
Web 內容需要在各種裝置和網路條件下都能提供良好的外觀和感受。通常,最好在常用螢幕解析度下測試您的網頁,以確保您的頁面可用。
如果您使用多列布局,您可能還需要檢查列是否正確對齊,並且在訪問者解析度較低時仍然可見。瞭解標準螢幕解析度也很重要:
- 640 × 480
- 800 × 600
- 1024 × 768
- 1280 × 800
- 1366 × 768
- 1400 × 900
- 1680 × 1050
可用工具
市場上有很多工具可以使移動 UI 測試更流暢、更簡單。例如:
- Google Chrome 擴充套件程式
- Screenfly
- BrowserStack
讓我們進一步瞭解這些工具及其用途。
Google Chrome 擴充套件程式
這是 Google Chrome 網路瀏覽器提供的一項免費功能。我們在此提供了使用 Google Chrome 擴充套件程式測試移動 Web 的分步說明:
**步驟 1** - 在“Google Chrome 網路瀏覽器”中開啟要測試的網站。
**步驟 2** - 按 F12。它將開啟開發者工具視窗,如下面的螢幕截圖所示。
**步驟 3** - 點選類似移動裝置的圖示。請參考下面的螢幕截圖。
**步驟 4** - 選擇要測試網站的移動裝置。您可以選擇不同的可用裝置來進行 UI 驗證。
Screenfly
Screenfly 是一款免費且易於使用的工具。要使用它,您只需在網路瀏覽器中輸入Quirktools。您將看到以下螢幕。
輸入要測試的網站並點選**Go**。選擇您想檢視網站的移動裝置。
BrowserStack
這是另一個用於執行移動 UI 測試的強大工具。它提供極佳的結果。雖然它是一個付費工具,但您可以透過使用有效的電子郵件地址在BrowserStack上註冊來獲得免費試用。
觸控式螢幕
多點觸控與單點觸控螢幕
如果您的裝置和應用程式支援多點觸控功能(例如 iPhone 上的捏合縮放效果),請確保包含大量涉及同時觸控式螢幕幕多個位置的測試用例,尤其是在使用軟鍵盤輸入時。
長觸控與短觸控
雖然觸控式螢幕裝置上沒有雙擊的概念(儘管可以實現,如果在您的應用程式中專門實現),但某些裝置(如 Android 智慧手機)區分長觸控和短觸控。按住某個專案會使其在螢幕中間顯示上下文選單,而短按同一專案將自動執行該上下文選單中的第一個操作。
按鈕大小和位置
確保按鈕和圖示足夠大,並且離螢幕邊緣足夠遠,以便大拇指可以輕鬆點選。
軟鍵和硬鍵
軟鍵盤
通常,一些特殊情況和極端情況對終端使用者很重要。
如果使用者的主要操作是輸入一些文字,軟鍵盤是否會自動出現?
如果突出顯示的欄位用於輸入電子郵件地址,軟鍵盤的第一層是否包含快捷鍵“@”和“.com”鍵?
是否可以輕鬆地隱藏和重新顯示軟鍵盤?
軟鍵盤和硬鍵盤是否可以互換使用(如果裝置同時具有兩者)?
硬鍵
確保在使用裝置提供的硬鍵(如開始、主頁、選單和返回)時進行大量測試。它們都應該與您的應用程式互動,就像它們與裝置的原生應用程式互動一樣。
軌跡球、滾輪和觸控板
如果您的裝置沒有觸控式螢幕,那麼驗證螢幕導航對使用者儘可能流暢就更加重要。在這種情況下,使用者可能依靠軌跡球、滾輪或觸控板在物件之間移動。
移動測試 - 計劃與工具
測試手機、平板電腦和電子閱讀器等移動裝置需要特殊的裝置和方法。由於傳統的桌面螢幕截圖軟體無法充分捕獲觸控互動,因此可用性從業人員一直使用戰略性放置的攝像頭來記錄這些移動裝置上的可用性測試互動。
準備執行移動裝置測試
用於在手機、平板電腦和電子閱讀器上進行可用性測試的方法和裝置仍在不斷發展。在計劃移動裝置測試時,您應牢記以下幾點:
**您的時間框架和預算。** 充分了解時間框架和預算將幫助您根據您的需求確定哪些流程和裝置最有效。
**空間的物理設定以及您將如何捕獲測試。** 這可能從較低保真度的佈置到使用專門的平臺和攝像頭裝置,或者可能使用眼動追蹤軟體。
**您的目標受眾和裝置。** 使用網路分析來檢查有多少移動使用者訪問網站、他們使用什麼裝置以及他們的作業系統。瞭解這些資訊將幫助您知道要測試哪些裝置。
測試計劃後要涵蓋的另一個重要方面是**測試裝置管理**。在一個大型組織中,處理移動裝置測試需要一種明智的方法來保護組織的機密資料。為此,您將需要安全軟體。在下一節中,我們將進一步瞭解裝置管理工具。
裝置管理工具
移動裝置管理 (MDM) 是一種 IT 中使用的安全軟體,用於監控、管理和保護跨多個移動服務提供商和多個移動作業系統在組織中部署的員工的移動裝置。
MDM 通常與其他安全服務和工具(如移動應用程式管理)結合使用,以建立完整的移動裝置和安全企業移動管理解決方案。
市場上有許多工具可以完成這項工作。下表概述了一些流行的工具及其功能。
| 產品 | BlackBerry MDM | Citrix MDM | Dell MDM | IBM MDM | MobileIron MDM | SOTI MDM |
|---|---|---|---|---|---|---|
| Android | 2.3+ | 是 | 是 | 是 | 2.3 至當前 | 是 |
| iOS | 5.0+ | 是 | 是 | 是 | 4.0 至當前 | 是 |
| Windows Phone | BES10 否(BES12 適用於 WP 8+) | 是 | 是 | 是 | 7 至當前 | 是 |
| BlackBerry | 是,BBOS,BlackBerry 10 | 是 | 否 | 是 | 10(透過 ActiveSync) | 否 |
| Symbian | 否 | 是 | 否 | 是 | 否 | 否 |
| Windows OS | 否 | 是 | 是 | 是 | 8.1 RT/Pro | 否 |
| Mac OSX | 否 | 即將推出 | 是 | 是 | Lion、Mountain Lion | 是 |
| 其他 | 否 | Windows Mobile | 無 | Office 365、Gmail、Lotus | 無 | Windows Mobile、CE、嵌入式 |
| 配置/停用 WiFi | 是 | 是 | 是 | 是 | 是 | 是 |
| 裝置加密 | 是 | 是 | 是,取決於裝置型別 | 是 | 是 | 是 |
| 電子郵件加密 | 是 | 是 | 是,取決於裝置型別 | 是 | 是 | 是 |
| 多因素身份驗證 | 是 | 是 | 否 | 是 | 是 | 是 |
| 惡意軟體檢測 | 否 | 否 | 否 | 是 | 與合作伙伴整合時是 | 是 |
| 防火牆 | 是 | 否 | 否 | 是 | 與合作伙伴整合時是 | 是 |
| 將使用者資料與公司資料分開 | 是 | 是 | 是 | 是 | 是 | 是 |
移動測試 - 硬體視角
在我們繼續進行實際的移動裝置測試之前,深入瞭解移動裝置硬體架構非常重要。這將有助於我們在實際進行移動裝置/移動裝置應用程式測試時更好地進行測試計劃。讓我們看一下移動裝置硬體的不同特性。
硬體元件
如果您拿任何一部手機,它大多包含以下部件。
電路板
它可以被視為手機的大腦,控制著手機的所有活動。
觸控式螢幕顯示
觸控式螢幕是智慧手機的重要組成部分。觸控式螢幕識別您在螢幕上放置手指或觸控筆的位置,並將座標相應地傳達給手機 CPU。
觸控式螢幕主要有兩種型別:
電阻式觸控式螢幕 − 它有兩層(由一個微小的間隙隔開),形成螢幕上的覆蓋層。當手指放置在螢幕上的任何一點時,這兩層形成接觸,並獲得座標。這種觸控式螢幕相對便宜,因此在大多數預算手機上都能找到。缺點是需要一定的壓力才能註冊觸控。隨著時間的推移,螢幕會發生一定程度的損壞。
電容式觸控式螢幕 − 整個螢幕都塗有一層電容性物質,該物質儲存一定量的電荷。當像手指這樣的導電物體放置在螢幕上時,該點上的電容會發生變化,從而獲得座標。電容式觸控式螢幕在寒冷的氣候下反應不佳,因為人手指不會導致電容發生變化,因此在這種情況下建議使用觸控筆。還有一些多點觸控觸控式螢幕,幾乎可以精確地識別所有手指。這導致了可以在觸控式螢幕上執行的手勢數量增加。
儲存卡
儲存卡有不同的尺寸和容量。它們被廣泛用作資料儲存裝置來儲存數字資訊。
SIM 卡
SIM 卡提供個人移動性,以便使用者無論終端位置和使用特定終端與否,都可以訪問所有已訂閱的服務。您需要將 SIM 卡插入另一部 GSM 手機才能在該手機上接聽電話、從該手機撥打電話或接收其他已訂閱的服務。
電池
智慧手機使用各種不同的電池,具體取決於手機的製造商、尺寸和功能。對於那些嚴重依賴智慧手機的人來說,電池的續航時間越長越好。這樣可以避免頻繁充電,並且可以降低在最需要的時候沒電的可能性。
iOS 裝置 UDID
每個 iPhone 或 iPod Touch 都有一個唯一的裝置識別符號 (UDID),它是由 40 個字母和數字組成的序列,特定於您的裝置。它就像序列號,但更難以猜測。它看起來像這樣:2b6f0cc904d137be2e1730235f5664094b831186。
如何找到您的 UUID?
- 將您的 iOS 裝置連線到您的電腦。
- 開啟 iTunes。
- 在 iTunes 中,單擊左側欄“裝置”下方的裝置名稱。
- 在視窗的主部分單擊裝置的序列號一次。
- 序列號應更改為裝置的 UDID。
iOS 配置檔案
配置檔案是一組數字實體,它將開發人員和裝置唯一地繫結到授權的 iPhone 開發團隊,並允許裝置用於測試。必須在您希望在其上執行應用程式程式碼的每個裝置上安裝開發配置檔案。
如何為 iOS 建立配置檔案?
執行 Google Chrome、Mozilla Firefox 或 Safari。
在 iOS 開發中心,點選證書、識別符號和配置檔案。
在 iOS 應用面板中,點選配置檔案。
點選 +。
選擇 iOS 應用開發,然後點選繼續。
選擇要與配置檔案關聯的 App ID,然後點選繼續。
要能夠跨多個應用使用一個開發配置檔案,請選擇一個萬用字元 App ID(如果可用)。
選擇要包含在配置檔案中的一個或多個開發證書,然後點選繼續。
僅列出開發證書。
選擇要包含在配置檔案中的一個或多個裝置,然後點選繼續。
輸入配置檔案的名稱,然後點選生成。
(可選)點選下載以下載配置檔案。
如何在 AppBuilder 中新增您的配置檔案?
點選齒輪圖示,然後選擇選項。
選擇 iOS → 配置檔案。
點選匯入。
瀏覽到儲存配置檔案的移動配置檔案所在的位置,選擇它並確認匯入。
裝置選項和首選項
您可以為任何文字、動態搜尋、影像或展示廣告指定裝置首選項(移動或全部)。
如果廣告組同時包含移動優先廣告和常規廣告,則只有移動優先廣告會在移動裝置上投放,只有常規廣告會在電腦和平板上投放。
在型別列表中,選擇廣告和擴充套件程式,然後選擇要更新的廣告型別。選擇一個或多個廣告。在編輯面板上的“裝置首選項”下,選擇移動或全部。
移動裝置測試 - 型別
讓我們詳細瞭解一下可以在移動裝置上執行的不同型別的測試。
網路連線
下表提供了可對移動裝置執行的網路連線測試清單。
| 序號 | 描述 |
|---|---|
| 1 | 如果透過 Wi-Fi 連線到網際網路,應用程式的行為是否符合規範? |
| 2 | 如果透過 3G 連線到網際網路,應用程式的行為是否符合規範? |
| 3 | 如果透過 2G 連線到網際網路,應用程式的行為是否符合規範? |
| 4 | 如果應用程式超出網路範圍,應用程式的行為是否符合規範? |
| 5 | 當應用程式從網路範圍外恢復到網路範圍時,它是否恢復工作? |
| 6 | 重新建立連線後,更新交易是否正確處理。 |
| 7 | 當連線到其他裝置(例如,透過網路共享)時,應用程式是否仍然可以正常工作? |
| 8 | 如果應用程式在網路之間切換(Wi-Fi、3G、2G),會發生什麼情況? |
| 9 | 應用程式是否使用標準網路埠(郵件:25、143、465、993 或 995 HTTP:80 或 443 SFTP:22)連線到遠端服務,因為某些提供商會阻止某些埠。 |
SD 卡互動
下表提供了檢查 SD 卡與手機互動的主要功能的清單。
| 序號 | 描述 |
|---|---|
| 1 | 應用程式是否可以安裝在裝置上? |
| 2 | 如果有來電,應用程式的行為是否符合設計/預期? |
| 3 | 如果有簡訊,應用程式的行為是否符合設計/預期? |
| 4 | 如果連線充電器,應用程式的行為是否符合設計/預期? |
| 5 | 如果斷開充電器,應用程式的行為是否符合設計/預期? |
| 6 | 如果裝置進入睡眠模式,應用程式的行為是否符合設計/預期? |
| 7 | 如果裝置從睡眠模式恢復,應用程式的行為是否符合設計/預期? |
| 8 | 如果裝置從鎖定螢幕恢復,應用程式的行為是否符合設計/預期? |
| 9 | 如果裝置傾斜,應用程式的行為是否符合設計/預期? |
| 10 | 如果裝置搖晃,應用程式的行為是否符合設計/預期? |
| 11 | 如果來自另一個應用程式的本地訊息(例如:日曆提醒、待辦事項等),應用程式的行為是否符合設計/預期? |
| 12 | 如果來自另一個應用程式的推送訊息(例如:推特提及、WhatsApp 訊息、文字遊戲邀請等),應用程式的行為是否符合設計/預期? |
| 13 | 應用程式是否正確地與 GPS 感測器互動(開啟/關閉、檢索 GPS 資料)? |
| 14 | 裝置上為該應用程式定義的所有按鈕或按鍵的功能是否正常? |
| 15 | 驗證沒有定義功能的按鈕或按鍵在啟用時對應用程式沒有意外行為。 |
| 16 | 如果裝置上有一個真正的“返回”按鈕,則“返回”按鈕是否將使用者帶到上一螢幕? |
| 17 | 如果裝置上有一個真正的“選單”按鈕,則選單按鈕是否顯示應用程式的選單? |
| 18 | 如果裝置上有一個真正的“主頁”按鈕,則主頁按鈕是否將使用者帶回裝置的主螢幕? |
| 19 | 如果裝置上有一個真正的“搜尋”按鈕,這是否會將使用者帶到應用程式中的某種搜尋? |
| 20 | 如果推送“電池電量低”訊息,應用程式的行為是否符合設計/預期? |
| 21 | 如果裝置上的聲音關閉,應用程式的行為是否符合設計/預期? |
| 22 | 如果裝置處於飛航模式,應用程式的行為是否符合設計/預期? |
| 23 | 應用程式是否可以從裝置中解除安裝? |
| 24 | 重新安裝後,應用程式是否按預期工作? |
| 25 | 應用程式是否可以在應用商店中找到?(上線後檢查) |
| 26 | 應用程式是否可以根據設計/預期透過多工處理切換到裝置上的其他應用程式? |
| 27 | 使用螢幕保護膜時,所有觸控式螢幕位置(按鈕)是否都正常工作。 |
藍牙測試
藍牙裝置只能在 10 米半徑內通訊。此類裝置可以是鍵盤、滑鼠、無線耳機等。下表提供了可執行的藍牙測試清單:
| 序號 | 描述 |
|---|---|
| 1 | 使用者能夠搜尋範圍內所有可用的裝置。 |
| 2 | 可以透過使用短距離網路傳送資料和語音傳輸。 |
| 3 | 可以透過使用短距離網路接收資料和語音傳輸。 |
| 4 | 使用者可以隨時斷開連線。 |
| 5 | 關閉藍牙時,詢問是否斷開當前連線。 |
| 6 | 藍牙最大範圍為 10 米。 |
| 7 | 透過手機,您可以傳送圖片、影片、交換名片,還可以將檔案傳輸到您的電腦。 |
| 8 | (裝置已配對)此訊息用於確認使用者已成功配對兩個藍牙裝置。 |
| 9 | 不可發現模式,裝置不會響應發現請求。 |
| 10 | 不可發現模式,裝置不會響應發現請求。 |
| 11 | 不可配對模式,不接受配對的裝置被稱為處於不可配對模式。 |
| 12 | 金鑰,金鑰是使用者定義的密碼,需要從任何其他裝置連線到裝置。強烈建議儘可能使用金鑰,以避免未經授權訪問您的藍牙裝置。 |
| 13 | 身份驗證 - 驗證通訊鏈路另一端身份的過程。在藍牙技術中,這是透過基於金鑰和配對的身份驗證過程實現的。 |
| 14 | 未找到裝置,如果搜尋範圍內其他裝置未找到任何內容,則可能會出現此錯誤訊息。 |
| 15 | 空閒模式,裝置在沒有與其他裝置建立連線時處於空閒模式。在此模式下,裝置可以發現其他裝置。 |
| 16 | 已知裝置測試,另一個裝置已知的裝置。這些裝置過去可能已配對,或者已儲存已知裝置的一些資訊。 |
Wi-Fi 測試
測試手機WiFi連線是確保您的網際網路以服務提供商承諾的速度執行的好方法,但您不限於在臺式電腦上執行這些測試。手機WiFi測試是測試WiFi訊號在您家或辦公室各個位置的強度的完美方法。下面是移動裝置的WiFi測試清單。
| 序號 | 描述 |
|---|---|
| 1 | 如果透過 Wi-Fi 連線到網際網路,應用程式的行為是否符合規範? |
| 2 | 如果應用程式超出網路範圍,應用程式的行為是否符合規範? |
| 3 | 當應用程式從網路覆蓋範圍之外回到網路覆蓋範圍內時,它是否會恢復工作? |
| 4 | 如果應用程式在網路之間切換(Wi-Fi、3G、2G)會發生什麼? |
| 5 | 應用程式是否使用標準網路埠(郵件:25、143、465、993 或 995 HTTP:80 或 443 SFTP:22)連線到遠端服務,因為某些提供商會阻止某些埠。 |
如何在智慧手機上執行手機WiFi速度測試
在智慧手機上執行WiFi速度測試是一項簡單的任務。最方便的是在智慧手機的移動瀏覽器中執行的速度測試。只需按照簡單的螢幕提示即可開始測試。如果線上測試未儲存您的結果,請在測試完成後截圖以提供歷史記錄。
某些測試可以作為iOS和Android平臺的應用程式使用。要使用它們,請下載您想要的應用程式。然後按照說明執行測試並儲存您的結果。
執行速度測試的工具
Speed Test SpeedSmart WiFi & Mobile Network Speedtest - 它與蘋果iPhone和iPad相容。這是一個付費應用程式。SpeedSmart是用於評估所有iOS裝置上的蜂窩(3G、4G和LTE)和Wi-Fi連線的終極iOS速度測試實用程式。全球伺服器網路和智慧速度測試方法確保結果準確。
WiFi Speed Test - 它與Android手機相容。這是一個付費工具。使用此工具,您可以測試本地(LAN)網路的速度。可以在無線(WiFi)或有線網路上進行測試。
本地化和全球化
請參閱下面的清單,瞭解移動裝置的本地化和全球化測試。
| 序號 | 描述 |
|---|---|
| 1 | 文字已翻譯。 |
| 2 | 翻譯在語法和術語準確性方面符合母語人士的標準。 |
| 3 | 對話方塊已正確調整大小,對話方塊文字根據使用者介面語言的規則進行連字元處理。 |
| 4 | 翻譯後的對話方塊、狀態列、工具欄和選單在不同解析度的螢幕上都能正常顯示。它們不會換行,也不會被截斷。 |
| 5 | 選單和對話方塊加速鍵是唯一的。 |
| 6 | 視覺佈局與原生版本的佈局一致。例如,對話方塊元素按正確的選項卡順序排列。 |
資料庫測試
您可以透過多種方式在移動應用程式中儲存資料。對於Android,您可以選擇透過伺服器、共享首選項或SQLite儲存資料。
SQLite是一個輕量級資料庫,通常用於Android和其他作業系統。為了檢視SQLite中的資料,您可能需要root裝置,或者可以使用模擬器進行測試。Android Play商店中有一些工具可以幫助您從該資料庫中提取資料。
以下型別的測試應成為移動資料庫測試的一部分 -
- 資料庫驗證測試。
- 資料庫整合測試。
- 資料庫效能測試。
- 過程和函式測試。
- 觸發器測試。
- CRUD(建立/讀取/更新/刪除)操作測試,以確保它們將在資料庫上執行。
- 測試資料庫更改是否在應用程式的UI上正確顯示。
- 搜尋和索引功能測試。
恢復測試
恢復測試用於確保在災難發生後可以繼續操作。恢復測試不僅驗證恢復過程,還驗證該過程組成部分的有效性。
恢復測試是測試應用程式在崩潰、硬體故障和其他類似問題後恢復能力的活動。下面是可恢復性測試的清單。
| 序號 | 描述 |
|---|---|
| 1 | 保留了足夠備份資料。 |
| 2 | 備份資料儲存在安全的位置。 |
| 3 | 恢復程式已記錄在案。 |
| 4 | 所有媒體檔案都已從還原點恢復 |
| 5 | 所有聯絡人均已恢復 |
| 6 | 所有應用程式均已成功恢復 |
併發測試
我們通常藉助併發測試來確保多個使用者可以同時併發訪問程式。在將併發測試應用於移動裝置時,實際上只有一個使用者。因此,它消除了對移動裝置進行併發測試的需要。
可用性測試
通常,您會獲得一個裝置,其中可以調整手機和網路攝像頭以記錄可用性評估會話。
有一些工具可用,例如Applause。他們提供了一組目標調查參與者,這些參與者經過精心挑選來測試您的應用程式。Applause與其他此類服務的區別在於,您可以與Applause的專家進行諮詢,然後根據諮詢選擇理想的參與者。
下面是GUI測試的一般清單。
| 序號 | 描述 |
|---|---|
| 1 | 應用程式是否可以安裝在裝置上? |
| 2 | 如果有來電,應用程式的行為是否符合設計/預期? |
| 3 | 如果有簡訊,應用程式的行為是否符合設計/預期? |
| 4 | 如果連線充電器,應用程式的行為是否符合設計/預期? |
| 5 | 如果斷開充電器,應用程式的行為是否符合設計/預期? |
| 6 | 如果裝置進入睡眠模式,應用程式是否按設計/預期執行。 |
| 7 | 如果裝置從睡眠模式恢復,應用程式是否按設計/預期執行。 |
| 8 | 如果裝置從鎖定螢幕恢復,應用程式的行為是否符合設計/預期? |
| 9 | 如果裝置傾斜,應用程式的行為是否符合設計/預期? |
| 10 | 如果裝置搖晃,應用程式的行為是否符合設計/預期? |
| 11 | 如果來自其他應用程式的本地訊息(例如:日曆提醒、待辦事項等),應用程式是否按設計/預期執行。 |
| 12 | 如果來自其他應用程式的推送訊息(例如:推特提及、WhatsApp訊息等),應用程式是否按設計/預期執行。 |
| 13 | 應用程式是否正確地與 GPS 感測器互動(開啟/關閉、檢索 GPS 資料)? |
| 14 | 裝置上為該應用程式定義的所有按鈕或按鍵的功能是否正常? |
| 15 | 驗證沒有定義功能的按鈕或按鍵在啟用時對應用程式沒有意外行為。 |
| 16 | 如果裝置上有一個真正的“返回”按鈕,則“返回”按鈕是否將使用者帶到上一螢幕? |
| 17 | 如果裝置上有一個真正的“選單”按鈕,則選單按鈕是否顯示應用程式的選單? |
| 18 | 如果裝置上有一個真正的“主頁”按鈕,則主頁按鈕是否將使用者帶回裝置的主螢幕? |
| 19 | 如果裝置上有一個真正的“搜尋”按鈕,這是否會將使用者帶到應用程式中的某種搜尋? |
| 20 | 如果推送“電池電量低”訊息,應用程式的行為是否符合設計/預期? |
| 21 | 如果裝置上的聲音關閉,應用程式的行為是否符合設計/預期? |
| 22 | 如果裝置處於飛航模式,應用程式的行為是否符合設計/預期? |
| 23 | 應用程式是否可以從裝置中解除安裝? |
| 24 | 重新安裝後,應用程式是否按預期工作? |
| 25 | 應用程式是否可以在應用商店中找到?(上線後檢查) |
| 26 | 應用程式是否可以根據設計/預期透過多工處理切換到裝置上的其他應用程式? |
| 27 | 使用螢幕保護膜時,所有觸控式螢幕位置(按鈕)是否都正常工作。 |
移動測試 - 框架概述
測試框架或更具體地說是測試自動化框架是執行自動化測試的執行環境。它是自動化測試的整體系統。它被定義為構成工作平臺或自動化測試支援的一組假設、概念和實踐。
測試框架負責 -
- 定義表達期望的格式
- 建立掛鉤或驅動被測應用程式的機制
- 執行測試並報告結果
框架架構
測試框架的一般架構如下 -
對於移動測試自動化,我們需要一個良好的移動自動化測試框架。在此框架之上,我們可以構建我們的測試用例。移動自動化測試框架可以根據移動裝置的作業系統進行區分。在接下來的章節中,我們將討論兩種型別的移動測試框架:Android測試框架和iOS測試框架。
移動測試 - Android 框架
市場上有許多Android測試框架可用。讓我們來看看堆疊中的前5名。
Robotium - Robotium是一個開源測試框架,用於開發功能、系統和驗收測試場景。它與Selenium非常相似。
UIAutomator - UIAutomator是Google提供的測試框架,提供原生Android應用程式和遊戲的UI高階測試。它具有一個包含用於建立功能性UI測試的API的Java庫,以及一個用於執行測試的執行引擎。
Appium - Appium是一個開源測試自動化框架,用於測試原生和混合應用程式以及移動Web應用程式。框架內的Appium庫函式會呼叫後臺執行的Appium伺服器,該伺服器操作連線的裝置。
Calabash - Calabash是一個功能測試框架,可用於iOS和Android功能測試。從理論上講,它一定是最易於使用的框架之一,即使是非開發人員也應該能夠使用它建立功能測試。
Selendroid - Selendroid是該領域的新成員,可用於功能測試您的Android應用程式。顯然,如果您習慣使用Selenium,則Selendroid應該是使用您的知識為Android建立功能測試的簡便方法。
移動測試 - IOS 框架
與Android測試框架類似,市場上也有許多iOS測試框架可用。在這裡,我們將討論一些流行的框架。
Appium - Appium是一個開源測試自動化框架,用於測試原生和混合應用程式以及移動Web應用程式。框架內的Appium庫函式會呼叫後臺執行的Appium伺服器,該伺服器操作連線的裝置。
Calabash - Calabash是一個功能測試框架,可用於iOS和Android功能測試。從理論上講,它一定是最易於使用的框架之一,即使是非開發人員也應該能夠使用它建立功能測試。
Zucchini - Zucchini是一個基於Apple UIAutomation的iOS應用程式的開源視覺功能測試框架。
UI Automation - 對於您更典型的功能測試(或黑盒測試),您將在其中編寫程式碼來模擬終端使用者瀏覽您的應用程式,可以使用UI Automation。UI Automation由Apple提供,是執行iOS功能測試的Apple認可的方式。
FRANK – BDD for iOS - 如果您想在iOS中進行端到端測試,並希望可以使用BDD和Cucumber,不用擔心 - 有一個名為Frank的工具可以讓您使用Cucumber建立驗收測試和需求。
不同測試框架之間的比較
移動測試 - Robotium框架
Robotium是一個開源測試框架,用於為Android應用程式編寫自動灰盒測試用例。在Robotium的支援下,測試用例開發人員可以編寫功能、系統和驗收測試場景,涵蓋多個Android活動。
Robotium可用於測試有原始碼的應用程式和只有APK檔案的應用程式。
Robotium的優勢
易於編寫,程式碼更簡潔。編寫可靠的測試用例所需的時間最少。
您可以開發強大的測試用例,只需具備最少的被測應用程式知識。
該框架自動處理多個Android活動。與標準儀器測試相比,測試用例的可讀性大大提高。
自動計時和延遲。
自動跟蹤當前活動。
自動查詢檢視。
自動做出自己的決策(例如:何時滾動等)。
無需修改Android平臺。
測試執行速度快。
由於與GUI元件的執行時繫結,測試用例更加健壯。
與Maven或Ant無縫整合。
Robotium的缺點
Robotium無法處理Flash或Web元件。
它一次只能處理一個應用程式。
Robotium無法模擬點選軟鍵盤(需要使用‘enterText()’方法將文字輸入到EditText欄位中)。
Robotium無法與狀態列通知互動,也就是說,無法下拉通知區域並點選指定的通知。
執行速度可能有點慢,尤其是在舊裝置上。
如何使用Robotium
步驟1 - 使用Robotium的先決條件是Java SDK(最低版本1.6)。如果您的系統上沒有安裝Java,請按照以下步驟操作。
從Oracle Technology Network下載JDK和JRE
接受許可協議。
安裝JDK和JRE。
設定環境變數,如下面的截圖所示。
步驟2 - 從Android Studio下載Android Studio
- 雙擊exe檔案並執行安裝程式。
- 繼續使用所有預設選項。
- 設定ANDROID_HOME。
步驟3 - 安裝Android映象和工具。
- 點選SDK Manager -
選擇必要的包。例如,如果我們正在為Android 4.4.2構建一個App,那麼請確保Tools部分中選中以下包:
- Android SDK Tools rev 22.6.3
- Android Platform-tools rev 19.0.1
- Android SDK Build-tools rev 19.1
步驟4 - 建立Android虛擬裝置。
- 開啟Android Studio,然後點選工具欄中的AVD Manager。AVD允許我們測試和執行我們的Android應用程式。
對於Nexus5 AVD,使用以下設定:
- 裝置 - Nexus 5 (4.95, 1080 x 1920; xxhdpi)
- 目標 - Google APIs x86 (Google Inc.) - API Level 19
- (確保您選擇了名稱中包含Google APIs的目標。)
- CPU - Intel Atom (x86)
- 選中“使用主機GPU”複選框
- 點選確定
您現在應該在AVD Manager中看到您建立的AVD,您可以在其中啟動它、刪除它或建立另一個AVD!
步驟5 - Robotium Jar檔案 從RobotiumTech下載Robotium Jar檔案
使用Robotium測試App
要使用Robotium測試App,請按照以下步驟操作:
步驟1 - 在Android Studio中建立一個名為“RobotiumTest”的測試專案。
選擇所有預設選項,直到到達主頁面。
步驟2 - 將Robotium jar檔案複製到專案的Lib資料夾中。
步驟3 - 在src資料夾下的build.gradle檔案中新增依賴項。
androidTestCompile 'com.jayway.android.robotium:robotium-solo-5.5.3'
步驟4 - 同步Gradle。
步驟5 - 建立測試類,如下所示:
package com.example;
import com.robotium.solo.Solo;
import android.test.ActivityInstrumentationTestCase2;
import android.widget.EditText;
import android.widget.TextView;
public class MyTestClass extends ActivityInstrumentationTestCase2<TestActivity>{
private Solo solo;
public MyTestClass() {
super(TestActivity.class);
}
public void setUp() throws Exception {
solo = new Solo(getInstrumentation(), getActivity());
}
public void testCase() throws Exception {
String vResult="TestExample";
EditText vEditText = (EditText) solo.getView(R.id.edit1);
solo.clearEditText(vEditText);
solo.enterText(vEditText,"TestExample");
solo.clickOnButton("Submit");
assertTrue(solo.searchText(vResult));
TextView textField = (TextView) solo.getView(R.id.txt1);
//Assert to verify result with visible value
assertEquals(vResult, textField.getText().toString());
}
@Override
public void tearDown() throws Exception {
solo.finishOpenedActivities();
}
}
步驟6 - 儲存所有更改。確保沒有錯誤。
步驟7 - 現在,執行測試用例。如果測試用例成功,您應該會看到以下輸出!
移動測試 - Selendroid框架
Selendroid是一個用於測試Android原生和混合應用程式的測試自動化框架。Selendroid測試使用Selenium Webdriver客戶端API編寫。
Selendroid的優勢
完全相容JSON Wire協議/Selenium 3就緒。
無需修改被測應用程式即可對其進行自動化。
使用內建的Android驅動程式webview應用程式測試行動網路。
自動化原生或混合應用程式的概念相同。
UI元素可以透過不同的定位器型別找到。
支援手勢:高階使用者互動API。
自動啟動現有的模擬器。
Selendroid支援硬體裝置的熱插拔。
完全整合到Selenium Grid中,用於擴充套件和並行測試。
支援多個Android目標API(10到19)。
內建檢查器,簡化測試用例開發。
Selendroid可以在執行時擴充套件您自己的擴充套件。
Selendroid可以同時與多個Android裝置(模擬器或硬體裝置)互動。
Selendroid的缺點
此工具的缺點是速度相當慢,並且在某些記憶體小於4GB的機器上無法使用。
如何使用Selendroid
步驟1 - 使用Robotium的先決條件是Java SDK(最低版本1.6)。如果您的系統上沒有安裝Java,請按照以下步驟操作。
從Oracle JavaSE下載JDK和JRE
接受許可協議。
安裝JDK和JRE。
設定環境變數,如下面的截圖所示。
步驟2 - 從SDK Android下載Android Studio(由於檔案大小,這將需要一些時間)。
- 雙擊exe檔案並執行安裝程式。
- 繼續使用所有預設選項。
- 設定ANDROID_HOME。
步驟3 - 從Selendroid下載Selenium jar檔案和測試應用程式
- 下載selenium jar檔案和測試應用程式。
- 將其放置到任何資料夾中,例如D:\SelendroidJars。
步驟4 - 使用USB電纜連線的物理裝置。
確保裝置已透過USB電纜連線到工作站。
確保已啟用USB除錯模式(在設定→開發者選項下)。
使用Selendroid測試App
要使用Selendroid測試App,請按照以下步驟操作:
步驟1 - 安裝Eclipse。
步驟2 - 建立一個Java專案。
步驟3 - 將下載的Selendroid jar檔案新增到新建立的專案中。
步驟4 - 將下載的Selenium jar檔案新增到新建立的專案中。
步驟5 - 在Eclipse中配置testNG。
步驟6 - 使用USB電纜將移動裝置連線到系統。從設定下的開發者選項中設定USB除錯模式。
步驟7 - 執行Selendroid伺服器。開啟命令提示符並寫入以下程式碼,然後按Enter鍵:
java -jar selendroid-standalone-0.17.0-with-dependencies.jar -app selendroid-test-app-0.17.0.apk
Selendroid-standalone將在埠4444上啟動一個http伺服器,並將掃描使用者建立的所有Android虛擬裝置(avd)(~/.android/avd/)。
開啟Web瀏覽器並導航到:https://:4444/wd/hub/status。
步驟8 - 建立一個Java專案;在構建路徑中新增Selendroid Standalone庫、Selenium jar和JUnit庫。
步驟9 - 在Java專案下建立包。
步驟10 - 在包下建立一個類並編寫以下程式碼。
package selTest;
import io.selendroid.SelendroidDriver;
import io.selendroid.common.SelendroidCapabilities;
import io.selendroid.standalone.SelendroidConfiguration;
import io.selendroid.standalone.SelendroidLauncher;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.testng.Assert;
import org.testng.annotations.AfterSuite;
import org.testng.annotations.BeforeSuite;
import org.testng.annotations.Test;
public class SelendroidTest {
private WebDriver driver ;
@BeforeSuite
public void setUp() throws Exception {
SelendroidConfiguration config = new SelendroidConfiguration();
config.addSupportedApp("selendroid-test-app-0.9.0.apk");
SelendroidLauncher selendroidServer = new SelendroidLauncher(config);
selendroidServer.launchSelendroid();
SelendroidCapabilities caps = new
SelendroidCapabilities("io.selendroid.testapp:0.9.0");
driver = new SelendroidDriver(caps);
}
@Test
public void selendroidTest() throws Exception {
WebElement inputField = driver.findElement(By.id("my_text_field"));
Assert.assertEquals("true", inputField.getAttribute("enabled"));
inputField.sendKeys("Selendroid");
Assert.assertEquals("Selendroid", inputField.getText());
WebElement button = driver.findElement(By.id("buttonTest"));
button.click();
button = driver.findElement(By.id("button2"));
button.click();
Thread.sleep(5000);
button = driver.findElement(By.id("startUserRegistration"));
button.click();
Thread.sleep(10000);
WebElement element = driver.findElement(By.id("label_username"));
String text = element.getText();
System.out.println(text);
element = driver.findElement(By.id("inputUsername"));
element.sendKeys("bob");
element = driver.findElement(By.id("inputEmail"));
element.sendKeys("test@gmail.com");
element = driver.findElement(By.id("inputPassword"));
element.clear();
element.sendKeys("test1233");
element = driver.findElement(By.id("inputName"));
element.clear();
element.sendKeys("My Name ");
element = driver.findElement(By.id("input_preferedProgrammingLanguage"));
element.click();
element = driver.findElement(By.id("text1"));
element.click();
element = driver.findElement(By.id("input_adds"));
element.click();
element = driver.findElement(By.id("btnRegisterUser"));
element.click();
element = driver.findElement(By.id("buttonRegisterUser"));
element.click();
}
@AfterSuite
public void tearDown(){
driver.quit();
}
}
步驟11 - 使用testNG執行配置執行該類。
移動測試 - Appium 框架
Appium是一個開源的測試自動化框架,用於測試原生和混合應用程式以及移動Web應用程式。它使用WebDriver協議驅動iOS和Android應用程式。
Appium的優勢
它是免費的(並且主要)開源的。
它有一個非常受支援且活躍的Google小組。
它符合Selenium 3規範,因此應該是面向未來的。
它同時支援Android和iOS。
它不需要在裝置上安裝任何東西 - 不需要伺服器或程式碼更改。
Appium的缺點
- 不支援智慧等待。
- 在iOS上,您每次只能在一個Mac上執行一個測試。
- 對手勢的支援有限。
- 對Android < 4.1的支援有限
如何使用Appium
步驟1 - 使用Appium的先決條件是Java SDK(最低版本1.6)。如果您的系統上沒有安裝Java,請按照以下步驟操作。
從Oracle JavaSE下載JDK和JRE
接受許可協議。
安裝JDK和JRE。
設定環境變數,如下面的截圖所示。
步驟2 - 從SDK下載Android Studio(由於檔案大小,這將需要一些時間)。
- 雙擊exe檔案並執行安裝程式。
- 繼續使用所有預設選項。
- 設定ANDROID_HOME。
步驟3 - 安裝Android映象和工具。
- 點選SDK Manager -
選擇必要的包。例如,如果我們正在為Android 4.4.2構建一個App,那麼請確保Tools部分中選中以下包:
- Android SDK Tools rev 22.6.3
- Android Platform-tools rev 19.0.1
- Android SDK Build-tools rev 19.1
步驟4 - 建立Android虛擬裝置 -
開啟Android Studio,然後點選工具欄中的AVD Manager。AVD允許我們測試和執行我們的Android應用程式。
對於Nexus5 AVD,使用以下設定:
裝置:Nexus 5 (4.95, 1080 x 1920; xxhdpi)
目標:Google APIs x86 (Google Inc.) - API Level 19
確保您選擇了名稱中包含Google APIs的目標。
CPU:Intel Atom (x86)
選中“使用主機GPU”複選框
點選確定。
您現在應該在AVD Manager中看到您建立的AVD,您可以在其中啟動它、刪除它或建立另一個AVD!
步驟5 - 從Appium下載Appium jar檔案
使用Appium測試App
要使用Appium測試App,請按照以下步驟操作:
步驟1 - 在Android Studio中建立一個名為“RobotiumTest”的測試專案。
選擇所有預設選項,直到到達主頁面。
步驟2 - 將Appium jar新增到您的專案中。點選Project → App → 複製lib中的所有jar。選擇複製的jar(Selenium、Java客戶端和Junit Jar除外),然後右鍵單擊並點選“新增為庫”。
步驟3 - 點選App中的build.gradle。您將看到所有新增的庫,如下面的截圖所示。
步驟4 - 現在建立一個Java類,如下所示:
AppiumDriver driver;
@Before
public void testCaseSetup()throws Exception {
//service.start();
//reader.readFile();
DesiredCapabilities cap = new DesiredCapabilities();
cap.setCapability(MobileCapabilityType.PLATFORM_NAME,"Android");
cap.setCapability(MobileCapabilityType.DEVICE_NAME, "Android device");
cap.setCapability(MobileCapabilityType.NEW_COMMAND_TIMEOUT, "4000");
cap.setCapability(MobileCapabilityType.APP, "c://apk//sample.apk");
driver = new AndroidDriver<MobileElement>("http://127.0.0.1:4444/wd/hub",cap);
}
@Test
public void testcase1()throws Exception {
driver.findElementByID("Example").click();
Asser.assertTrue(driver.findElementByID("Example").isDisplayed));
}
@After
public void testCaseTearDown() {
driver.quit();
}
步驟5 - 執行測試用例。
- 點選構建變體並選擇單元測試。
- 使用特定埠“4444”啟動Appium伺服器。
- 從此處下載適用於Windows的Appium。
- 雙擊.exe檔案並安裝Appium。
- 點選圖示以啟動UI。
- 如果需要,更改埠,如下所示。
- 點選播放按鈕啟動伺服器。
- 連線裝置並開啟USB除錯或啟動模擬器。
- 右鍵單擊測試類,然後點選“執行”。
移動測試 - Zucchini 框架
Zucchini是一個新的測試框架,它使用BDD風格的領域特定語言(DSL)。它的重點之一是簡化使用Selenium編寫的驗收測試。
它不是JBehave或Robot Framework的替代品,您稍後會看到這一點。在這裡,我們將透過逐步描述一個示例來讓您一窺Zucchini的概念。
如何安裝Zucchini
安裝Zucchini的先決條件是XCode 4.2。此外,還需要一些命令列工具,例如brew update && brew install imagemagick && brew install coffee-script。
如何使用Zucchini
gem install zucchini-ios
首先建立一個專案腳手架
為您的第一個功能建立一個功能腳手架
透過修改features/my_feature/feature.zucchini和features/support/screens/welcome.coffee開始進行修改。
Zucchini不需要對應用程式程式碼進行任何修改。您也可以將Zucchini測試儲存在單獨的專案中。
zucchini generate --project /path/to/my_project
zucchini generate --feature /path/to/my_project/features/my_feature
或者,檢視zucchini-demo專案,該專案圍繞Apple的CoreDataBooks示例提供了一個易於探索的Zucchini設定。
在裝置上執行
將您的裝置新增到features/support/config.yml中。
在iOS模擬器上執行。我們強烈建議您在真實的硬體上執行Zucchini功能。但是,如果您必須這樣做,您可以在iOS模擬器上執行它們。
首先,修改您的features/support/config.yml以包含已編譯應用程式的完整路徑。例如,
app:/Users/vaskas/Library/Developer/Xcode/DerivedData/CoreDataBooks-ebeqiuqksrwwoscupvxuzjzrdfjz/Build/Products/Debug-iphonesimulator/CoreDataBooks.app
其次,在devices部分新增一個“iOS Simulator”條目(不需要UDID),並確保根據您的iOS Simulator設定提供“screen”的實際值 -
像這樣執行它 -
ZUCCHINI_DEVICE="iOS Simulator" zucchini run /path/to/my_feature
如果您計劃不時新增裝置,udidetect實用程式會派上用場 - udidetect -z。
ZUCCHINI_DEVICE="My Device" zucchini run /path/to/my_feature
結果顯示