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』
版權申明：本文為部落客原創文章，轉載請保留原文鏈接及作者。
