移動互聯網走到今天,App寡頭化的趨勢已經愈來愈明顯,同時用戶的口味愈來愈高,這對移動App開發者提出了更高的要求。幾年前可能你有一個創意,隨便作一個App,就算功能簡單,Bug不少,也會有很多用戶會使用,由於當時的選擇少。而如今,若是App的質量不過關,體驗很差,還常常崩潰閃退的話,會被好不容易得到的用戶馬上卸載掉。這就要求開發者對於App的測試愈來愈重視,而App的測試和傳統測試相比,面臨更多挑戰:程序員
如今的App迭代速度很是快,一般一個月一個大版本,兩週一個小版本,而開發人員水平良莠不齊,基本上都是臨近發佈前才能提供可測試的版本,給測試人員留出的時間很是有限,這就直接致使了測試人員可能沒法對App進行全面的測試,根本沒法保證App的質量,因此咱們常常看到不少App帶着Bug就上線了。數據庫
據統計,因爲缺少真實環境下的用戶場景,App測試遺漏環節高達20-50%。因爲測試人員自己不專業,同時缺少通用的App測試工具,致使不少App發生了崩潰嚴重問題時,測試人員很難提供給開發人員精準的崩潰日誌,讓開發者沒法精肯定位問題和分析問題。安全
目前安卓機型有幾千款之多,加上各類操做系統版本、各類屏幕尺寸、各類廠家自定義ROM,給App帶來了嚴重的兼容適配問題。而隨着蘋果發佈新機的節奏在加快,以及iOS版本不斷更新,iOS上的兼容適配問題也開始增多。App的測試人員沒有時間,沒有能力在全部機型上驗證App是否能夠正常運行,大多數狀況只能挑幾個手頭能找到的機型作簡單的驗證測試,就草草進行發佈上線,結果在最終用戶手機上出現各類意想不到的適配問題。 微信
如上圖所示,移動App測試根據產品不一樣階段分爲如下幾個階段:網絡
App代碼開發完成後,會進入內測階段,團隊內部測試人員會進行功能驗證,有能力的團隊除了人工黑盒測試外,還會使用自動化工具進行集成測試。架構
功能驗證經過後,能夠引入真實用戶進行體驗測試,根據用戶的真實反饋快速響應,迅速調整App的功能。框架
因爲目前App在不一樣手機上可能存在嚴重的兼容適配問題,進行大版本迭代,或App底層框架有所調整時,須要進行兼容測試,確保App在絕大多數手機上可以正常運行。購買市面上全部手機來一個個進行測試,不管從時間上仍是成本上來講,對普通開發者都是難以承受的,如今市面上已經有很多SAAS服務可使用,如Testin提供的兼容測試服務。工具
真實環境的複雜,用戶行爲的不可預知,致使再完美的測試,也不能保證App沒有Bug,因此App上線後的質量監控就尤其重要,這時就須要使用質量監控工具,第一時間掌握App在用戶側真實發生的各類崩潰閃退等問題。性能
接下來咱們就以上不一樣階段具體講講移動App測試都是怎麼作的。開發工具
3.1. 從傳統到如今的用例測試
App功能測試通常是團隊內部人員執行,一般進行的都是黑盒測試。目前研發團隊逐漸經過執行用例測試的方式來完成App基本功能的測試。用例測試的意義在於使得測試有針對性和目標,測試點能夠量化,測試行爲能夠控制。
App的用例測試是從傳統軟件測試繼承下來,早期的測試用例一般比較簡單和隨意,只是對功能或使用場景作了簡單的羅列,較少考慮功能的覆蓋,顆粒度大小等問題。而如今的測試用例會愈來愈多的考慮測試覆蓋率,缺陷的發現,和執行的效率等方面的影響。
具體的測試用例設計方法包括等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、斷定表驅動法、正交試驗設計法、功能圖法、場景法等,測試人員能夠根據實際狀況來量體裁衣。
App測試一般會進行如下幾個必測項目:UI測試覈對RP/效果圖;功能測試覈對需求文檔編寫測試用例覆蓋所有的功能點,對照需求文檔逐一完成驗證。這類工做一般都是純手工進行的,測試者須要維護好App的測試用例,隨着App的功能迭代,不斷更新App的測試用例,並按期進行全用例測試,保證用例覆蓋度以確保App的每一個功能點的正確運行。
3.2. 移動App的自動化測試
在App功能測試中,對於一些固定的用例執行,可使用自動化測試工具,經過編寫自動化測試腳原本執行,減小人員的重複勞動,提升整個測試的效率。
自動化測試分爲ui自動化,接口自動化,性能自動化,安全自動化。從流程來講不搭配持續集成的話就不能稱爲全流程自動化,持續集成包括的不止是自動化測試,還包括環境部署和開發打包等環節。作自動化測試時,可能測試腳本能夠作的很好,可是持續集成不是一個測試或者一個測試團隊能作好的,須要一個有決策力的人推進才能完成。而目前國內App開發團隊的領導人對移動App的自動化測試支持有限。
同時App因爲迭代速度快,機型多,這就對測試腳本維護提出了很高的要求,又因爲自動化測試腳本的代碼覆蓋度不夠,因此即便有了自動化測試,人工參與的功能測試工做量依然很大,這也致使了目前國內App自動化測試總體程度不高,只有部分大廠纔有能力簡歷App的自動化測試團隊,而通常的中小開發團隊,自動化測試能力基本爲0。
目前市面的App自動化測試工具很少,主要是國外的一些自動化測試工具,下面是App自動化測試工具對比:
關於App測試,App開發者須要提早作計劃,一個好的商業分析、清楚的目標用戶羣體以及大量的測試能夠有效下降App「無人問津」和差評不斷的概率。在把App正式發佈到最終用戶手上以前,開發者得儘量保證它是完美沒有瑕疵的。一般來講內測階段分爲幾個環節:
此階段主要由開發人員來完成檢查APP邏輯連貫性每一個功能模塊是否按照需求能夠跑通,核心功能點能力是否實現。注重於測試軟件的功能需求,功能不正確或遺漏;界面錯誤;輸入和輸出錯誤;數據庫訪問錯誤;性能錯誤;初始化和終止錯誤等。
開發人員在完成內部邏輯驗證後會搭建測試環境供測試者來在測試環境下完成內測。這個測試人員有多是專職的測試者,也有些團隊是動用公司的其餘人力資源來完成,如產品經理和老闆其餘同事,不論是哪些人來完成測試,測試行爲必須可以加以量化,才能真正保證軟件質量,而測試用例就是將測試行爲具體量化的方法之一。
在開發團隊和測試團隊完成內部測試後,採用小範圍用戶測試的方式能夠在最小的成本下驗證App對目標用戶的接受程度,須要作好用戶反饋收集的渠道,調查問卷、App中加入吐槽反饋功能、用戶交流羣、都是經常使用的收集反饋的渠道。
移動App測試過程當中,因爲迭代速度快,App包更新頻繁,開發人員和測試人員之間沒有很好的工具進行App的傳送。
此外在App測試中,提交Bug時截圖上傳比較麻煩,獲取App日誌須要專門工具,這些對於測試人員已經比較困難,對於引入的灰度測試用戶更是難於登天。
Testin提供的專業的App內測工具:pre.im主要就是解決以上內測中問題:
只需一步上傳,便可生成應用短地址,解決開發人員和測試人員之間傳包的問題。
完善的版本記錄,方便管理快速迭代的各類App版本。
強大的內測專用SDK,測試者不須要使用任何工具,只須要在出現Bug時搖一搖手機,便可自動完成Bug截屏,並讀取當時App的運行Log、內存、CPU等信息,連同Bug截圖和描述一同提交給開發者,幫助開發者更精準定位問題。
真實環境的複雜,用戶行爲的不可預知,致使再完美的測試,也不能保證App沒有Bug,因此App上線後的質量監控就尤其重要,這時就須要使用質量監控工具,第一時間掌握App在用戶側真實發生的各類崩潰閃退等問題。
對於開發者來說,最頭疼的問題就是App用戶反饋本身手機上出現了崩潰,卻始終沒法提供具體的崩潰信息,結果開發者明知道問題存在,卻只能眼睜睜看着用戶流失。
大量的App花費了巨大的市場和研發資源投入,卻在應用上線後「裸奔」,它意味着開發者不能第一時間發現應用在運行過程當中出現的各種質量問題,如崩潰、閃退、內存泄露等問題,而此時用戶卻對這些不佳的產品體驗深惡痛絕。
一個好消息是,目前市面上已經有很多專門解決質量監控的工具能夠供開發者使用,如友盟就在其SDK中集成了錯誤捕捉的功能,而對崩潰定位要求較高的開發者也可使用Testin的崩潰分析SDK,實時收集App在不一樣環境下的產品體驗,從網絡、版本、渠道、運營商、設備五個維度深刻分析用戶的使用狀況,幫助開發者快速定位並解決崩潰、閃退、異常等問題,優化App性能,提升App的用戶體驗和質量,下降用戶流失率。
Testin的崩潰分析SDK目前和Pre.im的內測SDK已經進行深度融合,開發者只需嵌入一個SDK,便可完成從內測階段的問題收集到App發佈後的質量監控,而這個SDK的接入成本較低,只須要修改一行代碼,三分鐘內完成嵌入。
移動App體驗和質量要求愈來愈高的今天,但願開發者更加劇視App的測試,提升程序員對測試的重視,將測試集成到整個開發流程中,同時多采用各種測試工具或服務,進一步提升開發效率和保證App質量。
把生命浪費在美好的事物上,而不是枯燥的測試。
【活動預告】 2015年11月18日,由CSDN主辦的「2015開發工具及服務年度大獎評選」活動正式啓動。近兩年,開發工具及服務不斷涌現,從雲服務、即時通信、安全到統計監測、人工智能、物聯網平臺等。CSDN將經過公開徵集,並結合平臺內用戶數據採集分析,評選出CSDN 2015開發工具及服務年度大獎。趕快爲你的開發工具與服務報名參與評選吧。更多詳情,請關注評選活動官網。
做者簡介:
徐琨,Testin雲測總裁。80後,國內第一代移動互聯網公司PICA創始成員,曾任PICA技術副總裁;後做爲千萬人在線的即時通訊系統架構師,領導開發了移動社交平臺移動139社區;2011年創辦主打HTML5遊戲的北京山水地信息有限公司,出品H5遊戲《小鳥情人》,是中國H5手遊領域探索的先行者;2014年加入Testin雲測,歷任CTO、總裁等職。徐琨畢業於長春理工大學,擁有計算機學士學位
已