移動App測試的22條軍規(guī)

移動App測試的22條軍規(guī)目錄\h軍規(guī)1確定設(shè)備和平臺再動手\h1.1移動App的特性\h1.2移動App的生命周期\h1.3設(shè)備的硬件參數(shù)\h軍規(guī)2“移動”測試\h軍規(guī)3關(guān)注多任務(wù)和意外情況處理\h3.1第一個場景\h3.2第二個場景\h3.3需注意的場景\h3.4硬件的影響\h軍規(guī)4避免手勢沖突\h4.1從屏幕左側(cè)邊緣向右滑動\h4.2在屏幕上向左滑動\h4.3從屏幕頂部向下滑動\h4.4從屏幕底部向上滑動\h4.5按住屏幕向下滑動\h4.6在圖片上雙擊\h4.7兩根手指分開和捏合\h4.8兩根手指按住屏幕旋轉(zhuǎn)\h4.93根手指的手勢操作\h4.104根手指向上/下滑動\h4.114根手指向左/右滑動\h4.125根手指聚攏的捏合操作\h4.13搖動設(shè)備\h4.14長按屏幕\h軍規(guī)5關(guān)注用戶體驗\h5.1橫豎屏幕測試\h5.2WebView的測試\h5.3規(guī)范與習(xí)慣\h5.4關(guān)注用戶體驗\h5.5其他需要關(guān)注的用戶體驗的小細(xì)節(jié)\h軍規(guī)6設(shè)計通知和消息展示\h6.1測試App安裝時是否明確申明在用戶使用App時需要用到的權(quán)限\h6.2測試App在用戶使用過程中是否有合適的通知和消息顯示\h6.3測試App在后臺運行時是否有合適的通知和消息顯示\h6.4測試App的消息推送功能\h6.5測試App在出錯時是否有合適的通知和消息顯示\h軍規(guī)7支持操作系統(tǒng)特性\h7.1AndroidApp測試設(shè)備的碎片化\h7.2AndroidApp更容易受到惡意軟件的攻擊\h7.3iOS和Android對于App間通信的處理方式不一樣\h7.4Android和iOS就是否支持?jǐn)U展存儲有所不同\h7.5iOS和Android對Widget的實現(xiàn)和使用不同\h7.6測試AndroidApp對于Dalvik和ART運行環(huán)境（RunTime）的兼容性\h7.7測試iOSApp在特定設(shè)置下的行為\h軍規(guī)8及時顯示和同步消息\h軍規(guī)9適應(yīng)特定用戶界面對功能和顯示的影響\h9.1三星的TouchWiz用戶界面\h9.2HTC的Sense用戶界面\h9.3LG的UX用戶界面\h9.4小米的米柚MIUI用戶界面\h9.5魅族的Flyme用戶界面\h9.6Sony的XperiaUI用戶界面\h9.7iOSApp的顯式效果測試\h軍規(guī)10支持多種文件格式\h10.1App支持Office文件\h10.2App支持圖片文件\h10.3App支持視頻和音頻文件\h軍規(guī)11支持多語言和地區(qū)設(shè)置\h11.1App不支持多語言和地區(qū)設(shè)置影響用戶輸入\h11.2App不支持多語言和地區(qū)設(shè)置的影響\h軍規(guī)12重點測試高內(nèi)存占用的功能\h12.1iOS操作系統(tǒng)的內(nèi)存管理機制以及對App使用內(nèi)存的限制是很不透明的\h12.2Android操作系統(tǒng)的內(nèi)存管理機制更加透明，對App使用內(nèi)存的限制也更加靈活\h軍規(guī)13降低流量和電量消耗\h13.1測試App安裝文件的大小和安裝過程\h13.2測試App占用的存儲空間\h13.3測試App的流量消耗\h13.4測試App對于設(shè)備電量的消耗\h軍規(guī)14增量升級必不可少\h14.1測試App的增量升級\h14.2測試App的刪除\h14.3測試App數(shù)據(jù)的清除\h軍規(guī)15確保成功集成和調(diào)用第三方App\h15.1App對第三方App的直接集成\h15.2測試App的分享功能\h15.3測試App顯示外部鏈接的功能\h15.4測試免費App中集成廣告的功能\h15.5測試App使用社交媒體等賬號登錄的功能\h15.6測試App推送服務(wù)\h15.7測試App關(guān)聯(lián)其他文件的功能\h15.8測試App和輸入法等App交互的功能\h軍規(guī)16盡量不使用非標(biāo)準(zhǔn)控件\h軍規(guī)17提前關(guān)注操作系統(tǒng)升級\h17.1iOS6升級所引入的新特性\h17.2iOS7升級所引入的新特性\h17.3iOS8升級所引入的新特性\h17.4Android4.1升級所引入的新特性\h17.5Android4.4升級所引入的新特性\h17.6Android5.0升級所引入的新特性\h軍規(guī)18盡量減少依賴\h18.1對于既有Web版本又有App版本的App要減少依賴\h18.2沒有Web版本的App也需要考慮App的依賴\h軍規(guī)19進(jìn)行自動化和探索性測試\h19.1測試設(shè)計和測試金字塔\h19.2單元和組件測試以及TDD\h19.3MobileService的API測試\h19.4用戶界面的自動化測試\h19.5行為驅(qū)動開發(fā)BDD\h19.6頁面模式PageObject\h19.7自動化測試中模擬器的使用\h19.8用戶界面自動化測試的常見工具\h19.9探索性測試\h軍規(guī)20進(jìn)行性能和安全性測試\h20.1測試App連接網(wǎng)絡(luò)的速度\h20.2測試App在不同網(wǎng)絡(luò)速度下操作的流暢程度\h20.3測試App對于前臺頁面渲染的性能\h20.4測試App操作數(shù)據(jù)庫的性能\h20.5測試App用到的后臺服務(wù)MobileService的性能\h20.6測試App是否保存了臨時數(shù)據(jù)或者已刪除的數(shù)據(jù)\h20.7測試App的會話session是否有過期設(shè)置\h20.8測試App請求中是否包含了明文的用戶信息\h20.9測試App的請求是否加密\h20.10測試SQLite數(shù)據(jù)庫的存儲是否安全\h20.11測試App使用WebView的安全性\h20.12測試App的后臺服務(wù)MobileService\h軍規(guī)21使用log定位問題\h軍規(guī)22充分使用持續(xù)集成和持續(xù)部署\h22.1第一種方式\h22.2第二種方式\hApp測試綜合案例分析\h23.1首先需要確定測試微信App需要的設(shè)備和版本\h23.2“移動”測試微信App\h23.3測試微信App的多任務(wù)和意外情況處理\h23.4測試微信App的手勢操作\h23.5測試微信App的用戶體驗\h23.6測試微信App的消息顯示和通知展示\h23.7測試微信App對于操作系統(tǒng)特性的支持程度\h23.8測試微信App能否及時顯示和同步消息\h23.9測試微信App能否適應(yīng)不同設(shè)備的不同用戶界面\h23.10測試微信App對于多種格式圖片的支持\h23.11測試微信App對多語言和地區(qū)的支持\h23.12測試微信App中高內(nèi)存使用的功能\h23.13測試微信App的流量和電量消耗\h23.14測試微信App的增量升級\h23.15測試微信App中集成和調(diào)用第三方App\h23.16測試微信App中非標(biāo)準(zhǔn)控件的使用情況\h23.17測試微信App對于最新操作系統(tǒng)特性的支持\h23.18測試微信App的依賴情況\h23.19對微信App進(jìn)行自動化測試和探索性測試\h23.20對微信App進(jìn)行性能測試和安全性測試\h23.21測試微信App的log提交\h23.22實現(xiàn)微信App的持續(xù)集成和持續(xù)部署\h22條軍規(guī)之外軍規(guī)1確定設(shè)備和平臺再動手在測試設(shè)計之初，測試人員首先會考慮的是什么呢？沒錯，就是測試的環(huán)境，也就是確定App究竟需要運行在什么樣的設(shè)備和平臺上。顯然，在移動設(shè)備和平臺碎片化的現(xiàn)實中，測試人員窮盡所有設(shè)備和操作系統(tǒng)的版本來實現(xiàn)全覆蓋的測試是不可能的。那如何在有限的時間和精力投入下，從投入產(chǎn)出比的角度出發(fā)，達(dá)到盡可能多的測試覆蓋呢？這里主要考慮以下幾個方面。1.1移動App的特性（1）如果App是針對心率監(jiān)測、指紋識別、近場通信（NFC）、紅外線操控這些需要特殊傳感器設(shè)計的，那對測試設(shè)備和平臺的選擇就相對少一些，只需要考慮那些擁有這些傳感器的設(shè)備。例如對于支持指紋識別的App，測試人員需要考慮的設(shè)備也就是iPhone5s、iPhone6、iPhone6Plus、iPadAir2、iPadmini3、LGG3、三星GalaxyS5、三星GalaxyNote4、HTCOneMax和華為Mate7這些設(shè)備（不考慮市場占有率比較低的vivo和OPPO的手機）；而如果App支持心率監(jiān)測，測試人員就只能選擇三星GalaxyS5和GalaxyNote4了。這里推薦大家使用一個網(wǎng)站（\h//）來做設(shè)備的查找工作。通過這個網(wǎng)站不僅可以查詢到各種手機和平板設(shè)備的詳細(xì)參數(shù)信息，還可以對它們進(jìn)行橫向?qū)Ρ龋奖銣y試人員找到適合用來做測試的設(shè)備（如圖1.1所示）。（2）如果App是針對某種平臺所獨有的功能設(shè)計的，或者是某種平臺獨占的，測試人員就只需要考慮相應(yīng)平臺下的設(shè)備。比如App是類似Android設(shè)備上層出不窮的“xx清理大師”，那在確定測試設(shè)備和平臺時就不需要考慮iOS平臺了；又比如之前Instagram選擇只支持iOS平臺，那作為Instagram的測試人員只需要關(guān)注于iOS設(shè)備就足夠了。圖1.1\h//設(shè)備對比或者，如果App選擇不支持某種平臺，相應(yīng)的，測試人員也就不需要測試運行這些平臺的設(shè)備了。比如WindowsPhone、黑莓（BlackBerry）以及塞班（Symbian）平臺在市場上的占有率已經(jīng)很低了（根據(jù)2014年第四季度的調(diào)查，詳見圖1.2），如果在開發(fā)時選擇不支持這些平臺，那在測試時測試人員就完全可以忽略相關(guān)的設(shè)備。圖1.22014年第四季度各操作系統(tǒng)市場占有率調(diào)查表

（數(shù)據(jù)來源：）（3）如果App是面向大眾的通用型App，測試人員就需要結(jié)合移動App的生命周期和測試設(shè)備的硬件參數(shù)來確定測試設(shè)備和平臺了。1.2移動App的生命周期（1）對于還處于開發(fā)階段但準(zhǔn)備不久之后投入市場的一款新App，鑒于并沒有已經(jīng)實際使用App的用戶，所以測試人員要“預(yù)測”真實的用戶所使用的設(shè)備和平臺。在這種情況下，首先需要了解使用App的主要用戶是哪一類人群，比如說是發(fā)燒友，還是商務(wù)人士。發(fā)燒友極有可能使用的是最新的設(shè)備和平臺；商務(wù)人士更多使用的是成熟的平臺，高端一些的設(shè)備；而如果用戶是普通大眾，就需要通過Apple和Google官方發(fā)布的版本占有率數(shù)據(jù)來幫助測試人員進(jìn)行有依據(jù)的“拍腦袋”了。以下是Apple官方發(fā)布的iOS版本占有率數(shù)據(jù)(\h/support/appstore/)，如圖1.3所示；和Google官方發(fā)布的Android版本占有率數(shù)據(jù)（\h///

about/dashboards/index.html），如圖1.4所示。（2）對于已經(jīng)發(fā)布并且有穩(wěn)定用戶群的App，測試人員可以使用在桌面應(yīng)用開發(fā)時用到的工具，例如GoogleAnalytics或OmnitureSiteCatalyst（現(xiàn)在Omniture被Adobe收購了，工具也改名叫做AdobeAnalytics）來統(tǒng)計用戶的信息，從而確定App支持和需要測試的設(shè)備及平臺。這里對于App有一點要求，就是App需要聯(lián)網(wǎng)對后臺的服務(wù)器發(fā)送請求，從而能獲取到用戶信息。圖1.3截至2015年1月5日，iOS各版本所占比例圖1.4截至2015年1月5日，Android各版本所占比例GoogleAnalytics（Google分析，網(wǎng)址為\h///analytics）是Google的一款免費的網(wǎng)站分析服務(wù)，使用范圍十分廣泛。GoogleAnalytics功能非常強大，只要在網(wǎng)站的頁面上加入一段代碼，就可以提供豐富詳盡的圖表式報告。GoogleAnalytics的特點是簡單易用，但是相應(yīng)的缺點就是不可定制化。GoogleAnalytics的頁面如圖1.5所示。圖1.5GoogleAnalyticsOmnitureSiteCatalyst（AdobeAnalytics，網(wǎng)址為\h///solutions/digital-analytics.html）是一個進(jìn)行網(wǎng)站基本指標(biāo)的搜集、報告和分析的工具。通過這個軟件可以得到網(wǎng)站和App的訪問量、瀏覽量、跳出率、轉(zhuǎn)化率、來源等諸多指標(biāo)。只要在App中對不同事件以及發(fā)送請求都添加相應(yīng)的Omniture追蹤，然后再登錄Omniture的網(wǎng)頁就可以進(jìn)行用戶數(shù)據(jù)分析。OmnitureSiteCatalyst不同于GoogleAnalytics的一個特點是，它可以對數(shù)據(jù)進(jìn)行高級細(xì)分，也就是說，可以對用戶的各種操作打上不同的標(biāo)簽，在服務(wù)器端搜集到信息后進(jìn)行統(tǒng)一的篩選和分析。OmnitureSiteCatalyst的頁面如圖1.6所示。（3）對于上面兩種情況，有一種特例需要考慮，就是在有新的操作系統(tǒng)版本將要發(fā)布的時候，需要參考以前操作系統(tǒng)版本升級時用戶更新的進(jìn)度。正如圖1.3和圖1.4所示，在iOS8發(fā)布3個月之內(nèi)有68%的用戶進(jìn)行了升級，而使用iOS7之前版本的用戶只有4%；而Android4.4Kitkat發(fā)布一年后，市場占有率才剛剛達(dá)到39.1%，有超過52.7%的用戶使用的還是4.0～4.3版本的Android，甚至還有8.2%左右的用戶還在使用著Android2.x的設(shè)備。圖1.6OmnitureSiteCatalyst根據(jù)這些數(shù)據(jù)，測試人員在iOS操作系統(tǒng)版本升級時需要及早適配新的App版本；而對于Android發(fā)布新的操作系統(tǒng)時，測試人員主要還得關(guān)注當(dāng)前市場占有率高的那些老版本。1.3設(shè)備的硬件參數(shù)（1）屏幕尺寸。現(xiàn)在手機越出越大，連堅持自己風(fēng)格的蘋果公司也開始跟風(fēng)發(fā)布大屏手機了。屏幕大小除了會影響顯示效果外，還會影響到用戶的使用習(xí)慣。一般用戶手持6英寸屏幕的設(shè)備時，會采取雙手操作的方式，所以App如果同時支持橫縱屏顯示會帶來更好的用戶體驗（如圖1.7所示）。圖1.7雙手持握設(shè)備的方式而對于4～5英寸這種可以單手持握的設(shè)備，如果App無論橫縱向顯示，按鈕都最好不要放在屏幕四個角，以免用戶很難點擊（如圖1.8所示）。圖1.8單手操作范圍49%的單手操作用戶采用的是以上兩種姿勢（左手用戶相反）。綠色代表容易點擊區(qū)域，黃色為拇指伸展可點擊區(qū)域，紅色區(qū)域為超出單手可點擊范圍。（2）分辨率。分辨率的大小會決定顯示內(nèi)容的多少，這對顯示圖片和視頻時會有一定的影響（如圖1.9所示）。圖1.9不同分辨率下顯示內(nèi)容的大小以及顯示比例還需要注意的是，有些廠商（比如說魅族）雖然標(biāo)注的屏幕尺寸和通用產(chǎn)品一致，但由于顯示比例的不同，分辨率和通用產(chǎn)品也會有差別（圖1.10所示為魅族MX4采用的15:9的屏幕比例，而非標(biāo)準(zhǔn)的16:9的屏幕比例）。圖1.10魅族MX4的的屏幕比例（右）（3）像素密度。屏幕大小和分辨率決定了像素密度。不同的像素密度對于顯示也會有差別。在retina的屏幕上顯示非retina的圖片會很模糊，反之則會顯得失真（如圖1.11和圖1.12所示）。如果需要同時支持retina和非retina的設(shè)備，那測試人員需要測試是否對圖片，尤其是App的顯示圖片提供retina和非retina兩個版本。圖1.11非retina和retina的文字顯示圖1.12非retina和retina的圖片顯示選取了操作系統(tǒng)版本和測試設(shè)備之后，就可以設(shè)計矩陣來配對操作系統(tǒng)版本和測試設(shè)備了。具體可以參考表1.1。表1.1測試設(shè)備和操作系統(tǒng)版本對照表SNOSOSVersionCategoryModelManufacturer001iOS7.1iPhone5sApple002iOS8.1iPhone5sApple003iOS8.0.2iPhone6Apple004iOS8.1iPhone6PlusApple005iOS8.0.2iPadAiir2Apple006iOS8.1iPadminiApple007Android4.1PhoneOneXLHTC008Android4.2PhoneXperiaZSony009Android4.2PhoneGalaxyS3Samsung010Android4.4.2PhoneGalaxyS5SamsungonAndroid4.4.4PhoneNexus5Google012Android4.2.2TabletGalaxyTab310.1Samsung013Android4.3TabletNexus7IIGoogle設(shè)計測試設(shè)備和操作系統(tǒng)版本對照表的原則是：讓不同分辨率、不同屏幕尺寸大小的設(shè)備盡可能多地涵蓋各個操作系統(tǒng)版本，另外，對于市場占有率很高的重點操作系統(tǒng)版本，可以使用多個設(shè)備來測試。可以看到，對于同一種設(shè)備（如圖1.13中的iPhone5s所示），由于市場占有率大，而且支持多個操作系統(tǒng)版本，所以在iPhone5s上需要測試iOS7.1和iOS8.1兩個版本；由于iPhone5s和iPhone6Plus分辨率、性能等都不一樣，所以同樣對于iOS8.1，兩者都需要測試。在設(shè)計Android設(shè)備和操作系統(tǒng)的覆蓋時，可以看到對于類似的設(shè)備（比如HTCOneXL和三星GalaxyS3硬件水平很接近），并沒有要在它們上分別都測試覆蓋Android4.1和4.2，而是在HTCOneXL測試Android4.1，在三星GalaxyS3上測試Android4.2。而SonyXperiaZ在CPU、內(nèi)存、屏幕大小和分辨率上都和三星GalaxyS3不同，所以在這兩部設(shè)備上都需要測試Android4.2。設(shè)計表格的過程中，測試人員還需要注意以下兩點。（1）操作系統(tǒng)的小版本升級一般只是修復(fù)缺陷，不會引入新的功能，例如iOS從8.0.1升級到8.0.2，以及Android從4.4.1升級到4.4.4。這時，如果不是App恰好被這些缺陷修復(fù)所影響，測試人員不需要考慮覆蓋這些小版本。至于中間版本的升級，例如從iOS8.0.2升級到8.1，以及Android從4.1升級到4.4，這時需要考察變動對App的影響，決定是否測試覆蓋相應(yīng)版本。就拿Android4.1和Android4.4來說，因為Android4.4相比于4.1新增了ART運行環(huán)境，所以針對這一點，測試人員需要準(zhǔn)備設(shè)備安裝Android4.4，而不是僅僅在安裝有Android4.1的設(shè)備上測試。至于操作系統(tǒng)大的版本升級，就必須要進(jìn)行測試覆蓋了。（2）隨著操作系統(tǒng)升級，既有的設(shè)備可能無法流暢地運行新的操作系統(tǒng)時，測試人員就需要考慮是不是還繼續(xù)在新的操作系統(tǒng)上測試這些設(shè)備。比如，iPhone4在升級為iOS7之后運行速度變得很慢，各種操作的延遲都會很長，固然有一部分用戶還是強忍著會繼續(xù)使用，但是很多用戶會放棄在新的操作系統(tǒng)上使用運行很慢的老舊設(shè)備。當(dāng)新的操作系統(tǒng)升級時，甚至有些舊的設(shè)備就不會被支持了，例如iOS8就不再支持iPhone4。這時候如果確定這些舊的設(shè)備上的操作系統(tǒng)占比很小的話，測試人員就可以果斷放棄這些設(shè)備。所以測試人員需要從設(shè)備角度出發(fā)決定要測試的操作系統(tǒng)，以及從操作系統(tǒng)出發(fā)決定要測試的設(shè)備這兩方面來考慮測試設(shè)備和操作系統(tǒng)版本對照表的制定。明確了測試設(shè)備和操作系統(tǒng)版本，下面我們就來了解下在設(shè)計測試場景和用例中可以運用哪些具體的軍規(guī)。軍規(guī)2“移動”測試當(dāng)App上線之后，我們可以通過各種途徑得到用戶的反饋。有些時候我們會很納悶，用戶說有問題的功能，明明是我們重點測試過的，怎么可能還會有問題呢？是不是用戶打開的姿勢不對？這時候很可能我們已經(jīng)陷入了一個誤區(qū)，覺得我們是按照用戶的使用習(xí)慣來測試的，用戶在使用中不可能出現(xiàn)這樣的問題。但是我們忽略了用戶使用App時的場景，也就是環(huán)境對App的影響。相對于桌面應(yīng)用，移動App最大的特點就在于移動性。用戶在任何時間任何地點都可以打開App使用，這意味著App對于不同網(wǎng)絡(luò)，以及網(wǎng)絡(luò)變化的情況都能進(jìn)行處理。圖2.1展示了iPhone上支持的網(wǎng)絡(luò)種類。測試人員并非對于每一種網(wǎng)絡(luò)都需要測試，如何確定需要測試的網(wǎng)絡(luò)，取決于App在網(wǎng)絡(luò)上獲取什么樣的信息。圖2.1iOS上不同的網(wǎng)絡(luò)狀態(tài)圖標(biāo)（1）如果App只是通過網(wǎng)絡(luò)訪問服務(wù)器，那需要考慮的主要就是高速和低速網(wǎng)絡(luò)之間的差別。因此只要測試Wi-Fi、3G/4G/LTE、EDGE/GPRS以及飛行模式就可以了。為什么需要單獨測試飛行模式呢？因為對于聯(lián)網(wǎng)的App，不僅需要考慮到有網(wǎng)絡(luò)環(huán)境中用戶的使用，在無網(wǎng)絡(luò)的情況下也要保證App不會出錯，例如App崩潰等。當(dāng)App需要大數(shù)據(jù)量傳輸數(shù)據(jù)時，很可能需要把3G和4G/LTE的測試分開，充分模擬真實用戶使用的場景。（2）如果App需要在不同的網(wǎng)絡(luò)環(huán)境里得到認(rèn)證信息，例如移動運營商的信令，那測試人員就需要對于不同的信令獲取方式進(jìn)行單獨的測試分類了。比如說，如果App在4G/LTE的環(huán)境下進(jìn)行的驗證方式不同于3G環(huán)境，就不能把這兩種網(wǎng)絡(luò)狀態(tài)當(dāng)成一種情況來進(jìn)行測試，而是要分別進(jìn)行測試。哇，這么多種網(wǎng)絡(luò)環(huán)境，怎么進(jìn)行測試??？需要買這么多種SIM卡嗎？不對啊，EDGE和GPRS可沒有對應(yīng)的SIM卡，現(xiàn)在什么SIM卡能支持這兩種網(wǎng)絡(luò)?。∈沁@兩種網(wǎng)絡(luò)環(huán)境一定要一起測試嗎？或者需要專門的設(shè)備來測試？其實，我們大可不必為網(wǎng)絡(luò)環(huán)境而憂心忡忡，因為在程序開發(fā)和自動化測試中可以使用Mock技術(shù)。通過使用Mock可以從服務(wù)器端返回一般需要真實網(wǎng)絡(luò)環(huán)境才能得到的response應(yīng)答，這樣App就可以直接處理信息，而不用非得連接到真實的網(wǎng)絡(luò)環(huán)境或者是非得處于特定的狀態(tài)下了。使用Mock這種方式減少了在開發(fā)和測試過程中由于需要真實環(huán)境而對于網(wǎng)絡(luò)、設(shè)備和資源的投入。那具體如何使用Mock技術(shù)呢？（1）對于不用在網(wǎng)絡(luò)上獲取信令Token的App，可以直接在代碼里對App包進(jìn)行標(biāo)記，比如打上測試的標(biāo)簽，并且在向服務(wù)器發(fā)送請求的時候帶上這個標(biāo)簽，這樣服務(wù)器就可以根據(jù)這個測試的標(biāo)簽，判斷出客戶端是測試的App，從而對網(wǎng)絡(luò)環(huán)境進(jìn)行模擬并運行對應(yīng)的Mock代碼，延遲把產(chǎn)生的應(yīng)答response發(fā)送回App，這樣就可以模擬低網(wǎng)速下的網(wǎng)絡(luò)環(huán)境了。另外，可以通過控制延遲時間的多少，模擬真實環(huán)境中不同網(wǎng)絡(luò)速度的網(wǎng)絡(luò)狀況。（2）對于需要在網(wǎng)絡(luò)上獲取信令的App，基本過程和上述一致，只是需要在Mock代碼中添加生成信令的代碼，從而使服務(wù)器在返回應(yīng)答時把信令告知客戶端，從而繞過真實環(huán)境中的網(wǎng)絡(luò)驗證環(huán)節(jié)。如果你還有疑問，猜想開發(fā)人員會不會因為增加了工作量而不同意做這些工作呢，那么大可放心，因為這些工作只是一次性的環(huán)境準(zhǔn)備工作，對于整個團(tuán)隊來說都是必要的。開發(fā)人員也更希望在編碼的時候就確保App能應(yīng)對各種網(wǎng)絡(luò)環(huán)境，而不用等出現(xiàn)了缺陷，花了很大力氣之后才發(fā)現(xiàn)是網(wǎng)絡(luò)環(huán)境的影響，而且還要得東奔西走，找不同的網(wǎng)絡(luò)來驗證修復(fù)；另外，業(yè)務(wù)分析人員也需要在不同的網(wǎng)絡(luò)環(huán)境下設(shè)計用戶的體驗和交互方式。目前也有不少工具可以幫我們快速搭建Mock環(huán)境，例如Mountebank、Charles、AppleNetworkLinkConditioner和moco。筆者比較常用的是moco，不僅是因為moco是2013年OracleDuke’sChoice獲獎作品，而且因為moco搭建簡單，如果App不涉及獲取信令的驗證，以及與其他Service的集成，測試人員按照說明手冊自己搭建一個Mock環(huán)境也是很快的。這樣測試人員還可以參與后期Mock環(huán)境的維護(hù)，確保Mock的真實性和準(zhǔn)確性（如圖2.2所示）。下面先簡單介紹一下如何快速搭建moco環(huán)境（以MacOSX為例）。（1）首先下載moco的獨立運行的jar文件（地址如下）。

///maven2/com/github/dreamhead/moco-runner/0.9.2/moco-runner-0.9.2-standalone.jar

（2）打開任何一個文本編輯器，比如說SublimeText。（3）輸入以下的內(nèi)容，這些內(nèi)容將作為moco的配置文件，在moco運行時被讀?。贿@些配置文件的作用，是用來向客戶端返回被Mock過的服務(wù)器的response（如圖2.3所示）。

[

{

"response":

{

"text":"Hi，移動App測試的22條軍規(guī)的讀者"

}

}

]

圖2.2配置文件中設(shè)置的response以及從頁面中看到的結(jié)果圖2.3設(shè)置moco配置文件內(nèi)容（4）保存成文件，并命名為“22rules”，并放置于mocojar文件所在的同一目錄下（如圖2.4所示）。圖2.4把保存的“22rules”和mocojar文件放在同一文件夾下（比如“workspace”）（5）在命令行工具，如“Terminal”下打開“workspace”這個文件夾。（6）輸入命令“（java-jarmoco-runner-0.9.2-standalone.jarstart-p12306-c22rules）”來啟動moco，以下是moco的運行提示（如圖2.5所示）。圖2.5moco運行后的提示信息（7）在瀏覽器中打開//localhost:12306/就可以看到網(wǎng)頁上顯示之前在“22rules”里設(shè)置的信息：“Hi，移動App測試的22條軍規(guī)的讀者”（如圖2.6所示）。圖2.6在瀏覽器中能看到之前在moco配置文件中輸入的內(nèi)容（8）當(dāng)然，真實的場景不會這么簡單，特定的請求request需要不同的response。這時就需要對moco配置文件改成如下內(nèi)容（如圖2.7所示）。

[

{

"response":

{

"text":"Hi，移動App測試的22條軍規(guī)的讀者"

}

},

{

"request":

{

"uri":"/22"

},

"response":

{

"text":"我是特定的response"

}

}

]

圖2.7對特定的請求request設(shè)置特定的應(yīng)答response（9）打開//localhost:12306/22查看結(jié)果，會發(fā)現(xiàn)針對不同的請求request，返回的response也是不一樣的（如圖2.8所示）。圖2.8特定的請求request返回特定的應(yīng)答response（10）如果多個配置文件需要一起讀取，那怎么辦呢？這時就需要多個配置文件。下面來創(chuàng)建另外兩個配置文件“another”和“combined”，它們的內(nèi)容如下（如圖2.9和圖2.10所示）?！癮nother”配置文件的內(nèi)容如下。

[

{

"request":

{

"uri":"/another"

},

"response":

{

"text":"我是另一個特定的response"

}

}

]

圖2.9“another”配置文件的內(nèi)容圖2.10“combined”配置文件的內(nèi)容“combined”配置文件的內(nèi)容如下。

[

{

"include":"22rules"

},

{

"include":"another"

}

]

（11）這兩個配置文件也需要和之前的“22rules”以及mocojar文件在同一文件夾下（如圖2.11所示）。圖2.11所有文件都需要放置在同一文件夾下（12）在命令行（“Terminal”）里運行“（java-jarmoco-runner-0.9.2-standalone.jarstart-p12306-gcombined）”（如圖2.12所示）。圖2.12moco讀取多個配置文件運行后的提示信息（13）再次打開//localhost:12306/，//localhost:12306/22，以及//localhost:12306/another來查看同時支持多個不同配置文件的運行效果（如圖2.13所示）。圖2.13moco同時支持多個配置文件的讀取和運行（14）關(guān)于更多的moco的進(jìn)階使用和配置，請參考GitHub上moco的文檔。當(dāng)然，有些特殊的網(wǎng)絡(luò)環(huán)境我們是沒有辦法很容易地進(jìn)行模擬的，例如前幾年2GSIM卡的cmwap會拋棄一些http自定義頭，現(xiàn)在的移動3GSIM卡丟包率很高等場景。對于這些場景的測試，我們還是需要使用真實的SIM卡，在手機等設(shè)備上進(jìn)行測試?，F(xiàn)在讓我們回到本章最開始的那個問題，你可能會說，我都按照你所說的在不同的網(wǎng)絡(luò)狀態(tài)下進(jìn)行了測試了，可是用戶還是會在執(zhí)行過測試的那些場景發(fā)現(xiàn)我們沒有發(fā)現(xiàn)的bug，這是為什么呢？好，讓我們再想一想測試人員所在的測試場景和用戶的使用場景有什么不同呢？用戶都是在什么樣的環(huán)境中使用呢？咦，用戶好像是不會像測試人員一樣一直在辦公桌前，在網(wǎng)絡(luò)環(huán)境很好很穩(wěn)定的區(qū)域使用App的！沒錯，測試人員測試的僅僅是在特定的網(wǎng)絡(luò)環(huán)境下App的表現(xiàn)，在網(wǎng)絡(luò)切換的時候，App會如何處理測試人員是完全不清楚的。所以不要以為App在不同網(wǎng)絡(luò)環(huán)境下表現(xiàn)正常，在網(wǎng)絡(luò)切換的時候就不會有問題。下面還是拿需要在網(wǎng)絡(luò)上驗證信息取得信令的App來做例子（如圖2.14所示）。試想在App使用過程中需要在3G/4G網(wǎng)絡(luò)上取得SIM卡注冊后的信令，通過這個信令用戶可以直接進(jìn)行支付和延長合約等操作；在無線網(wǎng)絡(luò)或者無網(wǎng)絡(luò)的情況下，因為不驗證SIM卡注冊信息，所以無法進(jìn)行相應(yīng)的操作。但是當(dāng)用戶從一個有3G/4G信號的地點移動到一個沒有信號（或者有無線網(wǎng)絡(luò)連接）的地點，如果App處理不好，就會出現(xiàn)雖然App拿到了信令，相應(yīng)的菜單顯示可用，但是實際用戶不僅無法成功操作，甚至還會出現(xiàn)異常的信息提示。再試想一下，如果App具有支付功能，在網(wǎng)絡(luò)不好的情況下，用戶支付了訂單，突然網(wǎng)絡(luò)中斷，用戶的訂單信息還是未完成，但錢已經(jīng)從用戶賬戶上支出了，這就不是一個小的問題了。相對而言，對于銀行類的App，如果用戶在網(wǎng)絡(luò)不好的情況下支取了資金，但是用戶賬面金額并沒有相應(yīng)地扣除，銀行損失的就不會是一筆小錢了。對于網(wǎng)絡(luò)異常的提示信息也需要人性化的設(shè)計，只告訴用戶“HTTP500InternalError”這樣的消息對用戶來說不僅沒有任何幫助，反而會加劇用戶的挫敗感和不滿情緒。圖2.15就展示了這種不恰當(dāng)?shù)腻e誤提示信息的真實場景。圖2.14獲取移動網(wǎng)絡(luò)信令A(yù)pp的結(jié)構(gòu)示例圖2.15不恰當(dāng)?shù)腻e誤提示信息在網(wǎng)絡(luò)出現(xiàn)異常，程序無法進(jìn)一步處理的情況時，App應(yīng)該明確告訴用戶應(yīng)該怎么操作，例如在網(wǎng)絡(luò)連接不上的時候告知用戶：“網(wǎng)絡(luò)無連接，請稍后再試?！被蛘咴诰W(wǎng)速很慢的時候提示用戶：“當(dāng)前網(wǎng)速很慢，可能會影響您的體驗?！倍诤笈_，則需要定時刷新，避免在網(wǎng)絡(luò)恢復(fù)的時候，App依舊顯示網(wǎng)絡(luò)異常時的提示信息，也避免用戶需要不停手動刷新。當(dāng)然，在多次嘗試失敗之后，可以放棄刷新嘗試，改為讓用戶手動刷新來減少對于網(wǎng)絡(luò)流量和電量的消耗。對于視頻播放類App，也需要驗證在網(wǎng)絡(luò)進(jìn)行切換，比如Wi-Fi切換到4G或者3G網(wǎng)絡(luò)時，對應(yīng)播放的視頻清晰度是否也會進(jìn)行對應(yīng)的切換。當(dāng)然，畢竟任何模擬都是替代方案，為了能模擬真實的網(wǎng)絡(luò)環(huán)境和網(wǎng)絡(luò)切換，走出去，“移動著”測試不失為一個選擇。在真實環(huán)境的測試過程中，測試人員也會注意到更多之前忽略的用戶使用的小細(xì)節(jié)。讓我們在移動App測試的時候“動”起來吧！軍規(guī)3關(guān)注多任務(wù)和意外情況處理想必我們都有過這樣的體驗：在購物的App中填寫信息，比如說收貨地址的時候，忘記了具體地址，然后切換出該App到“印象筆記”之類的記錄App中查找到地址，復(fù)制下來，再切換回購物App的時候發(fā)現(xiàn)，剛才填寫的好多信息都沒有了，還得手動輸入一遍，這樣就會覺得App的功能和體驗很差。這種情況其實就是沒有處理好多任務(wù)時App的表現(xiàn)。不同于功能機的時代，在使用智能手機的時候，經(jīng)常會同時運行多個程序（如圖3.1所示），這就要求測試人員在設(shè)計和測試App的時候考慮到App被別的程序或者用戶切換到后臺時，需要進(jìn)行什么操作。圖3.1iOS的多任務(wù)處理3.1第一個場景一個典型的場景就是，App在使用過程中用戶接聽一個來電，App應(yīng)該如何處理（如圖3.2所示）。圖3.2使用App時接收到來電App是否需要在后臺運行？是否需要在狀態(tài)欄和通知欄顯示信息？當(dāng)用戶掛機后，App是否需要恢復(fù)之前的狀態(tài)，還是需要重新刷新？不同的App需要有不同的處理，比如說用戶在接聽電話前正在使用微信編輯消息，當(dāng)掛斷電話后，用戶自然希望能繼續(xù)編輯，并且剛才填寫的消息內(nèi)容都還在；而如果用戶剛才打開的是一個計時器，用戶自然希望得到App一直運行的時間；而對于音樂或視頻播放類App，在接聽電話前已經(jīng)暫停播放，在掛斷之后，用戶也希望保證音樂或視頻還是處在暫停狀態(tài)，或者反之。3.2第二個場景另外一個場景是，不同App之間切換，打開App的速度是否會變慢，以及切換時的動畫是否出現(xiàn)卡頓。App切換時卡頓的問題在Android平臺上會更嚴(yán)重一些（如圖3.3所示）。圖3.3Android平臺上多任務(wù)處理出現(xiàn)卡頓的概率要大一些與之類似，當(dāng)App關(guān)閉之后，被重新打開的時候，App響應(yīng)速度也是需要考慮的。因為App徹底關(guān)閉時，通常都會在關(guān)閉前先把緩存的數(shù)據(jù)保存到本地，然后再關(guān)閉App；而等App再次啟動時讀取這些數(shù)據(jù)，以便恢復(fù)App關(guān)閉時的狀態(tài)。但是如果在App再次打開之前，這些數(shù)據(jù)已經(jīng)被修改或者破壞，這個時候打開App，并試圖恢復(fù)App關(guān)閉時的狀態(tài)，可能會造成App長時間處于等待狀態(tài)，甚至可能造成App崩潰（如圖3.4所示）。圖3.4SecureElement無響應(yīng)導(dǎo)致GoogleWallet終止3.3需注意的場景有種場景需要單獨注意：對于在具備同樣功能的App，尤其是具有視頻和音頻播放功能的App之間進(jìn)行切換時，需要注意它們之間的播放控制是否會對另外的App產(chǎn)生影響。例如我們正使用QQ音樂播放著歌曲，這時切換到酷狗音樂，酷狗音樂里的歌曲是否會自動播放呢？要是暫停了酷狗音樂的音樂播放，再回到QQ音樂里，這時QQ音樂是否會繼續(xù)播放音樂呢？通常的做法是，App的操作只對本App有效，所以QQ音樂不應(yīng)該影響到酷狗音樂，也不應(yīng)該被酷狗音樂所影響。同時，App被切換回當(dāng)前應(yīng)用時是否刷新，也會因App后臺數(shù)據(jù)是否有可能改變而有所不同。比如在使用具有記錄通話和網(wǎng)絡(luò)流量功能的App時，用戶撥打/接聽電話，或者在使用別的App之后切換回來，因為用戶關(guān)心的通話和流量的使用量很可能發(fā)生變化，所以App必須要刷新顯示。微信這種通信類的App也是如此，用戶切換出App的時候，無法避免App中數(shù)據(jù)的更新。運動和健康監(jiān)測類的App更是如此，無論App是否被切換到后臺，改變都需要隨時被記錄，如圖3.5所示。圖3.5iOS8上的Health會隨時記錄運動和健康監(jiān)測數(shù)據(jù)對于App切換或停止，還需要考慮的是，切換App究竟是需要用戶打開多任務(wù)處理界面，選擇App才能恢復(fù)App的運行（這時直接點擊桌面App圖標(biāo)意味著重新運行App），還是允許用戶通過點擊桌面圖標(biāo)來恢復(fù)App運行狀態(tài)。一般我們都會選擇后者，但是也有少部分軟件出于設(shè)計的考慮而采用的是前者。3.4硬件的影響以上場景介紹的都是軟件進(jìn)行多任務(wù)的情景，其實硬件也是會影響到App的多任務(wù)操作的。最常見的例子就是，當(dāng)我們插著耳機正在聽音樂，突然耳機被拔掉了，這時App并不會通過揚聲器播放聲音，而是會暫停音樂的播放。雖然這種情況比較極端，對于App來說是一種意外中斷的情況，但是設(shè)計時測試人員會更多考慮發(fā)生這種情況的場景是用戶由于某些原因，比如說要和別人說話而拔掉了耳機，所以，為了更好的用戶體驗，顯然暫停播放比用揚聲器播放要好不少。不僅是耳機會對App多任務(wù)有影響，鎖屏鍵和Home鍵也會影響App的運行。（1）通常我們會使用鎖屏鍵進(jìn)行鎖屏和解鎖，測試時以下情景需要考慮：當(dāng)運行App的時候，使用鎖屏鍵關(guān)閉屏幕，App是應(yīng)該繼續(xù)運行，還是等待屏幕恢復(fù)之后再運行；當(dāng)解鎖時，App是停留在當(dāng)前的子頁面，還是回到App的主頁面；前臺運行App，等待屏幕進(jìn)行休眠時，點擊解鎖鍵，觀察App的表現(xiàn)。（2）Home鍵被用作切換App到后臺。測試人員可以觀察App在被切換到后臺1分鐘，5分鐘，10分鐘，30分鐘之后，再被重新打開的時候是如何表現(xiàn)的，是停留在之前的子頁面，還是回到App的主頁面。除此之外，這種情境下頁面的信息顯示是怎么樣的。（3）另一種App中斷也需要考慮，就是Android設(shè)備上SD卡被拔出的情況。對于允許把數(shù)據(jù)或者App本身存放到SD卡的設(shè)備，SD卡被拔出意味著讀寫App數(shù)據(jù)甚至App本身的運行都不存在（如圖3.6所示）。這種操作對于App來說是毀滅級的，除非App在運行過程中不斷地把App自身和緩存數(shù)據(jù)寫到設(shè)備自帶內(nèi)存中的臨時存儲空間，不然App是沒有辦法恢復(fù)之前運行的狀態(tài)的。而這么做又和把App存儲到設(shè)備自帶內(nèi)存沒有區(qū)別，所以在設(shè)計App的時候也不要使App能存儲到SD卡。圖3.6卸載SD卡時Android系統(tǒng)的提示軍規(guī)4避免手勢沖突不知道你是否碰到過這樣的問題：明明App是支持手勢的，但是在使用手勢操作App的過程中，有時候就是不好使，有時候還莫名其妙地打開或者關(guān)閉了一些頁面，完全不符合App預(yù)期的行為。試想一下App是否使用了以下這些手勢之一：從屏幕左側(cè)邊緣向右滑動，從屏幕右側(cè)邊緣向左滑動，從屏幕頂部向下滑動，從屏幕底部向上滑動，按住屏幕向下滑動，在圖片上雙擊，兩根手指分開和捏合，兩根手指按住屏幕旋轉(zhuǎn)，四根手指向上/下滑動，四根手指向左/右滑動，五根手指聚攏的捏合操作，搖動設(shè)備，長按屏幕。除了最后長按屏幕這個手勢經(jīng)常出現(xiàn)在Android平臺上之外，其他手勢都是iOS平臺上很常見和通用的手勢。之所以會碰到使用App時出現(xiàn)不符合預(yù)期行為的這些詭異問題，很可能是我們在App中使用了這些手勢，而這些手勢本身又是操作系統(tǒng)的手勢，當(dāng)App運行時，碰到這些手勢的使用，并不清楚應(yīng)該執(zhí)行哪一個手勢的命令，所以會造成混亂的局面。下面筆者來為大家一一介紹這些手勢的作用。4.1從屏幕左側(cè)邊緣向右滑動這個手勢是iPhone和iPad升級到iOS7之后開始支持的，作用是返回上一頁（如圖4.1所示）。這個手勢引起的沖突是最常見的手勢沖突。在iOS6剛剛推出的時候，絕大多數(shù)的設(shè)備都是iPhone4和4s，而它們的屏幕都是3.5英寸大小的，如果直接在App中固定顯示菜單欄，會使用戶可操作的面積減少，所以大部分App采用的方式是把App的菜單欄隱藏起來，而用一個手勢，就是從屏幕左側(cè)邊緣向右滑動來顯示菜單欄。這一手勢在iOS6的時候成為了業(yè)界的標(biāo)準(zhǔn)，絕大多數(shù)的App采用的都是這樣的方式（圖4.2所示為iOS6時期Facebook的菜單欄）。而當(dāng)時iOS6也并不支持這樣的手勢，所以這些App和操作系統(tǒng)還都相安無事。圖4.1從屏幕左側(cè)邊緣向右滑動，從Page3返回到Page2圖4.2Facebook的App在iOS6的時候是支持從屏幕左側(cè)邊緣向右滑動呼出App的菜單欄當(dāng)iOS7推出的時候，iPhone5，iPhone5s和iPhone5c這些4英寸屏幕的設(shè)備已經(jīng)成為市場的主流了，很多App都重新把菜單欄放置回到常駐屏幕了（如圖4.3所示為iOS7時期Facebook的菜單欄）。圖4.3Facebook的App在iOS7的時候重新把菜單欄調(diào)整回屏幕頂部，并且常駐屏幕了由于對于iOS7這個手勢變化的適應(yīng)程度不一致，導(dǎo)致不同App對于從屏幕左側(cè)邊緣向右滑動出現(xiàn)不同的處理方式。（1）只有從主界面向右滑動時會呼出左側(cè)導(dǎo)航菜單欄，在其他層級界面這個手勢操作不會有任何反應(yīng)，比如之前版本的Path（如圖4.4所示）。不過新版Path的App也遵照iOS的設(shè)計，把菜單欄固定放置于屏幕底部了（如圖4.5所示）。（2）完全遵照iOS7的設(shè)計，在主界面右滑呼出左側(cè)導(dǎo)航菜單欄，在別的界面右滑則會返回上一級頁面。這種設(shè)計很符合iOS7的規(guī)范了，但是如果路徑設(shè)計太深，那么一級一級的返回方式會讓用戶感到很疲憊（如圖4.6所示為微信App中設(shè)置QQ郵箱提醒的文件夾）。圖4.4之前版本的Path只在主界面向右滑動會呼出左側(cè)導(dǎo)航菜單欄圖4.5新版Path的App也遵照iOS的設(shè)計，把菜單欄固定放置于屏幕底部圖4.6微信App中設(shè)置QQ郵箱提醒中的文件夾，需要很多步操作（3）一方面遵照iOS7上關(guān)于右滑返回的規(guī)范，另一方面加入自己的設(shè)計，比如新版的FacebookApp增加了左滑呼出右側(cè)導(dǎo)航菜單欄的手勢（如圖4.7所示）。圖4.7FacebookApp增加了左滑呼出右側(cè)導(dǎo)航菜單欄的手勢（4）完全不理會iOS7右滑操作的規(guī)范，在任何界面右滑都是呼出左側(cè)導(dǎo)航菜單欄，而只能通過左上角的返回按鈕來返回上一級。這類App通常設(shè)定為長按左上角的返回按鈕彈出快捷路徑，以此解決路徑深度過長的問題。典型的代表是Dropbox的第三方客戶端App—Boxie（如圖4.8所示）。圖4.8Boxie中長按左上角返回按鈕彈出快捷路徑（5）最后這種是容易導(dǎo)致誤觸的：從屏幕左側(cè)邊緣右滑執(zhí)行操作系統(tǒng)的右滑返回手勢，而在屏幕上其他位置右滑則會呼出App的導(dǎo)航菜單欄。這種方式非常不好的一點是由于用戶控制不好這兩種手勢操作的邊界，經(jīng)常會觸發(fā)錯誤的手勢操作。這里就不給出App的例子了。4.2在屏幕上向左滑動在iOS7自帶的程序，比如電子郵件和短信中，在某一條郵件或者短信記錄上向左滑動，會出現(xiàn)“更多”和“刪除”的菜單（如圖4.9所示）。圖4.9在iOS7自帶的電子郵件客戶端中，在郵件上向左滑動，會出現(xiàn)“更多”和“刪除”菜單這個手勢現(xiàn)在作為iOS上標(biāo)準(zhǔn)的操作手勢，很多App都在使用，包括大家熟知的微信（如圖4.10所示）。圖4.10在微信的聊天記錄上左滑，會出現(xiàn)“置頂/取消置頂”和“刪除”的菜單一般使用在屏幕上向左滑動的自定義手勢操作的App比較少，所以沖突不多，不過也要當(dāng)心像之前提到的Facebook這類在屏幕上向左滑動會呼出右側(cè)導(dǎo)航菜單欄的App。4.3從屏幕頂部向下滑動這個手勢操作在iOS和Android平臺上都是通用的，而它的作用就是呼出操作系統(tǒng)的通知中心（如圖4.11所示）。圖4.11AndroidL（左）和iOS8（右）的通知中心由于這個手勢操作在各平臺上都通用并且廣為人知，筆者還沒有見過因為在App中設(shè)置具有同樣手勢操作的功能而導(dǎo)致呼出通知中心的手勢操作失敗的。4.4從屏幕底部向上滑動從iOS7開始，在iOS設(shè)備底部向上滑，會呼出控制中心（如圖4.12所示）。圖4.12從iOS7開始出現(xiàn)的上滑呼出控制中心與呼出通知中心的從屏幕頂部向下滑動的手勢操作類似，呼出控制中心的從屏幕底部向上滑動的手勢操作也在幾乎任何的界面和應(yīng)用中都可以使用，但全屏任務(wù)下為了避免誤操作，需要進(jìn)行兩次，第一次可以看到小箭頭出現(xiàn)，第二次操作才會進(jìn)入功能。因為這個操作容易和有些App用作刷新數(shù)據(jù)的從下向上滑動的手勢操作沖突，所以如果你不想觸發(fā)控制中心，可以在設(shè)置中關(guān)閉“應(yīng)用程序內(nèi)訪問”來禁止它，使其只在主屏或鎖定屏幕界面才能使用。4.5按住屏幕向下滑動從iOS7開始，在iOS設(shè)備上，除了屏幕最頂部（那是為通知中心預(yù)留的操作范圍）之外，在主屏的任何位置向下滑動，都可以呼出搜索框（如圖4.13所示）。同樣是這個手勢，在iOSApp里的表現(xiàn)卻和在iOS主屏上不一樣，在iOSApp里，按住屏幕向下滑動，通常會導(dǎo)致App當(dāng)前頁面的刷新（如圖4.14所示為iOS自帶的Mail的情況）。圖4.13在iOS7主屏上按住屏幕向下滑動會呼出搜索框圖4.14在iOSApp，如Mail里按住屏幕向下滑動，會導(dǎo)致App當(dāng)前頁面刷新同樣，在AndroidApp中，按住屏幕向下滑動也會導(dǎo)致App當(dāng)前頁面的刷新（如圖4.15所示為Android的FacebookMessengerApp的情況）。所以對于按住屏幕向下滑動這個手勢，需要按照App的通用習(xí)慣來設(shè)計，避免引起用戶的不適應(yīng)。圖4.15在AndroidApp中按住屏幕向下滑動，會導(dǎo)致App當(dāng)前頁面刷新4.6在圖片上雙擊通常在圖片上，如果用戶進(jìn)行雙擊，App會放大這張圖片；再次雙擊，App就會恢復(fù)圖片之前的大?。ㄈ鐖D4.16所示）。因為這個手勢操作是App通用的手勢習(xí)慣，所以盡可能不要破壞這個手勢。圖4.16通常在App中雙擊圖片，就會放大該圖片；再次雙擊，會顯示原始圖片4.7兩根手指分開和捏合通常在App中，尤其是在圖片上，這兩個手勢操作產(chǎn)生的效果是放大和縮小當(dāng)前頁面（如圖4.17所示）。和在圖片上雙擊不太一樣，兩根手指分開和捏合的操作，可以平滑地放大或縮小頁面/圖片，而不是只有原始大小和放大這兩種顯示效果。圖4.17兩根手指分開和捏合可以無級放大或縮小App的當(dāng)前頁面同樣，作為通用的App標(biāo)準(zhǔn)手勢操作，也盡量不要破壞這兩種手勢。4.8兩根手指按住屏幕旋轉(zhuǎn)這個手勢操作通常出現(xiàn)在圖片編輯上，作用是用來旋轉(zhuǎn)圖片（如圖4.18所示）。圖4.18在圖片上用兩根手指按住屏幕旋轉(zhuǎn)，可以調(diào)整圖片顯示方向這個手勢操作只是針對圖片編輯或者文檔編輯類App有效，所以App中的手勢操作和這個手勢操作的沖突發(fā)生得比較少。4.93根手指的手勢操作3根手指也有手勢操作嗎？是的，只不過它的用處很少，只在iOS多任務(wù)處理的頁面，通過3根手指上滑，可以同時關(guān)閉3個當(dāng)前顯示的App（如圖4.19所示）。鑒于這個手勢操作的使用范圍很小，App中使用這個手勢發(fā)生沖突的概率也會很小。不過由于3根手指的手勢操作用戶并不容易使用，所以App還是盡量少使用這樣的手勢。眾所周知，因為iPhone的屏幕不是很大，所以最多只支持3根手指的操作；而iPad由于屏幕相對于iPhone來說大了不少，所以可以支持更多的手勢操作。以下介紹的4根手指和5根手指的操作，都只在iPad上適用。圖4.19在iOS多任務(wù)處理界面，3根手指上滑，可以同時關(guān)閉3個當(dāng)前顯示的App4.104根手指向上/下滑動在iPad上，在任何App中或者主屏上，使用4根手指向上滑動，會呼出iPad上的多任務(wù)處理界面（如圖4.20所示）。與之對應(yīng)的，在iPad上，呼出多任務(wù)處理界面時，在屏幕上用4根手指向下滑動，就能關(guān)閉多任務(wù)處理界面。圖4.20在iPad上使用4根手指向上滑動會呼出多任務(wù)處理界面4.114根手指向左/右滑動在iPad上，打開任何App，使用4根手指在屏幕上向左滑動，可以切換到最近使用的App，再向左，可以繼續(xù)切換到上一個App，依此類推（如圖4.21所示）。圖4.21在iPad中的任何App中使用4根手指向左或者向右滑動，可以快速切換前/后一個App這時如果使用4根手指在屏幕上向右滑動，可以向后切換App。4根手指向左和向右滑動是一組對應(yīng)的操作。4.125根手指聚攏的捏合操作在iPad上使用5根手指聚攏的捏合操作，能在任何一個App中返回主界面（如圖4.22所示）。圖4.22在iPad上任何一個App中用5根手指聚攏進(jìn)行捏合操作，可以返回主界面5根手指的操作雖然用戶容易使用，但是意味著用戶需要進(jìn)行雙手操作，這一點也需要注意。4.13搖動設(shè)備在iOS7自帶的短信、電子郵件、日歷、便箋和聯(lián)系人這些App中，當(dāng)輸入了一串有錯的信息，想從頭重新開始輸入，只需要左右搖晃設(shè)備（當(dāng)然對于橫屏的iPad來說就是上下?lián)u晃），屏幕就會出現(xiàn)一個彈出框，從而可以選擇是否要撤銷當(dāng)前的輸入（如圖4.23所示）。當(dāng)撤銷了當(dāng)前的輸入之后，再次左右搖晃設(shè)備，屏幕就會出現(xiàn)一個彈出框，這時還可以選擇重做之前的輸入（如圖4.24所示）。圖4.23在iOS7中，使用自帶的短信App，左右設(shè)備，會出現(xiàn)是否要撤銷當(dāng)前輸入的選擇圖4.24在iOS7中，使用自帶的短信App，當(dāng)撤銷了之前輸入，再次左右搖晃設(shè)備，會出現(xiàn)是否需要重做的選擇不知道在之后的操作系統(tǒng)里是否會對這樣的手勢操作有更大范圍的應(yīng)用，不過測試人員需要關(guān)注這樣的手勢操作，避免在新的操作系統(tǒng)修改這些手勢操作的時候，App沒有及時的修改。4.14長按屏幕在大多數(shù)的iOS的App中，長按手勢基本被拋棄，只是在對文本的復(fù)制粘貼和使用放大鏡時才出現(xiàn)；而在Android中長按手勢則基本可以認(rèn)為是標(biāo)準(zhǔn)操作之一。在Android中，長按屏幕的操作產(chǎn)生的效果很多，但是大部分都是長按后出現(xiàn)某一類的菜單，比如說在桌面的空白處長按會呼出編輯桌面的選項（如圖4.25所示）；而在很多App中，則會呼出對應(yīng)的上下文菜單。圖4.25在Android設(shè)備上，在桌面的空白處長按屏幕會呼出編輯桌面的選項了解這些不同手勢操作的目的在于，測試人員應(yīng)該盡量確保在App設(shè)計和測試中避免與操作系統(tǒng)手勢操作的沖突，當(dāng)然，另一方面還需要遵循約定俗成的手勢操作習(xí)慣，以減少用戶學(xué)習(xí)的成本。所以在測試App的過程中，大家不妨多使用這些手勢操作，看看會有什么樣不同的效果出現(xiàn)吧。軍規(guī)5關(guān)注用戶體驗在經(jīng)歷了移動App匱乏的時代之后，當(dāng)今移動App呈現(xiàn)出大爆發(fā)式的增長趨勢。同一類型的軟件，雖然提供的功能都差不多，但是也會有多家公司競爭。例如即時通信類軟件，大家常見的就有微信、來往、米聊、WhatsApp（如圖5.1所示）、LINE（如圖5.2所示）、Skype、KakaoTalk這些，而不常見的就更多了。圖5.1常見的即時通信類軟件WhatsApp圖5.2常見的即時通信類軟件LINE當(dāng)我們的App也是這眾多App中一員的時候，如何才能脫穎而出呢？其實就是按照現(xiàn)在流行的說法——為用戶設(shè)計，關(guān)注用戶的體驗。就移動App測試來說，也需要關(guān)注用戶體驗嗎？是的，測試人員不僅需要關(guān)注App的功能性需求，對于非功能性但關(guān)乎到用戶體驗的需求，更需要關(guān)注。這就要求大家在測試時思維更加開放一些，不只局限在功能性的需求上。那在測試移動App的時候，怎樣才能進(jìn)行用戶體驗的測試呢？在這里筆者列出了一些常見的用戶體驗所要關(guān)注的方面，不妨就從這些方面，讓我們來看看自己手中測試的App是否達(dá)到了要求。5.1橫豎屏幕測試在移動設(shè)備上做用戶體驗測試，最容易想到的就是對App做橫豎屏幕的測試，來觀察App的顯示效果。首先需要被測試的App支持橫豎屏。如果App不支持行不行呢？其實也是可以的，但是隨著大屏幕手機的流行，連保守的iPhone都發(fā)布了5.5英寸屏幕的iPhone6Plus，可見大屏幕手機是很有吸引力的。用戶在操作大屏幕手機的時候，通常選用的都是橫屏來使用App的。所以大家就盡量確保App支持橫屏操作吧（如圖5.3所示）。圖5.3大量的App都已經(jīng)支持了橫豎屏的顯示其次，要解決橫豎屏切換的問題。別看這是個很簡單的功能，貌似只要在代碼中設(shè)置支持橫豎屏顯示就可以避免橫豎屏切換出現(xiàn)問題。但實際上，在某些情況下App代碼有可能破壞了屏幕旋轉(zhuǎn)的功能，比如說在App中的某些頁面限制了屏幕顯示的方向（如圖5.4所示）。圖5.4在圖片上我們可以看見App展示內(nèi)容的方向和設(shè)備橫屏的方向不一致除此之外，還需要注意在App中嵌入了WebView的頁面的顯示。在支持橫豎屏切換的App中的頁面嵌入了WebView，當(dāng)WebView讀取完成時，有可能橫豎屏切換功能就被破壞了（如圖5.5所示，游戲中這種彈出頁面就破壞了橫豎屏的切換）。圖5.5當(dāng)把移動設(shè)備向右橫屏（設(shè)備底部在左手邊），然后打開App，App本身顯示正常。但是當(dāng)有WebView彈出的時候，頁面會反向；而當(dāng)設(shè)備向左橫屏的時候，卻沒有這個問題值得一提的是，如果App支持顯示圖表，測試人員更需要關(guān)注圖表在橫豎屏之間的切換，因為橫豎屏的顯示寬度不一樣，圖表在不同屏幕狀態(tài)下，顯示的內(nèi)容和樣式很可能也是不一樣的（如圖5.6所示）。在測試中，測試人員最好對每個頁面都進(jìn)行橫豎屏顯示的測試。當(dāng)然，要更加關(guān)注于嵌入WebView和其他彈出式的控件的頁面，以及圖表這類可能因屏幕寬度和高度不同而改變顯示內(nèi)容和效果的頁面。圖5.6App中同一個圖表在橫豎屏下顯示的內(nèi)容和樣式都有可能是不一樣的對于可以設(shè)置橫豎屏顯示的App，一旦設(shè)置了橫屏或者豎屏，從啟動App開始到關(guān)閉App為止，用戶所有操作的頁面都應(yīng)該以設(shè)置的屏幕顯示方向顯示，不能出現(xiàn)有些頁面橫屏，有些頁面豎屏這種混雜顯示的問題。5.2WebView的測試對于WebView的顯示，除了需要關(guān)注它對于橫豎屏的影響，還需要關(guān)注它在不同設(shè)備上的顯示。因為不同設(shè)備會有不同的屏幕寬度和高度，所以WebView的顯示效果通常也是千差萬別的。比如顯示寬度過寬（如圖5.7所示），顯示寬度過窄（如圖5.8所示），或者顯示位置太靠下從而導(dǎo)致頁面出現(xiàn)很大的空白（如圖5.9所示）等。圖5.7WebView顯示寬度過寬，造成有些文字被截斷圖5.8WebView顯示寬度過窄，造成顯示內(nèi)容不全圖5.9WebView顯示位置太靠下從而導(dǎo)致頁面出現(xiàn)很大的空白如果是具有特定格式的WebView，在不同設(shè)備上的顯示效果很可能差異更大，例如圖5.10所示表格的顯示差異。圖5.10在手機App中嵌入的WebView顯示樣式和在Web上是不一樣的如果在嵌入WebView的頁面輸入文本，可能會出現(xiàn)更多的問題，如圖5.11所示。圖5.11在嵌入的WebView中點擊Google搜索欄輸入的時候，頁面顯示會出現(xiàn)問題通常，開發(fā)移動App時想要在App里嵌入WebView，都是基于已經(jīng)有了產(chǎn)品的Web版本。如果構(gòu)建移動App的時候能使用已有的功能和資源，會節(jié)約開發(fā)的成本，降低開發(fā)難度。是的，理論上是這樣沒錯，但是如果在Web端沒有做到響應(yīng)式設(shè)計“ResponsiveDesign”（如圖5.12所示），在設(shè)計Web架構(gòu)的時候沒有考慮到Web端和移動App端功能以及特性的不同，就會造成在桌面端顯示正常的Web頁面被嵌入移動App之后會出現(xiàn)很多諸如前述的樣式顯示的問題。圖5.12響應(yīng)式設(shè)計“ResponsiveDesign”的理念是集中創(chuàng)建頁面的圖片排版大小，可以智能地根據(jù)用戶行為以及使用的設(shè)備環(huán)境（系統(tǒng)平臺、屏幕尺寸、屏幕定向等）進(jìn)行相對應(yīng)的布局所以最好不要在移動App中嵌入WebView，而是通過服務(wù)器返回信息，由原生代碼控制顯示的樣式，這樣可以更好地使用操作系統(tǒng)的特性來避免顯示問題。但是如果想使用WebView的優(yōu)勢，也就是在不改變客戶端代碼的情況下實現(xiàn)功能和樣式的更新時，就要盡量保證在Web端和移動App端都能實現(xiàn)響應(yīng)式設(shè)計（如圖5.13所示為iPhone上的AppStore從iOS6升級到iOS7時的變化）。圖5.13AppStore使用的就是WebView，所以即使設(shè)備沒有從iOS6升級到iOS7，

也可以體驗到新版的AppStore5.3規(guī)范與習(xí)慣對于支持多個操作系統(tǒng)平臺的移動App，也需要在不同的操作系統(tǒng)上，遵循當(dāng)前操作系統(tǒng)的設(shè)計規(guī)范和使用習(xí)慣，而不要一味地為了自己各個App的一致性而破壞操作系統(tǒng)的設(shè)計規(guī)范和使用習(xí)慣。iOS的設(shè)計規(guī)范要求把菜單放置在設(shè)備底端，在記錄上從右向左滑動會呼出“刪除”和“更多”菜單等（如圖5.14所示）。圖5.14微信iPhone版本一直遵循iOS的操作規(guī)范Android的設(shè)計規(guī)范則要求把多于3個的菜單放置在右上角3個點的按鈕中，而長按記錄則可以呼出更多的操作選項等（如圖5.15所示）。不同的操作系統(tǒng)有不同的特性，因此也有自己獨特的設(shè)計和使用習(xí)慣，測試人員在開發(fā)和測試移動App的時候，都需要盡可能遵循這些規(guī)范，減少用戶的學(xué)習(xí)成本，提高使用App的便利性。圖5.15Android版本微信在5.2版本的時候從遵循iOS的風(fēng)格改為Android的設(shè)計風(fēng)格，

可惜在5.4版本的時候又改回到iOS的風(fēng)格了5.4關(guān)注用戶體驗測試人員不僅需要關(guān)注身體健全的用戶，也需要關(guān)注殘障人士。這不僅是人性的關(guān)懷，還是很多發(fā)達(dá)國家，比如美國、澳大利亞、新加坡等國家和地區(qū)在法律中有明文規(guī)定需要強制執(zhí)行的。所以不僅為了移動App能順利發(fā)布和避免引起訴訟，而且為了更多的用戶能使用我們的App，稍微多花一些開發(fā)時間和精力關(guān)注用戶體驗也是非常值得的。在當(dāng)前主流的操作系統(tǒng)中，都帶有“輔助功能”的選項（如圖5.16、圖5.17和圖5.18所示）。圖5.16iOS8自帶的“輔助功能”選項。更多iOS上的“輔助功能”可以參看

\hhttps://www.A/cn/accessibility/ios/圖5.17Android5.0自帶的“輔助功能”選項。更多Android上的“輔助功能”可以參看

\h/guide/topics/ui/accessibility/index.html圖5.18不少Android廠商也對“輔助功能”做了增強，例如圖中所示的三星Galaxy上的TouchWiz在這些輔助功能中，測試人員可以重點測試“放大字體”、“反色”、“放大”和“文字轉(zhuǎn)語音”/“VoiceOver”這些功能。比如，在測試視力不好的用戶經(jīng)常使用的放大字體的功能時，需要保證在更大字體的顯示設(shè)置下，App不會出現(xiàn)界面顯示不全，文字模糊等問題（如圖5.19所示）。圖5.19字體放大后文字可能顯示不全，如圖片中部的“Headphonesandaudioeffects”還有當(dāng)測試人員在測試聽力殘障的用戶常使用的“文字轉(zhuǎn)語音”/“VoiceOver”功能時，需要檢查App是否提供了完整的備用文本AltText，以便這些功能可以給用戶讀出頁面信息，并且能夠正常使用按鈕等功能。當(dāng)然還需要測試這些功能的朗讀質(zhì)量，比如有沒有不連續(xù)的現(xiàn)象等（5.4版本的微信iOS版就存在朗讀不流暢的問題）。5.5其他需要關(guān)注的用戶體驗的小細(xì)節(jié)（1）在不同顏色的背景下，狀態(tài)欄的顯示是否正常。不僅iOS7，而且Android4.4都開始支持沉浸式狀態(tài)欄，所以如果App支持這些平臺，就需要注意測試在App不同顏色的頁面上，狀態(tài)欄的顏色顯示是否正常，是否做到了沉浸式設(shè)計（如圖5.20所示）。圖5.20iOS從iOS7開始支持沉浸式狀態(tài)欄設(shè)計，我們可以通過和iOS6的對比明顯看出區(qū)別（2）當(dāng)用戶快速點擊App中的按鈕等可操作控件時，會出現(xiàn)什么樣的效果？相信很多經(jīng)驗豐富的測試人員看到這里都會會心一笑，因為這是在桌面軟件測試和Web測試時的一個小技巧，現(xiàn)在在移動App測試中也是同樣適用的。使用這個測試技巧的目的在于，當(dāng)用戶在App中進(jìn)行不必要的多次操作時，應(yīng)確保App避免對這些重復(fù)的多次操作作出響應(yīng)。當(dāng)然，有一種情況例外，如果App具有多次點擊操作的特性時（比如說各類游戲中的點擊操作），App當(dāng)然需要允許這些操作。（3）對于不支持多點觸摸的App，也需要測試App對于多點觸摸的支持。讀者可能覺得疑惑，不是明明App不支持多點觸摸嗎，為什么還需要測試呢？答案是，我們不能限制真實用戶是怎么使用App的，只能模仿真實用戶對App多點觸摸的支持進(jìn)行測試，尤其是對于游戲類App的測試（如圖5.21所示為iPad上的GarageBand）。圖5.21iPad上的GarageBand支持多點觸摸的特性雖然這章介紹的知識都比較細(xì)碎，但是用戶體驗就是在細(xì)節(jié)上才能體現(xiàn)出App的質(zhì)量和對用戶的重視程度，而且界面也是用戶最容易關(guān)注到的地方，所以測試人員在測試中一定不能忽視這些細(xì)節(jié)。軍規(guī)6設(shè)計通知和消息展示作為Android用戶，最痛苦的一點莫過于接收到各種已安裝的App發(fā)送的各類通知，而這些通知的行為和觸發(fā)方式又各不相同，讓用戶使用起來感覺無所適從。測試人員在測試移動App的時候，也需要關(guān)注App的通知、消息顯示和消息推送。6.1測試App安裝時是否明確申明在用戶使用App時需要用到的權(quán)限在移動App的安裝方面，由于Apple公司和Microsoft公司嚴(yán)格控制自己操作系統(tǒng)的生態(tài)系統(tǒng)，只允許通過官方的應(yīng)用商店安裝應(yīng)用，并對提交的每份移動App都進(jìn)行非常詳盡的審查，所以用戶在iOSAppStore或者WindowsPhone應(yīng)用商店中下載App并安裝時，并不會對App使用的權(quán)限進(jìn)行提示。對于iOS和WindowsPhone平臺，如果用戶同意下載和安裝App，就代表用戶默認(rèn)App使用其向AppStore或WindowsPhoneStore提交時申明的那些權(quán)限。而Android則不相同，由于Android的開放性，用戶可以通過官方或者第三方的應(yīng)用商店安裝App，也可以先下載apk文件，再手動安裝。GooglePlay作為Android官方商店，在下載和安裝的時候，也會明確提示用戶App所需要用到的權(quán)限（如圖6.1所示）。對于手動下載安裝App，Google希望保證用戶在任何安裝方式下，都能及時了解自己的隱私是否被泄漏，以及App是否使用了自己不希望App使用的傳感器和權(quán)限。鑒于此，Android在非系統(tǒng)自帶App安裝的時候，都會提示用戶當(dāng)前安裝App所要求的權(quán)限（如圖6.2所示），而這個權(quán)限申明頁面列出了App有可能使用到的所有權(quán)限。如果用戶不同意向App開放某些權(quán)限，就只能拒絕App的安裝了。所以測試人員在測試App的時候，需要注意到這些權(quán)限是否已經(jīng)明確申明，不然App在提交到操作系統(tǒng)官方應(yīng)用商店時會被拒絕，或者在用戶安裝App的時候被拒絕。圖6.1GooglePlay在用戶下載和安裝App時會提示App使用的權(quán)限圖6.2Android在非系統(tǒng)自帶App安裝的時候提示用戶的權(quán)限申明頁面6.2測試App在用戶使用過程中是否有合適的通知和消息顯示在用戶使用App的過程中，當(dāng)App需要使用到類似GPS、藍(lán)牙等傳感器，或者需要開啟數(shù)據(jù)流量設(shè)置，iOS中訪問用戶的照片和短信等應(yīng)用資源的時候，測試人員需要及時通知用戶；當(dāng)App需要獲得用戶位置等隱私信息時，當(dāng)然也需要對用戶進(jìn)行提示（如圖6.3所示）。那如果測試人員在使用App過程中改變權(quán)限獲取本不該得到的權(quán)限時，會出現(xiàn)什么問題呢？在iOS上App會訪問不到它想獲得的資源和權(quán)限；而在Android平臺上，操作系統(tǒng)會彈出安全性異常的提示框，并強制關(guān)閉App（如圖6.4所示）。從另一方面來說，怎樣才能提高向用戶申請訪問權(quán)限的成功率呢？我們不妨檢查一下App在需要用戶授權(quán)的時候是否遵循了以下的設(shè)計原則和實踐。圖6.3在App使用過程中，如果需要訪問用戶位置信息，需要明確提示用戶圖6.4在Android上當(dāng)App越權(quán)訪問不該得到的權(quán)限時，操作系統(tǒng)會彈出安全性異常的提示框，并強制關(guān)閉App1．App向用戶申請訪問權(quán)限的第一次很關(guān)鍵對很多App而言，如果無法獲取對手機傳感器或數(shù)據(jù)的訪問權(quán)限，會嚴(yán)重影響用戶體驗。試想如果滴滴打車不知道你身在何處，它將如何通知附近的司機呢？更糟糕的情況是，一旦用戶點擊了“不允許”，再想讓他們改變主意就不那么容易了。比如根據(jù)iOS的系統(tǒng)設(shè)置，在用戶拒絕App的訪問申請后，需要執(zhí)行5個步驟，才能重新允許App的訪問（如圖6.5所示）。因此我們的目的在于如何在App第一次對用戶申請訪問權(quán)限時取得用戶的允許。圖6.5在iOS操作系統(tǒng)中，用戶需要執(zhí)行5個步驟才能重新允許App對某種資源或權(quán)限的訪問不要在用戶第一次打開App的時候直接申請訪問權(quán)限。我們看到有些App剛下載安裝完成，當(dāng)用戶第一次打開App時，App就向用戶申請訪問權(quán)限：“×××想要給您發(fā)送推送通知”，“×××想訪問您的照片”等（如圖6.6所示）。圖6.6Skype在第一次啟動的時候就向用戶申請訪問權(quán)限，用戶很容易選擇拒絕這種方式對于用戶來說過于突然，除非用戶已經(jīng)很熟悉這個應(yīng)用，例如QQ和微信這種App，否則用戶在這時更傾向于選擇“不允許”。因此我們不應(yīng)該在App申請