1、數值型輸入框：
（3）特殊字符："~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能導致系統錯誤的字符 —— 禁止直接輸入特殊字符時，嘗試使用粘貼拷貝查看是否能正常提交
（4）存在的數據：輸入存在的搜索內容
（5）不存在的數據：輸入不存在的搜索內容
2、在輸入框單擊鼠標左鍵,是否有光標出現
3、在輸入框單擊鼠標左鍵,是否有光標出現，光標出現后使用"Tab"鍵后,"搜索"按鈕是否出現選定TIP
4、在輸入框點擊鼠標右鍵是否出現Menu,Menu內容依次為"撤消"、"復制"、"粘貼"、"刪除"、"全選"(具體情況視實際情況而定)
5、檢查以上Menu出現的選擇模塊是否可正常使用
6、在輸入框輸入任意長度字母、數字、漢字,雙擊鼠標左鍵,觀察輸入項目能否被全部選中
7、輸入正則表達式
2）當前頁面不在最后一頁且當前的頁數大於1頁時，下一頁和最后一頁的按鈕能否正常顯示，可否點擊
2）當前頁面不在最后一頁且當前數據的頁數大於1頁時，下一頁和最后一頁的按鈕能否正常顯示，可否點擊
5）文件命名長度的名稱過長。
6）文件命名長度的名稱達到最大長度（中文，英文或混在一起）上傳后名稱顯示，頁面排版-----------頁面顯示正常
7）文件名稱中包含特殊字符-------------根據需求而定
8）文件名稱全為中文--------------------根據需求而定
9）文件名稱全為英文--------------------根據需求而定
10）文件名稱為中、英混合-----------------根據需求而定
6）文件類型大小都合適視頻，文件內容相同，名稱相同，上傳
7）文件類型大小都合適，文件內容不同，名稱不同，上傳
1）一條已經成功提交的記錄，返回后再提交，是否做了處理
2）檢查多次使用返回鍵的情況，在有返回鍵的地方，返回到原來的頁面多次，查看是否會出錯
網站測試的主要方面
1 功能測試（包含基本功能測試和數據准確性校驗）
對於網站的測試而言，每一個獨立的功能模塊需要單獨的測試用例的設計導出，主要依據為《需求規格說明書》及《詳細設計說明書》，對於應用程序模塊需要設計者提供基本路徑測試法的測試用例。
B/S結構實現的功能可能主要的就在於提交數據，處理數據等，如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重復使用的腳本代碼，可以在測試、回歸測試時運行以便減輕測試人員工作量。
- 鏈接測試（根據需求是否需要指導用戶使用）
- 表單測試
1）當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶注冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。
例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。
如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。
2）要測試這些程序，需要驗證服務器能正確保存這些數據，而且后台運行的程序能正確解釋和使用這些信息。
3）B/S結構實現的功能可能主要的就在這里，提交數據，處理數據等如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重復使用的腳本代碼，可以在測試、回歸測試時運行以便減輕測試人員工作量。
4）我們對UM子系統中各個功能模塊中的各項功能進行逐一的測試，主要測試方法為：邊界值測試、等價類測試，以及異常類測試。測試中要保證每種類型都有2個以上的典型數值的輸入，以確保測試輸入的全面性。
- cookie測試（如果web應用系統使用cookie）
- 設計語言測試
1）Web設計語言版本的差異可以引起客戶端或服務器端嚴重的問題，例如使用哪種版本的HTML等。
2）當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。
3）除了HTML的版本問題外，不同的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
- 數據庫測試
1）在Web應用技術中，數據庫起着重要的作用，數據庫為Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。
在Web應用中，最常用的數據庫類型是關系型數據庫，可以使用SQL對信息進行處理。
2）在使用了數據庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。
數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。
主要包括以下幾個方面的內容：
（1）站點地圖和導航條： 位置是否合理、是否可以導航等內容布局--布局是否合理；簡介說明--說明文字是否合理，位置是否正確
（2）背景/色調： 是否正確、美觀，是否符合用戶需求
（3）頁面：在窗口中的顯示是否正確、美觀（在調整瀏覽器窗口大小時，屏幕刷新是否正確）；表單樣式--大小，格式，是否對提交數據進行驗證（如果在頁面部分進行驗證的話）等
（4）連接： 連接的形式、位置是否易於理解等
web測試的主要頁面元素：
（1）頁面元素的容錯性列表（如輸入框、時間列表或日歷）
（2）頁面元素清單（為實現功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、復選框、列表框、超連接、輸入框等等）
（3）頁面元素的容錯性是否存在
（4）頁面元素的容錯性是否正確
（5）頁面元素基本功能是否實現（如文字特效、動畫特效、按鈕、超連接）
（6）頁面元素的外形、擺放位置（如按鈕、列表框、核選框、輸入框、超連接等）
（7）頁面元素是否顯示正確（主要針對文字、圖形、簽章）
（8）元素是否顯示（元素是否存在）
（9）頁面元素清單（為實現功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、復選框、列表框、超連接、輸入框等等）
測試技術
1、通過頁面走查，瀏覽確定使用的頁面是否符合需求，可以結合兼容性測試對不用分辨率下頁面顯示效果，如果有影響應該交給設計人員提出解決方案。
2、可以結合數據定義文檔查看表單項的內容，長度等信息。
3、對於動態生成的頁面最好也能進行瀏覽查看。如Servelet部分可以結合編碼規范，進行代碼走查。是否支持中文，如果數據用XM，封裝要做的工作會多一點等。
易用性測試七大要素：符合標准和規范,靈活性,正確性,直觀性,舒適性,實用性,一致性
1、風格、樣式、顏色是否協調
2、界面布局是否整齊、協調（保證全部顯示出來的，盡量不要使用滾動條）
3、界面操作、標題描述是否恰當（描述有歧義、注意是否有錯別字）
4、操作是否符合人們的常規習慣（有沒有把相似的功能的控件放在一起，方便操作）
5、提示界面是否符合規范，有無中英文混合（不應該顯示英文的cancel、ok，應該顯示中文的確定、取消等）
6、界面中各個控件是否對齊，是否顯示完整，間隔是否一致，是否有重疊區域
7、日期控件是否可編輯
8、日期控件的長度是否合理，以修改時可以把時間全部顯示出來為准
9、查詢結果列表列寬是否合理、標簽描述是否合理
10、查詢結果列表太寬沒有橫向滾動提示
11、對於信息比較長的文本，文本框有沒有提供自動豎直滾動條
12、數據錄入控件是否方便
13、有沒有支持Tab鍵，鍵的順序要有條理，不亂跳
14、有沒有提供相關的熱鍵
15、控件的提示語描述是否正確
16、模塊調用是否統一，相同的模塊是否調用同一個界面
17、用滾動條移動頁面時，頁面的控件是否顯示正常
18、日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX
19、頁面是否有多余按鈕或標簽
20、窗口標題或圖標是否與菜單欄的統一
21、窗口的最大化、最小化是否能正確切換
22、對於正常的功能，用戶可以不必閱讀用戶手冊就能使用【控件名稱易懂，用詞准確，與同一界面上的其他按鈕易於區分】
23、執行風險操作時，有確認、刪除等提示嗎
24、操作順序是否合理
25、正確性檢查：檢查頁面上的form, button, table, header, footer,提示信息，還有其他文字拼寫，句子的語法等是否正確
26、系統應該在用戶執行錯誤的操作之前提出警告，提示信息
27、頁面分辨率檢查，在各種分辨率瀏覽系統檢查系統界面友好性
28、合理性檢查：做delete, update, add, cancel, back等操作后，查看信息回到的頁面是否合理
29、檢查本地化是否通過：英文版不應該有中文信息，英文翻譯准確，專業
30、控件字體和大小是否一致，有無錯別字
5 性能測試（轉）
用戶連接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。
當下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容，就需要重新登陸了。
而且，連接速度太慢，還可能引起數據丟失，使用戶得不到真實的頁面。
2、負載測試(負荷測試指的是進行一些邊界數據的測試）——基本功能已經通過后進行的.可以在集成測試階段,亦可以在系統測試階段進行.
負載測試是為了測量Web系統在某一負載級別上的性能，以保證Web系統在需求范圍內能正常工作。
負載級別可以是某個時刻同時訪問Web系統的用戶數量，也可以是在線數據處理的數量。
例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什么現象？Web應用系統能否處理大量用戶對同一個頁面的請求？
負載測試應該安排在Web系統發布以后，在實際的網絡環境中進行測試。對負載工具的延伸使用可以進行系統穩定性測試，系統極限測試。
因為一個企業內部員工，特別是項目組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。
壓力測試是指實際破壞一個Web應用系統，測試系統的反應。
壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什么情況下會崩潰。
如果有負載平衡的話還要在服務器端打開監測工具,查看服務器CPU使用率,內存占用情況
如果有必要可以模擬大量數據輸入,對硬盤的影響等等信息
如果有必要的話必須進行性能優化(軟硬件都可以).這里的壓力測試針對的是某幾項功能
黑客常常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統重新啟動時獲得存儲權。
壓力測試的區域包括表單、登陸和其他信息傳輸頁面等。
1、負載/壓力測試應該關注什么
測試需要驗證系統能否在同一時間響應大量的用戶，在用戶傳送大量數據的時候能否響應，系統能否長時間運行。
可訪問性對用戶來說是極其重要的。如果用戶得到“系統忙”的信息，他們可能放棄，並轉向競爭對手。
系統檢測不僅要使用戶能夠正常訪問站點，在很多情況下，可能會有黑客試圖通過發送大量數據包來攻擊服務器。
出於安全的原因，測試人員應該知道當系統過載時，需要采取哪些措施，而不是簡單地提升系統性能。
如果您的站點用於公布彩票的抽獎結果，最好使系統在中獎號碼公布后的一段時間內能夠響應上百萬的請求。
負載測試工具能夠模擬X個用戶同時訪問測試站點。
3）長時間的使用
采用的測試工具：
性能測試可以采用相應的工具進行自動化測試，我們目前采用如下工具：
Apache自帶的ab測試工具
OpenSTA—開發系統測試架構
Loadrunner—強大的性能測試工具
e-test、webload等
6 接口測試（轉）
在很多情況下，web 站點不是孤立。Web 站點可能會與外部服務器通訊，請求數據、驗證數據或提交訂單。
7 回歸測試
過一段時間以后，再回過頭來對以前修復過的Bug重新進行測試，看該Bug 是否會重新出現。
回歸測試技術可以在測試的各個階段出現，無論是單元測試還是集成測試還是系統測試，是對以前問題進行驗證的過程。
回歸測試的目的就是保證以前已經修復的Bug不會再出現。
實際上，許多Bug都是在回歸測試時發現的，在此階段，我們首先要檢查以前找到的Bug是否已經更正了。
值得注意的是，已經更正的Bug 也可能又回來了，有的Bug 經過修改之后可能又產生了新的Bug。
所以，回歸測試可保證已更正的Bug不再重現，不產生新的Bug。
web端測試中應該注意的其他情況：
存在風險及解決方法
說明：測試不能找出所有的問題，只是盡量將問題在開發階段解決大多數的問題而已。
測試風險如下：
1）軟硬件的測試環境提供上也對測試結果有很大的影響
2）測試團隊的水平，經驗，合作效果等
3）整個開發流程對測試的重視程度，測試的進入時間等
4）由於測試環境操作系統，網絡環境，帶寬等情況可能產生的測試結果可能不同，這是需要經驗以及對測試環境的保護等方面下一些功夫
【參考鏈接】http://www.cnblogs.com/Jessy/p/3539638.html
（如有不足，請指點。后續更新）