確保運作流暢度　穿戴式裝置測試不容輕忽

近期國內、外市調機構的資料指出，全球穿戴式裝置市場已初步成形，而分析全球穿戴式裝置市場的發展，約可分為三個時期(圖1)：

圖1　智慧穿戴的市場發展預估

‧	摸索期(百花齊放)
	2013～2015年，2013年為智慧手表、智慧眼鏡等創新穿戴式電子裝置的發展元年，初期將有一波因大量產業投入所造成之高成長，然市場出現高成長的原因是較低的基期數字，且大部分銷售並非來自資通訊(ICT)廠商所主攻的資訊與娛樂應用。
‧	停滯期(整合與修正)td>
	2016～2017年，第一代穿戴產品終因未達市場需求而成長趨緩，市場成長進入停滯期，廠商開始重新思考真正符合需求之產品，並可能開始建立標準化共通性平台。
‧	穩定成長期(成熟發展)td>
	2018年後，第二代產品上市，市場進入穩定成長期，並於2020年後開始高速成長，但目前資料顯示穿戴裝置將會與其他智慧手持裝置並存使用的機率最高。

然而，穿戴裝置的操作行為和介面與現有的手機、平板裝置大不相容，因此在作業系統(OS)設計上也必須有所因應，而現有市場上穿戴裝置搭載之作業系統依據架構設計，約可分為原生系統改良與專屬作業系統兩大類。

原生系統改良

圖2　原生系統改良的穿戴裝置作業系統

原生系統改良的設計原理，也就是這類型的作業系統架構，主要是透過既有作業系統如Android、Windows等進行少部分的模組修改搭載於裝置上(圖2)。 論及其代表產品，基本上可以想像成手機使用的系統直接放入穿戴裝置，是目前最常見的做法，代表產品包含鉅景科技 Smart Glass、愛普生(Epson)Moverio BT-200、Vuzix Smart Glass、索尼(Sony)SmartWatch、Omate True SmartWatch等 此類型的裝置在應用程式相容性上多半不會有太大的問題，但是對於使用者介面操作與畫面顯示(如解析度、畫面物件排放位置)則須要特別注意。以智慧眼鏡為例，操作方式除了既有的觸控板控制外，還可以使用語音、手勢等元件進行操作，因此在測試過程中都必須注意(表1)。

表1　穿戴裝置的操作技術項目列表

而常見的使用者介面自動化測試，有以下三種做法：

‧	座標式
	圖3　座標式範例程式 此方式是將畫面透過座標化定義成(x,y)座標，再藉由按鈕位置或是特定的座標進行使用者介面操作，圖3所示為簡易的測試範例，此方式是最簡易也最容易達到的自動化使用者介面測試，尤其特別適用於操作介面固定的裝置上。
‧	圖像式
	圖4　圖像式範例程式 此方式主要是補足測試圖像判定以及帶有記憶作用的應用程式(圖像的位置會依據上一次使用者操作更動)，其運作原理是透過影像辨識的方式來達成使用者介面的操作(圖4)，此方式除了可以適用於動態的介面測試外，同時也大幅增加結果判定的便利性，但缺點在於因為必須透過圖形比對，因此所需的系統資源也較高。
‧	物件概念
	透過物件的方式進行介面操作，可達到跨平台測試的功能需求，但須要配合原始物件編譯且須要裝置特定權限配合，才可達成自動化測試。

專屬作業系統

這類型的作業系統架構，是依據裝置特性，打造專屬作業系統搭載於裝置上，通常會帶有特殊的專屬功能。這部分的代表產品多為國際大廠，藉由作業系統建立產品生態鏈。代表產品包含Google Glass GDK、Android Wear/L、三星(Samsung)Tizen與MTK LinkIt。

也由於是全新的作業系統，因此在效能與應用程式相容性上必須多加留意，其次則為新增功能的穩定性測試。測試時須留意以下幾個重點：

‧	原生應用程式相容性測試
	圖5　原生應用程式測試示意圖 為確認裝置搭載的原生應用程式(Native App)是否皆可正常執行(圖5)，測試程式會自動針對裝置搭載之應用程式逐一執行。
‧	應用程式壓力測試
	圖6　程式出現異常錯誤 測試重點是透過系統的隨機輸入，確保系統不會因為不合邏輯的組合操作造成應用程式或系統異常(圖6)，應用程式可能因為不正常的操作造成錯誤訊息。測試說明如表2所示。 表2　壓力測試範例說明
‧	MTTF定義
	是指某個元件預計的可運作平均時間。硬體元件故障通常是永久的，因此一般修復或替換該元件所需的時間也很重要，也就是修復前平均時間，即壽命平均值，記為故障前平均時間(MTTF)。設有No.個產品(不可修復的產品)在同樣條件下進行試驗，測得全部壽命數據為，平均壽命時間為Q： 另外，為了加速驗證程式的穩定性，亦將研發可以調整裝置處理器與記憶體負載之初始值設定。
‧	系統效能
	圖7　相同功能的應用程式因為架構產生不同的系統耗能 此部分將會影響裝置執行時的流暢性與電力使用，以手機內建的地圖功能為例，Onavo比較iOS 6內建的蘋果地圖功能與iOS 5內建的Google地圖功能，讓兩者進行同樣的搜尋定位及放大縮小動作。蘋果地圖不僅省電，在流暢性方面也有著明顯的優勢，主因在於設計原理的不同，Google地圖每個動作平均數據下載用量為1.3MB，而蘋果地圖卻只需271KB，同時越大傳輸量，也表示行為越消耗電量。因此，相似的遊戲控制動作行為也會因系統設計方法不同造成執行效率及電量的耗損(圖7)。而須要注意的系統剖析參數，則如表3所示。

表3　系統剖析參數列表

(本文作者為資策會智慧網通系統研究所組長)