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』


版權申明：本文為博主原創文章，轉載請保留原文連結及作者。