日常測試中，我們用的最多的就是功能測試，雖然功能測試只是點來點去，但是點來點去也是需要經驗和頭腦的，我也加了自己平時測試時發現的一些問題，總結如下：

一、輸入框

1. 字元型輸入框：
（1）字元型輸入框：英文全形，英文半形，數字，空或者空格，特殊字元（共32個，特別要注意單引號，下劃線，雙引號，&），禁止直接輸入特殊字元時，使用“貼上”、“拷貝”功能嘗試輸入。
（2）長度檢查：最小長度，最大長度，最小長度-1，最大長度+1，輸入超長字元。
（3）空格檢查：輸入的字元間有空格，字元後有空格，字元前後有空格。
（4）多行文字框輸入：允許回車換行，儲存後再顯示能夠儲存輸入的格式，僅輸入回車換行，檢查能否正確儲存（若能，檢查儲存結果，若不能，檢視是否有正常提示）。
（5）安全性檢查：輸入字串或指令碼函式
2. 數值型輸入框

（1）邊界值：最大值，最小值，最大值+1，最小值-1
（2）位數：最小位數，最大位數，最小位數-1，輸入超長值，輸入整數
（3）異常值、特殊字元：輸入空白（NULL）、空格或特殊字元等可能導致系統錯誤的字元，禁止直接輸入特殊字元時，嘗試使用貼上拷貝，檢視是否能正常提交、word中的特殊功能，通過剪貼簿拷貝到輸入框，分頁符，分節符類似公式的上下標等、數值的特殊符號如∑，㏒，㏑，∏，+，-等、輸入負整數、負小數、分數、輸入字母或漢字、小數（小數前0點捨去的情況，多個小數點的情況）、首位為0的數字如01、02、科學計數法是否支援1.0E2、全形數字與半形數字、數字與字母混合、16進位制，8進位制數值、貨幣型輸入（允許小數點後面幾位）
（4）安全性檢查：不能直接輸入就copy

3. 日期型輸入框：
（1）合法性檢查：(輸入0日、1日、32日)、月輸入1、3、5、7、8、10、12、日輸入31、月輸入4、6、9、11、日輸入30、31、輸入非閏年，月輸入2，日期輸入28、29、輸入閏年，月輸入2、日期輸入29、30、月輸入0、1、12、13
（2）異常值、特殊字元：輸入空白或NULL、輸入特殊字元等可能導致系統錯誤的字元
（3）安全性檢查：不能直接輸入，就copy，是否資料檢驗出錯。

4. 資訊重複
在一些需要命名,且名字應該唯一的資訊輸入重複的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的前後輸入空格,系統是否作出正確處理。

二、搜尋功能

若查詢條件為輸入框，則參考輸入框對應型別的測試方法：

1. 功能實現：
（1）如果支援模糊查詢，搜尋名稱中任意一個字元是否能搜尋到
（2）比較長的名稱是否能查到
（3）輸入系統中不存在的與之匹配的條件
（4）使用者進行查詢操作時，一般情況是不進行查詢條件的清空，除非需求特殊說明。

2. 組合測試：
（1）不同查詢條件之間來回選擇，是否出現頁面錯誤（單選框和多選框最容易出錯）
（2）測試多個查詢條件時，要注意查詢條件的組合測試，可能不同組合的測試會報錯。

三、新增、修改功能

1. 特殊鍵：
（1）是否支援Tab鍵 （2）是否支援回車鍵
2. 提示資訊：
（1）不符合要求的地方是否有錯誤提示
3. 唯一性：
（1）欄位唯一的，是否可以重複新增，新增後是否能修改為已存在的欄位（欄位包括區分大小寫以及在輸入的內容前後輸入空格，儲存後，資料是否真的插入到資料庫中，注意儲存後資料的正確性）
4. 資料正確性：
（1）對編輯頁的每個編輯項進行修改，點選儲存，是否可以儲存成功，檢查想關聯的資料是否得到更新。
（2）進行必填項檢查（即是否給出提示以及提示後是否依然把資料存到資料庫中；是否提示後出現頁碼錯亂等）
（3）是否能夠連續新增（針對特殊情況）
（4）在編輯的時候，注意編輯項的長度限制，有時在新增的時候有，在編輯的時候卻沒有（注意要新增和修改規則是否一致）
（5）對於有圖片上傳功能的編輯框，若不上傳圖片，檢視編輯頁面時是否顯示有預設的圖片，若上傳圖片，檢視是否顯示為上傳圖片
（6）修改後增加資料後，特別要注意查詢頁面的資料是否及時更新，特別是在首頁時要注意資料的更新。
（7）提交資料時，連續多次點選，檢視系統會不會連續增加幾條相同的資料或報錯。
（8）若結果列表中沒有記錄或者沒選擇某條記錄，點選修改按鈕，系統會拋異常。

四、刪除功能

1. 特殊鍵：
（1）是否支援Tab鍵 （2）是否支援回車鍵
2. 提示資訊：
（1）不選擇任何資訊，直接點選刪除按鈕，是否有提示
（2）刪除某條資訊時，應該有確認提示
3. 資料 實現：
（1）是否能連續刪除多個產品
（2）當只有一條資料時，是否可以刪除成功
（3）刪除一條資料後，是否可以新增相同的資料
（4）如系統支援批量刪除，注意刪除的資訊是否正確
（5）如有全選，注意是否把所有的資料刪除
（6）刪除資料時，要注意相應查詢頁面的資料是否及時更新
（7）如刪除的資料與其他業務資料關聯，要注意其關聯性（如刪除部門資訊時，部門下游員工，則應該給出提示）
（8）如果結果列表中沒有記錄或沒有選擇任何一條記錄，點選刪除按鈕系統會報錯。
如：某一功能模組具有最基本的增刪改查功能，則需要進行以下測試
單項功能測試（增加、修改、查詢、刪除）
增加——>增加——>增加 （連續增加測試）
增加——>刪除
增加——>刪除——>增加 （新增加的內容與刪除內容一致）
增加——>修改——>刪除
修改——>修改——>修改 （連續修改測試）
修改——>增加（新增加的內容與修改前內容一致）
修改——>刪除
修改——>刪除——>增加 （新增加的內容與刪除內容一致）
刪除——>刪除——>刪除 （連續刪除測試）

五、修改密碼

1. 不輸入舊密碼，直接改密碼
2. 輸入錯誤舊密碼
3. 不輸入確認新密碼
4. 新密碼和確認新密碼不一致
5. 新密碼中有空格
6. 新密碼為空
7. 新密碼格式正確
8. 新密碼格式錯誤
9. 新密碼為非允許字元
10. 看是否支援tap和enter鍵等；密碼是否可以複製貼上；密碼是否以*之類的加密符號
11. 看密碼是否區分大小寫，新密碼中小寫，確認密碼中大寫
12. 新密碼和舊密碼一樣能否修改成功

六、註冊、登入模組

1. 註冊功能：
（1）註冊時，設定密碼為特殊版本號，檢查登入時是否會報錯
（2）註冊成功後，頁面應該以登陸狀態跳轉到首頁或指定頁面
（3）在註冊資訊中刪除已輸入的資訊，檢查是否可以註冊成功。
2. 登入功能：
（1）輸入正確的使用者名稱和正確的密碼
（2）輸入正確的使用者名稱和錯誤的密碼
（3）輸入錯誤的使用者名稱和正確的密碼
（4）輸入錯誤的使用者名稱和錯誤的密碼
（5）不輸入使用者名稱和密碼（均為空格）
（6）只輸入使用者名稱，密碼為空
（7）使用者名稱為空，只輸入密碼
（8）輸入正確的使用者名稱和密碼，但是不區分大小寫
（9）使用者名稱和密碼包括特殊字元
（10）使用者名稱和密碼輸入超長值
（11）已刪除的使用者名稱和密碼
（12）登入時，當頁面重新整理或重新輸入資料時，驗證碼是否更新

七、上傳圖片測試

1. 功能實現：
（1）檔案型別正確、大小合適
（2）檔案型別正確，大小不合適
（3）檔案型別錯誤，大小合適
（4）檔案型別和大小都合適，上傳一個正在使用中的圖片
（5）檔案型別大小都合適，手動輸入存在的圖片地址來上傳
（6）檔案型別和大小都合適，輸入不存在的圖片地址來上傳
（7）檔案型別和大小都合適，輸入圖片名稱來上傳
（8）不選擇檔案直接點選上傳，檢視是否給出提示
（9）連續多次選擇不同的檔案，檢視是否上傳最後一次選擇的檔案

八、查詢結果列表

1. 功能實現：
（1）列表、列寬是否合理
（2）列表資料太寬有沒有提供橫向滾動
（3）列表的列名有沒有與內容對應
（4）列表的每列的列名是否描述的清晰
（5）列表是否把不必要的列都顯示出來
（6）點選某列進行排序，是否會報錯（點選檢視每一頁的排序是否正確）
（7）雙擊或單擊某列資訊，是否會報錯

九、返回鍵檢查

1. 一條已經成功提交的記錄，返回後再提交，是否做了處理
2. 檢查多次使用返回鍵的情況，在有返回鍵的地方，返回到原來的頁面多次，檢視是否會出錯

十、回車鍵檢查

1. 在輸入結果後，直接按回車鍵，看系統如何處理，是否會報錯

十一、重新整理鍵檢查

1. 在Web系統中，使用重新整理鍵，看系統如何處理，是否會報錯

十二、直接URL連結檢查

1. 在Web系統中，在位址列直接輸入各個功能頁面的URL地址，看系統如何處理，是否能夠直接連結檢視（匿名檢視），是否有許可權控制，是否直接執行，並返回相應結果頁。

十三、介面和易用性測試

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. 檢查本地化是否通過：英文版不應該有中文資訊，英文翻譯準確，專業。

十四、相容性測試

1. 相容性測試不只是指介面在不同作業系統或瀏覽器下的相容，有些功能方面的測試，也要考慮到相容性，
   包括作業系統相容和應用軟體相容，可能還包括硬體相容
   比如涉及到ajax、jquery、javascript等技術的，都要考慮到不同瀏覽器下的相容性問題。

十五、連結測試

主要是保證連結的可用性和正確性，它也是網站測試中比較重要的一個方面。
可以使用特定的工具如XENU來進行連結測試。

1. 導航測試
    導航描述了使用者在一個頁面內操作的方式，在不同的使用者介面控制之間，例如按鈕、對話方塊、列表和視窗等；或在不同的連線頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜尋引擎或其他的導航幫助？
    在一個頁面上放太多的資訊往往起到與預期相反的效果。Web應用系統的使用者趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的資訊，如果沒有，就會很快地離開。很少有使用者願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要儘可能地準確。
    導航的另一個重要方面是Web應用系統的頁面結構、導航、選單、連線的風格是否一致。確保使用者憑直覺就知道Web應用系統裡面是否還有內容，內容在什麼地方。
Web應用系統的層次一旦決定，就要著手測試使用者導航功能，讓終端使用者參與這種測試，效果將更加明顯。

2. 圖形測試
    在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字型、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都連結到某個具體的頁面。
（2）驗證所有頁面字型的風格是否一致。
（3）背景顏色應該與字型顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮，最好能使圖片的大小減小到30k以下
（5）最後，需要驗證的是文字迴繞是否正確。如果說明文字指向右邊的圖片，應該確保該圖片出現在右邊。不要因為使用圖片而使視窗和段落排列古怪或者出現孤行。
通常來說，使用少許或儘量不使用背景是個不錯的選擇。如果您想用背景，那麼最好使用單色的，和導航條一起放在頁面的左邊。另外，圖案和圖片可能會轉移使用者的注意力。

十六、業務流程測試（主要功能測試）

業務流程，一般會涉及到多個模組的資料，所以在對業務流程測試時，首先要保證單個模組功能的正確性，其次就要對各個模組間傳遞的資料進行測試，這往往是容易出現問題的地方，測試時一定要設計不同的資料進行測試。

十七、安全性測試

1. SQL注入（比如登陸頁面）
2. XSS跨網站指令碼攻擊：程式或資料庫沒有對一些特殊字元進行過濾或處理，導致使用者所輸入的一些破壞性的指令碼語句能夠直接寫進資料庫中，瀏覽器會直接執行這些指令碼語句，破壞網站的正常顯示，或網站使用者的資訊被盜,構造指令碼語句時，要保證指令碼的完整性。
   
3. URL地址後面隨便輸入一些符號，並儘量是動態引數靠後
4. 驗證碼更新問題
5. 現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的使用者名稱和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
6. Web應用系統是否有超時的限制，也就是說，使用者登陸後在一定時間內（例如15分鐘）沒有點選任何頁面，是否需要重新登陸才能正常使用。
7. 為了保證Web應用系統的安全性，日誌檔案是至關重要的。需要測試相關資訊是否寫進了日誌檔案、是否可追蹤。
8. 當使用了安全套接字時，還要測試加密是否正確，檢查資訊的完整性。
9. 伺服器端的指令碼常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯指令碼的問題。

十八、效能測試

1. 連線速度測試
使用者連線到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程式時，使用者可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鐘），使用者就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果響應速度太慢，使用者可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連線速度太慢，還可能引起資料丟失，使使用者得不到真實的頁面。

2. 負載測試
負載測試是為了測量Web系統在某一負載級別上的效能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的使用者數量，也可以是線上資料處理的數量。例如：Web應用系統能允許多少個使用者同時線上？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量使用者對同一個頁面的請求？

3. 壓力測試
負載測試應該安排在Web系統釋出以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是專案組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的資料負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。
壓力測試的區域包括表單、登陸和其他資訊傳輸頁面等。

備註：

1. 負載/壓力測試應該關注什麼？
   測試需要驗證系統能否在同一時間響應大量的使用者，在使用者傳送大量資料的時候能否響應，系統能否長時間執行。可訪問性對使用者來說是極其重要的。如果使用者得到“系統忙”的資訊，他們可能放棄，並轉向競爭對手。系統檢測不僅要使使用者能夠正常訪問站點，在很多情況下，可能會有黑客試圖通過傳送大量資料包來攻擊伺服器。出於安全的原因，測試人員應該知道當系統過載時，需要採取哪些措施，而不是簡單地提升系統性能。
   1）瞬間訪問高峰
   如果您的站點用於公佈彩票的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內能夠響應上百萬的請求。負載測試工具能夠模擬X個使用者同時訪問測試站點。
   2）每個使用者傳送大量資料
   網上書店的多數使用者可能只訂購1-5書，但是大學書店可能會訂購5000本有關心理學介紹的課本?或者一個祖母為她的50個兒孫購買聖誕禮物(當然每個孩子都有自己的郵件地址)系統能處理單個使用者的大量資料嗎?
   3）長時間的使用
   如果站點用於處理鮮花訂單，那麼至少希望它在母親節前的一週內能持續執行。如果站點提供基於web的email服務，那麼點最好能持續執行幾個月，甚至幾年。可能需要使用自動測試工具來完成這種型別的測試，因為很難通過手工完成這些測試。你可以想象組織100個人同時點選某個站點。但是同時組織100000個人呢。通常，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。而且，測試工具安裝完成之後，再次使用的時候，只要點選幾下。
   採取措施：採用效能測試工具WAS、ACT，LR等協助進行測試

十九、測試中應該注意的其他情況

1. 在測試時，與網路有關的步驟或者模組必須考慮到斷網的情況
2. 每個頁面都有相應的Title，不能為空，或者顯示“無標題頁”
3. 在測試的時候要考慮到頁面出現滾動條時，滾動條上下滾動時，頁面是否正常
4. URL不區分大小寫，大小寫不敏感
5. 對於電子商務網站，當用戶併發購買數量大於庫存的數量時，系統如何處理
6. 測試資料避免單純輸入“123”、“abc“之類的，讓測試資料儘量接近實際
7. 進行測試時，儘量不要用超級管理員進行測試，用新建的使用者進行測試。測試人員儘量不要使用同一個使用者進行測試
8. 提示資訊：提示資訊是否完整、正確、詳細
9. 幫助資訊：是否提供幫助資訊，幫助資訊的表現形式（頁面文字、提示資訊、幫助檔案），幫助資訊是否正確、詳細
10. 可擴充套件性：是否有升級的餘地，是否保留了介面
11. 穩定性：執行所需的軟硬體配置，佔用資源情況，出現問題時的容錯性，對資料的保護
12. 執行速度：執行的快慢，頻寬佔用情況