web測試點集合

轉自：https://blog.csdn.net/yuki_ying/article/details/54946541

web測試點
一 、界面檢查
　　進入一個頁面測試，首先是檢查title，頁面排版，字段等，而不是立刻進入文本框校驗
　　一、頁面名稱title是否正確
　　二、當前位置是否可見  您的位置：xxx>xxxx
　　三、文字格式統一性
　　四、排版是否整齊
　　五、列表項顯示字段是否齊全,列表項字段名稱是否跟表單統一
　　六、同一頁面，是否出現 字段名稱相同、值取不一樣的問題。
　　七、數據加載狀況：除了文本框的值，還要注意：
　　複選框，是否保存打√，或者保存不打√
　　下拉框，是否保存選擇的值
　　多文本框，值是否都被保存，空格，換行是否保存

2、單文本框（type=text）
　　一、邊界：字段長度
　　二、判空：是否能夠爲空
　　三、惟一性：是否惟一        (小歸結：邊界、判空、惟一性、特殊字符、正確性)
　　四、考慮語言，操做環境
　　五、特殊符號測試輸入：' or 1<>'1　、　' or '1'='1　、　' or '1'<>'2　、　"|?><  、where a='xxx'　、下劃線是否容許　、輸入所有空格 、輸入單引號、><script>alert(「123」);</script>>

　　特殊字段輸入限定：
　　框內容是否合法（tel，ip，url，email）序號等，直接限制輸入數字，其餘過濾掉
　　輸入金額文本框，整數首位爲0，過濾掉，小數點後面，通常保留兩個有效數字。
　　

　　正確性測試：（必不可少的步驟）
　　1)、(字段長度輸入最大容許長度時)數據容許長度的測試：
　　　　 a、頁面是否被擠出的測試(都輸入長英文字符串，是否斷行)；
　　 　　b、數據庫是否容許最大字符(都輸入漢字、都輸入英文、混合……)；
　　 　　c、最短長度的正確流程，最大長度的正確流程覆蓋。
　　2）、對於容許爲空的字段，不填入，再次數據傳遞後，看是否報500錯誤。
　　3）、未規定字段長度（或者數值大小），不按死板輸入，輸入很是多字符（或者很是大的數值）時，作容許動做的正確性校驗，看是否報錯。(要達到的結果：無論有沒有長度限制(沒有給最長、最大限　　制讓你去測？)，最終頁面不能拋數據庫異常。)monkeytest
　　說明：經過不斷輸入長字符串，看是否有長度校驗；
　　最終都會出現如下兩種狀況的一種：
　　A、頁面(前臺)有校驗長度、大小；   或者
　　B、無校驗，數據庫報錯。
　　因此： 全部字段都要作長度、大小限制(無論需求有沒有給出明確要求，無論測試顆粒度，都要限制長度，不容許報數據庫錯誤，都要測！！！)。最大長度限制可限定方法：一、不容許再輸入；二、自動　　截斷處理，而且給用戶提示。

　　關於長度概念：
　　　　一、 數據庫規定的字節長度A
　　　　二、 頁面上能夠輸入的字符數B
　　控制方法：
　　　　1）、頁面上，無論輸入什麼字符（全角如漢字、半角如字母），統一規定不能超過B個字符，此種限制，
　　　　測試點：

　　　　　　a、所有輸入全角B個，測試（B*3字節）會不會超過數據庫字節長度
　　　　　　b、所有輸入半角B個，測試（B*1字節）會不會超過數據庫字節長度
　　　　　　c、混合輸入全角X半角Y，測試（X*3+Y字節）會不會超過數據庫長度
　　　　2）、頁面上，不以字符統計，以總的輸入字節數統計，好比，所有輸入全角字符，容許能夠輸入A/3個字符，所有輸入半角字符，容許輸入A個字符（ 民生網的設計）
　　　　測試點：

　　　　　　a、所有輸入全角，看是否容許輸入A/3個字符
　　　　　　b、所有輸入半角，看是否容許輸入A個字符
　　　　　　c、混合輸入全角X，半角Y，看是否容許X*3+Y=A
　　　　(5個：判空、惟1、邊界值、特殊字符、正確流程(多種數據、多種分支))
　　　　+測試校驗位置：ajax鼠標事件校驗、前臺提交按鈕js校驗，服務器拿到數據後再次驗證

3、多文本框（type=textarea）
　　1)、空格和換行的問題，看需求，是否須要作支持HTML Encoding
　　輸入所有空格時，是否判空處理？」」空格，   。
　　輸入折行，是否也顯示折行？
　　好比：列點說明緣由，就須要支持。
　　2)、字母截斷的問題
　　對於一串字母，開發人員每每會忘掉作截斷，這樣若是展現在咱們的平臺上的話，這一串字母就會把咱們的UI撐開
　　3）、長度控制格式， 您還能夠輸入***個字符

4、添加按鈕
　　添加動做檢查範圍：
　　失敗：是否提示
　　提示內容是否正確
　　失敗時：保存用戶已輸入的內容，避免從新再輸入
　　成功：對話框消失
　　記錄是否可直接查看（還須要刷新？）
　　列表記錄順序
　　重複提交狀況，點擊一次後，是否變成disable
　　上傳附件的添加：
　　A. 文件名稱：文件名稱很長；文件名稱字符多樣化(漢字，英文，符號)；文件名稱重複。
　　B. 判空？
　　C. 附件格式類型支持？
　　D. 附件個數？
　　E. 附件空間大小。

5、移除按鈕
　　1.通常都要在前臺先給出一個提示操做「肯定移除該……」
　　2.相關聯的東西，是否須要限制移除「該類型下存在應用，沒法移除」有到後臺比較
　　3.肯定後，真正執行移除操做。
　　結果：
　　移除後，列表數據是否當即消失。
　　必須有確認刪除的提示信息

6、列表
　　1）、列表記錄順序
　　2）、是否須要翻頁、有沒有翻頁功能
　　3）、字段名稱是否與表單一致

7、搜索-文本框
　　一、功能點、需求點考慮：
　　是否提供模糊查詢、輸入數值有種類有限定時，是否考慮換成下拉框搜索；
　　二、檢查點：
　　文本框值是否消失(是否回填條件值)，再次點擊「查詢」可查看全部記錄；
　　考慮搜索結果：是否存在分頁，分頁是否正常；是否有序；
　　注意：分頁是否仍保存查詢條件，檢查後面的記錄是否符合條件
　　三、查詢數據多樣性：
　　輸入不存在的字段值測試、包括特殊字符查詢測試例如：' or '1'='1；
　　輸入相似程序語句的條件時是否執行查詢，如：XXXX」、XXX and ；
　　四、操做類型：
　　　　1) 不輸入的查詢
　　　　2) 輸入所有空格的查詢
　　　　3) 模糊查詢(輸入部分字段，或者說，輸入英文字母，查詢到相關中文數據)
　　　　4) 輸入不存在的查詢
　　　　5) 輸入存在的查詢
　　　　6) 單個查詢和多個條件複合查詢。

8、搜索-下拉框
　　檢查點：
　　　　a) 搜索結果是否有序；
　　　　b) 下拉框值是否齊全；(下拉框值自己也是一個動態查詢的結果)
　　　　c) 下拉框值是否自動消失，再次點擊「查詢」可查看全部記錄(是否要回填條件值)；
　　　　d) 分頁時，是否保存搜索條件。
　　　　（從UI、開發、業務邏輯、用戶使用等角度測試）

　　PS:
　　以上總結的， 是比較純粹的從頁面控件角度測試點出發， 對於完整測試一個總體頁面，須要各種測試有機結合起來：
　　1）UI測試：
　　頁面佈局； 頁面樣式檢查；控件長度是否夠長；顯示時，是否會被截斷；支持的快捷鍵，Tab鍵切換焦點順序正確性等。
　　2）功能測試：頁面上各種控件的測試範圍，測試點，可參考上方
　　結合控件的實際做用來補充檢查點： 好比， 密碼框是否*顯示， 輸入是否作trim處理等
　　3）安全測試：輸入特殊字符，sql注入，腳本注入測試
　　後臺驗證測試，對於較重要的表單 ，繞過js檢驗後臺是否驗證
　　數據傳輸是否加密處理，好比， 直接請求轉發，地址欄直接顯示發送字符串？
　　數據庫存儲，特別密碼等，是否加密形式存儲
　　4）兼容性測試
　　5）性能測試



常見功能點測試思路

根據經驗，總結常見的功能點的測試思路：
　　1. 新增 或 建立（Add or Create）
　　　　.1 操做後的頁面指向
　　　　.2 操做後全部綁定此數據源的控件數據更新，常見的排列順序爲棧Stack類型，後進先出
　　　　.3 取消操做是否成功
　　2.編輯 或 更新 (Edit or Update)
　　　　.1 操做後的頁面指向
　　　　.2 操做後全部綁定此數據源的控件數據更新
　　　　.3 取消操做是否成功
　　　　.4 編輯界面是否讀取出正確、所有的數據源
　　　　.5 記錄在工做流中的編輯功能可用性
　　　　.6 操做成功的生效時刻及生效範圍
　　3.刪除 或 移除 (Delete or Remove)
　　　　.1 操做後的頁面指向
　　　　.2 操做後全部綁定此數據源的控件數據更新 (以下就是刪除後，Tab數據沒有當即刷新的bug)
　　　　.3 取消操做是否成功
　　　　.4 記錄在工做流中的編輯功能可用性
　　　　.5 操做成功的生效時刻及生效範圍（好比：購物網站，店家商品下架後，並無同時刪除買家的購買記錄）
　　4.選中 或 全選 (Check or Check all)
　　　　.1 多頁面中，全選對全部頁面是否有效
　　　　.2 支持多頁面的個別選中，且返回查看時保留選中狀態
　　　　.3 界面上的按鈕的操做範圍是否均受選中功能控制
　　　　.4 前一頁選中狀態，在翻頁後，應保留原來狀態
　　　　.5 先全選-》移除某個單選-》全選按鈕是否移除選中狀態


談談性能測試分類
性能測試是經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，二者能夠結合進行。經過負載測試，肯定在各類工做負載下系統的性能，目標是測試當負載逐漸增長時，系統各項性能指標的變化狀況。壓力測試是經過肯定一個系統的瓶頸或者不能接收的性能點，來得到系統能提供的最大服務級別的測試。
　　驗收性能測試（狹義）：性能測試方法是經過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否知足生產性能要求。通俗地說，這種方法就是要在特定的運行條件下驗證系統的能力狀態。
　　特色：

　　　　一、這種方法的主要目的是驗證系統是否有系統宣稱具備的能力。

　　　　二、這種方法要事先了解被測試系統經典場景，並具備肯定的性能目標。

　　　　三、這種方法要求在已經肯定的環境下運行。 也就是說，這種方法是對系統性能已經有了解的前提，並對需求有明確的目標，並在已經肯定的環境下進行的。
　　

　　負載測試(Load Test)：經過在被測系統上不斷加壓，直到性能指標達到極限（例如「響應時間」）超過預約指標或都某種資源已經達到飽和狀態。
　　特色：

　　　　一、這種性能測試方法的主要目的是找到系統處理能力的極限。

　　　　二、這種性能測試方法須要在給定的測試環境下進行，一般也須要考慮被測試系統的業務壓力量和典型場景、使得測試結果具備業務上的意義。

　　　　三、這種性能測試方法通常用來了解系統的性能容量，或是配合性能調優來使用。 也就是說，這種方法是對一個系統持續不段的加壓，看你在何時已經超出「個人要求」或系統崩潰。


　　壓力測試（強度測試）(Stress Test)壓力測試方法測試系統在必定飽和狀態下，例如cpu、內存在飽和使用狀況下，系統可以處理的會話能力，以及系統是否會出現錯誤
　　特色：

　　　　一、這種性能測試方法的主要目的是檢查系統處於壓力性能下時應用的表現。

　　　　二、這種性能測試通常經過模擬負載等方法，使得系統的資源使用達到較高的水平。

　　　　三、這種性能測試方法通常用於測試系統的穩定性。 也就是說，這種測試是讓系統處在很大強度的壓力之下，看系統是否穩定，哪裏會出問題。

　　併發測試（Concurrency Testing）併發測試方法經過模擬用戶併發訪問，測試多用戶併發訪問同一個應用、同一個模塊或者數據記錄時是否存在死鎖或其者他性能問題。
　　特色：

　　　　一、這種性能測試方法的主要目的是發現系統中可能隱藏的併發訪問時的問題。

　　　　二、這種性能測試方法主要關注系統可能存在的併發問題，例如系統中的內存泄漏、線程鎖和資源爭用方面的問題。

　　　　三、這種性能測試方法能夠在開發的各個階段使用須要相關的測試工具的配合和支持。 也就是說，這種測試關注點是多個用戶同時（併發）對一個模塊或操做進行加壓。

　　配置測試（Configuration Testing）配置測試方法經過對被測系統的軟\硬件環境的調整，瞭解各類不一樣對系統的性能影響的程度，從而找到系統各項資源的最優分配原則。
　　特色：

　　　　一、這種性能測試方法的主要目的是瞭解各類不一樣因素對系統性能影響的程度，從而判斷出最值得進行的調優操做。

　　　　二、這種性能測試方法通常在對系統性能情況有初步瞭解後進行。

　　　　三、這種性能測試方法通常用於性能調優和規劃能力。 也就是說，這種測試關注點是「微調」，經過對軟硬件的不段調整，找出這他們的最佳狀態，使系統達到一個最強的狀態。

　　可靠性測試：經過給系統加載必定業務壓力（例如資源在70%-90%的使用率），使系統運行一段時間，以此檢測系統是否穩定運行。
　　特色：

　　　　一、這種性能測試方法的主要目的是驗證是否支持長期穩定的運行。

　　　　二、這種性能測試方法須要在壓力下持續一段時間的運行。（2~3天）

　　　　三、測試過程當中須要關注系統的運行情況。 若是測試過程當中發現，隨着時間的推移，響應時間有明顯的變化，或是系統資源使用率有明顯波動，均可能是系統不穩定的徵兆。 也就是說，這種測試的關注點是「穩定」，不須要給系統太大的壓力，只要系統可以長期處於一個穩定的狀態。

　　失效恢復測試：若是系統局部發生故障，用戶是否可以繼續使用系統，以及若是這種狀況發生，用戶將受到多大程度的影響。
　　特色：

　　　　1.這種性能測試方法的主要目的是驗證在局部故障狀況下，系統可否繼續使用。

　　　　2.這種性能測試方法還須要指出，當問題發生時，「能支持多少用戶訪問」的結論和「採起何種應急措施」的方案。

　　　　3.通常來講，只有對系統持續運行指標有明確要求的系統才須要進行這種類型的測試。

　　大數據量測試：針對某些系統存儲、傳輸、統計查詢等業務進行大數據量的測試。
　　疲勞強度測試：主要特色是長時間對目標測試系統加壓，目的是測試系統的穩定性，持續時間通常在1小時以上；感受等同於可靠性測試。
　　注意：在作性能測試時請忘掉分類.例如，運行8個小時來測試系統是否可靠，而這個測試極有可能包含了可靠性能測、強度測試、併發測試、負載測試，等等。所以，在實施性能測試時決不能割裂它們的內部聯繫去進行，而應該分析它們之間的關係，以一種高效率的方式來設計性能測試。


Web測試中的幾個case
1、頁面上對引發 大量數據提交的 按鈕/連接 點擊一次後，  disable
　　需求：
　　對於重要的表單、數量龐大/響應慢的系統，在作提交時， 又有頁面還在loading狀態， 此時連續作兩次點擊， 常常引發各類報錯，這種狀況下， 須要提出 對 按鈕/連接 點擊一次後， 作 disable
　　測試：
　　1）查看頁面源代碼是否有腳本控制，例如：
　　　　<a href="javascript: $('#next').val('true'); buttonDisable();headerFormSubmit();" type="submit" class="btn" id="nextButton"> Next </a>
　　　　function buttonDisable(){
　　　　$("#nextButton").attr("disabled", "disabled");
　　　　}
　　2）對腳本進行調試，
　　能夠藉助firebug工具，在Script Tab上，在$("#nextButton").attr("disabled", "disabled");這行腳本設置disable， 點擊nextButton，檢查運行到斷點處中止，按鈕沒法再次點擊。運行斷點後， disable解除。

2、新增數據庫字段測試須要考慮的幾個點
　　1）從數據庫檢查起， 檢查相關表： 原表、歷史表、與其同步庫的表 有沒有都添上該字段，而且注意在每一個表中， 字段類型是否統一
　　2）校驗：考慮字段自己類型，   判空、邊界、惟一性、特殊字符、正確性容許的data
　　特別在作判空時，若字段不容許爲空時，考慮： 須要提交腳本初始化歷史數據set dafault value
　　3）流程覆蓋：考慮該字段覆蓋到哪幾個相關頁面， 測試到整個流程， 每一個頁面校驗要一致；

3、查log測試的幾個操做
　　通常狀況下， 項目都部署在linux環境上， 測試時， 有些須要查log， 或者有些服務須要本身去重啓， 此時就須要一些基本的linux操做命令：
　　1）首先鏈接到linux系統的機器上，可使用putty軟件， 要有 服務器地址+端口+協議  loginName+password，就能夠登陸
　　2）cd到腳本或者log放置的文件夾位置去重啓服務或查看log，還有一些經常使用的命令
　　less 文件名(W向上翻頁、F向下翻頁，Shift+F自動翻頁，Ctrl+C中止自動翻頁)；
　　grep "findString" 文件名；
　　執行腳本：   ../腳本名   或者   sh./腳本名




web常見安全問題以及測試方法
Web安全是咱們測試組一直以來做爲和性能測試並駕齊驅的兩個重點。開發的過程當中還須要着重注意，該轉義的地方轉義；該屏蔽的地方屏蔽，該過濾的地方過濾等等。年末又到了，勢必又有大批的發號抽獎之類的活動開發、上線，在這個過程當中，安全問題是咱們每一個人應該緊繃的神經，對於咱們測試人員來講，每一個活動須要作到手動安全測試加自動化安全測試相結合。
　　常見的web安全問題有：
　　SQL注入、跨站點腳本攻擊、跨站點僞造請求、目錄遍歷、郵件表頭注入、頁面錯誤信息等。
　　對於手動安全測試來講，通常經常使用的有三點：
　　一、URL有參數的，手動修改參數，看是否獲得其餘用戶的信息和相關頁面；
　　二、在登陸輸入框的地方輸入‘ or 1=1--或 「 or 1=1--等看是否有SQL注入；
　　三、在注重SQL注入的同時，通常在有輸入框的地方輸入
　　對於自動化安全測試來講：
　　測試組目前使用的安全測試工具爲IBM的AppScan（固然，是破解版,34上已經放過該工具的安裝包）
　　一、在使用以前務必確認本身綁定的Host；
　　二、配置URL、開發環境、錯誤顯示類型；
　　三、結果保存後可根據提示的問題類型和解決建議進行分析。

　　Web安全測試一般要考慮的測試點：
　　一、輸入的數據沒有進行有效的控制和驗證
　　二、用戶名和密碼
　　三、直接輸入須要權限的網頁地址能夠訪問
　　四、認證和會話數據做爲GET的一部分來發送
　　五、隱藏域與CGI參數
　　六、上傳文件沒有限制
　　七、把數據驗證寄但願於客戶端的驗證
　　八、跨站腳本（XSS）
　　九、注入式漏洞（SQL注入）
　　十、不恰當的異常處理
　　十一、不安全的存儲
　　十二、不安全的配置管理
　　1三、傳輸中的密碼沒有加密
　　1四、弱密碼，默認密碼
　　1五、緩衝區溢出
　　1六、拒絕服務

SQL注入：
　　所謂SQL注入，就是經過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令，好比先前的不少影視網站泄露VIP會員密碼大多就是經過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊．
（select * form 表 where id=1 or 1

1 or 1是輸入框輸入的這樣會致使知足 id=1 或 1 的數據都查出來而全部的數據都知足 1 這樣就查出來了不少不應被查出來的數據這就是sql注入）