測試用例（五）（擴展篇）

時間 2019-11-13

標籤測試擴展简体版

原文原文鏈接

2018-08-22 10:04:09html

故障模型---缺陷查找攻擊的二十一招大法程序員

3．輸入特殊字符集web

根據被測軟件的具體狀況輸入非法字符。數據庫

多瞭解ASCII 字符集、程序設計語言和OS中的保留字符串及其特定含義。瀏覽器

4．輸入使緩衝區溢出的數據緩存

在須要接受字符串的地方輸入一個比最大字符串更長的字符串。安全

黑客經常使用此法來攻擊系統。服務器

14．計算結果溢出cookie

一次又一次地執行計算或使用很大或很小的輸入和數據進行計算，重點測試數據類型的初始值或邊界值附近的值，強制數據產生上溢或下溢。網絡

16．文件系統超載

當軟件較大，運行時須要較大空間時，強制磁盤系統滿容量或小於等於被測試軟件運行時所需容量後，運行被測試軟件或利用測試工具模擬磁盤情況。

21．文件內容受損

對於那些須要對文件格式和內容進行校驗的應用程序，可經過手工損壞文件或利用測試工具模擬CRC錯誤。

界面設計的行業標準總結一

　GUI的總體標準包括如下四個方面：

　　1.規範性

　　2.合理性

　　3.一致性

　　4.界面定製性

1、GUI設計的規範性

　　遵循一致的準則，確立標準並遵循，是軟件界面設計中必不可必的環節。確立界面標準的好處：

　　1.便於用戶操做：戶使用起來可以創建起精確的內心模型，使用熟練了一個界面後，切換到另一個界面可以很輕鬆的推測出各類功能

　　2.使用戶感受到統1、規範，在使用軟件的過程當中愉快輕鬆的完成操做，提升對軟件的認知

　　3.下降培訓、支持成本，沒必要花費較多的人力對客戶進行逐個指導

2、GUI佈局的合理性

　　界面的合理性是指界面是否與軟件功能相融洽，界面的顏色和佈局是否協調等。例如：

　　1.界面佈局

　　a.屏幕不能擁擠

　　* Mayhew在1992年的試驗結果代表屏幕整體覆蓋度不該該超過40％，而分組覆蓋度不該該超過62％。

　　* 整個項目，採用統一的控件間距，經過調整窗體大小達到一致，即便在窗體大小不變的狀況下，寧肯留空部分區域，也不要破壞控件間的行間距。

　　b.控件按區域排列

　　* 一行控件縱向中對齊, 控件間距基本保持一致，行與行之間間距相同，靠窗體的控件距窗體邊緣的距離應大於行間距。

　　* 當屏幕有多個編輯區域，要以視覺效果和效率來組織這些區域

　　c.有效組合

　　邏輯上相關聯的控件應當加以組合以表示其關聯性，反之，任何不相關的項目應當分隔開。在項目集合間用間隔對其進行分組，或者使用方框劃分各自區域

　　d.窗口縮放時，控件位置、佈局

　　* 固定窗口大小，不容許改變尺寸

　　* 改變尺寸的窗口，在窗口尺寸發生變化時控件的位置、大小作出相應的改變

　　* 改變尺寸的窗口，在窗口改變尺寸時增長相應在的縱向、橫向滾動條，以方便用戶使用窗體上的控件

　　2.界面顏色搭配

　　使用恰當的顏色，能夠使軟件的界面看起來更加規範：

　　a.統一色調

　　針對軟件類型以及用戶工做環境選擇恰當色調，如：安全軟件，根據工業標準，能夠選取黃色。綠色體現環保，藍色表現時尚清新、紫色表現浪漫等等，淡色能夠令人溫馨，暗色作背景令人不以爲累等。

　　b.與操做系統統一，讀取系統標準色表

　　c.遵循對比原則

　　在淺色背景上使用深色文字，深色背景上使用淺色文字，如藍色文字以白色背景容易識別，而在紅色背景則不易分辨。除非特殊場合，杜絕使用對比強烈，讓人產生憎惡感的顏色

　　d.整個界面色彩儘可能少的使用類別不一樣的顏色

　　e.顏色方案也許會由於顯示器、顯卡、操做系統等緣由顯示出不一樣的色彩

　　f.針對色盲、色弱用戶，能夠使用特殊指示符

　　e.顏色方案也許會由於顯示器、顯卡、操做系統等緣由顯示出不一樣的色彩

　　f.針對色盲、色弱用戶，能夠使用特殊指示符

3、GUI風格的一致性

　　界面的一致性既包括使用標準的控件，也指相同的信息表現方法，如在字體、標籤風格、顏色、術語、顯示錯誤信息等方面確保一致。

　　1.在不一樣分辨率下的美觀程度

　　軟件界面要有一個默認的分辨率，而在其餘分辨率下也能夠運行，分別在800×600，1024×768，1280×768，1280×1024，1200×1600分辨率下的大字體、小字體下的界面表現。

　　2.界面佈局要一致

　　如全部窗口按鈕的位置和對齊方式要保持一致。

　　3.界面的外觀要一致

　　如控件的大小、顏色、背景和顯示信息等屬性要一致，一些須要特殊處理或有特殊要求的地方除外。

　　4.界面所用顏色要一致

　　顏色的先後一致會使整個應用軟件有一樣的觀感，反之會讓用戶以爲所操做的軟件雜亂無章，沒有規則或言。

　　5.操做方法要一致

　　如雙擊其中的項，觸發某事件，那麼雙擊任何其餘列表框中的項，都應該有一樣的事件發生。

　　6.控件風格、控件功能要專注

　　a.不錯誤的使用控件

　　例如使用Button樣式作Table的功能，拿主菜單條顯示版權信息等

　　b.一個控件只作單一功能，不復用

　　若是在特殊狀況下出現複用的時候，可採用如下兩種方法解決：

　　* 分組，使用雙份控件

　　* 使用Table頁，給用戶很明顯的視覺變化

　　7.標籤和訊息的措詞要一致

　　如在提示、菜單和幫助中產生相同的術語。

　　8.標籤中文字信息的對齊方式要一致

　　如某類描述信息的標題行定爲居中，那麼其餘相似的功能也應該與此一致。

　　9.快捷鍵在各個配置項上語義保持一致

　　如Tab鍵的習慣用法是閱讀順序從從左到右，從上到下。在定義軟件快捷鍵時也能夠將現有一些快捷鍵的屬性做爲參考，如表1-3-1（見附件）列出了經常使用的快捷鍵及其功能。

4、GUI界面操做可定製性

　　界面的可定製性大體可分爲如下幾個特性：

　　1.界面元素可定製

　　容許用戶定義工具欄、狀態欄是否顯示，工具欄顯示在界面上的位置；容許用戶定義菜單的位置等。

　　2.工具欄可定製

　　不一樣用戶對經常使用工具的使用是不一樣的，所以容許用戶創建新的工具欄，選擇要顯示的工具欄，定製工具欄上的按鈕等功能在軟件系統中常常被用到

　　3.統計檢索可定製

　　對於某些特殊行業的軟件能夠提供統計檢索的可定製性，在充分了解用戶需求的基礎上制定大量的安全供用戶選擇。

GUI所包含各種元素標準的定製

　　GUI的元素大體可分爲如下幾個方面：

　　1. 窗口

　　2. 菜單

　　3. 圖標

　　4. 控件

　　5. 鼠標

　　6. 文字

7. 聯機幫助

界面設計的行業標準總結二

1、GUI窗口的標準

　　窗口是顯示設備中的一個區域，用於觀看對象、對象相關信息以及應用與對象的動做進行交互。從外觀上來講，一般窗口是由標題、邊框、菜單、工做區、滾動條等組成。窗口的標題欄能夠進行打開、關閉、建立、縮放、移動、刪除、重疊等操做

　　好的GUI窗口應該具有如下標準：

　　1.窗口控件的大小、對齊方向、顏色、背景等屬性的設置和程序設計規約相一致

　　2.顯示相關的下拉菜單、工具條、滾動條、對話框、按鈕、圖標和其餘控制，既能正確顯示又能調用

　　3.若窗口沒法顯示，全部內容可以改變大小、移動和滾動

　　4.活動窗口可以反顯加亮

　　5.窗口可以正確的關閉

　　6.多個窗口疊加時窗口的名稱正確顯示

　　7.窗口的數據可以利用鼠標、功能鍵、方向前頭和鍵盤操做

　　8.當窗口被覆蓋並從新調用後，窗口可以正確再生

　　9.若是使用多任務，全部的窗口可以被實時更新

　　10.窗口支持最小化和最大化或放大

　　11.窗口上的控件隨着窗體的縮放而縮放

　　12.父窗體支持縮放時，子窗體也應該支持縮放

　　13. 一個窗口中按Tab鍵，移動聚焦按順序移動。先從左至右，再從上到下

　　14.子窗口位置在父窗口的左上角或正中，正上方1/4處爲易吸引用戶注意力的位。父窗口或主窗口的中心位置應該在對角線焦點附近，以下圖2-1-2所示

　　15.當多個子窗口彈出時依次向右下方偏移，而且顯示出窗口標題，以下圖2-1-3所示

　　16.重要的命令按鈕與使用頻繁的按鈕放在了界面醒目的位置

　　17.與正在進行的操做無關的按鈕應該加以屏蔽

　　18.按鈕大小要與界面的大小和空間協調

　　19.窗口中所包含的標籤左對齊排列

　　20.多窗口的切換響應時間不宜過長

2、GUI菜單的標準

　　菜單是否易用主要體如今它可否提供線索幫助用戶識別，而不用強迫用戶去記憶，一個好的菜單設置能夠分爲如下幾個方面：

　　1.菜單設置符合軟件的需求

　　2.菜單項的措詞準確，可以表達出所要進行設置的功能

　　3.菜單項的順序合理，具備邏輯關聯的項目集中放置

　　4.圖形佈局一致

　　5.菜單設置在窗體標題欄的下方

3、GUI圖標的標準

　　圖標是表示實體信息簡潔、抽象的符號，它還能夠做爲可視按鈕項，當被選中激活時，能夠完成指定的功能。那麼圖標的設計當中應該着重考慮哪些問題呢，如下提供幾點可供參考：

　　1.圖標的設置符合常規的表達習慣

　　2.不一樣的目標採用不一樣的圖標

　　3.圖標具備清晰的輪廓，輪廓清晰的圖標可保證圖像在不一樣背景色上都具備較好的效果

　　4.選擇合適的尺寸來定義圖標。Windows XP系統的圖標有四種尺寸（以像素爲單位）可做爲參考： 48×48， 32×32，24×24以及16×16，圖標大小的選取決定於工具欄所定義的寬度

　　5.圖標的外形與實際功能類似，應儘可能避免抽象。這樣的圖標能夠使用戶很輕鬆、容易地認識圖標的做用

　　6.在圖標上加以標註，用來講明圖標所完成的功能

　　7.圖標放置在菜單欄的下方

4、GUI中控件的標準

　　軟件系統功能的實現與控件是密不可分的，各控件位置的擺放直接影響到軟件的使用，及其美觀程度。下面舉例說明軟件系統中最經常使用到的控件對其元素間距、擺放位置進行說明：

　　1.控件元素的間距

　　a.單個元素間距

　　* 輸入框之間垂直間距爲5px

　　* Label文本標籤和輸入元素之間水平間距爲8-22px

　　* 複選框、單選按鈕之間垂直間距爲8px

　　* 多種元素混合垂直排列時，複選框和單選按鈕邊上的間距不管在什麼狀況下都爲8px

　　b.元素分組間距

　　* 窗口邊框和內容區域的四周邊距爲11px；

　　* 父組和子組之間的四周間距爲10px；

　　* 分組框邊框和內部內容區域的四周邊距爲5px；

　　* 複選框組、單選框組的組水平間距爲15px

　　2.按鈕的位置，以下表2-4-1對按鈕擺放位置的規則作了總結

5、鼠標在GUI中的標準

　　用戶會把鼠標移進、移出窗口，或當光標在窗口，或當光標在窗口中，用戶按下、釋放鼠標鍵，鼠標是否準確、靈活，對一個軟件系統來講也很重要。如下幾點標準可做爲在軟件系統中鼠標設計的參考：

　　1.在整個交互的過程當中，能夠識別鼠標操做

　　2.屢次點擊鼠標後，仍可以正確識別

　　3.鼠標有多個按鈕的狀況下，可以正確識別每一個按鈕所要完成的功能

　　4.光標、處理指示器和識別指針隨操做恰當的改變

　　5.點擊選中時，鼠標指針停留在選中內容上，而不會滑動

　　6.支持鼠標滑輪上下翻動操做

　　7.對於相同種類的元素採用相同的操做激活

　　8.採用動態圖標形象的表示出當前的操做，如用水漏表示系統忙，用手型表示能夠點擊等

　　9.鼠標無規則點擊時不會產生不良後果

　　10.單擊鼠標右鍵彈出快捷菜單，取消右鍵後該菜單隱藏

　　11.鼠標光標樣式統一，儘可能使用系統標準，杜絕出現重複的狀況

6、GUI文字的標準

　　文字在視覺上向用戶傳達各類信息，界面文字包括界面文字的字體和界面文字的用語兩個方面，那這兩方面都有哪些要求呢？如下分別闡述。

　　1.字體

　　a.使用統一字體，如規定軟件系統的中文字體爲「宋體」，英文及數據採用「Times New Roman」

　　b.全部控件、描述信息儘可能使用大小統一的字體屬性，除了特殊提示信息、增強顯示等例外狀況

　　2.文字表達

　　提示信息、幫助文檔文字表達遵循如下準則：

　　a.口語化描述，用詞客氣多用您、請，不要用或少用專業術語，杜絕錯別字

　　b.標點符號（斷句、逗號、句號、頓號、分號）的用法要統一，提示信息比較多的話要進行分段

　　c.警告、信息、錯誤使用對應的表示方法

　　d.使用統一的語言描述，例如一個關閉功能按鈕，能夠描述爲退出、返回、關閉，則應該統一規定

　　e.根據用戶不一樣採用相應的詞語語氣語調

7、GUI聯機幫助的標準

　　幫助文檔適用於如下三種狀況：

　　* 系統默認、行業標準的控件操做不須要逐一描述，只須要對特殊控件加以描述

　　* 特殊操做、特殊功能界面，在界面上加控件直接鏈接到對應的幫助文件中

　　* 特殊設置的詳細信息，除了應該在界面上用簡潔明瞭的語句說明外，還能夠在界面上加控件直接鏈接到對應的幫助文件中

　　幫助文檔的標準要求：

　　* 結構化，按功能模塊劃分

　　* 必須闡述功能經過什麼方法能夠在軟件中實現

　　* 措詞恰當、簡捷、通俗易懂，明瞭的幫助用戶解決問題

* 不在幫助文檔中作廣告宣傳

淺談易用性測試及GUI常見的測試要求

對於一個須要面對用戶的軟件產品來講，最直觀的UI和使用感覺也是產品可否得到用戶承認的關鍵一環。我的認爲，在毒霸的產品傳統中，從設計到開發再到測試，對產品的易用性和GUI的規範每每給予的關注較少。我在測試過程當中就遇到了不少影響使用心情的非關功能方面的 BUG。但願此文能夠在毒霸的易用性和GUI方面的測試中給同窗們提供一些參考。

　　易用性測試

　　易用性(Useability)是交互的適應性、功能性和有效性的集中體現。

　　在《軟件工程產品質量》質量模型中，提出易用性包含易理解性、易學習性和易操做性；即易用性是指在指定條件下使用時，軟件產品被理解、學習、使用和吸引用戶的能力。易用性測試包括針對應用程序的測試，同時還包括對用戶手冊系統文檔的測試。一般採用質量外部模型來評價易用性。包括以下方面的測試：

　　(1) 易理解性測試

　　(2) 易學性測試

　　(3) 易操做性測試

　　(4) 吸引性測試

　　(5) 易用的依從性測試

　　易用性測試方法有：靜態測試；動態測試；動態和靜態結合測試。

　　因爲易用性缺陷的主觀性，所以測試人員和UI設計人員常常產生不一樣意見。UI一般被看成創造者的做品，而測試人員說某處是錯誤，就可能挫傷「藝術家」。易用性是軟件缺陷中的敏感問題。

　　人體工程學(ergonomics)是一門將平常使用的東西設計爲易於使用和實用性強的學科。人體工程學的主要目標是達到易用性。

　　一、用戶界面測試

　　用於與軟件交互的方式稱爲用戶界面或UI。

　　二、優秀UI的構成

　　軟件測試員要負責測試軟件的易用性，包括其用戶界面。

　　記住，軟件測試員不須要去設計UI，只須要把本身看成用戶，而後去找出UI中的問題。

　　優秀UI具有的七個要素：

(1) 符合標準和規範

　　重要的用戶界面要符合現行標準和規範，這些標準和規範由軟件易用性專家開發。它們是由大量正式測試、經驗、技巧和錯誤得出的方便用戶的規則。若是軟件嚴格遵照這些規則，優秀UI的其餘要素就天然具有。

　　(2) 直觀性

　　* 用戶界面是否潔淨、不唐突、不擁擠？

　　* UI的組織和佈局合理嗎？

　　* 是否容許用戶輕鬆地從一個功能轉移到另外一個功能？

　　* 下一步作什麼明顯嗎？

　　* 任什麼時候候均可以決定放棄或者退回、退出嗎？

　　* 菜單或者窗口是否深藏不露？

　　* 有多餘功能嗎？軟件總體抑或局部是否作得太深？

　　* 幫助系統有效嗎？

　　(3) 一致性

　　* 用戶的使用習慣性強，但願一個程序的操做方式可以帶到另外一個程序中。在審查軟件一致性時要考慮一下術語：

　　* 快捷鍵和菜單選項

　　* 術語和命名

　　* 聽衆

　　* 諸如OK和Cancel按鈕的位置

　　(4) 靈活性

　　* 靈活性表如今：用戶喜歡選擇不要太多，可是足以容許他們選擇作什麼和怎麼作。

　　* 狀態跳轉

　　* 狀態終止和跳過

　　* 數據輸入和輸出

　　(5) 溫馨性

　　* 軟件使用起來應該溫馨，不能給用戶工做製造障礙和困難。如何鑑別軟件溫馨性的一些好想法：

　　* 恰當。軟件外觀和感受應該與所作的工做和使用者相符。

　　* 錯誤處理。程序應該在用戶執行嚴重錯誤的操做以前提出警告，而且容許用戶恢復因爲錯誤操做致使丟失的數據。

　　* 性能。快不見得是好事。很多程序的錯誤提示信息一閃而過，沒法看清。若是操做緩慢，應該讓用戶獲得相應的信息。

　　(6) 正確性

　　* 要測試正確性，就是測試UI是否作了該作的事。

　　* 市場定位誤差：有沒有多餘的或者遺漏的功能，或者某些功能執行了與市場宣傳材料不符的操做？

　　* 語言和拼寫：程序員經常能製造出很是有趣的用戶信息。

　　* 不良媒體：圖標是否一樣大小？是否具備相同的調色板？聲音是否應該有相同的格式和採樣率？

　　* 所見即所得：保證UI所說的就是實際獲得的。

　　(7) 實用性

　　* 是否實用是優秀用戶界面的最後一個要素。

　　* 不是指軟件自己是否實用，而是指具體特性是否實用。

　　* 在審查產品說明書、準備測試或者實際測試時，想想看到的特性對軟件是否有實際價值。它們有助於用戶執行軟件設計的功能嗎？若是認爲它們不必，就要研究一下找出它們存在於軟件中的緣由。

　　總之，不要讓易用性測試的模糊性和主觀性阻礙測試工做。易用性測試的模糊和主觀是當然的，即便設計用戶界面的專家也會認可有的地方是這樣的。

GUI常見的測試要求

　　窗口

　　* 窗口可否基於相關的輸入或菜單命令適當的打開

　　* 窗口可否改變大小、移動和滾動

　　* 窗口中的數據可否用鼠標、功能鍵、方向箭頭和鍵盤操做

　　* 當被覆蓋的窗口從新調用後，全部相關功能是否可操做

　　* 可否使用全部窗口的相關功能，全部相關功能是否可操做

　　* 相關的下拉式菜單，工具條，滾動條，對話框，按鈕，圖標和其它控制有否？可否正常顯示？徹底可用？

　　* 顯示多窗口時，窗口名可否正確顯示，活動窗口是否加亮

　　* 使用多用戶時，全部窗口是否能實時更新

　　* 屢次或不正確按鼠標是否會產生沒法預測的結果

　　* 窗口的聲音、顏色提示和窗口的操做順序是否符合需求

　　* 窗口可否正確關閉

　　數據項

　　* 字母、數據可否正確顯示且輸入系統

　　* 圖象方式數據項（如滾動條）是否正常工做

　　* 數據輸入、消失是否能夠理解，可否識別非法數據

　　下列式菜單和鼠標操做

　　* 菜單條顯示在合適語言環境中

　　* 應用程序的菜單是否顯示系統相關特性

　　* 下拉式操做是否正確，功能是否正確

　　* 菜單、調色板和工具條是否能正常的工做

　　* 可否列出全部菜單功能和下拉式功能

　　* 可否經過鼠標操做全部菜單的功能，經過文本命令激活每一個菜單功能

　　* 菜單功能隨當前窗口操做加亮或變灰

　　* 若是要求屢次點擊鼠標或鼠標有多個按鈕時可否正確識別

　　* 光標、處理指示器和識別指針可否隨操做而適當改變

UI測試常見BUG

錄入界面

　　1. 輸入字段要完整，且要與列表字段相符合（參照數據庫進行檢查）

　　2. 必填項一概在後面用*表示（必填項爲空在處理以前要有相關的提示信息）

　　3. 字段須要作校驗，若是校驗不對須要在處理以前要有相關的提示信息

　　 (1) 長度校驗

　　 (2) 數字、字母、日期等等的校驗

　　 (3) 範圍的校驗

　　4. 錄入字段的排序按照流程或使用習慣，字段特別多的時候須要進行分組顯示

　　5. 下拉框不選值的時候應該提供默認值

　　6. 相同字段的錄入方式應該統一（錄入方式有如下幾種：手動輸入、點選、下拉選擇、參照）

　　7. 錄入後自動計算的字段要隨着別的字段修改更新（如單價變後，金額也變）

　　8. 日期參照應該既能輸入，又能從文本框選擇

界面格式

　　1. 字體顏色、大小、對齊方式（根據字段的性質肯定）、加粗的一致性

　　2. 文本框、按鈕、滾動條、列表等控件的大小、對齊、位置的一致性

　　3. 全部新增、修改、查看頁面加上頁面說明（如：XXX新增、XXX編輯、XXX查看等說明字樣），（彈出的）界面要有標題，標題與內容要一致

　　4. 不一樣界面顯示相同字段的一致性（如列表界面和編輯界面）

　　5. 界面按鈕顯示要求（查詢、新增、刪除順序）

　　6. 列表的順序排列應該統一（按照某些特定條件排序）

　　7. 下拉框中的排列順序須要符合使用習慣或者是按照特定的規則排定

　　8. 全部彈出窗口居中顯示或者最大化顯示

　　9. 信息列表中若是某個字段顯示過長用「…」或者分行顯示

　　10. 人員、時間的缺省值通常取當前登陸人員和時間

　　11. 對於帶有單位的字段，須要字段的標籤後面添加以下內容：「（單位）」

功能問題

　　1. 按鈕功能的實現（如返回按鈕可否返回）

　　2. 信息保存提交後系統給出「保存/提交成功」提示信息，並自動更新顯示

　　3. 全部有提交按鈕的頁面都要有保存按鈕（每一個界面風格一致）

　　4. 凡是點選或者下拉選擇的界面，若是一旦選擇完了沒法回到不選擇的狀況，須要加上「清除選擇」功能按鈕（即空白選項）、還須要有一個‘所有’選項。

　　5. 沒有選擇記錄點擊刪除/修改按鈕要提示「請先選擇記錄」

　　6. 選擇記錄後點擊刪除按鈕要提示「確實要刪除嗎？」

　　7. 須要考慮刪除的關聯性，即刪除某一個內容須要同時刪除其關聯的某些內容（當存在關聯的數據時，此記錄應該不能刪除，必須將其關聯的記錄先刪除，才能再回到此界面將此記錄刪除）

　　8. 界面只讀的時候（查詢、統計、導入）等，應該不能編輯。

查詢問題

　　1. 查詢條件缺乏一些能夠查詢的字段（在查詢條件中應當將能夠進行查詢的字段都列舉出來並支持該字段的查詢），

查詢條件分爲：可輸入和枚舉型（點選、框選、下拉框選擇、日期選擇：‘年月日分開選擇’或‘彈出日期選擇界面’）等兩大類。

　　2. 有些查詢條件須要支持模糊查詢：關鍵字查詢即部分匹配

　　3. 須要考慮有些查詢條件自己的關聯性（即某個查詢條件的取值範圍是依賴於其它查詢條件的取值）：

即查詢條件的過濾功能

（好比第一個下拉框選擇選擇‘浙江省’，則第二個下拉框自動過濾出屬於浙江的地區名稱如‘紹興市、寧波市、杭州市…等’；選擇其中一個，則在第三個下拉框中出現該地區包括的縣級城市名稱）

　　4. 查詢條件名稱與信息列表及信息編輯頁面相應的字段名稱徹底統一

　　5. 不一樣模塊相同字段的查詢方式應該統一（手動輸入、點選、下拉選擇）

　　不一樣模塊相同字段顯示的字段名稱應該徹底統一。

　　6. 出報表的時候，查詢條件須要顯示在報表標題的下面，這樣看報表的時候知道數據的依據是什麼。

　　7. 對於範圍的查詢採用全閉的形式。

網站測試清單

通用

◇ 全部測試是否運行在乾淨系統上？

◇ 系統是否正常運行？

◇ 是否顯示正確輸出？

◇ 系統是否能提供所需功能？

◇ 普通用戶是否能輕鬆地操做該系統？

◇ 是否易學易用？

◇ 系統是否會爲客戶提供服務？如響應的、有幫助的、正確的服務？

◇ 是否能夠簡單辨別系統的正確性與可靠性？

◇ 是否能輕易地修復或修改系統？

◇ 新版本中未經修改的功能是否能與老版本保持一致？

◇是否能夠有效驗證系統的工做方式是適當的？

◇ 本系統內一些組成部分是否能夠被其餘的系統再利用？

◇ 不一樣用戶不一樣平臺上安裝系統是否一樣快捷便利？

◇ 系統是否設置有將來更新的路徑？

◇ 是否能夠方便地獲取信息？

◇ 網站是否能被搜索

可用性、界面及導航

◇ 系統爲一個用戶、十個用戶或一千個用戶服務時，是否一樣工做正常？

◇ 是否能夠快速登錄主頁？

◇ 網站的操做方法是否清晰地展現給用戶？

◇ 若是按操做方法進行操做是否能夠獲得預期結果？

◇ 是否全部新用戶都理解網站內的全部術語？

◇ 是否全部窗體都有導航欄？

◇ 導航欄的位置是否始終保持一致？

◇ 是否導航欄僅做用於使用中的文本？

◇ 用戶是否能夠在不用鼠標的狀況下使用導航欄功能？

◇ 視力障礙者是否能夠使用網站？紅綠色盲，少於 20/20

◇ 網站標誌是否風格一致？

◇ 每一個單獨頁面內是否包含主頁連接？

◇ 每一個頁面的排版是否統一？

◇ 每一個頁面的管理風格是否一致？

◇ 網站內圖表的使用是否協調？

◇ 快速下載的圖表是否質量優化？

◇全部圖片是爲頁面添彩，仍是浪費網速？

◇ 是否使用了圖表的最佳尺寸？

◇ 圖表/圖片周圍的文字佈局是否合理？

◇ 是否對全部的參考網站或電子郵件地址都設置了超連接？

◇ 超連接顏色設置是否標準？

◇ 網站在 1024x 76八、600x800 等像素下是否顯示正常？

◇ 字體是否過小（切忌並不是每一個人都能得到相同的視圖效果）？

◇ 字體是否太大？

◇ 全部文本是否排列適當？

◇ 全部圖標是否排列適當？

◇ 圖片是否能被完整打印？

◇ 網站內是否有站內地圖？

◇ 站內地圖的每一個超連接是否有對應的目標連接頁？

◇ 站內地圖是否包含了網站內全部的超連接？

◇ 每一個頁面的超連接是否正常工做？

◇ 內容是合法正確的（非單元測試期間開發者設置的填充內容）

◇ 頁面背景（顏色）是否會分散注意力？

◇ 返回按鈕是否正常工做？不會打開一個新的瀏覽器窗口，或重定向其餘站點。

◇ 返回上頁或轉至新頁面時，是否會致使本頁面內容丟失？

◇ 從主頁開始是否能夠經過 3 次或更少的點擊數到達目標頁面？

◇ 圖表或表格中的內容是否完整？是否正確列出？是否能肯定所選文本處於圖表或表格的正確區域內？

◇ 頁面上的連接是否和先前一致？有沒有新出來的或消失的連接？

有沒有連接失敗的狀況？

◇ 點擊連接是否能到達正確的目標頁面？

◇ 目標頁面是否存在？

◇ 站主的聯繫信息是否能從網站中得到（姓名、電話、電子郵件地址、郵寄地址、傳真號）？

◇ 若是用戶須要爲某個頁面做標籤，該頁面的名稱是否易懂？

◇ 若是用戶有獲取歷史頁面紀錄的權限，那網站地址是否會出如今 History 列表中？

◇ 網站頁面的狀態欄是否真實反映出頁面登錄的進度、信息等？

表格

◇ 表格是否過長，常常須要經過拖動滾動條才能看到表格右邊的欄目？

◇ 表格是否能正確打印？

◇ 表格內的列寬和行高是否合適？

◇ 會不會由於某個輸入而使行高變化異常？

框架

◇ 是否會出現瀏覽器不支持的框架？

◇ 框架是否能自動準確地調整大小？用戶是否能夠操控框架的尺寸？

◇ 滾動條是否會適時出現？

◇ 框架頁面上是否有明確的數據供書籤或收藏夾識別？

◇ 搜索引擎是否能夠找到框架中的內容？

◇ 框架邊框是否美觀？

◇ 框架內更新是否會出現問題？

數據認證

◇ 網站內面向用戶的數據描述是否清楚？

◇ 隱私制度是否制定清楚？用戶可否看到該制度？

◇ 保存的數據是否準確？

◇ 工做站是否對數據進行認證？

◇ 服務器是否對數據進行認證？

◇ 是否能夠確保用戶在工做站錄入的信息能夠被服務器正確接收？

◇ 在不一樣的時間段是否能夠避免錄入相同的信息（訂單表等）？

◇ 是否爲每一個用戶分配有惟一標識符，用於錄入表格數據，保證表格對象的惟一性？

◇ 要求用戶錄入的信息是不是進程所必需的？例如：要求用戶錄入生日信息是用於其訂單編號？或是僅僅爲了多得到一些用戶信息？

◇ 數字錄入區域是否能夠錄入文字？

◇ 搜索中可否使用通配符？

◇ 是否能夠在域內錄入空格和空值？

◇ 是否能夠錄入長串？

◇ 域內是否能夠錄入文本最大的數量？

◇ 複選框和控件按鈕的初值是否設置正確？

◇ 一個組內的控件按鈕是每次只能選中一個？

◇ 複選框是否會觸發預期事件？

◇在表格域內用戶是否不能輸入 HTML 代碼？

◇智能錯誤處理是否會引起數據認證？ IE.如生日域的需求格式爲 MM/DD/YYYY，則用戶輸入出聲年份爲 1857 是不匹配的。

外部界面

◇ 系統界面是否與相關的外部系統相匹配？

◇ 界面是否經過驗證？

◇ 是否全部的支持的瀏覽器都通過測試？

◇ 一旦外部應用程序不可用或服務器鏈接失敗，是否全部與外部界面相關的錯誤環境都通過測試？

◇ 代理緩存是否通過測試？

◇ 是否全部可能從網站內部安裝的應用程序都通過測試？

內部界面

◇ 網站是否支持無下載功能的用戶使用？

◇ 網站是否設置有防火牆？

◇ 網站是否能夠靈活使用卸載插件？

◇ 網站處於不一樣模式或運行速度的狀況下可能須要使用插件，網站是否支持？

◇ 是否全部的插件能夠協同工做？

◇ 是否全部平臺都支持，且能打開連接文件（如 Solaris 操做系統是否能夠打開 Microsoft Word 文件）？

◇ 是否全部瀏覽器都支持這些插件？

◇ 一旦 Java 不可用，是否網站就不可用？

◇ 是否全部的插件都能正常啓動？

◇ 若是下載時遇到錯誤，是否會有錯誤處理？

◇ 網站功能中是否有使用"非標準"硬件（如話筒、線纜調制解調器等）的功能存在？

◇ 是否能夠下載註冊的 ActiveX 控件？

◇ 是否能夠下載未註冊的 ActiveX 控件？

◇ 是否能夠初始化並編譯未被認定爲安全的 ActiveX 控件？

◇ 是否能夠運行 ActiveX 控件和插件？

◇ 是否能夠編譯被認定爲安全可編譯的 ActiveX 控件？

◇ 反饋結果是否須要 cookie？

◇ 若是用戶不支持 cookie，反饋結果是否正常？

◇ 反饋結果是否容許使用每一個對話 cookie？

◇ 反饋結果是否須要文件下載？

◇ 若是用戶不要下載文件，網站是否仍能夠使用？

◇ 反饋結果是否須要使用特定字體？

◇ 反饋結果是否須要用戶跨越多個站點/域連接數據源？

◇ 用戶是否能夠使用拖拉和點擊功能？

◇ 用戶是否能夠使用複製/粘貼功能？

◇ 反饋結果是否須要下載任何桌面項？

◇ 反饋結果是否須要登錄或安裝任何帶框架的文件？

◇ 是否容許提交未加密數據？

◇ 網站是否容許經過腳本複製操做？

瀏覽器 - IE、Netscape、AOL、Mac 等

◇ HTML 版本是否與相應的瀏覽器版本相匹配？

◇ 測試時，JAVA 源碼/腳本是否被瀏覽器支持？

◇ 測試時，瀏覽器是否能夠正確顯示圖片？

◇ 是否能夠肯定在任何瀏覽器上，字型都是可用的？

◇ 與每一個瀏覽器相關的安全性設置/風險是否通過檢驗？

◇ 是否在多個瀏覽器上驗證過數字證書？

◇ 與瀏覽器配套的插件是否和網站一塊兒通過測試？

◇ 是否設置了源碼不可見？

◇ 不一樣瀏覽器上的網站內容是否均可打印？

◇ 是否影響總體的內容大小（可靠性、一致性）？

◇ 是否驗證過應用程序與框架是否兼容？

◇ 鼠標和鍵盤是否經測試適用於不一樣的瀏覽器？

◇ 是否執行過智能錯誤處理（如：cookie 不可用）？

◇ 128 位編碼是否經驗證可用？

◇ 在不一樣瀏覽器上 GIF 是否經測試可用？

Cookies

◇ cookie 儲存的信息是否通過驗證？

◇ cookie 信息是否通過加密？

◇ cookie 信息是否適量增長？

◇ 是否阻止用戶編輯 cookie？

◇ 是否檢查過若是用戶瀏覽網站期間刪除 cookie，會發生什麼？

◇ 是否檢查過若是用戶關閉網站後刪除 cookie，會發生什麼？

◇ cookie 儲存的路徑是否正確？

◇ cookie 的信息是否正確有效，用戶是否能夠使用該信息鏈接網站？

登錄/併發使用

◇ 系統是否達到預期的響應時間、流量以及實用價值？

◇ 系統是否能夠承受極限用戶量的訪問？

◇ 系統是否能夠長期無端障地正確運行？

◇ 是否監視過 CPU 的使用、響應時間、硬盤空間、內存用量及泄露？

◇ 是否認義標準響應時間（如：全部的頁面的顯示時間應小於 10 秒）？

◇ 是否驗證防火牆、證書、服務提供商以及能夠網絡的影響？

◇ 不一樣速度的調制解調器上網頁的登錄性能是否可接受？

◇ 同一用戶是否能夠長時間連續使用網站？

◇ 多個用戶是否能夠長時間連續使用網站？

◇ 在高流量的狀況下，網站是否能支持短期的使用？

◇ 網站是否能夠維持大量數據的處理，而不崩潰？

◇ 若是事務是無效的，網站是否仍容許大訂單，而不會死鎖目錄？

錯誤處理

◇ 是否創建自動錯誤監察恢復機制，以保持系統運行？

◇ 若是系統崩潰，重啓和恢復機制是否有效可靠？

◇ 若是半途斷開網站，事務是否隨之取消？

◇ 若是網絡突然中斷，事務是否隨之取消？

◇ 反饋結果是否處理文件傳輸的中斷？

◇ 反饋結果是否處理瀏覽器崩潰？

◇ 當網站和應用服務器鏈接中斷時，反饋結果是否處理？

◇ 反饋結果是否處理數據庫服務器中斷連接的狀況？

◇ 應用程序是否通報用戶事務的狀態？

◇ 網站是否包含 24 x 7 性能監控？

◇ 監控軟件 MAPI 的電子郵件協議/限制

◇ 網站是否能夠連接到頁面系統？

◇ 時間 - 連續、每時、天天、每週

◇ 硬件限制 - 監視軟件是否必須運行在專用機器上？

◇ 內存 - 泄露、隱藏、持續運行致使的問題

網絡影響

◇ 是否考慮過 32 位和 64 位版本的 IP 問題？

◇ 是否測試過安全代理服務器的影響？

安全

◇ 是否足夠安全？

◇ 是否機密/用戶私密保護？

◇ 是否只有使用 128 位瀏覽器才能成功連接？

◇ 網站是否提示用戶姓名和密碼？

◇ 網站是否須要孩童輸入我的信息？若是須要，是否在安全頁面進行，且警示其家長？

◇ 服務器和客戶端是否都有數字證書？

◇ 是否驗證密碼開始和結束的地方？

◇ 是否容許同時註銷？

◇ 應用程序是否支持因靜止而致使超時？

◇ 安全頁面內書籤是否不能使用？

◇ 在非安全/安全頁面的狀態欄上是否有顯示鑰匙/鎖？

◇ 右擊、查看、源文件是否不可用？

◇ 是否不能在 URL 上經過編輯內容而進行直接搜索？

◇ 若是使用數字證書，請經過註冊證書、按規定填寫安全信息測試瀏覽器緩存。安裝證書後，試着使用回車鍵，看安全信息是否仍保存在緩存中。若是仍舊存在，那任何使用者均可能有機會獲取這些高敏感的數字證書中的安全信息。

◇ 因爲 SSL 和低於 3.0 版本的瀏覽器不兼容，是否有第二種方法能夠鏈接到安全頁面？

◇ 用戶是否清楚什麼時候進入、什麼時候離開網站的安所有分？

◇ 當用戶屢次使用無效登錄名/密碼信息登錄失敗時，服務器是否會拒絕該用戶再次嘗試連接？

GUI測試之窗口篇

窗口是Windows自己以及Windows 環境下的應用程序的基本界面單位，就是顯示在屏幕上的一個矩形區域。通常來講窗口是具備標題欄、菜單/菜單欄、工具欄、工做區、狀態欄、最大化、最小化按鈕和滾動條的標準方框，應用程序經過它和用戶進行交互。可是若是沒有標題欄、狀態欄、最大化、最小化按鈕是否是就不叫窗口呢。其實否則，窗口的概念很廣，例如按鈕和對話框等也是窗口，只不過是一種特殊的窗口罷了。這裏我主要將的仍是標準意義上的窗口。

窗口主要有進入、移動、改變窗口大小；最大化、最小化和還原；使用滾動條和關閉窗口等操做。

所以能夠經過以下來測試窗口：

大多數的窗口、屏幕/對話框應該有最小化，恢復和關閉按鈕。

全部的窗口、屏幕/對話框應該有和內容相一致對應的標題。

只有主窗口才有標題欄圖標、菜單欄、工具欄和狀態欄。二級窗口不要使用菜單欄、工具欄或狀態欄。

每個窗口/屏幕都應有功能匹配的OK和Cancel按鈕。窗口/對話框的缺省<Enter>鍵應該設置在OK按鈕上；窗口/對話框的缺省<Esc>鍵應該設置在Cancel按鈕上。

a.Escape鍵取消對話框，焦點從新定位回到父窗口先前的焦點上，
b.Alt＋F4關閉窗口，和Escape鍵類似，但它能夠在即便沒有Cancel按鈕的對話框中工做

c.Alt＋Space打開窗口的菜單Restore, Move, Size, Minimize, Maximize, Close
d.Shift＋F10和右擊效果同樣。
e.能夠用鍵盤上的箭頭按鈕實現Move和Size功能

一個窗口每一個組件的訪問鍵必須是惟一的。

父窗體或主窗體的中心位置應該在對角線焦點附近;子窗體位置應該在主窗體的左上角或正中;多個子窗體彈出時應該依次向右下方偏移，以顯示窗體出標題爲宜。

二級窗口最好不要顯示在任務欄中，由於單擊主窗口的任務欄按鈕也會激活二級窗口。

若是子窗體的任何操做會影響了父窗體的數據時，關閉子窗體同時必須刷新父窗體的數據。

關閉父窗體時必須關閉全部打開的子窗體。若是因爲子窗口沒有關閉而沒法關閉父窗口，必須給予提示信息框。在關閉提示信息框後顯示必須關閉的子窗口。

子窗體的大小最好不要超過父窗體，且最好不要遮住父窗體的主要信息。若是存在多層嵌套窗口，每層窗口彈出時都自動往右下移動一點點，以保證不遮蓋上層窗口標題爲準。

窗口嵌套層次最好不超過3層。

點擊窗口中的幫助按鈕或F1必須帶出和窗口內容相一致的幫助。

窗口能夠被屢次打開和關閉。但窗口未關閉或被其餘窗口覆蓋時，再次點擊菜單或按鈕，測試窗口是否能夠被激活。

若是窗體能夠最小化，最大化或可調整大小時，窗體上的控件也要隨着窗體而縮放；對於含有按鈕的界面通常不該該支持縮放，即右上角只有關閉功能。

工具欄按鈕應該有浮動的提示，能夠根據用戶的要求本身選擇定製；:相同或相近功能的工具欄放在一塊兒；:一條工具欄的長度最長不能超出屏幕寬度；工具欄的圖標能直觀的表明要完成的操做；系統經常使用的工具欄設置默認放置位置；:工具欄太多時能夠考慮使用工具廂；:工具廂要具備可增減性，由用戶本身根據需求定製。:工具廂的默認總寬度不要超過屏幕寬度的1/5

狀態條要能顯示用戶切實須要的信息，經常使用的有：目前的操做、系統狀態、用戶位置、用戶信息、提示信息、錯誤信息等，若是某一操做須要的時間較長，還應該顯示進度條和進程提示。狀態條的高度以放置五好字爲宜，滾動條的寬度比狀態條的略窄。

菜單和工具條應有清楚的界限，菜單和狀態欄中使用統一大小的字體（一般使用5號字體）

菜單應採用「經常使用--主要--次要--工具--幫助」的位置排列。提供經常使用的菜單項，如「文件」、「編輯」，「查找」，「打印」等。對經常使用的菜單項提供快捷命令方式。快捷方式惟一。

主菜單數目不太多時最好爲單排佈置。若是菜單選項較多，應該採用加長菜單的長度而減小深度的原則排列。菜單深度通常要求最多控制在三層之內。

下拉菜單要根據菜單選項的含義進行分組，並且按照必定的規則進行排列，用橫線隔開。一組菜單的使用有前後要求或有嚮導做用時，應該按前後次序排列。沒有順序要求的菜單項按使用頻率和重要性排列，經常使用的放在開頭，不經常使用的靠後放置；重要的放在開頭，次要的放在後邊。對與進行的操做無關的菜單要用屏蔽的方式加以處理，若是採用動態加載方式——即只有須要的菜單才顯示——最好。

菜單前的圖標不宜太大，與字高保持一直最好。主菜單的寬度要接近，字數不該多於四個，每一個菜單的字數能相同最好。

狀態欄中的信息應該根據窗口的內容的變化而變化，如在初始狀態時，系統有多少條數據，通過查詢後狀態欄的數據應該發生變化。

滾動條的長度根據顯示信息的長度或寬度及時變換，這樣有利於用戶瞭解顯示信息的位置和百分比；拖動滾動條，檢查屏幕刷新狀況，並查看是否有亂碼；單擊滾動條和滾動條的上下按鈕；用滾輪控制滾動條；

若是系統的模塊較多，較深，常常會多級菜單，最好在窗口上加上導航條，以方便用戶能夠快速返回

GUI測試之信息處理類篇

在這篇文章中，我將文本框（Text Box），列表框（List Box），組合框（Combo Box）、下拉列表框（Drop-down List Box），複選框（Check Box），單選框（Radio box）/（option box），選項框（Option box）、滑動條（Slider）、旋轉按鈕（Spin Button）等都做爲信息處理類來統一總結。

窗口/屏幕上的每個字段都應有相應的標籤。

根據文本框能夠接受的類型測試文本框：

1）輸入正常的字母或數字

2）輸入已存在的信息

（當某個字段不能重複的時候，輸入已存在的信息，看保存是否會提示，好比註冊用戶的時候，要求用戶名不可重複：先註冊一個用戶，保存成功（肯定數據庫中已保存該條數據），再註冊一個用戶，輸入一樣的用戶名，保存是否會提示：該用戶名已被使用等。）

3）輸入超過容許長度的字符或邊界數字

4）輸入空白，空格，（輸入其餘特殊字符如：#@￥%&*等）

5）輸入不一樣類型或不一樣日期格式的數據，

6）複製/粘貼等操做強制輸入程序不容許的輸入數據

7）輸入數據庫或特殊字符集，例如NULL及\n等

測試文件選擇框的正確性。使用空文件，只有空格的文件，不一樣類型的文件，同名文件，內容相同名稱不一樣的文件，大文件等。

測試強制性字段的正確性（即必輸項測試），強制性字段必須用紅色的星號*標識。強制性字段兩種處理方式：最好是必填項沒有輸入時，在光標移走時在相應的文本框後顯示須要用戶輸入的紅色信息。通常也能夠在提交時用彈出消息框提示未填的必填項，關閉消息框後必須停留在第一個待輸入的文本框中。

每個新窗口/屏幕中，光標默認停留在第一個待輸入的文本框中。

通常下拉框中應顯示一個默認值，列表框中高亮度顯示一個默認值。若是不須要默認值時，通常默認值未「請選擇。。。」。

通常來講系統應記憶之前輸入或選擇的信息，可是當涉及安全時，最好不要保留用戶的信息。有些地方能夠使用複選框讓用戶決定是否要保留信息。如登陸界面。

對輸入信息類型有限制的文本框應在輸入非法值後給予提示，對於日期型的輸入框，最好在標籤上就給予提示

當輸入的內容達到了字段的長度限制時，通常應控制不容許再輸入，或者在提交後提示具體的容許輸入的長度或者在光標轉移時提示‘***容許輸入的最大長度是***’等，而不是自動截斷。（農信社資金業務管理系統目前採起右截斷的處理方式，所以有問題）

系統中不容許的非法字符，最好是在輸入時不容許輸入，或在提交時給予具體系統不容許的非法字符列表提示。（如’、」、<、<>）

正確使用複選框或單選框。若是結果只有一個的，則使用單選框，如性別。驗證單選按鈕不能同時選中只能選中一個，而能夠選擇多個複選框。

一組單選按鈕在初始狀態時必須有一個被默認選中，不能同時爲空。

分別測試多個複選框能夠被逐一選中；同時選中，部分選中；都不被選中。

經過輸入數字或用點擊上下箭頭來測試旋轉按鈕,測試其自動循環性，如範圍爲（0～999）先輸入爲999，在點擊向下鍵，看是否會跳到0。輸入字符或超過邊界的數值，系統應該提示錯誤且從新輸入；

驗證列表框中的條目內容顯示正確；容許多選的列表框，要分別檢查shift和ctrl選中條目狀況

避免使用水平滾動條，由於它會使項目閱讀起來比較困難。解決的辦法有：儘可能使用垂直滾動條、加寬窗口、減少文本的寬度，或者使文本自動換行等。固然，若是確實須要，還能夠使用水平滾動條。

全選框勾中時應該選中當頁全部記錄，去掉當頁某個記錄的勾選，則全選也不選中。翻頁後，自動去掉已勾選的記錄及全選的勾選。

複選框能夠經過Space能夠控制選中/不選中

F4, Alt+down或alt+up控制combobox打開和關閉

對於combobox，Escape鍵等同於Cancel，Up/down箭頭按鈕控制向上或向下，Shift+up和shift+down能夠多選，Ctrl實現多選

GUI測試之按鈕篇

在同一窗口中實現某一功能的按鈕是惟一的。

按鈕位置：OK按鈕老是在上方或者左方,而Cancel按鈕老是在下方或右方。

等價鍵：Cancel按鈕的等價按鍵一般是Esc,而選中按鈕的等價按鈕一般是Enter保持一致。

測試按鈕可否正常的實現功能，經常使用按鈕的功能爲：

OK（肯定）接受輸入的數據或顯示的響應信息，關掉窗口

Cancel（取消）不接受輸入的信息，關掉窗口。取消時最好給予提示，尤爲時有大量輸入的窗口。

Close（關閉）：結束當前的任務，讓程序繼續進行；關掉數據窗口

Help（幫助）：調出程序的幫助信息

Save（保存）：保存數據，停留在當前窗口。如過保存耗時長的話，最好顯示相似沙漏，進度條之類的提示。注意驗證可否重複保存。如在IE中因爲網速慢而致使的重複保存。

Add（新增）：新增記錄。新增的記錄必須排在首頁首行。提交失敗後必須保留用戶已輸入的內容，以便再次提交。提交時需對主要標識字段進行重複值、空值（空格）判斷。

Update/Edit（編輯）：修改/編輯記錄。如界面存在複選按鈕，勾選多條記錄進行修改時，需給予只能對一條記錄進行修改，默認爲第一條的提示信息。修改時加載的內容都爲該記錄的實際內容，而再也不爲默認值。修改完成後必須回到原記錄所在位置，且刷新顯示修改後的值。提交失敗後必須保留用戶已修改的內容，以便再次提交。在查詢條件下修改返回後如不知足查詢條件則不顯示，反之知足當前的查詢條件則需顯示新增的記錄。需對主要標識字段進行重複值、空值（空格）判斷。

Delete（刪除）：刪除記錄。在刪除以前必須有確認刪除的提示信息。刪除成功後刷新不顯示被刪除的記錄。刪除成功後返回到原記錄所在頁面；而當原記錄所在頁不存在時，則返回上一頁。當被刪除的記錄與其它記錄存在關聯時，應給予不容許刪除及更明細提示等信息。針對大批量的刪除應提供全選複選框，方便用戶刪除。

Search（查詢）：查詢記錄。每次查詢應顯示返回的結果數。每次查詢應定位到首頁（當查詢結果有多頁時，應定位到首頁）。保留前一次的查詢條件。當查詢條件較多時，需配以重置按鈕。當未查詢到任何記錄時，需給予未查找到相關記錄的提示信息。除用戶明確要求不須要外，需提供模糊查詢及組合查詢功能。當查詢返回的結果大於默認的一頁大小時，最好採用分頁或者根據系統默認或用戶定義的一頁顯示的記錄數量來分頁。若有多頁，須要提供首頁，下一頁，上一頁，尾頁和跳至功能。每頁的記錄不能重複，但也能夠根據用戶須要顯示上一頁的最後一條數據。

Reset（重置）：重置。應回到打開窗口時的最初狀態。屢次點擊是否還能正常顯示。

Return（返回）：返回。若是一個窗口或頁面不能經過菜單，工具欄到達，而是必須經過前一個窗口完成纔到達，應提供返回按鈕或導航條讓用戶能夠返回。

若是點擊按鈕後還須要用戶的進一步的操做，按鈕的名稱應加上省略號。如Browse。。。

OK/Cancel/Apply/Help鍵的排放最好聽從Windows的標準排放。

按鈕最好都給予浮動提示（什麼是浮動提示），特別是圖片按鈕，能夠避免因爲網絡太慢而致使的太長時間不能往下操做。

GUI測試之對話框、消息框篇

對話框/消息框的缺省<Enter>鍵應該設置在OK按鈕上；對話框/消息框的缺省<Esc>鍵應該設置在Cancel按鈕上。

通常來講重要的或複雜操做成功後應該給予提示，根據系統的特性選擇彈出信息框或文字顯示。須要後續操做的操做在成功後應給予提示。

非法的輸入或操做應給出足夠的提示說明。

對可能形成數據沒法恢復的操做應該給予確認信息，給用戶放棄選擇的機會。如刪除操做。

提示信息不宜太長，寬度不能超過當前窗口的1/2；當超過此比例時，請視具體狀況進行換行。有多行提示信息的，請選擇對齊方式（通常爲左對齊）。

靜態文本標籤通常採用左對齊，這樣顯得更有條理且易於瀏覽。靜態文本標籤通常置於相關控件的左邊，有時選項過多過長時放在上面。

複雜或帶有專業性的操做或輸入最好在輸入項下面給予提示。

通用對話框控件，如Open…，Save As…，Color…，Fonts…，Print…，Page SetUp…等調用系統的對話框只須要是否調用正確，可否實現正常功能就能夠了，裏面的具體功能能夠不用測試。

消息框中的圖標必須根據須要選擇正確的使用，通常來講 X 表示有很重要的問題須要提醒用戶；? 增亮沒有危險的問題； ! 強調警告用戶必須知道的事情； i 通常信息，能夠使乏味的信息變得有趣。

正在進行的操做提示框應使用省略號，如「刪除中。。。」。

對話框標題文本中不要出現省略號。如選擇"打印選項..."命令結果而顯示的對話框的標題應該爲"打印"，而不是「打印。。。」。可是，表示命令正在執行過程當中菜單對話框（如"鏈接到Internet..."對話框）是一種例外狀況。

對於耗時的操做都應給出相似等待光標、進度表或其餘的可視反饋。用戶能夠取消長時間的操做。若是能夠取消未完成的操做，那麼將按鈕標記爲"取消"，不然將按鈕標記爲"中止"。

網站測試的主要方面

1功能測試

對於網站的測試而言，每個獨立的功能模塊須要單獨的測試用例的設計導出，主要依據爲《需求規格說明書》及《詳細設計說明書》，對於應用程序模塊須要設計者提供基本路徑測試法的測試用例。

● 連接測試

連接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。連接測試可分爲三個方面：

1）測試全部連接是否按指示的那樣確實連接到了該連接的頁面；

2）測試所連接的頁面是否存在；

3）保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連接指向該頁面，只有知道正確的URL地址才能訪問。

連接測試能夠自動進行，如今已經有許多工具能夠採用。連接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的全部頁面開發完成以後進行連接測試。

Xenu------主要測試連接的正確性的工具

惋惜的是對於動態生成的頁面的測試會出現一些錯誤。

●表單測試

當用戶給Web應用系統管理員提交信息時，就須要使用表單操做，例如用戶註冊、登錄、信息提交等。在這種狀況下，咱們必須測試提交操做的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。若是使用了默認值，還要檢驗默認值的正確性。若是表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時能夠跳過這些字符，看系統是否會報錯。

要測試這些程序，須要驗證服務器能正確保存這些數據，並且後臺運行的程序能正確解釋和使用這些信息。

B/S結構實現的功能可能主要的就在這裏，提交數據，處理數據等若是有固定的操做流程能夠考慮自動化測試工具的錄製功能，編寫可重複使用的腳本代碼，能夠在測試、迴歸測試時運行以便減輕測試人員工做量。

●Cookies測試

Cookies一般用來存儲用戶信息和用戶在某應用系統的操做，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來建立動態和自定義頁面或者存儲登錄等信息。

若是Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工做並且對這些信息已經加密。測試的內容可包括Cookies是否起做用，是否按預約的時間進行保存，刷新對Cookies有什麼影響等。

●設計語言測試

Web設計語言版本的差別能夠引發客戶端或服務器端嚴重的問題，例如使用哪一種版本的HTML等。當在分佈式環境中開發時，開發人員都不在一塊兒，這個問題就顯得尤其重要。除了HTML的版本問題外，不一樣的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。

●數據庫測試

在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最經常使用的數據庫類型是關係型數據庫，能夠使用SQL對信息進行處理。

在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。

2性能測試

網站的性能測試對於網站的運行而言異常重要，可是目前對於網站的性能測試作的不夠，咱們在進行系統設計時也沒有一個很好的基準能夠參考，於是創建網站的性能測試的一整套的測試方案將是相當重要的。

網站的性能測試主要從三個方面進行：鏈接速度測試、負荷測試（Load）和壓力測試（Stress）.鏈接速度測試指的是打開網頁的響應速度測試。負荷測試指的是進行一些邊界數據的測試，壓力測試更像是惡意測試，壓力測試傾向應該是導致整個系統崩潰。

●鏈接速度測試

用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。

另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。

●負載測試

負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工做。負載級別能夠是某個時刻同時訪問Web系統的用戶數量，也能夠是在線數據處理的數量。例如：Web應用系統能容許多少個用戶同時在線？若是超過了這個數量，會出現什麼現象？Web應用系統可否處理大量用戶對同一個頁面的請求？

●壓力測試

負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。

進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。黑客經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存取權。

壓力測試的區域包括表單、登錄和其餘信息傳輸頁面等。

採用的測試工具：

性能測試能夠採用相應的工具進行自動化測試，咱們目前採用以下工具

ab -----Apache 的測試工具

OpenSTA—開發系統測試架構

3 接口測試

在不少狀況下，web 站點不是孤立。Web 站點可能會與外部服務器通信，請求數據、驗證數據或提交訂單。

●服務器接口

第一個須要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，而後查看服務器記錄，並驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還能夠查詢數據庫，確認事務數據已正確保存。

●外部接口

有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減小欺詐行爲的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。若是商店只使用 Visa 卡和 Mastercard 卡，能夠嘗試使用 Discover 卡的數據。（簡單的客戶端腳本可以在提交事務以前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 表明Discover。）一般，測試人員須要確認軟件可以處理外部服務器返回的全部可能的消息。

●錯誤處理

最容易被測試人員忽略的地方是接口錯誤處理。一般咱們試圖確認系統可以處理全部錯誤，但卻沒法預期系統全部可能的錯誤。嘗試在處理過程當中中斷事務，看看會發生什麼狀況？訂單是否完成？嘗試中斷用戶到服務器的網絡鏈接。嘗試中斷 web 服務器到信用卡驗證服務器的鏈接。在這些狀況下，系統可否正確處理這些錯誤？是否已對信用卡進行收費？若是用戶本身中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，須要由客戶表明致電用戶進行訂單確認。

6 安全測試

Web應用系統的安全性測試區域主要有：

●目錄設置

Web 安全的第一步就是正確設置目錄。每一個目錄下應該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的全部內容。若是沒有執行這條規則。那麼選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑「…com/objects/images」。而後在瀏覽器地址欄中手工輸入該路徑，發現該站點全部圖片的列表。這可能沒什麼關係。可是進入下一級目錄「…com/objects」，點擊 jackpot。在該目錄下有不少資料，其中有些都是已過時頁面。若是該公司每月都要更改產品價格信息，而且保存過時頁面。那麼只要翻看了一下這些記錄，就能夠估計他們的邊際利潤以及他們爲了爭取一個合同還有多大的降價空間。若是某個客戶在談判以前查看了這些信息，他們在談判桌上確定處於上風。

●登陸

如今的Web應用系統基本採用先註冊，後登錄的方式。所以，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，能夠試多少次的限制，是否能夠不登錄而直接瀏覽某個頁面等。

●Session

Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內（例如15分鐘）沒有點擊任何頁面，是否須要從新登錄才能正常使用。

●日誌文件

爲了保證Web應用系統的安全性，日誌文件是相當重要的。須要測試相關信息是否寫進了日誌文件、是否可追蹤。

●加密

當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

●安全漏洞

服務器端的腳本經常構成安全漏洞，這些漏洞又經常被黑客利用。因此，還要測試沒有通過受權，就不能在服務器端放置和編輯腳本的問題。

目前網絡安全問題日益重要，特別對於有交互信息的網站及進行電子商務活動的網站尤爲重要。目前咱們的測試沒有涵蓋網站的安全性的測試，咱們擬定採用工具來測定。

工具以下