[本文出自天外歸雲的博客園]後端
客戶端測試用例UI界面覆蓋用例設計法,主要針對界面的UI處(User Interface),凡是UI,就意味着有網絡請求,和後臺數據打交道瀏覽器
UI的數據,分爲客戶端上報的數據和後端下發的數據。測試針對上報和下發的數據進行:微信
1)修改上報數據是爲了測試不一樣狀況下接入層下發是否正確,這部分邏輯能夠獨立於客戶端進行,屬於後臺接口測試範疇(後臺)網絡
2)修改下發數據是爲了測試不一樣的接入層下發的狀況下客戶端邏輯是否顯示正確,屬於客戶端接口容錯測試範疇(客戶端)app
對於下發的數據分爲有下發和無下發兩種,有下發的狀況下咱們再根據具體不一樣的需求進行改回包測試測試
狀態分析法:設計
1)無網絡進入,有網絡重試 / 有網絡進入,無網絡返回 兩態UI邏輯覆蓋視頻
2)已登陸 / 未登陸 兩態UI邏輯覆蓋接口
3)夜間模式 / 日間模式 兩種界面模式覆蓋博客
4)一級頁到二級頁 / 二級頁到一級頁 雙向UI邏輯覆蓋
5)自動刷新 / 手動刷新 兩種邏輯覆蓋
6)由端外進入端內(喚起)/ 由端內去往端外並返回(分享、下載) 雙向覆蓋
入口分析法:
1)點擊push消息訪問頁面,檢查頁面功能
2)從微信分享調起客戶端(冷啓動/熱啓動)進入訪問頁面,檢查頁面功能
邏輯分析法:
1)涉及網絡請求邏輯:UI處抓包,查看網絡請求是否正常,是否有重複發送的問題
2)涉及本地存儲邏輯:涉及利用設備本地存儲技術來記錄與用戶相關狀態的需求,同一用戶登陸多臺設備,檢查狀態是否有容錯邏輯。好比用戶「推」動態這一功能,已推狀態是根據存儲在設備本地的數據進行判斷的。在用戶,推,動態這三者之間的存在了一個隱形的紐帶——設備,因此能夠針對性設計測試用例:用戶A在設備X推進態M,用戶A在設備Y檢查動態M的推狀態,檢查是否能夠在設備Y推進態M
3)涉及多個入口邏輯:若是一個頁面能夠經過多個入口訪問到,只經過其中一個入口訪問該頁面沒問題並不能證實從其餘入口訪問該頁面也沒有問題。因此涉及頁面有多個入口的,從每一個入口都要訪問並校驗頁面顯示邏輯是否正確
場景設計法:
1)不一樣操做順序進行排列,好比:
一、看騰訊視頻的時候橫屏切豎屏後切後臺,打開瀏覽器app進行搜索,以後再返回客戶端切橫屏
二、在看視頻的時候關閉WiFi再打開WiFi,不斷的切換網絡信號源