程序測試規范(6)

　　流控制和狀態測試。在用戶填寫完表單中的字段并按下按鈕后，邏輯是否會到達期望的進程?下一次顯示同一頁面時，其中的值是否正確?有時頁面第一次顯示了正確的值，而以后不再顯示;或者情況相反。

　　配置測試。在可行的情況下，會用盡可能多的“受支持服務器”和客戶程序配置對應用程序進行測試。

　　負載測試。在將頁面或 Web 應用程序作為整體進行測試之前，應首先在組件級別進行負載和性能測試，以確保應用程序的每一部分能夠在適當的指標下運行。這種隔離測試使測試小組能夠更迅速地發現使用特定技術的問題。如果一個執行數據庫查詢功能的小腳本太慢，進行組件級別的測試比進行整個頁面或應用程序測試更容易發現它。

　　回歸測試。開發部門修復了代碼中的錯誤后，我們會重新進行測試，以檢查錯誤是否被修復并確保所做的修復不會引起其它問題。

　　二、按窗體位置分類：

　　左側導航窗格：

　　是否能夠在左側的導航窗格中來回移動，該窗格顯示是否正確?

　　是否能夠在大于屏幕的區域內滾動?

　　是否能夠選擇不同的新聞組，文章列表是否顯示在右上窗格中?

　　是否能夠調整左側導航窗格以及右上和右下窗格的大小?

　　右上窗格：

　　右上窗格是否正確地顯示文章，是否保持了每篇文章的連載狀況?

　　是否可以遍歷連載文章?

　　讀過一篇文章后，它是否被標記為紅色?

　　如果文章列表大于一個頁面，是否能夠遍歷右上窗格中的各個頁面?

　　右下窗格：

　　是否可以選擇一篇文章并顯示在該頁面的右下窗格中?

　　是否能夠發布新消息，回復組，回復個人或轉發文章?

　　在回復個人或轉發消息時，默認的郵件客戶程序是否啟動并顯示新消息?

　　是否能夠伴隨文章發送附件?

　　是否可以查看附件?

　　工具欄：

　　驗證工具欄適合其所在的頁面并能夠根據瀏覽器窗口調整大小。

　　驗證本地菜單能夠正常運行。

　　驗證本地菜單中的鏈接。

　　驗證全局菜單能夠正常運行。

　　驗證全局菜單中的鏈接。

　　驗證工具欄上的所有圖形。

　　驗證工具欄框架大小不可調整。

　　界面測試

　　站點地圖和導航條

　　確認你測試的站點是否有地圖。有些網絡高手可以直接去自己要去的地方，而不必點擊一大堆頁面。另外新用戶在網站中可能會迷失方向。站點地圖和/或導航條可以引導用戶進行瀏覽。需要驗證站點地圖是否正確。確認地圖上的鏈接是否確實存。地圖有沒有包括站點上的所有鏈接。是否每個頁面都有導航條? 導航條是否一致? 每個頁面的鏈接是否正常? 導航條是否直觀?

　　內容

　　測試人員應確保站點看起來更專業些。過分地使用粗體字、大字體和下劃線可能會讓用戶感到不舒服。在進行用戶可用性方面的測試時，最好先請圖形設計專家對站點進行評估。你可能不希望看到一篇到處是黑體字的文章，所以相信您也希望自己的站點能更專業一些。 最后，需要確定是否列出了相關站點的鏈接。很多站點希望用戶將郵件發到一個特定的地址，或者從某個站點下載瀏覽器。但是如果用戶無法點擊這些地址，他們可能會覺得很迷惑。

　　顏色/背景

　　由于 web 日益流行，很多人把它看作圖形設計作品。不幸的是，有些開發人員對新的背景顏色更感興趣，以至于忽略了這種背景顏色是否易于瀏覽。典型的站點是在紫色圖片的背景上顯示黃色的文本(如果你沒有見過這樣的站點，請瀏覽一下 GeoCities 或 AOL 上的個人主頁，有不少這樣的)。這種頁面顯得"非常高貴"，但是看起來很費勁。通常來說，使用少許或盡量不使用背景是個不錯的選擇。如果您想用背景，那么最好使用單色的，和導航條一起放在頁面的左邊。另外，圖案和圖片可能會轉移用戶的注意力。

　　圖片

　　無論作為屏幕的聚焦點或作為指引的小圖標，一張圖片都勝過千言萬語。有時，告訴用戶一個東西的最好辦法就是將它展示給用戶。但是，帶寬對客戶端或服務器來說都是非常寶貴的，所以要注意節約使用內存。是否所有的圖片對所在的頁面都是有價值的，或者它們只是浪費帶寬? 使用其它的文件格式(.GIF, .JPG) 是否能使圖片的大小減小到 30k 以下? 通常來說，不要將大圖片放在首頁上，因為這樣可能會使用戶放棄下載首頁。如果用戶可以很快看到首頁，他可能會瀏覽站點，否則可能放棄。

原文轉自：http://www.uml.org.cn/Test/200706154.asp