与其事后Bug丛生 不如事前做好品检

App在Go Production前，需做好严谨测试。

如果把软件从无到有的历程，简单分为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丛生或动辄死当的劣质品。