Web測試中，各類web控制元件測試點總結

一 、介面檢查

　　進入一個頁面測試，首先是檢查title，頁面排版，欄位等，而不是馬上進入文字框校驗

　　1、頁面名稱title是否正確

　　2、當前位置是否可見  您的位置：xxx>xxxx

　　3、文字格式統一性

　　4、排版是否整齊

　　5、列表項顯示欄位是否齊全,列表項欄位名稱是否跟表單統一

　　6、同一頁面，是否出現 欄位名稱相同、值取不同的問題。

　　7、資料載入情況：除了文字框的值，還要注意：

　　複選框，是否儲存打√，或者儲存不打√

　　下拉框，是否儲存選擇的值

　　多文字框，值是否都被儲存，空格，換行是否儲存

二、單文字框（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、無校驗，資料庫報錯。

　　所以： 所有欄位都要做長度、大小限制(不管需求有沒有給出明確要求，不管測試顆粒度，都要限制長度，不允許報資料庫錯誤，都要測！！！)。最大長度限制可限定方法：1、不允許再輸入；2、自動截斷處理，並且給使用者提示。

關於長度概念：

　　1、 資料庫規定的位元組長度A

　　2、 頁面上可以輸入的字元數B

　　控制方法：

　　1）、頁面上，不管輸入什麼字元（全形如漢字、半形如字母），統一規定不能超過B個字元，此種限制，

　　測試點：全部輸入全形B個，測試（B3位元組）會不會超過資料庫位元組長度

　　全部輸入半形B個，測試（B

1位元組）會不會超過資料庫位元組長度

　　混合輸入全形X半形Y，測試（X3+Y位元組）會不會超過資料庫長度

　　2）、頁面上，不以字元統計，以總的輸入位元組數統計，比如，全部輸入全形字元，允許可以輸入A/3個字元，全部輸入半形字元，允許輸入A個字元（ 民生網的設計）

　　測試點：全部輸入全形，看是否允許輸入A/3個字元

　　全部輸入半形，看是否允許輸入A個字元

　　混合輸入全形X，半形Y，看是否允許X3+Y=A

　　(5個：判空、唯一、邊界值、特殊字元、正確流程(多種資料、多種分支))

　　+測試校驗位置：ajax滑鼠事件校驗、前臺提交按鈕js校驗，伺服器拿到資料後再次驗證

　　三、多文字框（type=textarea）

　　1)、空格和換行的問題，看需求，是否需要做支援HTML Encoding

　　輸入全部空格時，是否判空處理？””空格，   。

　　輸入折行，是否也顯示折行？

　　比如：列點說明原因，就需要支援。

　　2)、字母截斷的問題

　　對於一串字母，開發人員往往會忘掉做截斷，這樣如果展示在我們的平臺上的話，這一串字母就會把我們的UI撐開

　　3）、長度控制格式， 您還可以輸入**個字元

　　四、新增按鈕

　　新增動作檢查範圍：

　　失敗：是否提示

　　提示內容是否正確

　　失敗時：儲存使用者已輸入的內容，避免重新再輸入

　　成功：對話方塊消失

　　記錄是否可直接檢視（還需要重新整理？）

　　列表記錄順序

　　重複提交情況，點選一次後，是否變成disable

　　上傳附件的新增：

　　A. 檔名稱：檔名稱很長；檔名稱字元多樣化(漢字，英文，符號)；檔名稱重複。

　　B. 判空？

　　C. 附件格式型別支援？

　　D. 附件個數？

　　E. 附件空間大小。

五、移除按鈕

　　1.一般都要在前臺先給出一個提示操作“確定移除該……”

　　2.相關聯的東西，是否需要限制移除“該型別下存在應用，無法移除”有到後臺比較

　　3.確定後，真正執行移除操作。

　　結果：

　　移除後，列表資料是否立即消失。

　　必須有確認刪除的提示資訊

　　六、列表

　　1）、列表記錄順序

　　2）、是否需要翻頁、有沒有翻頁功能

　　3）、欄位名稱是否與表單一致



　　七、搜尋-文字框

　　1、功能點、需求點考慮：

　　是否提供模糊查詢、輸入數值有種類有限定時，是否考慮換成下拉框搜尋；

　　2、檢查點：

　　文字框值是否消失(是否回填條件值)，再次點選“查詢”可檢視所有記錄；

　　考慮搜尋結果：是否存在分頁，分頁是否正常；是否有序；

　　注意：分頁是否仍儲存查詢條件，檢查後面的記錄是否符合條件

　　3、查詢資料多樣性：

　　輸入不存在的欄位值測試、包括特殊字元查詢測試例如：’ or ‘1’='1；

　　輸入類似程式語句的條件時是否執行查詢，如：XXXX”、XXX and ；

　　4、操作型別：

　　1) 不輸入的查詢

　　2) 輸入全部空格的查詢

　　3) 模糊查詢(輸入部分欄位，或者說，輸入英文字母，查詢到相關中文資料)

　　4) 輸入不存在的查詢

　　5) 輸入存在的查詢

　　6) 單個查詢和多個條件複合查詢。

　　八、搜尋-下拉框

　　檢查點：

　　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 先全選-》移除某個單選-》全選按鈕是否移除選中狀態



談談效能測試分類

效能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項效能指標進行測試。負載測試和壓力測試都屬於效能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的效能，目標是測試當負載逐漸增加時，系統各項效能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。

　　驗收效能測試（狹義） 　　效能測試方法是通過模擬生產執行的業務壓力量和使用場景組合，測試系統的效能是否滿足生產效能要求。通俗地說，這種方法就是要在特定的執行條件下驗證系統的能力狀態。

　　特點： 1、這種方法的主要目的是驗證系統是否有系統宣稱具有的能力。 2、這種方法要事先了解被測試系統經典場景，並具有確定的效能目標。 3、這種方法要求在已經確定的環境下執行。 也就是說，這種方法是對系統性能已經有了解的前提，並對需求有明確的目標，並在已經確定的環境下進行的。

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

　　特點： 1、這種效能測試方法的主要目的是找到系統處理能力的極限。 2、這種效能測試方法需要在給定的測試環境下進行，通常也需要考慮被測試系統的業務壓力量和典型場景、使得測試結果具有業務上的意義。 3、這種效能測試方法一般用來了解系統的效能容量，或是配合效能調優來使用。 也就是說，這種方法是對一個系統持續不段的加壓，看你在什麼時候已經超出“我的要求”或系統崩潰。



　　壓力測試（強度測試）(Stress Test)壓力測試方法測試系統在一定飽和狀態下，例如cpu、記憶體在飽和使用情況下，系統能夠處理的會話能力，以及系統是否會出現錯誤

　　特點： 1、這種效能測試方法的主要目的是檢查系統處於壓力效能下時應用的表現。 2、這種效能測試一般通過模擬負載等方法，使得系統的資源使用達到較高的水平。 3、這種效能測試方法一般用於測試系統的穩定性。 也就是說，這種測試是讓系統處在很大強度的壓力之下，看系統是否穩定，哪裡會出問題。

　　併發測試（Concurrency Testing）併發測試方法通過模擬使用者併發訪問，測試多使用者併發訪問同一個應用、同一個模組或者資料記錄時是否存在死鎖或其者他效能問題。

　　特點： 1、這種效能測試方法的主要目的是發現系統中可能隱藏的併發訪問時的問題。 2、這種效能測試方法主要關注系統可能存在的併發問題，例如系統中的記憶體洩漏、執行緒鎖和資源爭用方面的問題。 3、這種效能測試方法可以在開發的各個階段使用需要相關的測試工具的配合和支援。 也就是說，這種測試關注點是多個使用者同時（併發）對一個模組或操作進行加壓。

　　配置測試（Configuration Testing）配置測試方法通過對被測系統的軟\硬體環境的調整，瞭解各種不同對系統的效能影響的程度，從而找到系統各項資源的最優分配原則。

　　特點： 1、這種效能測試方法的主要目的是瞭解各種不同因素對系統性能影響的程度，從而判斷出最值得進行的調優操作。 2、這種效能測試方法一般在對系統性能狀況有初步瞭解後進行。 3、這種效能測試方法一般用於效能調優和規劃能力。 也就是說，這種測試關注點是“微調”，通過對軟硬體的不段調整，找出這他們的最佳狀態，使系統達到一個最強的狀態。

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

　　特點： 1、這種效能測試方法的主要目的是驗證是否支援長期穩定的執行。 2、這種效能測試方法需要在壓力下持續一段時間的執行。（2~3天） 3、測試過程中需要關注系統的執行狀況。 如果測試過程中發現，隨著時間的推移，響應時間有明顯的變化，或是系統資源使用率有明顯波動，都可能是系統不穩定的徵兆。 也就是說，這種測試的關注點是“穩定”，不需要給系統太大的壓力，只要系統能夠長期處於一個穩定的狀態。

　　失效恢復測試如果系統局部發生故障，使用者是否能夠繼續使用系統，以及如果這種情況發生，使用者將受到多大程度的影響。

　　特點： 1.這種效能測試方法的主要目的是驗證在區域性故障情況下，系統能否繼續使用。 2.這種效能測試方法還需要指出，當問題發生時，“能支援多少使用者訪問”的結論和“採取何種應急措施”的方案。 3.一般來說，只有對系統持續執行指標有明確要求的系統才需要進行這種型別的測試。

　　大資料量測試針對某些系統儲存、傳輸、統計查詢等業務進行大資料量的測試。

　　疲勞強度測試主要特點是長時間對目標測試系統加壓，目的是測試系統的穩定性，持續時間一般在1小時以上；感覺等同於可靠性測試。

　　注意：在做效能測試時請忘掉分類.例如，執行8個小時來測試系統是否可靠，而這個測試極有可能包含了可靠效能測、強度測試、併發測試、負載測試，等等。因此，在實施效能測試時決不能割裂它們的內部聯絡去進行，而應該分析它們之間的關係，以一種高效率的方式來設計效能測試。



Web測試中的幾個case

一、頁面上對引起 大量資料提交的 按鈕/連結 點選一次後，  disable

　　需求：

　　對於重要的表單、數量龐大/響應慢的系統，在做提交時， 又有頁面還在loading狀態， 此時連續做兩次點選， 經常引起各種報錯，這種情況下， 需要提出 對 按鈕/連結 點選一次後， 做 disable

　　測試：

　　1）、檢視頁面原始碼是否有指令碼控制，例如：

<a href="javascript: $(’#next’).val(‘true’); buttonDisable();headerFormSubmit();" type=“submit” class=“btn” id=“nextButton”> Next </a>

function buttonDisable(){

KaTeX parse error: Expected 'EOF', got '#' at position 3: ("#̲nextButton").at…("#nextButton").attr(“disabled”, “disabled”);這行指令碼設定disable， 點選nextButton，檢查執行到斷點處停止，按鈕無法再次點選。執行斷點後， disable解除。

　　二、新增資料庫欄位測試需要考慮的幾個點

　　1）、從資料庫檢查起， 檢查相關表： 原表、歷史表、與其同步庫的表 有沒有都添上該欄位，並且注意在每個表中， 欄位型別是否統一

　　2）、校驗：考慮欄位本身型別，   判空、邊界、唯一性、特殊字元、正確性允許的data

　　特別， 在做判空時，若欄位不允許為空時，考慮： 需要提交指令碼初始化歷史資料set dafault value

　　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注入、跨站點指令碼攻擊、跨站點偽造請求、目錄遍歷、郵件表頭注入、頁面錯誤資訊等。

　　對於手動安全測試來說，一般常用的有三點：

　　1、URL有引數的，手動修改引數，看是否得到其他使用者的資訊和相關頁面；

　　2、在登入輸入框的地方輸入‘ or 1=1–或 “ or 1=1–等看是否有SQL注入；

　　3、在注重SQL注入的同時，一般在有輸入框的地方輸入

　　對於自動化安全測試來說：

　　測試組目前使用的安全測試工具為IBM的AppScan（當然，是破解版,34上已經放過該工具的安裝包）

　　1、在使用之前務必確認自己繫結的Host；

　　2、配置URL、開發環境、錯誤顯示型別；

　　3、結果儲存後可根據提示的問題型別和解決建議進行分析。

　　Web安全測試通常要考慮的測試點：

　　1、輸入的資料沒有進行有效的控制和驗證

　　2、使用者名稱和密碼

　　3、直接輸入需要許可權的網頁地址可以訪問

　　4、認證和會話資料作為GET的一部分來發送

　　5、隱藏域與CGI引數

　　6、上傳檔案沒有限制

　　7、把資料驗證寄希望於客戶端的驗證

　　8、跨站指令碼（XSS）

　　9、注入式漏洞（SQL注入）

　　10、不恰當的異常處理

　　11、不安全的儲存

　　12、不安全的配置管理

　　13、傳輸中的密碼沒有加密

　　14、弱密碼，預設密碼

　　15、緩衝區溢位

　　16、拒絕服務

SQL注入：

所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字串，最終達到欺騙伺服器執行惡意的SQL命令，比如先前的很多影視網站洩露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到SQL注入式攻擊．（

（select * form 表 where id=1 or 1

1 or 1是輸入框輸入的

這樣會導致滿足 id=1 或 1 的資料都查出來

而所有的資料都滿足 1 

這樣就查出來了很多不該被查出來的資料

這就是sql注入）