如何保證APP兼容性覆蓋測試

如何保證APP兼容性覆蓋測試.背景眾所周知，APP兼容性覆蓋測試一直以來被認(rèn)為是一個高成本、耗時低效、耗人力的測試工作，且兼容性測試是一項必須要進(jìn)行的測試項目，因為有不同的機(jī)型、系統(tǒng)平臺、分辨率、網(wǎng)絡(luò)、廠商、數(shù)據(jù)兼容以及不同兼容問題場景需要進(jìn)行覆蓋。本文章將通過本人測試經(jīng)驗圍繞質(zhì)量和測試效率進(jìn)行闡述如何保證APP兼容測試覆蓋，期望有更多童鞋在既能保證兼容質(zhì)量的同時、又能高效地完成兼容性測試覆蓋。.認(rèn)識APP兼容測試什么是兼容測試兼容性測試將驗證軟件與其所依賴的環(huán)境的依賴程度，包括對硬件平臺的依賴和對軟件平臺依賴程度，即我們通常說的軟件的可移植性。簡單來說：待測試項目在同一個操作系統(tǒng)平臺的不同版本、不同的操作系統(tǒng)平臺上是否能很好的運行待測項目是否能與相關(guān)的其他軟件和平共處，會不會有相互不良的影響待測項目是否能在指定的硬件環(huán)境中正常運行，軟件和硬件之間能否發(fā)揮很好的效率工作，會不會影響或?qū)е孪到y(tǒng)的崩潰待測項目是否能在不同的網(wǎng)絡(luò)環(huán)境中正常運行什么是APP兼容測試APP兼容測試即是移動端的手機(jī)客戶端兼容測試。移動終端的碎片化特征使APP測試者為了保障不同系統(tǒng)及版本、不同網(wǎng)絡(luò)制式、不同分辨率和廠商（不同深度定制的ROM）、不同版本都能夠有很好的用戶體驗而面臨巨大挑戰(zhàn)，所以APP兼容性測試也是測試質(zhì)量保障任務(wù)中的重要環(huán)節(jié)。.兼容測試維度覆蓋保證兼容測試質(zhì)量APP兼容測試具備測試點多，碎片化嚴(yán)重的特征，兼容測試一旦存在漏測，質(zhì)量未得到保障就會導(dǎo)致線上用戶的流失。所以在移動開發(fā)中兼容性測試常常需要涉及到系統(tǒng)、廠商ROM、屏幕分辨率、網(wǎng)絡(luò)、等其他眾多維度。下面將詳細(xì)展開介紹兼容測試需要覆蓋的各個維度。系統(tǒng)兼容app系統(tǒng)兼容涉及Android和Ios系統(tǒng)，其中Android系統(tǒng)又分了不同的系統(tǒng)版本，Ios又分不同的系統(tǒng)版本。不同的系統(tǒng)、不同的系統(tǒng)版本都有不同的特征，不同的API，意味著都有可能產(chǎn)生各種各樣的兼容問題，所以需要進(jìn)行兼容覆蓋。其中Android系統(tǒng)具體分布及市場占有率如下表所示：

VersionCodenameAPIDistribution2.3.3-Gingerbread100.4%2.374.03-IceCream150.5%4.04Sandwich4.1.xJellyBean162.0%4.2.x173.0%4.3180.9%4.4KitKat19134%5,0Lollipop216,1%5,12220.2%6.0Marshmallow2329.7%7.0Nouaat24193%從表中數(shù)據(jù)可以得出，Android4.4以下市場占有率不到8%，份額小且適配難度高，越來越多的開發(fā)者選擇了放棄對舊版本的支持，如果目前項目APP的開發(fā)者已不支持舊版本兼容尤其是Android2.3之前的，那么測試也可以選擇放棄對該類型版本的兼容。其中Ios不同的系統(tǒng)版本具體分布及市場占有率如下:

LastUjMa^rMay曬120用艙33般AdoptionTrendsAllPlatforms：1LX10J應(yīng)修9.X8.3%8.X0魏7X口歌從表中數(shù)據(jù)可以得出，Ios8.X以下市場占有率不到2%，可以選擇放棄8.X以下版本的兼容，重點覆蓋8.X,11.X，10.X，9.X系統(tǒng)的覆蓋。廠商兼容Android和Ios都有不同的手機(jī)設(shè)備，蘋果幾乎每年會進(jìn)行一次換代，目前換代到iphoneX。相比而言，Android系統(tǒng)源碼是開放的，只要遵從相應(yīng)的協(xié)議，就可以對源碼進(jìn)行修改，國內(nèi)各個廠商就把基于Android源碼改造成自己對外發(fā)布的系統(tǒng)，比如我們熟悉的小米手機(jī)Miui系統(tǒng)、華為手機(jī)EMUI系統(tǒng)、Oppo手機(jī)ColorOS系統(tǒng)等（只有谷歌Nexus和Pixel系列才是原生系統(tǒng)，但是目前國內(nèi)很少人用。）由于每個廠商都修改過Android原生系統(tǒng)源碼，這里面就會引發(fā)一個問題，那就是著名的Android碎片化問題，本質(zhì)就是不同Android系統(tǒng)的應(yīng)用兼容性不同，哪怕是搭載完全相同的硬件，不同品牌的手機(jī)在運行速度、軟件兼容上都會有區(qū)別的。屏幕分辨率兼容在不同分辨率、尺寸的設(shè)備上，很容易出現(xiàn)字體異常、UI樣式異常、換行錯位等UI問題，所以需要測試程序在不同尺寸和不同的分辨率下能否正常顯示目前市面上主流的分辨率為：1280x720、2560*1440、1920x1080等等，主流的尺寸是5.5，5.0和4.7。網(wǎng)絡(luò)兼容保證各種網(wǎng)絡(luò)環(huán)境能夠覆蓋，包括WiFi、3大運營商的2G和3G、4G網(wǎng)絡(luò)、有鑒權(quán)的wifi和無鑒權(quán)的wifi.按運營商分：電信、移動、聯(lián)通按網(wǎng)絡(luò)模式分：2G、3G、4G、WiFi按接入點分：wap、net在目前4G，wifi盛行的時代在非視頻游戲類APP測試中網(wǎng)絡(luò)兼容顯得沒那么重要。一般APP網(wǎng)絡(luò)的兼容主要是針對IPV6網(wǎng)絡(luò)兼容、弱網(wǎng)兼容、wap和net接入、不同地域（地理位置）的運營網(wǎng)絡(luò)、有鑒權(quán)的wifi和無鑒權(quán)的wifi、代理類wifi。其他兼容數(shù)據(jù)兼容性（不同版本間的數(shù)據(jù)兼容）藍(lán)牙設(shè)備兼容性測試（如果是一款使用藍(lán)牙的應(yīng)用）存儲卡兼容性測試（比如文件管理器）第三方軟件兼容沖突（比如輸入法沖突）.制定測試策略提升兼容測試效率從上一章節(jié)中可以看到，APP兼容性測試需要覆蓋的維度就有那么多，每個維度可以繼續(xù)分裂，兼容性測試關(guān)注點如此之多，不可能在測試階段每個機(jī)型每個系統(tǒng)版本網(wǎng)絡(luò)等進(jìn)行逐個覆蓋，那么怎么在既保證質(zhì)量的同時，又提高測試效率呢？下面將會從測試需求階段到上線監(jiān)控階段的測試全流程中，講解每個測試環(huán)節(jié)應(yīng)該制定怎樣的測試策略來提升兼容性測試效率。需求階段測試越早介入，測試的成本就越低，兼容性測試也是如此。需求分析階段，測試童鞋需要和開發(fā)、產(chǎn)品、設(shè)計師根據(jù)需求的場景、歷史運營用戶數(shù)據(jù)、市場占有率數(shù)據(jù)討論及確定好當(dāng)前版本需求兼容的系統(tǒng)、系統(tǒng)版本、廠商、屏幕分辨率、網(wǎng)絡(luò)等的適配方案，這樣測試童鞋在需求階段確定好需要裁剪的系統(tǒng)，系統(tǒng)版本、分辨率兼容。例如：系統(tǒng)版本兼容覆蓋上：如果Android4.4以下市場占有率不到8%，份額小且適配難度高，目前項目APP的開發(fā)者已不支持舊版本兼容Android4.4之前的，那么測試可以在需求階段和產(chǎn)品、開發(fā)確認(rèn)選擇裁剪對該類型版本的兼容。版本差異兼容覆蓋上：需求階段和產(chǎn)品、開發(fā)了解程序底層交互及接口調(diào)用，結(jié)合本次適配測試重點，就能知道著重檢查哪些頁面和交互，原則上如果版本之間差異無前端UI和交互變動，則可以裁剪該版本的兼容覆蓋。屏幕分辨率及尺寸：與開發(fā)or設(shè)計師討論在不同的分辨率下系統(tǒng)的適配方案，對已不支持不適配的分辨率和尺寸進(jìn)行裁剪測試設(shè)計階段組合交叉矩陣測試設(shè)計通過做一些調(diào)研，當(dāng)前市場和線上運營用戶的各系統(tǒng)版本、廠商的使用率，結(jié)合移動設(shè)備分辨率的特性，得出APP的兼容測試矩陣，減少用例的重復(fù)設(shè)計和冗余。例如下表（參考）：APP兼容矩陣設(shè)計（僅供參考）隼臺崇能阮本甘桃甲尺寸「酬屋俸善)洌試是鬼(p/rf105BXU3京調(diào)口SiPhoneSS(㈣9.01545*22064.7iPhone17,3175T呼我4.7iPhone6S921024*7607qipadminiS31136*6405iPhoneSE10。1920110605.5IPhont?P10.11920*10W55iplion^gPLQ21920*10005JiphanebSP((0P)LLX1334x7504.7iPhoneB11X2436"11255^5iPhonex41，1280'80053二星6T-I9228『星34.ZX123￡1.7&B47NEXU544.3.X貿(mào)時劃5.5三星GALAX*14.4.X1520-10805C55]OPPOkMv1若：5.0若&0*14&05HTConeM9E5,112和“7205小泉nowjfeKPRDS氐口1?0*]0806華為出ATE?7.01920"10805.9MATES7.1石皿k144G5.7B.019ZO"1C3U%第用根據(jù)具體測試場景進(jìn)行兼容測試用例設(shè)計兼容性測試關(guān)注點有很多，有效的方法是根據(jù)測試項或者系統(tǒng)版本的特點、場景實現(xiàn)角度可以對明顯差異的內(nèi)容選擇性進(jìn)行測試設(shè)計，減少不必要的兼容覆蓋設(shè)計。具體場景特征角度舉例如下：(1)類似圖片上傳、ocr識別、人臉識別這種與攝像頭、手機(jī)相冊與手機(jī)系統(tǒng)應(yīng)用交互的場景需要考慮系統(tǒng)權(quán)限和系統(tǒng)廠商的特征兼容，所以如果有相關(guān)需求場景的在測試設(shè)計時需重點考慮廠商、系統(tǒng)版本的兼容(2)類似UI元素密集或圖片上傳場景，則與分辨率強(qiáng)關(guān)聯(lián)，在測試設(shè)計時該類需求需重點兼容屏幕分辨率維度(3)類似視頻播放、數(shù)據(jù)上傳下載、需要實時進(jìn)行數(shù)據(jù)刷新的場景則與網(wǎng)絡(luò)強(qiáng)關(guān)聯(lián)，網(wǎng)絡(luò)的強(qiáng)弱會很影響用戶體驗，在測試設(shè)計時該類需求需重點考慮網(wǎng)絡(luò)的兼容(與網(wǎng)絡(luò)兼容強(qiáng)關(guān)聯(lián))從功能實現(xiàn)角度舉例如下：(1)類似頁面數(shù)據(jù)獲取，按鈕跳轉(zhuǎn)不涉及網(wǎng)絡(luò)請求后端服務(wù)的，直接從本地數(shù)據(jù)庫獲取數(shù)據(jù)來實現(xiàn)的功能則可以直接考慮裁剪網(wǎng)絡(luò)兼容測試設(shè)計（2）類似PUSH測試等無UI設(shè)計的功能則可以考慮直接裁剪屏幕分辨率、尺寸的兼容測試（3）類似通過webview頁面展示的功能，例如webview在Android4.4以后有http與https的安全認(rèn)證方式的區(qū)別，默認(rèn)不保存cookie的區(qū)別，那么針對類似用webview實現(xiàn)的頁則需要重點考慮系統(tǒng)版本的兼容設(shè)計從系統(tǒng)版本，廠商特征角度舉例如下：（1）android6.0以上的部分危險權(quán)限需要通過運行時動態(tài)申請。所以涉及權(quán)限相關(guān)功能如定位功能、相機(jī)使用，相冊調(diào)用功能、存儲權(quán)限、讀取通訊錄、讀取sd卡等功能運行使用時的權(quán)限對話框均需要進(jìn)行系統(tǒng)6.0以下和6.0以上版本兼容測試設(shè)計（2）android8.0通知欄的機(jī)制有較大的變化，需要特別留意通知欄、消息推送、通知彈窗、懸浮窗等的兼容測試設(shè)計（3）ROM有特殊定制功能例如典型的三星，vivo和oppo的權(quán)限管理問題：對于國外的手機(jī)比如三星，不詢問權(quán)限直接調(diào)用，會直接崩潰，這符合android原生系統(tǒng)的權(quán)限管理策略。對于國內(nèi)手機(jī)，比如vivo，不詢問相機(jī)權(quán)限，照樣會給出彈窗，而且即使勾選“不在提醒”且拒絕權(quán)限，下次調(diào)用還是照樣彈窗直到用戶授權(quán)才能用，這是vivo系統(tǒng)定制的。對于國內(nèi)手機(jī)，魅族系列，不詢問相機(jī)權(quán)限，依然可以使用相機(jī)。所以不同手機(jī)rom和framework不一樣都會導(dǎo)致兼容問題出現(xiàn)，測試童鞋需要去分析各個廠商ROM存在哪些不同以及系統(tǒng)在使用過程中的調(diào)用方式，對差異性進(jìn)行評估，然后針對性去設(shè)計兼容測試場景。開發(fā)階段(1)在開發(fā)階段，可以推動開發(fā)同學(xué)在代碼里面打埋點，從而去獲取當(dāng)前APP線上用戶覆蓋的topn款手機(jī)數(shù)據(jù)，為后續(xù)版本兼容測試設(shè)計提供數(shù)據(jù)依據(jù)。(2)加強(qiáng)代碼掃描：通過Lint、sonar工具進(jìn)行靜態(tài)代碼掃描去提前發(fā)現(xiàn)因廠商、API不適配的兼容問題(3)加強(qiáng)開發(fā)代碼評審，包括基礎(chǔ)框架的代碼和各業(yè)務(wù)代碼SIT測試階段由于在測試前期，我們已經(jīng)做好兼容測試的部分裁剪確認(rèn)工作和兼容測試設(shè)計工作、以及靜態(tài)代碼掃描工作，所以在SIT測試階段，兼容性測試工作就會輕松不少。到了SIT測試階段，就是一個測試執(zhí)行的過程，測試執(zhí)行也有相應(yīng)的測試策略。(1)兼容測試執(zhí)行只要開發(fā)提測準(zhǔn)入通過了就可以開始進(jìn)行，測試童鞋可以在測試過程中根據(jù)兼容測試矩陣在不同測試輪次中切換不同的測試機(jī)進(jìn)行測試并記錄(2)根據(jù)二八原則，在做功能測試時先拿歷史常出問題機(jī)型進(jìn)行測試覆蓋(3)幾輪測試下來，不停切換手機(jī)，安裝測試包進(jìn)行測試也是一件繁瑣的事，另外測試機(jī)可能還存在非空閑情況，有條件的同學(xué)可以搭建STF平臺進(jìn)行組內(nèi)測試機(jī)設(shè)備管理平臺，所有兼容測試工作可以在PC端遠(yuǎn)程控制真機(jī)完成，省時又省力，還能做到測試組內(nèi)手機(jī)共享使用，減少溝通成本。(4)利用業(yè)內(nèi)已有的云測平臺進(jìn)行兼容測試：目前基本上大的云測平臺都有推出首次免費或者日首次免費的隨機(jī)安裝啟動標(biāo)準(zhǔn)兼容服務(wù)，免費的一般只能做50~100款機(jī)型。如果要做全面的機(jī)型覆蓋和深度兼容則需要付費了，而且目前各大云測平臺的收費較高，如果要全面覆蓋所有機(jī)型的話，是筆不小的開銷。所以，什么時候用云測平臺呢，這個要根據(jù)你測試的產(chǎn)品具體特征來考慮：如果測試的app屬于受眾廣泛，運營效果不錯，月活過億的，用戶千萬、億級用戶的比如微信，qq，支付寶類型的，那么就很有必要投入金錢或者組織人力搭建云測平臺進(jìn)行全面的機(jī)型覆蓋。如果測試的app受眾用戶只有不到萬，日活月活很低的產(chǎn)品比如中小銀行app、房產(chǎn)交易app,個人認(rèn)為沒有必要投入大量的金錢去兼容全部的機(jī)型。但是可以利用云測平臺去復(fù)現(xiàn)線上用戶個別未覆蓋機(jī)型所遇到的bug，拿到日志和解決方案，這樣投入的成本相對小且有針對性。如果測試的app受眾介于以上兩者特征之間的，而且效益也不錯，月活日活也能達(dá)到上萬的例如一些理財產(chǎn)品APP、證券類叩p、電商叩p，則可以對目前app當(dāng)前市場各版本和品牌的使用率，獲取當(dāng)前APP用戶覆蓋的topn款手機(jī)，在云測平臺進(jìn)行topn款手機(jī)的覆蓋測試UAT測試階段通過組織UAT測試，利用用戶或者業(yè)務(wù)人員的測試能力和測試資源，在短時間內(nèi)完成大工作量的產(chǎn)品測試和體驗，從用戶體驗的角度出發(fā)，反饋兼容Bug，并對產(chǎn)品提出改進(jìn)建議。線上階段(1)APP上線發(fā)布市場后，可以通過crash平臺、bugly等監(jiān)控平臺收集因兼容問題導(dǎo)致的閃退和無法安裝、運行的錯誤信息傳到后臺服務(wù)器端