Android在短短三年間已成為嵌入式裝置發展重要的平台之一，除手機之外各項新興領域裝置漸趨多元，並衍生出各式各樣的功能。處理器廠商與系統晶片廠商由過往提供Linux ready的Total Solution，順應市場所需，在有限的時間內，有效率的提出各自的Android平台解決方案。然而，商品化的過程，各式應用程式成功導入，例如FACEBOOK、Messenger等，測試驗證為其中最重要的關鍵之一。為此，本文將簡述Android沿革、Android裝置發展趨勢，接續深入淺出的介紹現有的標準測試規範，同時提供視覺化使用者介面(User Interface, UI)測試技術應用於Android系統。
Android沿革
Google在2007年11月5日公佈Android系統，並於2008年10月21日將其原始碼公開成為自由及開放源碼軟體，隨後Masataka Miura也在2009年2月成立了日本開放性嵌入式軟體基金會（Open Embedded Software Foundation，OESF），旨在於建立一個適用多種嵌入式產品的Android平台（非手機裝置，Non-phone）。
圖一為Android系統版本發展里程碑，由圖中可看出約略五至六個月便會有一次大幅度改版；非手機裝置系統發展上除2010年初OESF便開始推行的Embed Master版本外，Google亦於2011年2月提出了Android 3.0專為非手機裝置設計，代號為Honeycomb的新系統。
圖1 Android 作業系統里程碑 (資料來源:自行整理)
Android裝置發展趨勢
自2008年10月第一支Android手機上市，Android系統便以黑馬之姿態，在智慧型手機快速成長。依據市場研究機構Canalys資料，2010年第四季全球智慧型手機的總銷售量上看1億台，其中Android手機佔三成之多，包括HTC、Samsung等知名手機廠商共計售出3290萬。今年在平板電腦出貨上，Android系統的裝置更是呈現百家爭鳴態勢。從各家業者預估的出貨量調查中（如表1），採Android系統將上看八成左右。
而在應用程式方面，目前仍以Apple推行的App Store為下載次數最高的平台（如表2），但Android也在後急起直追，從過往的行動電話專用應用程式逐漸往平版裝置發展，2010年價格策略上也重新調整，提出更有競爭優勢的Android Market付費機制，足可看出Google對應用程式商店的企圖心。
現有Android測試規範
Android現有的測試規範並不多：以Google Android體系而言可將Comply with Android Compatibility Definition Document (CDD)視為測試綱要，Google在每一個版本發行後都會相對應的CDD版本，其內容定義各版本必要（Must）、應該（Should）等不同層級需求的功能項目，同時也在文中定義各版本必須支援的軟、硬體需求資訊（如：實體按鈕、多媒體格式支援等），此部份最新資訊可以至http://source.android.com/compatibility/index.html取得；而在OESF Embedded Master體系，目前測試綱要尚在草擬階段，僅有Mobile Internet Device Compatibility Definition一文，定義MID所該具有的功能項目，此部份的資訊可以至http://developer.oesf.biz/em/developer/compatibility/取得。
目前主要的測試仍是以Google的CTS以及GMS為主，如圖2所示，裝置上要放置Android Market此服務一定要通過CTS測試；若裝置上要具有Google服務（如Gmail、Google Talk、Google Map等）則需要通過Google GMS之認證方可放上：
圖2 Android測試說明（資料來源: 自行整理）
（1） Android Compatibility Test Suite（CTS）
這部份是較常聽到的一個相容性測試套件，Google透過Android instrumentation介面進行framework API測試，以確保使用者在Android Market裡所下載之軟體可在裝置上正確執行。此部份的測試方法是透過USB連接線將待測裝置與測試主機連接，依據所選擇的測試項目進行測試，測試完畢之後會自動產生一份XML測試報表於測試主機中，供使用者瞭解測試情形，相關資料可至http://source.android.com/compatibility/cts-intro.html。
（2） Google Mobile Service（GMS）
主要進行Google API的驗證，但此部份並無法事先自行進行模擬測試，要交由Google進行認證授權，進行此測試項目認證的效益可分為兩種：（1）測試完成後要在裝置上印有Google商標。（2）僅需要使用Google 服務授權，如Google Map、Gmail Account等這都需要Google提供自有的API函式庫，才能正確執行這些服務功能。
Android Visual User Interface測試技術
經由上述的介紹，可得知現有的標準測試工具（CTS、GMS）皆是針對Android Framework API進行測試，如圖3所示，此方式是透過Java語言編寫JUnit的方式再透過Android內建instrumentation介面進行測試，此種測試方式稱為白盒測試（white-box test），優點在於當錯誤發生後測試者可以很明確指出是哪一行程式、哪一個API發生問題以協助開發者除錯，但缺點則為測試程式撰寫人員必須清楚地瞭解程式運作，以及函式間運作流程。
圖3 CTS Test Case Design流程（資料來源: 自行繪製）
但實際上有很多情況，測試人員根本沒足夠時間研究程式原始碼便被要求提供測試項目，因此本文提供了一個黑盒測試（black-box test）應用，結合影像辨識技術來撰寫測試案例，測試案例撰寫過程中不需要更動Android裝置軔體亦不需要瞭解程式API如何呼叫及使用，而是透過截取畫面的方式來模擬人員操作動作並依據指令進行畫面判讀，此種測試的優點在於測試人員可以更快速、更直覺的撰寫測試案例，大幅降低學習程式語言的門檻，同時透過程式自動化技術達成Android裝置測試，可以避免人為操作疏失並可進行長時間壓力測試，缺點則為無法明確指出錯誤發生位置，只知道程式發生錯誤。
Visual User Interface測試工具在影像辨識方面，結合了麻省理工學院（MIT）所提出Sikuli技術：這是一種可透過截取影像（screenshots）自動搜尋判斷使用者圖形介面的視覺化技術，其運作流程如圖4所示，截取之影像配合Sikuli Script透過API的方式利用底層的影像辨識引擎OpenCV，進行解析判讀。
圖4 影像辨識架構（資料來源: Project Sikuli）
相較於傳統測試，Sikuli有以下特點：
— 程式碼的可讀性（readability）和易用性（usability）。透過螢幕截圖方法將動作描述在程式碼裡面，讓使用者能直接「看到」想控制的物件，這是一種非常直覺的動作。
— 除直觀上的UI自動化，提供了一種把使用者操作UI的互動過程利用截圖方式記錄下來的新方法。
舉例來說，要執行一個特定的應用程式，只需要分別截取程式圖示（Icon），並要求進行點擊（Click）即可，如圖5所示，一個完整的單元測試包括：初始化（Init）、結束（End）以及測試案例（Test Case）三部份，當執行測試時程式會先進行setUP函式（初始化）所要求的動作，接著按照testA（測試案例）所指定的步驟執行測試，當測試完成之後會進入到tearDown函式（結束），完成一個單元測試項目。
圖5 Sikuli Pyton Script（資料來源：自行繪製）
若是要在同一台測試主機執行多機測試時，例如：想要使用裝置A傳送簡訊給裝置B，此時就必須先規劃螢幕動作範圍，於程式初始化時定義出待測裝置所在畫面位置，如圖6所示，將一個畫面分成左右兩部份，裝置A所有操作指令必須在畫面左方完成，同理裝置B的動作必須在畫面右方完成。定義測試範圍此一動作除了適用於多機測試，亦可加快測試主機影像判讀速度、減少CPU運算負載。
圖6螢幕分割示意圖（資料來源：自行繪製）
Visual User Interface測試工具其測試案例設計流程如圖7所示，首先將依照測試案例文字描述，使用Python語法將動作描述出來，在特定的執行畫面進行畫面狀態判讀，並依據不同的測試主機加入延遲時間（Delay），完成後會產生三種格式檔案：.png為截取畫面影像檔、.html以及.py則為記錄動作指令的描述檔，此時可以將其編譯成為執行檔（.skl），方便日後執行測試不需要再透過IDE介面，連接Android裝置即可開始進行測試。
圖7 Visual UI Test Case Design（資料來源: 自行繪製）
如圖8所示，為一個Android測試示範系統，其中包含了以下幾項組件：
· Android Control Application：用來在主控端上模擬Android裝置動作。
· Automation Test Interface：測試程式主控制畫面，可選擇測試項目。
· DUT：待測Android裝置。
· Log & Report：記錄裝置測試動作與測試結果。
圖8 Visual UI Test Tool架構（資料來源: 自行繪製）
結論
甫才結束的CES，可以預期今年將是Android系統行動裝置發光發亮的一年，除了原有的行動電話市場加上平版裝置的開發，越來越多的產品應用相繼推出，相對的產品的功能性與穩定性也更趨重要，然而，現有的Android測試只能確保API相容性（Compatibility）無法顧及裝置其他層面，因此開發廠商需要尋求其他測試工具的配合輔助以達成測試需求。未來研究方向，應朝向Android測試工具的研發整合，以提供更快速、有效率的測試技術，達成Android裝置測試完封之目標。
本文作者林敬文任職於資策會網路多媒體研究所
Android沿革
Google在2007年11月5日公佈Android系統，並於2008年10月21日將其原始碼公開成為自由及開放源碼軟體，隨後Masataka Miura也在2009年2月成立了日本開放性嵌入式軟體基金會（Open Embedded Software Foundation，OESF），旨在於建立一個適用多種嵌入式產品的Android平台（非手機裝置，Non-phone）。
圖一為Android系統版本發展里程碑，由圖中可看出約略五至六個月便會有一次大幅度改版；非手機裝置系統發展上除2010年初OESF便開始推行的Embed Master版本外，Google亦於2011年2月提出了Android 3.0專為非手機裝置設計，代號為Honeycomb的新系統。
圖1 Android 作業系統里程碑 (資料來源:自行整理)
Android裝置發展趨勢
自2008年10月第一支Android手機上市，Android系統便以黑馬之姿態，在智慧型手機快速成長。依據市場研究機構Canalys資料，2010年第四季全球智慧型手機的總銷售量上看1億台，其中Android手機佔三成之多，包括HTC、Samsung等知名手機廠商共計售出3290萬。今年在平板電腦出貨上，Android系統的裝置更是呈現百家爭鳴態勢。從各家業者預估的出貨量調查中（如表1），採Android系統將上看八成左右。
而在應用程式方面，目前仍以Apple推行的App Store為下載次數最高的平台（如表2），但Android也在後急起直追，從過往的行動電話專用應用程式逐漸往平版裝置發展，2010年價格策略上也重新調整，提出更有競爭優勢的Android Market付費機制，足可看出Google對應用程式商店的企圖心。
現有Android測試規範
Android現有的測試規範並不多：以Google Android體系而言可將Comply with Android Compatibility Definition Document (CDD)視為測試綱要，Google在每一個版本發行後都會相對應的CDD版本，其內容定義各版本必要（Must）、應該（Should）等不同層級需求的功能項目，同時也在文中定義各版本必須支援的軟、硬體需求資訊（如：實體按鈕、多媒體格式支援等），此部份最新資訊可以至http://source.android.com/compatibility/index.html取得；而在OESF Embedded Master體系，目前測試綱要尚在草擬階段，僅有Mobile Internet Device Compatibility Definition一文，定義MID所該具有的功能項目，此部份的資訊可以至http://developer.oesf.biz/em/developer/compatibility/取得。
目前主要的測試仍是以Google的CTS以及GMS為主，如圖2所示，裝置上要放置Android Market此服務一定要通過CTS測試；若裝置上要具有Google服務（如Gmail、Google Talk、Google Map等）則需要通過Google GMS之認證方可放上：
圖2 Android測試說明（資料來源: 自行整理）
（1） Android Compatibility Test Suite（CTS）
這部份是較常聽到的一個相容性測試套件，Google透過Android instrumentation介面進行framework API測試，以確保使用者在Android Market裡所下載之軟體可在裝置上正確執行。此部份的測試方法是透過USB連接線將待測裝置與測試主機連接，依據所選擇的測試項目進行測試，測試完畢之後會自動產生一份XML測試報表於測試主機中，供使用者瞭解測試情形，相關資料可至http://source.android.com/compatibility/cts-intro.html。
（2） Google Mobile Service（GMS）
主要進行Google API的驗證，但此部份並無法事先自行進行模擬測試，要交由Google進行認證授權，進行此測試項目認證的效益可分為兩種：（1）測試完成後要在裝置上印有Google商標。（2）僅需要使用Google 服務授權，如Google Map、Gmail Account等這都需要Google提供自有的API函式庫，才能正確執行這些服務功能。
Android Visual User Interface測試技術
經由上述的介紹，可得知現有的標準測試工具（CTS、GMS）皆是針對Android Framework API進行測試，如圖3所示，此方式是透過Java語言編寫JUnit的方式再透過Android內建instrumentation介面進行測試，此種測試方式稱為白盒測試（white-box test），優點在於當錯誤發生後測試者可以很明確指出是哪一行程式、哪一個API發生問題以協助開發者除錯，但缺點則為測試程式撰寫人員必須清楚地瞭解程式運作，以及函式間運作流程。
圖3 CTS Test Case Design流程（資料來源: 自行繪製）
但實際上有很多情況，測試人員根本沒足夠時間研究程式原始碼便被要求提供測試項目，因此本文提供了一個黑盒測試（black-box test）應用，結合影像辨識技術來撰寫測試案例，測試案例撰寫過程中不需要更動Android裝置軔體亦不需要瞭解程式API如何呼叫及使用，而是透過截取畫面的方式來模擬人員操作動作並依據指令進行畫面判讀，此種測試的優點在於測試人員可以更快速、更直覺的撰寫測試案例，大幅降低學習程式語言的門檻，同時透過程式自動化技術達成Android裝置測試，可以避免人為操作疏失並可進行長時間壓力測試，缺點則為無法明確指出錯誤發生位置，只知道程式發生錯誤。
Visual User Interface測試工具在影像辨識方面，結合了麻省理工學院（MIT）所提出Sikuli技術：這是一種可透過截取影像（screenshots）自動搜尋判斷使用者圖形介面的視覺化技術，其運作流程如圖4所示，截取之影像配合Sikuli Script透過API的方式利用底層的影像辨識引擎OpenCV，進行解析判讀。
圖4 影像辨識架構（資料來源: Project Sikuli）
相較於傳統測試，Sikuli有以下特點：
— 程式碼的可讀性（readability）和易用性（usability）。透過螢幕截圖方法將動作描述在程式碼裡面，讓使用者能直接「看到」想控制的物件，這是一種非常直覺的動作。
— 除直觀上的UI自動化，提供了一種把使用者操作UI的互動過程利用截圖方式記錄下來的新方法。
舉例來說，要執行一個特定的應用程式，只需要分別截取程式圖示（Icon），並要求進行點擊（Click）即可，如圖5所示，一個完整的單元測試包括：初始化（Init）、結束（End）以及測試案例（Test Case）三部份，當執行測試時程式會先進行setUP函式（初始化）所要求的動作，接著按照testA（測試案例）所指定的步驟執行測試，當測試完成之後會進入到tearDown函式（結束），完成一個單元測試項目。
圖5 Sikuli Pyton Script（資料來源：自行繪製）
若是要在同一台測試主機執行多機測試時，例如：想要使用裝置A傳送簡訊給裝置B，此時就必須先規劃螢幕動作範圍，於程式初始化時定義出待測裝置所在畫面位置，如圖6所示，將一個畫面分成左右兩部份，裝置A所有操作指令必須在畫面左方完成，同理裝置B的動作必須在畫面右方完成。定義測試範圍此一動作除了適用於多機測試，亦可加快測試主機影像判讀速度、減少CPU運算負載。
圖6螢幕分割示意圖（資料來源：自行繪製）
Visual User Interface測試工具其測試案例設計流程如圖7所示，首先將依照測試案例文字描述，使用Python語法將動作描述出來，在特定的執行畫面進行畫面狀態判讀，並依據不同的測試主機加入延遲時間（Delay），完成後會產生三種格式檔案：.png為截取畫面影像檔、.html以及.py則為記錄動作指令的描述檔，此時可以將其編譯成為執行檔（.skl），方便日後執行測試不需要再透過IDE介面，連接Android裝置即可開始進行測試。
圖7 Visual UI Test Case Design（資料來源: 自行繪製）
如圖8所示，為一個Android測試示範系統，其中包含了以下幾項組件：
· Android Control Application：用來在主控端上模擬Android裝置動作。
· Automation Test Interface：測試程式主控制畫面，可選擇測試項目。
· DUT：待測Android裝置。
· Log & Report：記錄裝置測試動作與測試結果。
圖8 Visual UI Test Tool架構（資料來源: 自行繪製）
結論
甫才結束的CES，可以預期今年將是Android系統行動裝置發光發亮的一年，除了原有的行動電話市場加上平版裝置的開發，越來越多的產品應用相繼推出，相對的產品的功能性與穩定性也更趨重要，然而，現有的Android測試只能確保API相容性（Compatibility）無法顧及裝置其他層面，因此開發廠商需要尋求其他測試工具的配合輔助以達成測試需求。未來研究方向，應朝向Android測試工具的研發整合，以提供更快速、有效率的測試技術，達成Android裝置測試完封之目標。
本文作者林敬文任職於資策會網路多媒體研究所
