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