Web測試轉App測試不看不知道

Web測試

Web一般指的是互聯網應用系統，好比稅務電子化徵管檔案系統、金融數據平臺、餐飲商家管理後臺等等，其實質是C/S的程序。

C是Client——客戶端，S是Server——服務器。

Web中的客戶端通常指的是Browser——瀏覽器，也就是B/S。

Web系統有三層結構 == 表示層 + 業務層 + 數據層。

MVC軟件設計模式也是三層 == 模型 + 視圖 + 控制器。

它們的對應關係以下，不徹底準確，簡單意會意會便可，

測試的一個重要思路是，瞭解被測對象的架構，Web系統典型架構如圖所示，

這個圖很重要，多看幾秒！想一想這些問題，

我測試覆蓋的是哪些地方？

有哪些環節是漏掉的？

瀏覽器從請求到響應，這個過程是怎樣一個鏈路？

測試難點

Web測試，不只僅是頁面的點點點。

面對這樣複雜的系統，如何保障質量，使系統健康的、長期的、穩定的運行，是測試的難點。

業務複雜度自己就是難點，並且這是測試核心中的核心。

安全、性能的評估，也是一個棘手的難點。

網站用戶的能力，包括瀏覽器、操做系統、設備、網絡帶寬均可能是良莠不齊。

網絡中斷，或弱網狀況下，網站的表現。

網站自己的應用日誌、系統資源、冷熱數據。

引入的第三方程序的質量，雖然能夠直接用，但仍需作黑盒測試。

國際化差別，如語言、時差、貨幣兌換。

你要考慮的不是一個點，也不是一個面，而是一個總體。

表示層

表示層的測試對象包括了，

• UI（User Interface）用戶界面
• UE（User Experience）用戶體驗
• UED（User-Experience Design）用戶體驗設計

簡而言之就是，系統的外觀和感受。

更專業具體點，就是總體審美、字體、連接跳轉、圖形分辨率和大小、色彩、拼寫檢查、文字語法和風格、光標位置、選中默認按鈕、交互操做體驗友好、商業特定術語和風格、確認框、瀏覽器版本、操做系統配置等。

表示層的測試主要以人工爲主，部分測試也能夠經過工具完成，如無效連接檢測。

業務層

業務層包括內部業務和外部服務，內部業務和外部服務都須要通過測試。

內部業務就是實實在在的業務，每一個公司的業務都有差別。

業務測試是貫穿於測試周期自始始終的。

最開始測試考慮的是業務，測試結束考慮的也仍是業務。

業務層測試是用到測試用例設計方法最多的，包括等價類劃分、邊界值、斷定表、因果分析、場景法等。

同時也須要作性能測試，考察響應時間、吞吐率等性能指標。

絕不誇張的說，無業務，不測試！

數據層

數據層主要乾的事就是讀寫數據。

數據層的數據既包括系統自產的，也包括從用戶收集來的數據。

數據是存放在數據庫服務器裏邊的，包括RDBMS、NoSQL。

數據模型定義了數據層接口和數據存儲方式。

數據能夠直接使用，但每每是通過了ETL對數據進行加工。

數據層的測試是有一些門檻的，但一些隱藏的bug就藏在這一層。

首先須要測試的是數據存儲的正確，其次須要測試冗餘數據的清理，還有數據狀態的變化。

數據庫的性能，sql的耗時，數據量大小，數據冷熱。

數據庫的數據類型，長度、精度、字符集、日期時間格式、時區等。

數據庫的安全，數據加密和安全性。

還有數據庫的魯棒性，故障處理，備份恢復能力，最大化MTBF，最小化MTTR。

App測試

網絡

App測試仍是從架構入手，先看看App的典型的無線運營商網絡架構，

移動網絡，是App區別於Web應用的重要差別。

移動網絡的通訊協議並非基於IP的，而一般是一種基於射頻的協議。

如，

• CDMA（Code Division Multiple Access）碼分多址
• TDMA（Time Division Multiple Access）時分多址
• GSM（Global System for Mobile）全球移動通訊系統
• 4G （the 4th generation mobile communication technology）第四代移動通訊技術

不少運營商都使用某種代碼轉換器或Web代理來進行移動設備與互聯網的通訊。可是由於競爭的關係，運營商通常不會披露這些細節。他們可能會「偷偷」幹這些事，

• 將數據轉換成WAP或HTTP支持的格式
• 壓縮數據爲了更快地傳輸和提升吞吐量
• 數據傳輸加密和隱私保護
• 屏蔽一些佔用太高帶寬的站點
• 從網頁中抽取HTML頭信息和其餘元數據以供程序使用

WAP，是指Wireless Application Protocal，無線應用協議，已通過時。

如今大多數都使用HTTP協議了。

正是因爲移動網絡的存在，以及不一樣使用場景下網絡狀態的不穩定，在測App時，須要作弱網測試。

弱網包括無網（斷網）、弱網（2G 3G 4G）、網絡切換。

設備

App測試和Web測試，另一個明顯的區別就是，移動設備很是豐富。

不一樣的機型。不一樣的屏幕。不一樣的版本。不一樣的系統。不一樣的CPU內存。不一樣的瀏覽器。不一樣的配置。

App是To C的，也就意味着使用環境沒法統一控制，是千差萬別的。

這對測試來講是很大的挑戰，以致於有漫畫調侃，高級測試工程師，能夠轉行賣手機了！

不過好在有模擬器，有云測平臺，減小了測試設備兼容性的成本。

模擬器也不是銀彈，不能替代真機，因此App必須在真機上面跑過纔算ok。

真機和模擬器，各有利弊，須要作必要的權衡。

能夠先用模擬器完成大量測試，最後使用真機作驗收。

用真機測試還須要注意的一個小問題就是，測試用例設計的儘可能有效，否則每一次重複測試，就極可能在燃燒你的經費。

測試方法

App測試和Web測試有不少共同的地方，尤爲是業務層和數據層。

不過因爲網絡和設備等因素，讓App測試也有一些特殊的場景，

測試分類	說明
安裝/卸載	確保用戶能夠正確的安裝應用程序 確保用戶能夠徹底卸載應用程序 測試安裝中斷後可否恢復正常 測試卸載可否中斷
網絡基礎設施	證明應用程序在網絡丟失的狀況可以正確響應 證明應用程序可以正確響應網絡回覆的狀況 證明應用程序可以在網絡信號差的狀況下正確響應
來電和短信處理	測試用戶可以在應用程序運行的狀況下接電話以及回短信 測試用戶可以在處理完來電和短信以後可否返回應用程序 測試用戶可否在不中斷應用的狀況下取消來電和短信 測試用戶可否在不退出應用程序的條件下撥打電話和短信
內存不足	確保應用程序在設備內存不足的狀況下仍然可以穩定工做
按鍵	測試全部的熱鍵按照產品規格書實現
退出	檢查程序可以正常退出（經過按鍵合屏或滑塊鎖屏） 確保在機器關閉的狀況下應用程序的行爲和設計規格說明書上一致
充電	確保程序在切換到充電模式時工做正常 確保程序可以在充電狀態下正常工做 確保程序在退出充電模式時不會發生異常
電量	測試在電量不足的狀況下應用程序的行爲表現 計算應用程序將用多長時間耗盡電量 確保在電池忽然拔出的狀況下應用程序的反應和說明書一致
硬件資源	確保應用程序沒有過分佔用CPU 確保應用程序不消耗過多的內存資源
升級	確保靜默升級、提示升級、強制升級狀況下升級成功 確保補丁包、全量包升級成功

電子商務術語

B2B、B2C、C2C、O2O是電子商務的4種模式。

B2B，Business to Business，企業對企業，如經銷商銷貨給超市。

B2C，Business to Customer，企業對我的，如超市賣東西。

C2C，Customer to Customer，我的對我的，如擺地攤。

O2O，Online to Offline，線上到線下，如網上點個豆漿早餐到肯德基取。

B端-->企業端。

C端-->我的端。

G端-->政府端。

參考資料

——《軟件測試的藝術》

專一測試，堅持原創，只作精品。歡迎關注公衆號『東方er』


版權申明：本文爲博主原創文章，轉載請保留原文連接及做者。