移動app應用測試方法與測試思路(德魯)

  1 三種移動端產品類型的介紹
  2     移動端應用的測試其自身特色，和其餘傳統測試又有一些獨特
  3     測試方法和思路。
  4     
  5     移動端應用又能夠進一步細分爲三大類：
  6     Web APP 指的是移動端的Web瀏覽器，其實和PC端的Web瀏覽器
  7     沒有任何區別，只不過Web瀏覽器所依附的操做系統再也不是Windows
  8     和Linux了，而是IOS和Android了。
  9     
 10     Web App 採用的技術主要是，傳統的HTML，JavaScript，CSS等
 11     Web技術棧，固然如今HTML5也獲得了普遍的應用。另外，WebAPP
 12     所訪問的頁面內容都是放在服務器端的，本質就是Web網頁，因此
 13     天生跨平臺。
 14     
 15     Native App指的是移動端的原生應用，對於Android是apk，對於Android是apk，
 16     對於IOS就是ipa。NativeApp是一隻基於手機操做系統（IOS和android），
 17     並使用原生程序編寫運行的第三方應用程序。
 18     
 19     Native App的開發，Android使用的語言一般是Java，IOS使用的
 20     語言是Objective-C。一般來講，Native App能夠提供比較好的
 21     用戶體驗以及性能，並且能夠方便地操做手機本地資源。
 22     
 23     Hybrid App，是介於Web App和Native App 兩種之間的一種App形式。
 24     Hybrid App 利用了Web App和Native App的優勢，經過一個
 25     原生實現的NativeContainer展現HTML5的頁面。更通俗的講法
 26     能夠歸結爲，在原生移動應用中嵌入了Webview，而後經過該Webview
 27     來訪問網頁。
 28     Hybrid App具備維護更新簡單，用戶體驗優異以及較好的跨平臺性，
 29     是目前主流的移動應用開發模式。
 30     
 31 三類不一樣移動應用的測試方法
 32     根據它們的特性來總結出它們的測試方法：
 33     
 34 Web App，顯然其本質就是Web瀏覽器的測試，全部GUI自動化
 35     測試的方法和技術，好比數據驅動，頁面對象模型，業務流
 36     封裝等，都適用於Web App的測試。
 37     
 38     若是Web頁面是基於自適應網頁涉及（即符合ResponsiveWeb
 39     設計的規範），並且測試框架若是支持Responsive Page，那麼
 40     原則上以前開發的運行在PC Web 端的GUI自動化測試用例，不作
 41     任何修改就能夠直接在移動端的瀏覽器上直接執行，固然運行的
 42     前提是你的移動端瀏覽器必須支持WebDriver。其中，自適應網頁
 43     設計（Responsive Web Design）是指，同一個網頁能自動識別
 44     屏幕分辨率，並做出相應調整的網頁設計技術。
 45 
 46 Native App的測試，雖然不一樣的平臺會使用不一樣的自動化測試
 47     方案，iOS通常採用XCUITest Driver，而Android通常採用
 48     UiAutomator2 或者 Espresso 等，可是數據驅動，頁面
 49     對象以及業務流程封裝的思想依舊適用，徹底能夠把這些方法
 50     應用到測試用例設計中。
 51     
 52     Hybrid App的測試，狀況會稍微複雜一點，對Native Container
 53     的測試，可能須要用到XCUITest或者UiAutomator2這樣的原生
 54     測彷佛框架，而對Container中HTML5的測試，基本和傳統的網頁
 55     測試沒什麼區別，因此本來基於GUI的測試思想和方法都能繼續
 56     適用。
 57     
 58     惟一須要注意的是，Native Container 和 Webview 分別屬於兩個
 59     不一樣的上下文（Context),Native Container默認的Context爲
 60     「NATIVE APP」，而Webview默認的Context爲「WEBVIEW_+被測進程名稱」
 61     
 62     
 63     
 64 Web測試和APP測試的區別
 65 
 66     相同點:WEB測試和App測試從流程上來講，沒有區別，都須要
 67     經歷測試計劃方法，用例設計，測試執行，缺陷管理，測試報告
 68     等相關活動。從技術上來講，WEB測試和APP測試其測試類型也基本
 69     類似，都須要進行功能測試，性能測試，安全性測試，GUI測試
 70     等測試類型。
 71     
 72     不一樣點：它們的主要區別在於具體測試的細節和方法有卻別。
 73     
 74     性能測試：在WEB測試只須要測試響應時間這個要素，在App測試
 75     中須要考慮流量測試和耗電量測試。
 76     
 77     兼容性測試：在WEB端是兼容瀏覽器，在App端兼容的是手機設備。
 78     並且相對應的兼容性測試工具也不相同，WEB由於是測試兼容
 79     瀏覽器。因此須要使用不一樣的瀏覽器進行兼容性測試（經常使用的是
 80     兼容IE6，IE8，chrome，Firefox）若是是手機端，那麼就須要
 81     兼容不一樣品牌，不一樣分辨率，不一樣Android版本甚至不一樣操做系統
 82     的兼容。（常見的兼容方式是兼容市場佔用率前N位的手機便可），
 83     有時候也可使用到兼容性測試工具，但WEB兼容性工具多使用IETest
 84     等工具，而App兼容性測試會使用Testin這樣的商業工具也能夠作
 85     測試。
 86     
 87     安裝測試：WEB測試基本上沒有客戶端層面的安裝測試，可是App
 88     測試是存在客戶端層面的安裝測試，那麼就具有相關的測試點。
 89     
 90     App測試基於手機設備，還有一些手機設備的專項測試。如交叉
 91     事件測試，操做類型測試，網絡測試（弱網測試，網絡切換）交叉
 92     時間測試：就是在操做某個軟件的時候，來電話，來短信，電量
 93     不足提示等外部時間。操做類型測試：如橫屏測試，手勢測試
 94     網絡測試；包含弱網和網絡切換測試。須要測試弱網所形成的
 95     用戶體驗，重點要考慮回退和刷新是否會形成二次提交。弱網
 96     絡的模擬，聽說能夠用360wifi實現設置。升級測試：升級測試的
 97     提醒機制，升級取消是否會影響原有功能的使用，升級後用戶數據是否
 98     被清除了。
 99     
100         從系統架構的層面，WEB測試只要更新了服務器端，客戶端
101     就會同步更新。並且客戶端是能夠保證每個用戶的客戶端徹底
102     一致的。可是APP端是不可以保證徹底一致的，除非用戶更新客戶
103     端。若是是APP下修改了服務器端，意味着客戶端用戶所使用的核心
104     版本都須要進行迴歸測試一遍。
105     
106         如此看來，移動端的測試除了使用的測試框架不一樣之外，
107     測試設計自己和GUI測試用殊途同歸之妙，對於移動端還應該
108     有其餘的不一樣測試思路和方法。
109     
110 移動應用專項測試的思路和方法
111     
112     對於移動應用，順利完成所有業務功能測試每每是不夠的，
113     當移動應用被大量用戶安裝和使用時，就會暴露出不少以前
114     徹底沒有預料到的問題。
115     好比：
116     1.流量使用過多
117     2.耗電量過大；
118     3.在某些設備終端上出現崩潰或閃退的現象；
119     4.多個移動應用相互切換後，行爲異常；
120     5.在某些設備字段上沒法順利安裝或卸載；
121     6.弱網絡環境下，沒法正常使用；
122     7.App 運行時進入低電量模式；
123     8.App運行時第三方安全軟件彈出告警；
124     9.App運行時發生網絡切換，好比，由WiFi切換到移動4G網絡，
125     或者從4G網絡切換到3G網絡等。
126     。。。
127     
128     其實你能夠發現，這些須要覆蓋的場景，也是咱們從此測試的
129     測試用例集，每一場都是一個測試用例的集合。
130     
131 2.兼容性測試
132     兼容性測試顧名思義就是，要確保App在各類終端設備，各類操做
133     系統，各類屏幕分辨率，各類網絡環境下，功能的正確性。常見的
134     App兼容性測試每每須要覆蓋如下的測試場景：
135     1.不一樣操做系統的兼容性，包括主流的Android和iOS版本；
136     2.主流的設備分辨率下的兼容性；
137     3.主流移動終端機型的兼容性；
138     4.同一操做系統中，不一樣語言設置時的兼容性；
139     5.不一樣網絡鏈接下的兼容性，好比Wifi，GPRS，EDGE，CDMA200等；
140     6.在單一設備上，與主流熱門App的兼容性，好比微信，抖音，淘寶等；
141     
142     兼容性測試一般都須要在各類真機上執行相同或者相似的測試用例，
143     因此每每採用自動化測試的手段。同時，因爲須要覆蓋大量的真
144     實設備，除了大公司會基於Appium+SeleniumGrid+OpenST去搭建本身
145     的移動設備私有云平臺，其餘公司通常都會使用第三方的移動設備
146     雲平臺完成兼容性測試。第三方的移動設備雲測平臺，國外最知名的
147     是SauceLab，國內主流的是Testin。
148     
149     3.流量測試
150         因爲App常常須要在移動互聯網環境下運行，而移動互聯網
151     一般安裝實際使用流量計費，因此若是你的App耗費的流量過多，
152     第一會致使用戶流量費用增長，第二會致使功能加載緩慢。
153         流量測試，一般包含如下幾個方面的內容：
154         1.App執行業務操做引發的流量；
155         2.App在後臺運行時的消耗流量；
156         3.App安裝完成後首次啓動耗費的流量；
157         4.App安裝包自己的大小；
158         5.App內購買或者升級須要的流量；
159         
160         流量測試，每每藉助於Android和iOS自帶的工具進行流量
161         統計，也能夠是使用tcpdump，Wireshark和Fiddler等網絡
162         分析工具。
163         
164         對於Android系統，網絡流量信息一般存儲在/proc/net/dev目錄下，
165         也能夠直接利用ADB工具獲取實時的流量信息。Android的輕量級
166         性能監控小工具Emmagee，相似於Windows系統性能監視器，可以
167         實時顯示App運行過程當中CPU，內存和流量等信息。
168         
169         對於iOS系統，可使用Xcode自帶的性能分析工具集中的Network
170         Activity，分析具體的流量使用狀況。
171         
172         可是，流量測試的最終目的，並非獲得App的流量數據，而是要
173         想辦法減小App產生的流量。減小App消耗的流量不是測試工程師的
174         工做，但瞭解一些經常使用的方法，也將有助於你的測試平常工做：
175         1.啓用數據壓縮，尤爲是圖片；
176         2.使用優化的數據格式，好比一樣信息量的JSON文件就要比XML文件小；
177         3.遇到既須要加密又須要壓縮的場景，必定是先壓縮再加密；
178         4.減小單次GUI操做觸發的後臺調用數量；
179         5.每次回傳數據儘量只包括必要的數據；
180         6.啓用客戶端的緩存機制；
181         。。。
182         
183         4.耗電量測試
184             耗電量也是一個移動應用可否成功的關鍵因素之一。在
185             目前的生態環境下，能提供相似服務或者功能的App每每有
186             不少，若是功能相似的狀況下，App特別耗電，讓設備發熱比較
187             嚴重，那麼你的用戶必定會卸載你的App而改用其餘App。最
188             典型的就是地圖等導航類的應用，對耗電量特別敏感。
189             
190         耗電量測試一般從三個方面來考量：
191             App運行但沒有執行業務操做時的耗電量；
192             App運行且密集執行業務操做時的耗電量
193             App後臺運行的耗電量
194         
195         耗電量檢測即有基於硬件的方法，也有基於軟件的方法。
196         我所經歷過的項目都是採用軟件的方法，Android和iOS
197         都有各自本身的方法：Android經過adb命令「adb shell
198         dumpsys battery」來獲取應用的耗電量信息耗電測試中，
199         Google推出的history batterian工具很好分析耗電狀況；
200         
201         iOS經過Apple的官方工具Sysdiagnose來收集耗電量信息，而後 
202         ，能夠進一步經過Instrument工具鏈中的Energy Diagnostice
203         進行耗電量分析。
204     5.弱網絡測試    
205         與傳統桌面應用不一樣，移動應用的網絡環境比較
206 多樣，並且常常出現須要在不一樣網絡之間切換的場景，即便是在同一網絡環境下，也會出現網絡鏈接狀態時好時壞的狀況，好比時高時低的延遲、常常丟包、頻繁斷線，在乘坐地鐵、穿越隧道，和地下車庫的場景下常常會發生。
207 　　因此，移動應用的測試須要保證在複雜網絡環境下的質量。在測試階段，模擬這些網絡環境，在 App 發佈前儘量多地發現並修復問題。推薦開源移動網絡測試工具：FacebookAugmented TrafficControl（ATC）。
208 　　ATC 最好用的地方在於，它可以在移動終端設備上經過Web界面隨時切換不一樣的網絡環境，同時多個移動終端設備能夠鏈接到同一個Wifi，各自模擬不一樣的網絡環境，相互之間不會有任何影響。也就是說，只要搭建一套ATC就能知足你全部的網絡模擬需求。
209 　　6. 邊界測試
210 　　邊界測試是指，移動 App在一些臨界狀態下的行爲功能的驗證測試，基本思路是須要找出各類潛在的臨界場景，並對每一類臨界場景作驗證和測試。
211 　　主要的場景有：
212 　　1)系統內存佔用大於 90% 的場景；
213 　　2)系統存儲佔用大於 95% 的場景；
214 　　3)飛行模式來回切換的場景；
215 　　4)App不具備某些系統訪問權限的場景，好比App因爲隱私設置不能訪問相冊或者通信錄等；
216 　　5)長時間使用 App，系統資源是否有異常，好比內存泄漏、過多的連接數等；
217 　　6)出現 ANR 的場景；
218 　　7)操做系統時間早於或者晚於標準時間的場景；
219 　　8)時區切換的場景；
220 　　…
221 　　耗電量測試，流量測試，以及app性能測試，如何界定數據是否正常？例如流量消耗是到哪一個值以爲有優化空間，內存CPU到哪一個值不正常須要優化
222 　　其實並無明確的標準，主要基於一些歷史統計數據，主要的作法是和現有版本，以及同類app作比較。
223         
224     
225     
226 結合實際狀況測試點組合場景
227 
228 　　結合一些實際狀況測試點簡單組合下場景場景：
229 　　好比：
230 　　出現崩潰：
231 　　1)設備碎片化：因爲設備極具多樣性，App在不一樣的設備上可能有表現不一樣;
232 　　2)帶寬限制：帶寬不佳的網絡對App所需的快速響應時間可能不夠;
233 　　3)網絡的變化：不一樣網絡間的切換可能會影響App的穩定性;
234 　　4)內存管理：可用內存太低，或非受權的內存位置的使用可能會致使App失敗;
235 　　5)用戶過多：鏈接數量過多可能會致使App崩潰;
236 　　6)代碼錯誤：沒有通過測試的新功能，可能會致使App在生產環境中失敗;
237 　　7)第三方服務：廣告或彈出屏幕可能會致使App崩潰;
238 　　App的安裝與卸載
239 　　就是其餘web裏邊沒有的場景，最基本的藥考慮不一樣操做系統，考慮不一樣的操做系統版本，考慮不一樣手機廠商再操做系統版本修改上的不一樣，等等
240 　　安裝過程當中：
241 　　1)各個選項是否符合概要設計說明;
242 　　2)安裝嚮導的ui測試;
243 　　3)是否支持取消，以及取消後的操做流程（是否有殘留);
244 　　4)意外狀況處理（司機、重啓、斷電、斷網）;
245 　　5)安裝空間不足
246 　　安裝完成後：
247 　　1)是否正常運行;
248 　　2)安裝過程後的文件夾和文件是否寫在了指定的目錄裏邊;
249 　　3)是否生成了多餘的目錄結構和文件;
250 　　升級：
251 　　1)升級後功能是否和需求說明同樣
252 　　2)測試與升級模塊相關的模塊的功能是否
253 　　3)升級界面的ui測試（強制/非強制）
254 　　4)升級安裝意外狀況的測試（死機、重啓、斷電）
255 　　5)版本驗證：1.0版-2.0或者1.0-3.0
256 　　6)升級中用戶數據、設置、狀態的保留，注意新版本已去掉的狀態或設置；
257 　　7)是否能夠隔開版本覆蓋安裝；
258 　　8)是否能夠覆蓋安裝更低版本；
259 　　9)若是升級有忽略本次版本升級，那麼當有新的升級版本時，是否還有提示升級；
260 　　10)大版本更新不升級沒法使用；
261 　　卸載：
262 　　1)系統直接卸載以及卸載時候ui界面測試;
263 　　2)直接刪除文件夾，再卸載;
264 　　3)卸載過程當中是否支持取消，取消後的軟件狀態;
265 　　4)卸載時候意外的狀況處理（死機、斷網、斷電、重啓);
266 　　5)卸載安裝，安裝目錄清理，SD卡存儲數據不被清理；
267 　　6)在沒有更新或者網絡時，須要給予用戶正確的信息表達；
268 　　App的啓動與中止
269 　　1)首次啓動是否出現歡迎界面，能否進入App，停留時間是否合理;
270 　　2)首次啓動後拉取的信息是否正確;
271 　　3)再次啓動時間是否符合預期；
272 　　4)再次啓動app功能是否異常
273 　　5)再次啓動後狀態檢查：如初始化信息、初始狀態、啓動對網絡；
274 　　6)再次啓動進程服務檢查：進程名、進程數、服務名、服務數、第三方調用的SDK如GPS；
275 　　7)再次帶登錄的應用是否再次啓動的時候正常登陸；
276 　　8)出現崩潰是否能夠再次啓動;
277 　　9)手動終止進程、服務是否能夠在此啓動;
278 　　10)其餘系統軟件工具中止進程、清理軟件數據，是否能夠啓動；
279 　　中斷測試
280 　　1)鎖屏中斷：停留在程序操做界面進行鎖屏，恢復後檢查操做是否正常；
281 　　2)先後臺切換：停留在程序操做界面，經過Home鍵，進行程序的先後臺切換；
282 　　3)加載中斷：頁面接口請求、界面框架加載時，經過Home鍵、返回鍵、快速切換操做進行中斷；
283 　　4)系統異常中斷：如關機、斷電、來電；
284 　　流暢度
285 　　列表滑動、返回進入、快速點擊（這個肉眼很差評判，能夠藉助GT，通常打分在90分以上是比較好的）
286 　　軟件兼容
287 　　通用軟件；
288 　　輸入法；
289 　　安全軟件；
290 　　通訊類；
291 　　競品軟件 同類軟件，是否出現衝突；
292 
293 
294 總結
295 
296 　　移動應用根據技術架構的不一樣，主要分爲 Web App、Native App 和 Hybrid App 三大類，這三類應用的測試方法本質上都屬於 GUI 測試的範疇。
297 　　從業務功能測試的角度看，移動應用的測試用例設計和傳統 PC 端的 GUI 自動化測試策略比較相似，只是測試框架不一樣，數據驅動、頁面對象模型和業務流程封裝依舊適用；
298 　　各類專項測試是移動應用的測試重點，也有別於傳統 GUI 測試。專項測試包括：交叉事件測試、兼容性測試、流量測試、耗電量測試、弱網絡測試和邊界測試;
299 
300 
301 
302     
303     
304