關閉

                  軟件測試之全網最全Web端測試點

                  發表于:2023-3-17 09:14

                  字體: | 上一篇 | 下一篇 | 我要投稿

                   作者:極客先生    來源:知乎

                    這是一篇記錄Web測試點文章,隨著技術的不斷發展,后續碰到未收錄的Web測試點也會收錄到此篇文章中,盡量做到匯總全面,最重要的是持續更新中。本篇文章適用于中后臺管理系統的測試。
                    按照測試優先級,Web測試范圍可以分為下列幾類:
                    功能測試
                    這類測試范圍中包含子分類,如:業務流程、頁面組件、異常場景、瀏覽器相關等。在所有測試范圍中優先級最高,因為首要保證交付出去的產品用戶可以正常使用,故功能測試排第1名。以下將按照子分類逐一介紹。
                    業務流程
                    這類測試范圍是所有測試范圍中最基礎、最核心的,依據產品設計等相關資料,須考慮到正常流程、分支流程和異常流程,在設計測試用例時需覆蓋所有流程。另外這些用例也可以用于已有產品的回歸測試,所以它是重中之重!下圖是知乎桌面端的登錄頁面,從中可以看出有6種登錄方式,篇幅有限我挑選驗證碼登錄方式為例,畫一張流程圖就可以清晰表達業務流程的測試點!
                    知乎桌面版驗證碼登錄流程圖:
                    里面并沒有關于不符合手機號規范的測試點以及不符合驗證碼規范的測試點,因為這些不屬于業務流程范圍內的測試點,故不在此范圍內詳細說明,它應當屬于頁面組件測試,請繼續往下看!
                    頁面組件
                    首先需要明白什么是組件?簡單的可以認為一個按鈕、一個鏈接、一個輸入框等等,這些被成為基礎組件,那么對應還有復雜組件,如:日期選擇器、地區選擇器、文件上傳、視頻播放、圖片預覽等組件。拿知乎桌面版登錄頁面來舉例,這就是一個復雜且通用的組件。
                    為什么要把頁面組件拆分出來測試?記得10年前搞測試工作的時候這部分并沒有明確劃分為一個范圍的概念,基本在測試用例的分類里都劃分到業務流程類別里。隨著技術的發展,很多互聯網大廠在增效減能的過程中,頁面中某些通用的組件會被高度封裝,每一個組件可能都會有專人維護,其他研發人員調用即可,隨著這種生產方式流行,慢慢就形成企業自有的一套前端UI組件規范。整個平臺中調用這個組件的地方很多,從代碼的角度不管從哪里調用,都是調用同一段代碼,所以對于測試我們只需對其做專項測試,在后面的迭代中如果沒有改動則可以不測,這樣會增加測試效率減少重復性工作。
                    手機號可以采用等價類邊界值的方法來驗證,這里注意不同國家的手機號對應手機號規范也是不一樣的,具體的規范可以詳細在網上查查。同理,驗證碼同樣也是采用等價類邊界值的方法來驗證。
                    在制定測試計劃的時候需要與產品、設計、開發溝通,確定網站都有哪些組件,這樣做的目的是在保證測試覆蓋度的同時降低冗余的測試工作量。比如:網站中有多個頁面使用了自定義的文件上傳組件,那么我們只需單獨測試一個頁面的文件上傳,其余頁面則不用測試,而關于其他頁面組件與當前頁面的存在的一些交互則放在如業務流程等等相關測試范圍內。
                    異常場景測試
                    這個異常場景該怎么理解?主要是針對業務操作異常、網絡異常的情況下程序是否能夠做出正確處理,下面詳細說明一下:
                    1、系統不允許多端登錄、密碼錯誤多次錯誤會觸發安全策略、短時間內多次登錄會觸發安全策略、極快的時間點擊一個按鈕是否會觸發多次重復請求等等,這些都屬于業務操作異常場景;
                    2、斷網的情況下程序是否有給用戶友好提示、弱網的情況下程序是否有超時機制,斷網和弱網對于編程會分開判斷,這些都屬于網絡異常場景;
                    瀏覽器相關
                    這部分測試點主要是驗證網站在能否于瀏覽器正常的協同工作,比如點擊前進、后退、強制刷新等按鈕,或者清除緩存、Cookie等操作,網站的表現能否滿足預期?
                    舉一個我曾經遇到過的問題,在網頁上正常操作跳轉是正常的,但是一操作前進、后退、強制刷新就報404,最后經查是Nginx配置問題。
                    界面測試
                    在此我需要強調一下界面測試為什么會排名第2,人靠衣裝馬靠鞍裝,界面的美觀與整齊性對于用戶很重要,我們假設一下你看到一個網頁各個元素都不齊,你內心的感受是什么?這個網頁做的很Low,視覺上感覺很亂,任何一個人都是顏值控!所以界面測試主要從美觀、視覺體驗、易用性上來測試,如下:
                    1、檢查整體視覺是否跟視覺規范或者UI設計高保真效果圖一致,并且通過更改窗口大小檢查頁面元素是否按規范布局排列;
                    2、常規該有的交互必須要有,比如請求過程中的進度動效或者例如下載必須要有進度條展示進度;
                    3、從用戶體驗角度給出測試的建議,比如按鈕觸摸焦點區太小不容易完成點擊動作等等;
                    接口測試
                    接口測試就是服務端,其目的主要是2個,如下:
                    1、整套系統提測前,讓測試人員盡早介入項目流程,提前發現Bug,減少提測后的Bug數;
                    2、對前端功能測試覆蓋率不足的補充,畢竟只在頁面上點點有些功能是測不到的;
                    測試點如下:
                    1、單接口測試 正常場景:對軟件來說是合理的 異常場景 1)數據異常:參數類型和長度,不滿足業務需求 2)參數異常:多參、少參、無參、錯誤參數 3)業務異常:各種異常狀態碼的測試 2、多接口測試 將多個接口按照業務流程進行組合測試,就比如知乎驗證碼登錄,先測試獲取驗證碼再測試登錄/注冊接口,其實就是業務流程測試
                    兼容性測試
                    軟件在特定的軟硬件環境中運行時的測試過程稱之為兼容性測試。Web端的兼容性測試主要包括:操作系統、瀏覽器、分辨率、網速、數據兼容這幾個分類。
                    操作系統
                    在Web測試的經歷中,我沒有遇到過需要測試跟操作系統的兼容性,但是見過網上有不少小伙伴記錄這一點,所以也將其記錄下來,這里的兼容測試主要是針對Web端調用系統的某些功能函數時是否能正常調用,并且因操作系統不一樣或者同一操作系統的版本不一樣這些功能函數的調用方式也會不一樣,不過我總覺的這一測試點有寫別扭的地方,就是Web端的JS應該是調用瀏覽器的Api,然后由瀏覽器完成與系統層面的交互,不應該是JS直接與系統層交互,這點我是存疑的,但是看到很多測試同學關于這點的記錄,所以先記錄下來,如果某位大佬能給出一個場景案例,為我解惑,不勝感激。
                    下面記錄了需主要覆蓋的操作系統:
                    1、windows:win7、win8、win10、win11(重點是Windows系列,畢竟這套系統使用率是最高的)
                    2、macOS
                    3、Linux
                    瀏覽器
                    目前國內主流瀏覽器包括:IE瀏覽器、Chrome、Firefox、Safari、360安全瀏覽器、360極速瀏覽器、搜狗瀏覽器、QQ瀏覽器、百度瀏覽器、獵豹瀏覽器,如果測試人力有限主要覆蓋微軟系列和谷歌系列的瀏覽器即可,因為這兩個廠家的瀏覽器使用率最多!作為測試工程師對于瀏覽器的兼容性測試要注意以下幾點:
                    1、盡量跟進主流廠家的瀏覽器迭代更新內容,沒發布一個版本可以通過官網訂閱消息獲得內容,了解更新點,判斷對現有軟件是否有影響,下載最新版本的瀏覽器進行驗證,做到提前發現;
                    2、在測試過程中養成合理提高測試效率的工作方式,比如:不同的模塊在不同廠家的瀏覽器中做業務功能測試,這樣盡量最大覆蓋瀏覽器的兼容測試。因為假設業務功能測試用例1000條,逐個在N多種瀏覽器里做測試是一件很費勁而且公司也不會給予這么多時間去做一個優先級比較低的事情;
                    3、舉一反三,多思考,如果你發現有一個兼容性的問題,要思考一下這個功能在其他頁面有沒有,是不是也存在這個問題,盡量做到不遺漏;
                    4、多跟開發溝通,這點跟第3點有共同之處;
                    分辨率
                    使用不同的分辨率設備檢查頁面顯示的效果,這里的分辨率測試跟調整瀏覽器窗口大小無關,具體原因可以查閱分辨率的相關資料了解。
                    網速
                    現如今隨著科技的發展,很多PC機都不使用網線改用Wifi,所以網絡的不確定性也隨之增加,可以使用Fiddler、Charles等軟件做限速或者斷網測試。
                    舉一個例子,如果前端設置的超時時間或者Api設置的超時時間為5s,但是由于網速慢的原因造成頁面提示當前網絡環境不好,請稍候再試這樣的提示,那么超時間就顯得過短,可以提出建議進行修改。
                    數據兼容
                    由于某些原因數據庫做了調整,那么調整之后是否會影響到已存在的數據,這些需要做數據兼容測試。
                    版本升級
                    假設公司決定對站定進行熱升級,那么用戶當前是阻斷暫停使用還是可以繼續使用,這些要依據公司版本升級策略進行測試。
                    性能測試
                    響應測試
                    用戶打開一個頁面或者執行了操作請求了一個接口,從動作開始到服務器響應回瀏覽器的時間我們稱之為響應時間,業內有個2/5/8原則,2代表2s內響應完成用戶能接受、5代表5s內響應完成用戶勉強接受,8超過5s或者超過8s響應完成用戶很難接受。
                    所以響應測試指的是測試一個請求開始到響應結束的時間,應當注意那些數據量較大的頁面或者接口有些測試,同時也要注意高頻使用頁面和接口,重點對這兩類做測試,再測試資源充裕的情況下,當然是進行全量頁面和接口測試。
                    負載測試
                    服務器達到同一時刻一定數量級用戶訪問時的處理請求能力的測試稱為負載測試,我們假設一臺服務器可以同時處理1000個用戶訪問,我們模擬1000個用戶訪問,檢查服務器能否正常處理業務請求,比如網頁能否正常打開,接口能否正常響應,如果一切整成即測試通過,反之就需要交給開發進行優化。
                    實際中的負載情況需要考慮很多因素,比如我們需要固定設備硬件運算能力、還有固定網速、也分復雜查詢和簡單查詢,這個負載能力既要參考業內標準也需要測試和開發共同討論確定一個合理的預期負載情況。
                    壓力測試
                    壓力測試是指驗證當服務器遭遇過量用戶訪問時自我處理故障且恢復的能力或者限制此種場景的能力,防止遭受正規和非正規訪問時導致服務器癱瘓,例如DOS攻擊,黑客操縱成千上萬的木馬機進行大規模訪問,導致站點無法正常打開,后臺服務器癱瘓,或者利用工具模擬大批量用戶同一時刻訪問,服務器是否具有甄別和限制訪問的策略等等。
                    安全測試
                    1、敏感數據
                    類似于手機號、身份證號等私密信息是否加敏顯示,接口中是否加密等等
                    2、SQL注入
                    SQL注入攻擊的基本原理是通過構建特殊的輸入參數,迫使后臺數據庫執行額外的SQL語句,從而達到獲取數據庫數據的目的。
                    3、橫向越權
                    不同用戶之間session共享,可以非法操作對方的數據
                    4、縱向越權
                    很多應用簡單的通過前端判斷,或者低權限角色看不到對應的菜單,但并未在后臺去做當前登錄用戶是否有權限
                    5、XSS測試
                    跨站腳本攻擊(Cross Site Scripting):惡意攻擊者往Web頁面里插入惡意Script代碼,當用戶瀏覽該頁之時,嵌入其中Web里面的Script代碼會被執行,從而達到惡意攻擊用戶的目的
                    這種場景比較常見,比如服務端惡意植入js腳本、公用wifi攔截植入惡意腳本等
                    6、CSRF
                    CSRF(Cross-site requestforgery),中文名稱:跨站請求偽造。用戶C在為退出A的情況下,瀏覽B,B使用C的session非法訪問A。
                    7、目錄遍歷
                    在web應用中,如下圖所示的顯示目錄文件列表,會帶來一定的安全隱患(服務器文件列表)
                    8、CRLF
                    CRLF就是HTTP響應頭拆分漏洞。是對用戶輸入的CR 和LF字符沒有進行嚴格的過濾導致的。
                    本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系51Testing小編(021-64471599-8017),我們將立即處理
                  《2023軟件測試行業現狀調查報告》獨家發布~

                  關注51Testing

                  聯系我們

                  快捷面板 站點地圖 聯系我們 廣告服務 關于我們 站長統計 發展歷程

                  法律顧問:上海蘭迪律師事務所 項棋律師
                  版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2024
                  投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

                  滬ICP備05003035號

                  滬公網安備 31010102002173號

                  亚洲欧洲自拍图片专区123_久久久精品人妻无码专区不卡_青青精品视频国产色天使_A免看的日黄亚洲