1. 移動App測試的現(xiàn)狀及其挑戰(zhàn)
移動互聯(lián)網(wǎng)走到今天，App寡頭化的趨勢已經(jīng)越來越明顯，同時用戶的口味越來越高，這對移動App開發(fā)者提出了更高的要求。幾年前可能你有一個創(chuàng)意，隨便做一個App，就算功能簡單，Bug很多，也會有不少用戶會使用，因為當時的選擇少。而現(xiàn)在，如果App的質(zhì)量不過關(guān)，體驗不好，還經(jīng)常崩潰閃退的話，會被好不容易獲得的用戶立刻卸載掉。這就要求開發(fā)者對于App的測試越來越重視，而App的測試和傳統(tǒng)測試相比，面臨更多挑戰(zhàn)：
·App迭代速度快，測試時間少
現(xiàn)在的App迭代速度非�？�，通常一個月一個大版本，兩周一個小版本。而開發(fā)人員水平參差不齊，基本上都是臨近發(fā)布前才能提供可測試的版本，給測試人員留出的時間非常有限。這就直接導致了測試人員可能無法對App進行全面的測試，根本無法保證App的質(zhì)量，所以我們經(jīng)�？吹胶芏郃pp帶著Bug就上線了。
·App測試的準確性和問題追蹤難以保證
據(jù)統(tǒng)計，由于缺乏真實環(huán)境下的用戶場景，App測試遺漏環(huán)節(jié)高達20-50%。由于測試人員本身不專業(yè)，同時缺乏通用的App測試工具，導致很多App發(fā)生了崩潰嚴重問題時，測試人員很難提供給開發(fā)人員精準的崩潰日志，讓開發(fā)者無法精確定位問題和分析問題。
·手機機型分裂越來越嚴重，App兼容問題突出
目前Android機型有幾千款之多，加上各種操作系統(tǒng)版本、各種屏幕尺寸、各種廠家自定義ROM，給App帶來了嚴重的兼容適配問題。而隨著蘋果發(fā)布新機的節(jié)奏在加快，以及iOS版本不斷更新，iOS上的兼容適配問題也開始增多。App的測試人員沒有時間，沒有能力在所有機型上驗證App是否可以正常運行，大多數(shù)情況只能挑幾個手頭能找到的機型做簡單的驗證測試，就草草發(fā)布上線，結(jié)果可想而知，就是在最終用戶手機上出現(xiàn)各種意想不到的適配問題。
2. 移動App測試的幾個階段
如上圖所示，移動App測試根據(jù)產(chǎn)品不同階段分為以下幾個階段：
·功能測試
App代碼開發(fā)完成后，會進入內(nèi)測階段。團隊內(nèi)部測試人員會進行功能驗證，有能力的團隊除了人工黑盒測試外，還會使用自動化工具進行集成測試。
·體驗測試
功能驗證通過后，可以引入真實用戶進行體驗測試，根據(jù)用戶的真實反饋快速響應，迅速調(diào)整App的功能。
·兼容測試
由于目前App在不同手機上可能存在嚴重的兼容適配問題，進行大版本迭代，或App底層框架有所調(diào)整時，需要進行兼容測試，確保App在絕大多數(shù)手機上能夠正常運行。購買市面上所有手機來一個個進行測試，無論從時間上還是成本上來說，對普通開發(fā)者都是難以承受的。也正因如此，市面上出現(xiàn)了許多第三方服務來幫助開發(fā)者們完成兼容性測試。
·質(zhì)量監(jiān)控
真實環(huán)境的復雜，用戶行為的不可預知，導致再完美的測試也不能保證App完美得沒有Bug，所以App上線后的質(zhì)量監(jiān)控就尤為重要。這時就需要使用質(zhì)量監(jiān)控工具，第一時間掌握App在用戶端真實發(fā)生的各種崩潰閃退等問題。
接下來我們就以上不同階段具體講講移動App測試都是怎么做的。
3. 不同于傳統(tǒng)測試的App功能測試
3.1 從傳統(tǒng)到現(xiàn)在的用例測試
App功能測試一般是團隊內(nèi)部人員執(zhí)行，通常進行的都是黑盒測試。目前研發(fā)團隊逐漸通過執(zhí)行用例測試的方式來完成App基本功能的測試。用例測試的意義在于使得測試有針對性和目標，測試點可以量化，測試行為可以控制。
App的用例測試是從傳統(tǒng)軟件測試繼承下來，早期的測試用例通常比較簡單和隨意，只是對功能或使用場景做了簡單的羅列，較少考慮功能的覆蓋、顆粒度大小等問題。而現(xiàn)在的測試用例會越來越多地考慮測試覆蓋率、缺陷的發(fā)現(xiàn)和執(zhí)行的效率等方面的影響。
具體的測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、判定表驅(qū)動法、正交試驗設計法、功能圖法、場景法等，測試人員可以根據(jù)實際情況來量體裁衣。
App測試通常會進行以下幾個必測項目：UI測試核對RP/效果圖；功能測試核對需求文檔編寫測試用例覆蓋全部的功能點，對照需求文檔逐一完成驗證。這類工作通常都是純手工進行的，測試者需要維護好App的測試用例，隨著App的功能迭代，不斷更新App的測試用例，并定期進行全用例測試，保證用例覆蓋度以確保App的每個功能點的正確運行。
3.2 移動App的自動化測試
在App功能測試中，對于一些固定的用例執(zhí)行，可以使用自動化測試工具，通過編寫自動化測試腳本來執(zhí)行，減少人員的重復勞動，提高整個測試的效率。
自動化測試分為UI自動化、接口自動化、性能自動化和安全自動化。從流程來說不搭配持續(xù)集成的話就不能稱為全流程自動化，持續(xù)集成包含的不止是自動化測試，還有環(huán)境部署和開發(fā)打包等環(huán)節(jié)。進行自動化測試時，可能測試腳本可以做得很好。但持續(xù)集成不是一個測試或一個測試團隊就能做好的，需要一個有決策力的人推動才能完成，而目前國內(nèi)App開發(fā)團隊的領(lǐng)導人對移動App的自動化測試支持有限。
同時，App由于迭代速度快，機型多，這就對測試腳本維護提出了很高的要求，又由于自動化測試腳本的代碼覆蓋度不夠，所以即使有了自動化測試，人工參與的功能測試工作量依然很大。這也導致了目前國內(nèi)App自動化測試整體程度不高，只有部分大廠才有能力建立App的自動化測試團隊，而一般的中小開發(fā)團隊，自動化測試能力基本為0。
目前市面的App自動化測試工具不多，主要是國外的一些自動化測試工具，下面是App自動化測試工具對比：
4. App開發(fā)者應如何開展內(nèi)測
關(guān)于App測試，開發(fā)者需要提前做計劃，一個好的商業(yè)分析、清楚的目標用戶群體以及大量的測試可以有效降低App“無人問津”和差評不斷的幾率。在把App正式發(fā)布到最終用戶手上之前，開發(fā)者得盡可能保證它是完美沒有瑕疵的。通常來說，內(nèi)測階段分為幾個環(huán)節(jié)：
·開發(fā)團隊內(nèi)部流程測試
此階段主要由開發(fā)人員來完成，檢查App邏輯連貫性每個功能模塊是否按照需求可以跑通，核心功能點能力是否實現(xiàn)。注重于測試軟件的功能需求，功能不正確或遺漏；界面錯誤；輸入和輸出錯誤；數(shù)據(jù)庫訪問錯誤；性能錯誤；初始化和終止錯誤等。
·測試人員介入測試環(huán)境測試
開發(fā)人員在完成內(nèi)部邏輯驗證后，會搭建測試環(huán)境供測試者來在測試環(huán)境下完成內(nèi)測。這個測試人員有可能是專職的測試者，也有些團隊是動用公司的其他人力資源來完成，如產(chǎn)品經(jīng)理、BOSS或其他同事。不管是哪些人來完成測試，測試行為必須加以量化，才能真正保證軟件質(zhì)量，而測試用例就是將測試行為具體量化的方法之一。
·目標用戶引入灰度測試
在開發(fā)團隊和測試團隊完成內(nèi)部測試后，采用小范圍用戶測試的方式可以在最小的成本下驗證App對目標用戶的接受程度。這時需要做好用戶反饋收集的渠道，常見的渠道有調(diào)查問卷、App中加入吐槽反饋功能、用戶交流群等。
移動App測試過程中，由于迭代速度快，App包更新頻繁，開發(fā)人員和測試人員之間沒有很好的工具進行App傳送。此外，提交Bug時截圖上傳比較麻煩，獲取App日志需要專門工具，這些對于測試人員已經(jīng)比較困難，對于引入的灰度測試用戶更是難于登天。
針對這些問題，我們進行了解決方案的研發(fā)實踐。以第三方內(nèi)測服務pre.im幫助開發(fā)者與測試人員解決傳包問題，并擁有完善的版本記錄，方便管理快速迭代的各種App版本。其內(nèi)測專用SDK讓測試者無需使用任何工具，只需在出現(xiàn)Bug時搖一搖手機，即可自動完成Bug截屏，并讀取當時App的運行Log、內(nèi)存、CPU等信息，連同Bug截圖和描述一同提交給開發(fā)者，幫助開發(fā)者更精準定位問題。
5. 發(fā)布后的App質(zhì)量監(jiān)控
真實環(huán)境的復雜，用戶行為的不可預知，導致再完美的測試，也不能保證App沒有Bug，所以App上線后的質(zhì)量監(jiān)控就尤為重要。這時就需要使用質(zhì)量監(jiān)控工具，第一時間掌握App在用戶側(cè)真實發(fā)生的各種崩潰閃退等問題。
對于開發(fā)者來講，最頭疼的問題就是App用戶反饋自己手機上出現(xiàn)了崩潰，卻始終無法提供具體的崩潰信息。結(jié)果開發(fā)者明知道問題存在，卻只能眼睜睜看著用戶流失。
大量的App花費了巨大的市場和研發(fā)資源投入，卻在應用上線后“裸奔”。它意味著開發(fā)者不能第一時間發(fā)現(xiàn)應用在運行過程中出現(xiàn)的各類質(zhì)量問題，如崩潰、閃退、內(nèi)存泄露等，而此時用戶卻對這些不佳的產(chǎn)品體驗深惡痛絕。
一個好消息是，目前市面上已經(jīng)有不少專門解決質(zhì)量監(jiān)控的工具可以供開發(fā)者使用，如友盟就在其SDK中集成了錯誤捕捉的功能，而對崩潰定位要求較高的開發(fā)者也可以使用Testin的崩潰分析SDK，實時收集App在不同環(huán)境下的產(chǎn)品體驗，從網(wǎng)絡、版本、渠道、運營商、設備五個維度深入分析用戶的使用情況，幫助開發(fā)者快速定位并解決崩潰、閃退、異常等問題，優(yōu)化App性能，提高App的用戶體驗和質(zhì)量，降低用戶流失率。
6.結(jié)語
移動App體驗和質(zhì)量要求越來越高的今天，希望開發(fā)者更加重視App的測試，提高程序員對測試的重視，將測試集成到整個開發(fā)流程中，同時多采用各類測試工具或服務，進一步提高開發(fā)效率和保證App質(zhì)量。
作者簡介：徐琨，Testin云測總裁。80后，國內(nèi)第一代移動互聯(lián)網(wǎng)公司PICA創(chuàng)始成員，曾任PICA技術(shù)副總裁；后作為千萬人在線的即時通信系統(tǒng)架構(gòu)師，領(lǐng)導開發(fā)了移動社交平臺移動139社區(qū)；2011年創(chuàng)辦主打HTML5游戲的北京山水地信息有限公司，出品H5游戲《小鳥情人》，是中國H5手游領(lǐng)域探索的先行者；2014年加入Testin云測，歷任CTO、總裁等職。徐琨畢業(yè)于長春理工大學，擁有計算機學士學位。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領(lǐng)域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題：移動測試：應用上線不“裸奔”的正確方式
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839318947.html
相關(guān)文章
