# 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』
版權申明：本文為博主原創文章，轉載請保留原文連結及