OESF開放嵌入式軟體基金會 符合日本品質的Android測試平台

OESF開放嵌入式軟體基金會執行主任關根達記(Tad Sekineh)

嵌入式裝置業者常面臨到隱藏於規格、架構與軟體應用上的臭蟲，越晚被找出將累積越龐大的測試時間，甚至上市後回收還會造成的鉅額損失。日本業者推出針對Android OS平台開發出一系列自動化測試驗證的套件，以及針對業者量身打造的自動化測試項目，能有效的降低新產品測試驗證的時間與投入的測試人力，並加速產品的上市速度….

OESF(Open Embedded Software Foundation；開放嵌入式軟體基金會)執行主任關根達記(Tad Sekineh)首先介紹OESF是個商業型態的法人組織，目前在日本東京、南韓首爾、中國上海與台灣台北都設有辦事處。主要業務是針對Android OS平台下的嵌入式系統、非蜂巢式行動電話，並負責Google的一些專案，以根基於Apache 2.0開放源碼規範，加上OESF知識庫與工作小組專案計畫；OESF尋求產業聯盟合作進行標準化，降低時間成本並拓展商機。在差異化部份，追求即時上市、獨特性的服務性平台與內容獨立的硬體。

OESF為開放型嵌入式裝置軟體發展的基金會

目前OESF底下有11個工作小組，包含有SetTopBox機上盒、SystemCore系統核心、Application & Service應用程式與服務、Market行銷、Education教育、IP-
Communication IP通訊、Automotive汽車電子、Future Systemsx未來系統、Distribution 經銷商、SmartHouse智能家庭。

規格檢驗╱驗證與偵錯的時間成本

關根達記提到檢驗(Verification)與驗證(Validation)差別，前者是我們建立的軟體是否正確並符合規範，後者則是我們是否建立了正確的軟體並符合客戶所需要。他也提到越後面階段才找出臭蟲╱錯誤，所耗費的時間成本甚鉅。如果在建構階段就找出臭蟲，需花費1個單位的測試時間，若到系統整合測試階段才找出，則需花10倍測試時間；到了即將推出時才發現錯誤，則可能要花10~25倍測試時間。

若在早先選用架構階段就找出錯誤，花費大約1單位測試時間，到建構系統階段才發覺問題，則需花上10倍測試時間，到後端系統整合測試階段才發現錯誤，則需花上15倍測試時間，到即將推出時才找到，則可能要花25~100倍測試時間。

若一開始就掌握規格的問題所在，花費1倍單位測試時間，到選用架構階段才發覺規格需求問題，則需花掉3倍單位測試時間，到系統建構、整合階段才找出錯誤，則需花上5~10倍單位測試時間；一旦到即將推出時才發現錯誤，則可能要花上10倍甚至百倍的單位測試時間。

關根達記也提到臭蟲(bug)還是規格(spec)限制，是在偵錯階段就必須先釐清的。像
有些計算機按下4.52 – 4.49 = 0.029999999而不是出現0.03，按下1÷3×3 = 0.9999999而非1，這是當初浮點運算規格上的限制。另外他也提到幾個在智慧手機發生的案例，第一個是從簡訊或來電取得對方號碼回覆時，會擷取到錯誤字串而變成回撥到自己號碼的情況。第二個是蘋果iPhone曾發生跟iPod Touch同步後，會有服務業者名稱消失的情況。還有一個是日本手機訂票時，顯示出不知所云的訊息。諸如此類在上市後才被抓到錯誤的情況不勝枚舉。

測試範圍╱成本取捨與測試計畫的擬定

關根達記認為，業者進行規格確認與測試時，要先從用戶經驗與回饋來進行數據分析，確認哪些項目必要，到怎樣程度的測試，並從過去臭蟲的歷史紀錄、用戶使用模式、簡單還是複雜功能以及其他重要資料等。接下來是測試工具，可運用規格與通過與否的表格垂直交叉分析、成對測試與使用情況紀錄等方式進行。

目前所有嵌入式行動裝置的排列測試組合近乎無限多種，都要一一列入測試所耗費的時間成本太過龐大；若降為300萬種測試組合，估計大約可涵蓋所有必測項目以及應測項目，但測試時間與成本的縮減還是不夠。若把測試組合降為僅15萬種，則涵蓋到當前必測項目以及部份應測項目，把測試時間成本能夠降到最低。

在進行品管測試程序時，先確立品管計畫、預覽、品質分析與驗證、原因分析與避免方式。接下來在品管控制程序需擬定測試策略、測試計畫與引述、流程管理與錯誤管控。它細分成：1. Control Process(控制階段) 與2. Testing Process(測試階段)。首先在Kick-off(推出)、開始進入測試程序，此時需先針對測試需求定義，據此擬定控制階段的測試計畫；接下來才進入到所謂的Test Design(測試設計)。

接下來進入到測試環境建立、測試執行、錯誤回報、錯誤趨勢分析、回饋到收尾(Closure)，這整個測試流程都是最繁瑣、耗費測試人力與時間資源的部份，所以可以針對這個範圍進行最佳化，像是減少測試項目、改良涵蓋率、改進檢錯率與介紹測試工具等。

關根達記提到測試流程應先從：1.測試項目的定義。像是哪些功能需要測試與驗證，硬體認證與連接性。這部份涵蓋硬體測試與協定測試兩階段。2.測試組合。像是規格、等級判定與測試要件、協定以及現場測試。以上這涵蓋了標竿測試、效能測試與Google CTS套件驗證三個階段。3.報告。像功能、統計與可行的解決方案。這由Enhanced CTS套件以及應用程式測試兩階段來負責。

Android平台下的最佳自動化╱可訂製化套件

關根達記指出，目前Android約有10萬個應用程式，而深入Android平台下有Android驅動程式約33,000個，google服務項目有9,000個，支援的Protocol協定有6,000個，硬體驗證項目則有USB、WiFi、Bluetooth、HDMI等 Certification與Power management Test等。目前廣為開發業者所採用的Google CTS相容性測試套件，只能測試300套應用程式、1,000項Android驅動程式、Google服務與支援協定，涵蓋到6%的必須測試項目，且硬體驗證項目無法進行，其他項目則必須用人力方式進行測試驗證。

OESF所開發的Enhanced CTS(增強型相容測試套件)，以及針對每一個開發商獨一無二的Extended CTS延伸套件加入測試下，可以使整個Android平台從開發、相容性、服務、硬體與設備互連測試項目均達到自動化，縮減測試時間並減少測試人力。他舉例，以1個人每天測100個項目，配置10個測試員，前導驗證時間2個月計算，約驗證60,000個項目；導入OESF的ECTS之後，可以針對其中33,000項目進行全自動化測試╱驗證回報，因此僅剩下27,000項目需配置測試人力，在一樣是2個月驗證期間，則測試人力可降為只需5位即可。

OESF的綜合測試過程，是藉由Google CTS的9,000個項目，以及OESF ECTS提供33,000個自動化測試項目，達到接近一半的測試驗證項目的自動化，另外OESF可跟廠商合作開發Extended CTS，涵蓋並補足其他仍需人工測試驗證的項目。可配合的廠商從軟體開發商(S/W Development Vendor)、ODM到OEM，也可針對發行者要追加的測試項目上來搭配。

在提昇Android軟體品質這部份，目前OESF提供18,000標準Android功能測試，以及超過40,000項專屬功能測試，項目涵蓋核心、應用程式介面(API)與應用服務，從基本項目、衝突點、門檻值與壓力測試均涵蓋其中。據參與OESF測試套件計畫的廠商資料，可以在設計測試階段，每個月節省1,100萬日圓，執行測試階段每月節省2,600萬日圓，最後報告階段節省3,700萬日圓。

目前OESF提供一次性免費服務，只要告知設計裝置的規格，在簽下NDA保密協定後，OESF會告知該組織可以進行自動化的項目，若提供該裝置2個星期左右，就會給客戶1份簡略的測試報告，涵蓋部份Google CTS與Enhanced CTS的測試項目。