一、關注頁面請求。對於每一個頁面,要查看發送的請求是否正確,請求的接口是否有重複,接口請求是否正確返回等。可經過chrome中自帶的開發工具查看網絡請求。
關注是否有冗餘接口請求,是否有沒必要要的重複接口刷新請求。 冗餘和重複的接口請求會致使流量浪費和響應速度變慢。 javascript
二、關注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下查看。 css
三、session失效機制。對於要登陸的,須要用到session的地方,要注意模擬session失效時,功能業務邏輯是否正常。html
四、返回邏輯:對於頁面中的返回,以及瀏覽器自帶的返回的測試。 頁面中的返回要考慮業務邏輯,友好返回到相應層次,須要從用戶角度考慮返回的轉跳邏輯,不能出現死循環。並要注意返回後是否須要刷新頁面請求,好比支付完後返回訂單列表,最好刷新
展現上一步購買的訂單。 前端
五、頁面刷新,刷新時的請求連接是否正確。 html5
(1)下拉刷新是否仍然處於當前頁面 java
(2)用戶主動點擊刷新按鈕是否仍然處於當前頁面 android
(3)刷新頁面或者加載新內容時頁面是否有抖動。 ios
六、圖片適配,是否根據不一樣屏幕和分辨率作適配,高端機取雙倍尺寸的圖;是否對於2G網絡,或低端機單獨處理,不取高清圖或減小一些特效動畫效果;最好加上webp圖片的支持,可減小流量;在中低端機上考慮是否須要讓前端單獨處理,去掉複雜處理。並
對中低端機只取原圖,不取高清圖。注意:webp格式只對android有效,放在IOS上反而會起副作用。 git
七、是否要增長轉場動畫,loading動畫,點擊動畫等。以提高體驗。須要在動畫效果和卡頓上衡量。 github
八、對於隱私模式,不存cookie,不開javascript執行等,測試是否功能正常,或給出提示。
九、接口降級,接口異常時如何處理,前端要給出友好提示。
十、對於請求比較慢時,要有loading圖案,圖案在數據出來後要消失,且不能與轉場動畫等其它有衝突。
十一、輸入框的校驗:特殊字符顯示,過濾黑詞,js是否會執行,一連串長字母是否會換行等。 好比只輸入空字符的處理。
十二、弱網絡降級:處於2G/3G網絡省流量模式的一些特殊處理,好比2G網絡下測試,圖片多時是否要懶加載等。網絡情況差的場景,可提示文案,但不能閃退。
1三、網絡切換:從wifi切換到2G/3G網絡、從2G/3G網絡切換到wifi等
1四、H5與Native切換:切換時登陸信息是否記錄、流程是否順暢、是否出現中斷閃退等問題。 注意驗證 登陸信息是否能互通。 不能出現native已經登陸,進入h5後繼續讓登陸,實在技術實現不了的可toast提示用戶繼續登陸。
(1)若客戶端已登陸,那麼進入H5後仍然是登陸狀態。
(2)若客戶端未登陸,進入H5,點擊對應按鈕OR連接,若是須要登陸,須拉起native登陸。若取消登陸,是否可再次拉起登陸,或者停留在的頁面是否有對應的登陸提示。 (注:本次測試過程當中就發現,第一次點擊連接,能夠拉起登陸,第二次卻不能)
1五、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瀏覽器上不支持)
2三、滑動、定位
手指滑動是否流暢,手指點擊時焦點是否認位正確,不一樣機型會不同。焦點定位點擊是靈敏。
2四、對於相似公司名稱、offer名稱長度的問題,在手機上最好能根據屏幕大小自適應而不是截斷,由於手機上是不會有tips能夠看的。截斷致使大屏幕下也只能顯示幾個字,交互很差
2五、手機測試要特別關注交互是否友好,與PC機的事件模型不同,可能會致使一些體驗的問題,好比:彈出層的點擊,是否會穿透,影響到彈出層下面的頁面。
2六、對於一些浮層作的頁面,例如地圖、產品分類等浮層,注意拖動後是否能夠看到它下面的頁面,拖動後邊緣是否有留白
2七、手機端的瀏覽器測試的時候也要清除一下緩存,由於圖片和文件會被緩存下來,因此首次訪問和二次訪問體驗不同。例如UC瀏覽器的清楚緩存在設置-》系統設置-》基本設置--》清除記錄中。
28.關注頁面首屏加載時間。
2九、文件導入導出:
一、模板下載功能:
通常導出導出功能會有一個模板下載功能,此功能須要檢查模板是否能夠正常下載,正常打開,檢查Excel模板文件和網站中的數據字段是否一致便可。
二、文件導入功能
1) 錯誤提示,
若是導入的excel表格中中某一行或者某一字段格式不對或者數據爲空,是否能夠正常導入正確部分的數據,對錯誤的數據進行提示。
2)導入其餘格式的文件
當導入的文件格式不正確時,系統是否作出正確的判斷,並給出對應的錯誤提示。
3)重複導入相同的文件
重複導入相同的文件是否能夠導入成功,若是能夠導入成功,數據將如何處理,好比覆蓋或者忽略?
4)不使用下載的模板,本身新建excel導入
本身手動新建excel或者對其餘excel進行修改,使excel格式和模板一致,這種狀況下數據填寫正確的話,應能夠正確的導入系統。
5)表頭檢查:包括去掉、修改、新增列、列之間切換等
三、文件導出功能
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涉及到的各類資源文件,在測試環境(包括預發環境),通常都是內域,正式上線,RD童鞋有把資源文件(或者說url中的連接忘了修改)漏發的風險,因此上線後必定要用外網環境再快速回歸下。最簡單的就是用本身的4G網絡迴歸跟蹤線上。
一、經過H5網頁(非手機的返回功能)的返回功能能夠返回,不會出現沒法返回的狀況。
二、橫屏豎屏相互切換,能自適應,而且佈局不會亂掉;
三、爲能在不一樣分辨率的手機上能更好的展現,建議採用響應式設計(如:offerlist頁面在大屏時顯示3行,小屏時顯示2行)
四、在手機上從list點擊進入detail頁面,要在原窗口打開,這樣能夠經過頁頭的返回按鈕返回,而不須要經過手機的返回鍵返回,這樣交互上更友好。
五、關注頁面請求,是否會有多餘的請求,或者請求後有多餘的數據返回,儘可能精簡,不然會浪費流量。
六、圖片適配測試,根據不一樣屏幕和分辨率作適配,以及適配後的清晰度,高端機取雙倍尺寸的圖
七、H5的頁面在PC端也是能訪問的,chrome對H5支持最好,功能的測試能夠在PC端chrome下先測試,也能夠在手機上直接測試,這個看我的習慣。(ie系列包括ie8,及如下都支持的很差)
八、手指滑動是否流暢,手指點擊時焦點是否認位正確,不一樣機型會不同。焦點點擊是否靈敏。
九、對於相似公司名稱、offer名稱長度的問題,在手機上最好能根據屏幕大小自適應而不是截斷,由於手機上是不會有tips能夠看的。截斷致使大屏幕下也只能顯示幾個字,交互很差
十、手機測試要特別關注交互是否友好,與PC機的事件模型不同,可能會致使一些體驗的問題,好比:彈出層的點擊,是否會穿透,影響到彈出層下面的頁面。
十一、對於一些浮層作的頁面,例如地圖、產品分類等浮層,注意拖動後是否能夠看到它下面的頁面,拖動後邊緣是否有留白
十二、手機端的瀏覽器測試的時候也要清除一下緩存,由於圖片和文件會被緩存下來,因此首次訪問和二次訪問體驗不同。例如UC瀏覽器的清楚緩存在設置-》系統設置-》基本設置–》清除記錄中。
(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) 性能測試
隨着對接客戶的增長,對服務的性能方面的要求也會增長。對於雲服務的模塊須要作性能測試。