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