與其事後Bug叢生 不如事前做好品檢
- 闞大成
-
如果把軟體從無到有的歷程，簡單分為PM、SA、SD、SE、Coding及Go Production等前前後後不同階段，毫無疑問，愈是提前將Bug逐一揪出，則軟體開發者所需付出的除錯(Debug)代價就愈輕，相反的，倘若到了系統上線後才回頭補破網，小Bug可能早已化身大惡魔，更不容易被剷除；如今進入行動App，此項規則依然適用。
以下是1個發生於1年前的真實案例。某位App作者，著手製作1支可讓大家下載某大賣場折價卷的行動應用程式，在功能尚不齊備之際，便急就章將它放上Market，結果或許是該賣場太受歡迎，導致這支還不成熟的App，就已被熱烈下載，殊不知因而惹出一堆麻煩。
因為該App內含1個按理說不太可能發生的Bug，便是將原本旨在不顯示指定資料夾的.nomedia空白檔案，誤往SD卡的根目錄裡頭塞，導致許多下載者無法讀取SD卡之中的音樂或圖片檔案，甚至造成影片檔案就此消失不見。
從這個看似不起眼的事件一葉知秋，即便再怎麼單純的App，都有可能因作者的無心之過而潛藏Bug，終至讓該App下載者蒙受其害，甚至演變成為永遠無可挽回的遺憾！任何有意或已經推出App服務的企業，理當引以為鑑，以免哪天不小心成為顧客眼中的麻煩製造者，那可是會讓原本牢牢在握的生意機會，瞬間化為烏有的！
事實上，要想阻止這場悲劇的發生，絕非無計可施，企業只要想到，過去要推出1支Client端應用程式之前，通常會根據服務導向軟體工程的法則，實施哪些測試動作，如今只需先依樣畫葫蘆，先把這些步驟給做齊，接著因應行動應用環境的特殊需求，再就原本不足的把關程序加以補齊，如此一來，很多錯誤其實都不難被提前察覺與修正。
企業必須牢記，相較於傳統的Web或Client/Server應用程式，行動App複雜度更高，蘊含的變數也較多，滋生Bug的機率理所當然更大；既然如此，企業面對各項App服務的設計開發，更加沒有便宜行事的本錢，本該把持的品質檢測程序，絕對需要嚴格把關。
App若有Bug，會更快浮出檯面
或許聽在若干程式開發人員的耳裡，「品質檢測」相當刺耳，總是自認為該留意的環節都留意到了，哪裡還有這麼多Bug待除？然而以外人看待程式開發者，卻不難發現到，他們通常非常熱衷於功能開發，沒其他事情比此更加重要，至於Debug，往往先擺在一邊，可能一個不小心疏忽了，任由App帶著嚴重Bug而粉墨登場，也是司空見慣之事。
況且人非萬能，誰能不出錯？只要能提前防微杜漸，錯誤並不可怕，可怕的是，全世界的人都已經因為Bug而落難，App服務提供者卻仍渾然不覺，或者遲遲未能推動補救措施，遇到這般情況，誰還想繼續與這家企業打交道？
有1項不甚科學的說法，但在現實世界裡，卻形容得相當貼近。假設兩支內容相近的程式，1支跑在Desktop環境，另1支則是行動App，由於作者為同一人，犯的過失也一樣，導致兩支程式都存在某1種Bug，但原先更早問世的PC應用程式，已然歷經多時，潛藏的Bug仍未被人察覺，意即尚未惹出任何事端，行動App卻不然，上架後的3天內，同樣的Bug就已浮現，成為討論區中人人爭相咒罵的對象。
為何如此？牽涉到兩支程式被使用的頻率。PC程式被使用的高峰時刻，通常不脫人們每天下班後使用電腦的有限時段，再多也不超過3小時，反觀App則不同，一天24小時全是高峰，且應用場域遍及家庭、辦公室、咖啡廳、餐廳、百貨公司、公車、捷運、火車、高鐵，不像PC程式尚需侷限於電腦螢幕前的固定位置，兩相比較之下，App所創造的流量負載，遠比PC程式巨大許多，等於是利用更短時間，讓系統被操磨了好幾番，也難怪原本潛藏於程式內部深處的Bug，竟會這麼快浮出檯面。
更值得憂心的是，個人電腦通常連結速率不低的ADSL或專線，因此人們呼叫應用程式，並不需要費時等候，即使有時因網路壅塞而拖延等待時間，但都還在忍受範圍之內；但App身處的手機應用環境可不一樣，不論以3G或Wi-Fi連網，所得的頻寬資源，都難以與有線網路望其項背，更糟糕的是，使用者所能接收的系統回應時間，卻是更加短絀，意即忍耐度相對較低。
理應實施的檢測項目，樣樣馬虎不得
在此情況下，企業若以推出PC應用服務的相同心態、相同標準，照本宣科套用在行動App之上，肯定行不通，勢必容易出現紕漏；為免招惹廣大的行動應用族群，企業萬萬不可漠視App的效能、功能與資安等相關管控措施。
如果企業認同此事確實必要，那麼在系統Go Production之前，應當執行的任務，還真的不算少！無論是基本的功能測試、壓力測試，乃至於為了清理資訊安全漏洞，所不得不然的Code Review，都已算是「基本配備」，任何事項都不容閃躲迴避，也不容草率為之，通通都應該徹底執行。
這些動作與步驟，感覺上與傳統PC應用程式上線的情境如出一轍，既然換湯不換藥，若干企業難免心想，就把原本用於PC應用環境的品質檢測機制，完完整整地搬到行動應用環境即可；這般想法與做法，還真的是只能用「錯誤百出」來形容。
先不說別的，光看1件事，就不難看出傳統檢測工具，確實並不適用於行動應用環境。賴以驅動PC應用程式的載具，一是滑鼠，二就是鍵盤，因此需要Key-in的地方相當之多，但行動App有所不同，很多情況都需要「點點點」或「滑滑滑」，單單輸入方式便大異其趣，怎麼可能兩種環境所適用的檢測工具，竟可一脈相承？換句話說，一旦發展行動解決方案，若未能與時俱進建構現代化的系統檢測框架(Framework)，卻還想停留在傳統模式，絕對是不行的。
舉例來說，有1項普及率不算低的功能測試工具，其最大的特色在於，可利用GUI來模擬人們的操作行為，比方說操作對象、操作順序，通通都會被記錄下來，繼而產出可不斷重複使用的測試腳本。面對傳統應用環境，該工具所提供的模擬器，主要是以滑鼠與鍵盤為基礎，錄製電腦的操作步驟，如今面對截然不同的嶄新應用環境，該工具也從善如流繁衍出行動版本，但在產出測試腳本的過程中，其模擬器所錄製的操作步驟，則從原本的滑鼠、鍵盤，真的變成了「點點點」、「滑滑滑」，若不做這樣的改變，根本無法應付行動App的功能測試需求。
而待測試腳本出爐後，企業便可選定某一位置，例如利用泰國機房裡頭的伺服器，指向台灣承載App的應用伺服器，重複不斷地執行固定測試，每小時做個20次、30次甚至40次都有可能，藉由反覆操磨，檢視系統是否因承受不住而當機，即使並未當機，也需要看看反應速度快不快，如果一切正常無虞，即可初步證實，先不管採用手持裝置為何，至少在泰國網路環境啟用該App服務，並不會出現問題。
此處必須強調，所謂功能測試，不過是建構行動App檢測環境時，所需具備的環節之一，其餘包括App封包分析器、SLA監控工具，乃至於App效能測試工具、黑箱或白箱安全測試工具，也都需要逐一建立。準備得愈充足，就愈能確保行動App上線前的品質檢測做得更加到位，有了這道強而有力的把關機制，放行推出的App，就必然不會是Bug叢生或動輒死當的劣質品。
