一.功能測試
1、關注頁面請求。對於每個頁面，要查看發送的請求是否正確，請求的接口是否有重複，接口請求是否正確返回等。可通過chrome中自帶的開發工具查看網絡請求。
關注是否有冗餘接口請求，是否有不必要的重複接口刷新請求。 冗餘和重複的接口請求會導致流量浪費和響應速度變慢。
2、關注application cache
（http://www.html5rocks.com/zh/tutorials/appcache/beginner/）, local storage（http://www.html5china.com/HTML5features/LocalStorage/20120519_3711.html）, cookie中值是否正確，頁面是否有使用application cache, local storage存放數據。清除這些數據後功能是否正確，獲取數據失敗後是否有重試機制。（可以用下圖Chrome開發工具，進行查看和清除，也可用postman,soupUi等）。 注意：老版chrome開發者模式下在resource下查看cache，新版chrome在application下查看。
3、session失效機制。對於要登錄的，需要用到session的地方，要注意模擬session失效時，功能業務邏輯是否正常。
4、返回邏輯：對於頁面中的返回，以及瀏覽器自帶的返回的測試。 頁面中的返回要考慮業務邏輯，友好返回到相應層次，需要從用戶角度考慮返回的轉跳邏輯，不能出現死循環。並要注意返回後是否需要刷新頁面請求，比如支付完後返回訂單列表，最好刷新
展示上一步購買的訂單。
5、頁面刷新，刷新時的請求鏈接是否正確。
（1）下拉刷新是否仍然處於當前頁面
（2）用戶主動點擊刷新按鈕是否仍然處於當前頁面
（3）刷新頁面或者加載新內容時頁面是否有抖動。
6、圖片適配，是否根據不同屏幕和分辨率做適配，高端機取雙倍尺寸的圖；是否對於2G網絡，或低端機單獨處理，不取高清圖或減少一些特效動畫效果；最好加上webp圖片的支持，可減少流量；在中低端機上考慮是否需要讓前端單獨處理，去掉複雜處理。並
對中低端機只取原圖，不取高清圖。注意：webp格式只對android有效，放在IOS上反而會起反作用。
7、是否要增加轉場動畫，loading動畫，點擊動畫等。以提升體驗。需要在動畫效果和卡頓上衡量。
8、對於隱私模式，不存cookie，不開javascript執行等，測試是否功能正常，或給出提示。
9、接口降級，接口異常時如何處理，前端要給出友好提示。
10、對於請求比較慢時，要有loading圖案，圖案在數據出來後要消失，且不能與轉場動畫等其它有衝突。
11、輸入框的校驗：特殊字符顯示，過濾黑詞，js是否會執行，一連串長字母是否會換行等。 比如只輸入空字符的處理。
12、弱網絡降級：處於2G/3G網絡省流量模式的一些特殊處理，比如2G網絡下測試，圖片多時是否要懶加載等。網絡狀況差的場景，可提示文案，但不能閃退。
13、網絡切換：從wifi切換到2G/3G網絡、從2G/3G網絡切換到wifi等
14、H5與Native切換：切換時登錄信息是否記錄、流程是否順暢、是否出現中斷閃退等問題。 注意驗證 登錄信息是否能互通。 不能出現native已經登錄，進入h5後繼續讓登錄，實在技術實現不了的可toast提示用戶繼續登錄。
（1）若客戶端已登錄，那麼進入H5後仍然是登錄狀態。
（2）若客戶端未登錄，進入H5，點擊對應按鈕OR鏈接，如果需要登錄，須拉起native登錄。若取消登錄，是否可再次拉起登錄，或者停留在的頁面是否有對應的登錄提示。 （注：本次測試過程中就發現，第一次點擊鏈接，可以拉起登錄，第二次卻不能）
15、Pad上測試需要注意：橫屏和豎屏下的顯示效果可能不同，還有橫屏換成豎屏、豎屏換成橫屏。注意橫豎屏切換時輸入框的不同。
16.返回功能
通過H5頁面（非手機自帶返回鍵）的返回功能鍵返回，可以返回到正確的頁面（上一級/退出h5）
點擊返回與back鍵，回退頁面是否是期望頁面
17.屏幕切換
橫屏豎屏相互切換，能適應，佈局不亂，或頁面只支持橫或豎屏限制
18.分辨率適配更好
建議採用響應式設計（如：offerlist頁面大屏顯示3行，小屏顯示2行）
1）分辨率高（如720*1280，重點關注頁面背景是否完全撐開頁面，刷新是否有抖動）、分辨率低（如320*480，重點關注下彈框樣式和文案折行）
2）android4.2版本以上的設備隨便測試一兩臺即可
3）蘋果近幾年常用的系統版本手機
19.頁面打開形式
建議頁面在手機上從list點擊進入detail頁面，要在原窗口打開，通過頁面頁頭返回按鈕返回，不需要通過手機返回鍵返回，交互體驗好
20.頁面請求驗證
關注頁面請求，是否會有多餘的請求，或者請求後有多餘的數據返回，儘量精簡，否則會浪費流量。
21.圖片適配
圖片適配測試，根據不同屏幕和分辨率做適配，以及適配後的清晰度，高端機取雙倍尺寸的圖
22.用瀏覽器chrome f12進行測試
H5的頁面在PC端也是能訪問的，chrome對H5支持最好，功能的測試可以在PC端chrome下先測試，也可以在手機上直接測試，這個看個人習慣。（ie系列**ie8,及以下都支持的不好，這個可以與PD確認H5頁面在這些PC瀏覽器上不支持）
23、滑動、定位
手指滑動是否流暢，手指點擊時焦點是否定位正確，不同機型會不一樣。焦點定位點擊是靈敏。
24、對於類似公司名稱、offer名稱長度的問題，在手機上最好能根據屏幕大小自適應而不是截斷，因爲手機上是不會有tips可以看的。截斷導致大屏幕下也只能顯示幾個字，交互不好
25、手機測試要特別關注交互是否友好，與PC機的事件模型不一樣，可能會導致一些體驗的問題，比如：彈出層的點擊，是否會穿透，影響到彈出層下面的頁面。
26、對於一些浮層做的頁面，例如地圖、產品分類等浮層，注意拖動後是否可以看到它下面的頁面，拖動後邊緣是否有留白
27、手機端的瀏覽器測試的時候也要清除一下緩存，因爲圖片和文件會被緩存下來，所以首次訪問和二次訪問體驗不一樣。例如UC瀏覽器的清楚緩存在設置-》系統設置-》基本設置--》清除記錄中。
28.關注頁面首屏加載時間。
29、文件導入導出：
1、模板下載功能：
一般導出導出功能會有一個模板下載功能，此功能需要檢查模板是否可以正常下載，正常打開，檢查Excel模板文件和網站中的數據字段是否一致即可。
2、文件導入功能
1) 錯誤提示，
如果導入的excel表格中中某一行或者某一字段格式不對或者數據爲空，是否可以正常導入正確部分的數據，對錯誤的數據進行提示。
2）導入其他格式的文件
當導入的文件格式不正確時，系統是否做出正確的判斷，並給出對應的錯誤提示。
3）重複導入相同的文件
重複導入相同的文件是否可以導入成功，如果可以導入成功，數據將如何處理，比如覆蓋或者忽略？
4）不使用下載的模板，自己新建excel導入
自己手動新建excel或者對其他excel進行修改，使excel格式和模板一致，這種情況下數據填寫正確的話，應可以正確的導入系統。
5）表頭檢查：包括去掉、修改、新增列、列之間切換等
3、文件導出功能
1）導出的excel表格的格式檢查，主要檢查導出的excel格式是否符合預期，各字段是否正確。另外導出的excel文件名是否有要求。如果有要求，是否正確。
2）數據檢查，導出全部數據功能是否正確，到處部分數據功能是否正確，選擇數據爲空時是否可以導出。導出的數據內容是否與網頁中的內容一致。
二.適配測試
1）H5機型適配
在項目測試計劃給出時，確認是否要確定測試機基線，即是否要以幾款機型作爲最低適配需求。可參考目前應用市場佔有分佈。
操作系統適配範圍：ios 8-10固件版本的iphone必須覆蓋，ios7可選覆蓋，android 4.4-6.x必須覆蓋，4.0-4.3可選覆蓋，4.0以下可以不care。像小米，魅族這種自定義os版本的機子，其實底層也對應着標準的谷歌os系統版本。
對於ios, android大版本一定要覆蓋，對於系統版本，先看大版本佔用情況，再選擇大版本中佔用率較高的小版本。如4.3, 5.0大版本中選幾個佔用率較高的小版本測試。常用的有：ios：8.x.x, 9.3.5；android: 4.3.1, 4.4.2 等。
機型品牌適配範圍：參考集團內後端統計的top機型。對於ios，要覆蓋iphone 6/6s/6p, iphone 7,iphone5等。
對於android,如三星、小米、華爲，htc, lenovo，中興，魅族，阿里雲等。屌絲機型 華爲，中興，vivo，oppo,魅族佔有率很高，所以這幾個屌絲機型一定要覆蓋到。三星上的H5問題防不勝防，相當極品。小米近一兩年的機型適配問題不想2s那麼多了。
三星常見的H5適配問題：css加載不出來，控件操作無響應。小米常見的H5適配問題是UI，比如button會把這個按鈕四個角冗餘顯示，tab切換異常。 實時滾動信息時卡死等。
對於有些手機廠商有自已定製操作系統，要單獨適配，如小米，魅族。注意三星的假系統版本。
在選擇機子時，要兼顧屏幕尺寸和分辨率。覆蓋到主流的屏幕尺寸和分辨率，並組合一下，現在主流是1920大屏，但一定要找幾款小屏手機覆蓋。注意三星的
適配時不能光選性能好的機子，一定要適配幾款中低端機。華爲和中興的國產機，可選擇適配一下。
2）手機瀏覽器適配
需要覆蓋：自帶瀏覽器（默認的瀏覽器內核）爲主，有足夠時間時再覆蓋chrome,UC瀏覽器（最新版）和QQ瀏覽器（最新版）。
3）容易出現適配問題的機型：
三星i9100G，對於按鈕樣式，輸入框的區域要重點關注。
android 5.X 谷歌原生的nenux系列。
大屏高分辨率手機要適配一款，如三星galaxy note4
對於支持webp的機子要測試。如三星galaxy note2,或三星s3
4）工具
1.市面上各種雲測平臺，一般都可以單獨測試H5適配。
2.可藉助瀏覽器的開發者模式。
三.性能測試
1) 需要關注的性能指標：
頁面加載時間/頁面大小/頁面請求數/ DomReady時間/圖片等資源文件大小/請求錯誤數
2) 各種雲測平臺
3) 其他性能測試工具：dyna trace，yslow，page speed，firebug等等
4）免費公共測試web：
http://www.webpagetest.org/ 免費測試。
2）翻頁測試：
當遇到翻頁加載的頁面，需要注意內容爲1頁或者多頁的情況。
（1）數據分頁加載時，注意後續頁面請求數據的正確。
注：這個需要注意在快速操作場景中，請求頁數是不是依次遞增，快速操作（如第一頁尚未loading出來的時候仍然繼續上拉操作）時是否發出去對應的請求了。
四.安全測試
1）明確投放渠道都有哪些 ：
如獨客、主客、wap，是否對未投放渠道做了限制，直接通過url請求是否攔截等
2）評估是否需要接入集團安全，如mtee黑白名單等
3）是否需要接入支付寶實名認證：
涉及到金錢相關，如天貓積分，紅包等，爲了防刷，一般都需要判斷是否支付寶實名認證
4）是否接入windvane，所有請求通過native發出
1)、從代碼層級分析html5新特性帶來的安全漏洞。常見的：
通過formaction屬性進行XSS
通過autofocus屬性執行本身的focus事件
多個autofocus競爭焦點來觸發blur事件
通過的poster屬性執行Javascript
通過autofocus觸發的onscroll執行Javascript
具體原理和其他漏洞可見http://html5sec.org/#html5
2)、從手機用戶角度列舉手機網頁存在的一些安全問題（非測試角度）,大致有以下：
惡意url。包括html鏈接、短鏈接、短信中的url、掃二維碼產生的url
通過XSS竊取數據庫內容。各種XSS可參見http://html5sec.org/#html5
自BeEF的攻擊（BeEF有點類似fiddler，具體可見
https://github.com/beefproject/beef）。包括cookie竊取、披露設備地理位置、打騷擾電話、不需要的下載
訪問不安全的web服務。
竊聽移動網站流量。
五. H5上線後迴歸
H5涉及到的各種資源文件，在測試環境（包括預發環境），一般都是內域，正式上線，RD童鞋有把資源文件（或者說url中的鏈接忘了修改）漏發的風險，所以上線後一定要用外網環境再快速回歸下。最簡單的就是用自己的4G網絡迴歸跟蹤線上。
六.H5測試與PC端測試不同的點
1、通過H5網頁（非手機的返回功能）的返回功能可以返回，不會出現無法返回的情況。
2、橫屏豎屏相互切換，能自適應，並且佈局不會亂掉；
3、爲能在不同分辨率的手機上能更好的展示，建議採用響應式設計（如：offerlist頁面在大屏時顯示3行，小屏時顯示2行）
4、在手機上從list點擊進入detail頁面，要在原窗口打開，這樣可以通過頁頭的返回按鈕返回，而不需要通過手機的返回鍵返回，這樣交互上更友好。
5、關注頁面請求，是否會有多餘的請求，或者請求後有多餘的數據返回，儘量精簡，否則會浪費流量。
6、圖片適配測試，根據不同屏幕和分辨率做適配，以及適配後的清晰度，高端機取雙倍尺寸的圖
7、H5的頁面在PC端也是能訪問的，chrome對H5支持最好，功能的測試可以在PC端chrome下先測試，也可以在手機上直接測試，這個看個人習慣。（ie系列包括ie8,及以下都支持的不好）
8、手指滑動是否流暢，手指點擊時焦點是否定位正確，不同機型會不一樣。焦點點擊是否靈敏。
9、對於類似公司名稱、offer名稱長度的問題，在手機上最好能根據屏幕大小自適應而不是截斷，因爲手機上是不會有tips可以看的。截斷導致大屏幕下也只能顯示幾個字，交互不好
10、手機測試要特別關注交互是否友好，與PC機的事件模型不一樣，可能會導致一些體驗的問題，比如：彈出層的點擊，是否會穿透，影響到彈出層下面的頁面。
11、對於一些浮層做的頁面，例如地圖、產品分類等浮層，注意拖動後是否可以看到它下面的頁面，拖動後邊緣是否有留白
12、手機端的瀏覽器測試的時候也要清除一下緩存，因爲圖片和文件會被緩存下來，所以首次訪問和二次訪問體驗不一樣。例如UC瀏覽器的清楚緩存在設置-》系統設置-》基本設置–》清除記錄中。
七、H5各種測試總結：
（1）需求設計測試：
儘早的瞭解需求熟悉需求、參與需求評審與設計，通過原型圖以及真實用戶體驗和用戶習慣來檢查需求的合理性以及是否有更好地實現方法等。
這樣能把問題發現在源頭，減少後期因需求變更引起開發和測試的迭代成本。
在需求階段即介入測試功能點的編寫和記錄，也符合儘早介入測試的原則。
（2）接口測試
根據開發同學提供的接口文檔，可以通過Jmeter 等工具進行測試。
主要關注點爲：
接口返回的數據期望的是否一致；
接口入參的邊界值校驗 ；
檢查接口的容錯性 比如對於傳輸數據類型錯誤能否處理等，整型的輸入小數、中英文等；
接口的性能情況，調用接口數據返回的時間，接口反應慢肯定影響用戶體驗。
接口的安全性：接口部分敏感信息是否加密傳輸等
mtop接口返回處理：
發現這個出現問題的地方有很多，但是只要有意識的去處理，就很容易避免，主要是有以下幾種情況：
（1）請求成功，且返回有數據，測試mtop接口返回數據的各種場景。
（2）請求成功，但data內容爲空。
（3）請求接口異常，出現ERR_SID_INVALID::SESSION過期，拉起登錄。
（4）請求接口發生除C中提到的異常之外的異常，通常可歸結爲一類進行處理。
（3）功能測試
測試重點，根據業務邏輯和功能進行測試，主要是可用性。
（4）用戶界面測試
根據測試和評審修改過的UED（用戶體驗設計），測試開發遞交的測試包。
風格、樣式、顏色是否協調，不僅包括HTML5本身，因爲HTML5會嵌入App裏面，所以要考慮 H5 的風格、樣式、顏色是否與app本身協同，不至於格格不入，包括用戶習慣等也最好保持一致或相近，最好在設計初期就有顏色、按鈕、圖片、背景、邊框等詳細規劃和統一。
但是正是由於H5的可移植性，同一服務會嵌入到N家客戶的產品中，難以與各家都完全統一，所以在設計中就應該考慮這些問題。
（5） 兼容性測試
手機HTML5主要應用是嵌入在app或者微信公衆號裏面，所以兼容性主要是iOS、Android 2個系統各種主流機型的適配。
A、手機屏幕大小
B、主流手機機型
C、手機操作系統，iOS和Android各版本
D、瀏覽器：系統自帶瀏覽器和主流瀏覽器
（6）網絡測試
由於H5系統很多是雲服務，所有響應速度普遍較慢。我們測試的時候一般會用Wifi，速度會相對可觀點。
我們應該觀察在4G、3G、甚至2G的網下，弱網測試，看響應時間是否在忍受範圍內。
時間過長的話，需要提示優化代碼做改善。
（7） 安全測試
由於我們對應的產品部利用HTML5把一些通用功能做成了雲服務，可以嵌入多家客戶的App，根據渠道劃分，所以安全性顯得尤爲重要。
（8） 性能測試
隨着對接客戶的增加，對服務的性能方面的要求也會增加。對於雲服務的模塊需要做性能測試。