web測試方法總結(二)
阿新 • • 發佈：2019-01-06
十一、直接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、檢查本地化是否通過：英文版不應該有中文資訊，英文翻譯準確，專業。
十三、相容性測試
相容性測試不只是指介面在不同作業系統或瀏覽器下的相容，有些功能方面的測試，也要考慮到相容性，
包括作業系統相容和應用軟體相容，可能還包括硬體相容
比如涉及到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跨網站指令碼攻擊：程式或資料庫沒有對一些特殊字元進行過濾或處理，導致使用者所輸入的一些破壞性的指令碼語句能夠直接寫進資料庫中，瀏覽器會直接執行這些指令碼語句，破壞網站的正常顯示，或網站使用者的資訊被盜,構造指令碼語句時，要保證指令碼的完整性。
document.write("abc")
<script>alter("abc")</script>
（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、執行速度：執行的快慢，頻寬佔用情況
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、檢查本地化是否通過：英文版不應該有中文資訊，英文翻譯準確，專業。
十三、相容性測試
相容性測試不只是指介面在不同作業系統或瀏覽器下的相容，有些功能方面的測試，也要考慮到相容性，
包括作業系統相容和應用軟體相容，可能還包括硬體相容
比如涉及到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跨網站指令碼攻擊：程式或資料庫沒有對一些特殊字元進行過濾或處理，導致使用者所輸入的一些破壞性的指令碼語句能夠直接寫進資料庫中，瀏覽器會直接執行這些指令碼語句，破壞網站的正常顯示，或網站使用者的資訊被盜,構造指令碼語句時，要保證指令碼的完整性。
document.write("abc")
<script>alter("abc")</script>
（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、執行速度：執行的快慢，頻寬佔用情況