一些經常使用模塊的測試用例

一些經常使用模塊的測試用例

 

一、登陸　　二、添加　　三、查詢　　四、刪除

一、登陸

①用戶名和密碼都符合要求（格式上的要求）

②用戶名和密碼都不符合要求（格式上的要求）

③用戶名符合要求，密碼不符合要求（格式上的要求）

④密碼符合要求，用戶名不符合要求（格式上的要求）

⑤用戶名或密碼爲空

⑥數據庫中不存在的用戶名，不存在的密碼

⑦數據庫中存在的用戶名，錯誤的密碼

⑧數據庫中不存在的用戶名，存在的密碼

⑨輸入的數據前存在空格

⑩輸入正確的用戶名密碼

之後按[enter]是否能登錄

二、添加

①要添加的數據項均合理，在界面保存成功後，檢查數據庫中是否添加了相應的數據：select查詢

②留出一個必填數據爲空

③按照邊界值等價類設計測試用例的原則設計其餘輸入項的測試用例：數據組合測試

④不符合要求的地方要有錯誤提示

⑤是否支持table鍵

⑥按enter是否能保存

⑦若提示不能保存，也要察看數據庫裏是否多了一條數據

三、刪除

①刪除一個數據庫中存在的數據，而後查看數據庫中是否刪除（界面刪除一條數據，查看數據庫中是否刪除）

②刪除一個數據庫中並不存在的數據，看是否有錯誤提示，而且數據庫中沒有數據被刪除

③輸入一個格式錯誤的數據，看是否有錯誤提示，而且數據庫中沒有數據被刪除。

④輸入的正確數據前加空格，看是否能正確刪除數據

⑤什麼也不輸入

⑥是否支持table鍵：tab鍵

⑦是否支持enter鍵

四、查詢

精確查詢：

①輸入的查詢條件爲數據庫中存在的數據，看是否能正確地查出相應得數據

②輸入正確的查詢條件之前加上空格，看是否能正確地查出相應的數據

③輸入格式或範圍不符合要求的數據，看是否有錯誤提示：如日期格式：YYYY-MM-DD；範圍：月份中輸入13等，通常這些數據都是枚舉型數據，如下拉框的形式出現

④輸入數據庫中不存在的數據

⑤不輸入任何數據：查詢結果應該爲全部記錄

⑥是否支持table鍵

⑦是否支持enter鍵

模糊查詢：

在精確查詢的基礎上加上如下一點：

① 輸入一些字符，看是否能查出數據庫中全部的相關信息

 

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

 

1．輸入非法數據

輸入數據的類型、長度、邊界值；還要留意錯誤信息自己。

基本數據類型的邊界值

2．輸入默認值

從選項按鈕、配置面板等處去考察。

3．輸入特殊字符集

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

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

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

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

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

5．輸入產生錯誤的合法數據組合

在輸入值之間存在依賴關係時，輸入可能會出現問題的組合值。

6．產生同一個輸入的各類可能輸出

在同一輸入對應多個輸出時可用此法測試。

7．輸出不符合業務規則的無效輸出

列出全部的無效輸出，而後逐一測試，重點查看輸出結果的正確性。

8．輸出屬性修改後的結果

強制每一個輸出產生，並編輯其屬性，而後再次強制產生輸出。

9．屏幕刷新顯示

增長、刪除、移動屏幕上的對象。

10．數據結構溢出

嘗試將過多的值輸入數據結構，測試上溢；嘗試多刪除一個數據，測試下溢。

11．數據結構不符合約束

任什麼時候候都要對數據屬性的約束進行檢查，特別注意修改數據時也要進行。

可經過破壞內部數據的約束來進行測試。

12．操做數與操做符不符合

對於數值計算考慮操做數和操做符之間的限定關係；對於圖形計算還要考慮各類輸入數據之間的組合關係。

13．遞歸調用自身

考慮對象的自我交互或複製。

14．計算結果溢出

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

15．數據共享或關聯功能計算出錯

當一個以上的功能在同一時間處於運行狀態，能夠考慮以點帶面，重點測試某一功能，對可能與這個功能相連的其餘功能附帶測試。

16．文件系統超載

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

17．介質忙或不可用

軟件運行須要消耗大量內存或須要其餘相關軟件同時運行，可經過啓動大量程序或利用測試工具模擬磁盤情況。

18．介質損壞

用實際損壞介質的方法來測試應用程序。

19．文件名不合法

輸入OS不容許的文件名和應用程序不容許的文件名。

20．更改文件訪問權限

修改文件訪問權限或用低權限的用戶訪問文件。

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. 對於範圍的查詢採用全閉的形式。

 

輸入數據的設計方法和測試用例設計方法

測試用例的設計是測試設計的重要內容，關於測試用例的設計方法，當前很多出版的測試書和發表的測試文章，很多存在着表述錯誤，主要是把測試用例中的輸入數據的設計方法與測試用例的設計方法混爲一談，對測試初學者和測試用例設計人員產生誤導。

這種錯誤的主要表現舉例以下：

測試用例的設計方法包括：

(1)等價類劃分法

(2)邊界值法

(3)功能圖與斷定表法

(4)錯誤推測法

(5)用戶場景法

(6)......

其實，測試用例中輸入數據的設計方法只是測試用例設計方法的一個子集，上面列出的集中方法都是肯定黑盒測試用例的輸入測試數據的通常方法，而不是測試用例的設計方法。

除了肯定輸入數據以外，測試用例的設計還包括如何肯定測試用例的設計策略，如何組織設計用例，如何從測試需求等文檔建立完整的測試用例。

對測試執行人員來講，測試用例的表示內容包括如下幾個方面：

(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.定義：是一種利用圖解法分析輸入的各類組合狀況，從而設計測試用例的方法，它適合於檢查程序輸入條件的各類組合狀況。

2.因果圖法產生的背景：

等價類劃分法和邊界值分析方法都是着重考慮輸入條件，但沒有考慮輸入條件的各類組合、輸入條件之間的相互制約關係。這樣雖然各類輸入條件可能出錯的狀況已經測試到了，但多個輸入條件組合起來可能出錯的狀況卻被忽視了。

若是在測試時必須考慮輸入條件的各類組合，則可能的組合數目將是天文數字，所以必須考慮採用一種適合於描述多種條件的組合、相應產生多個動做的形式來進行測試用例的設計，這就須要利用因果圖（邏輯模型）。

3.因果圖介紹

1) 4種符號分別表示了規格說明中向4種因果關係。

2) 因果圖中使用了簡單的邏輯符號，以直線聯接左右結點。左結點表示輸入狀態（或稱緣由），右結點表示輸出狀態（或稱結果）。

3) Ci表示緣由，一般置於圖的左部；ei表示結果，一般在圖的右部。Ci和ei都可取值0或1，0表示某狀態不出現，1表示某狀態出現。

4. 因果圖概念

1) 關係

① 恆等：若ci是1，則ei也是1；不然ei爲0。

② 非：若ci是1，則ei是0；不然ei是1。

③ 或：若c1或c2或c3是1，則ei是1；不然ei爲0。「或」可有任意個輸入。

④ 與：若c1和c2都是1，則ei爲1；不然ei爲0。「與」也可有任意個輸入。

2) 約束

輸入狀態相互之間還可能存在某些依賴關係，稱爲約束。例如, 某些輸入條件自己不可能同時出現。輸出狀態之間也每每存在約束。在因果圖中,用特定的符號標明這些約束。

A.輸入條件的約束有如下4類：

① E約束（異）：a和b中至多有一個可能爲1，即a和b不能同時爲1。

② I約束（或）：a、b和c中至少有一個必須是1，即 a、b 和c不能同時爲0。

③ O約束（惟一）；a和b必須有一個，且僅有1個爲1。

④ R約束（要求）：a是1時，b必須是1，即不可能a是1時b是0。

B.輸出條件約束類型

輸出條件的約束只有M約束（強制）：若結果a是1，則結果b強制爲0。

5. 採用因果圖法設計測試用例的步驟：

1) 分析軟件規格說明描述中, 那些是緣由(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每一個緣由和結果賦予一個標識符。

2) 分析軟件規格說明描述中的語義，找出緣由與結果之間, 緣由與緣由之間對應的關係，根據這些關係,畫出因果圖。

3) 因爲語法或環境限制, 有些緣由與緣由之間,緣由與結果之間的組合狀況不可能出現，爲代表這些特殊狀況, 在因果圖上用一些記號代表約束或限制條件。

4) 把因果圖轉換爲斷定表。

5) 把斷定表的每一列拿出來做爲依據,設計測試用例。

 

網站測試的主要方面

1功能測試

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

● 連接測試

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

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

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

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

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

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

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

●表單測試

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

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

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

咱們對UM子系統中各個功能模塊中的各項功能進行逐一的測試，主要測試方法爲：邊界值測試、等價類測試，以及異常類測試。測試中要保證每種類型都有2個以上的典型數值的輸入，以確保測試輸入的全面性。

●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 服務器到信用卡驗證服務器的鏈接。在這些狀況下，系統可否正確處理這些錯誤？是否已對信用卡進行收費？若是用戶本身中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，須要由客戶表明致電用戶進行訂單確認。

4 可用性測試

可用性/易用性方面目前咱們只能採用手工測試的方法進行評判，並且缺少一個很好的評判基準進行，此一方面須要你們共同討論。

●導航測試

導航描述了用戶在一個頁面內操做的方式，在不一樣的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間。經過考慮下列問題，能夠決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可經過主頁存取？Web系統是否須要站點地圖、搜索引擎或其餘的導航幫助？

在一個頁面上放太多的信息每每起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有知足本身須要的信息，若是沒有，就會很快地離開。不多有用戶願意花時間去熟悉Web應用系統的結構，所以，Web應用系統導航幫助要儘量地準確。

導航的另外一個重要方面是Web應用系統的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。

Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。

●圖形測試

在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的做用，又能起到美化頁面的功能。一個Web應用系統的圖形能夠包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：

（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一塊兒，以避免浪費傳輸時間。Web應用系統的圖片尺寸要儘可能地小，而且要能清楚地說明某件事情，通常都連接到某個具體的頁面。

（2）驗證全部頁面字體的風格是否一致。

（3）背景顏色應該與字體顏色和前景顏色相搭配。

（4）圖片的大小和質量也是一個很重要的因素，通常採用JPG或GIF壓縮。

●內容測試

內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。

信息的正確性是指信息是可靠的仍是誤傳的。例如，在商品價格列表中，錯誤的價格可能引發財政問題甚至致使法律糾紛；信息的準確性是指是否有語法或拼寫錯誤。這種測試一般使用一些文字處理軟件來進行，例如使用Microsoft Word的「拼音與語法檢查」功能；信息的相關性是指是否在當前頁面能夠找到與當前瀏覽信息相關的信息列表或入口，也就是通常Web站點中的所謂「相關文章列表」。

●總體界面測試

總體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個總體感。例如：當用戶瀏覽Web應用系統時是否感到溫馨，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？

對總體界面的測試過程，實際上是一個對最終用戶進行調查的過程。通常Web應用系統採起在主頁上作一個調查問卷的形式，來獲得最終用戶的反饋信息。

對全部的可用性測試來講，都須要有外部人員（與Web應用系統開發沒有聯繫或聯繫不多的人員）的參與，最好是最終用戶的參與。

5 兼容性測試

須要驗證應用程序能夠在用戶使用的機器上運行。若是您用戶是全球範圍的，須要測試各類操做系統、瀏覽器、視頻設置和 modem 速度。最後，還要嘗試各類設置的組合。

●平臺測試

市場上有不少不一樣的操做系統類型，最多見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪種操做系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操做系統下能正常運行，但在另外的操做系統下可能會運行失敗。

所以，在Web系統發佈以前，須要在各類操做系統下對Web系統進行兼容性測試。

●瀏覽器測試

瀏覽器是Web客戶端最核心的構件，來自不一樣廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不一樣的HTML規格有不一樣的支持。例如，ActiveX是Microsoft的產品，是爲Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不一樣的瀏覽器中也有不一樣的顯示，甚至根本不顯示。不一樣的瀏覽器對安全性和Java的設置也不同。

測試瀏覽器兼容性的一個方法是建立一個兼容性矩陣。在這個矩陣中，測試不一樣廠商、不一樣版本的瀏覽器對某些構件和設置的適應性。

採用測試工具：

經過白盒測試或者黑盒測試導出的測試用例，採用相應的工具進行測試，能夠採用OpenSTA進行測試，此測試工具能夠採用不一樣的瀏覽器進行測試。

●視頻測試

頁面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否顯示正常? 字體是否過小以致於沒法瀏覽? 或者是太大? 文本和圖片是否對齊?

●Modem/鏈接速率測試

是否有這種狀況，用戶使用 28.8 modem下載一個頁面須要 10 分鐘，但測試人員在測試的時候使用的是 T1 專線? 用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。最後，須要確認圖片不會太大。

●打印機測試

用戶可能會將網頁打印下來。所以網頁在設計的時候要考慮到打印問題，注意節約紙張和油墨。有很多用戶喜歡閱讀而不是盯着屏幕，所以須要驗證網頁打印是否正常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不同。測試人員至少須要驗證訂單確認頁面打印是正常的。

●組合測試

最後須要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，可是在 IBM 兼容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻沒法使用 Lynx 來瀏覽。若是是內部使用的 web 站點，測試可能會輕鬆一些。若是公司指定使用某個類型的瀏覽器，那麼只需在該瀏覽器上進行測試。若是全部的人都使用 T1 專線，可能不須要測試下載施加。（但須要注意的是，可能會有員工從家裏撥號進入系統） 有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。可是，理想的狀況是，系統能在全部機器上運行，這樣就不會限制未來的發展和變更。

6 安全測試

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

●目錄設置

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

●登陸

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

●Session

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

●日誌文件

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

●加密

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

●安全漏洞

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

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

工具以下

SAINT------- Security Administrator’s Integrated Network Tool

此工具可以測出網站系統的相應的安全問題，而且可以給出安全漏洞的解決方案，不過是一些較爲常見的漏洞解決方案。

7 代碼合法性測試

代碼合法性測試主要包括2個部分：程序代碼合法性檢查與顯示代碼合法性檢查。

●程序代碼合法性檢查

程序代碼合法性檢查主要標準爲《intergrp小組編程規範》，目前採用由SCM管理員進行規範的檢查，將來指望可以有相應的工具進行測試。

●顯示代碼合法性檢查

顯示代碼的合法性檢查，主要分爲Html、JavaScript、Css代碼檢查，目前採用HTML代碼檢查------採用CSE HTML Validator進行測試JavaScript、Css也能夠在網上下載相應的測試工具。

8 文檔測試

●產品說明書屬性檢查清單

1）完整.是否有遺漏和丟失，徹底嗎？ 單獨使用是否包含所有內容

2）準確.既定解決方案正確嗎？ 目標明確嗎？ 有沒有錯誤？

3）精確、不含糊、清晰.描述是否一清二楚？ 仍是自說自話？容易看懂和理解嗎？

4）一致.產品功能能描述是否自相矛盾，與其餘功能有沒有衝突

5）貼切.描述功能的陳述是否必要？有沒有多餘信息？ 功能是否原來的客戶要求？

6）合理.在特定的預算和進度下，以現有人力，物力和資源可否實現？

7）代碼無關.是否堅持定義產品，而不是定義其所信賴的軟件設計，架構和代碼

8）可測試性.特性可否測試？ 測試員創建驗證操做的測試程序是否提供足夠的信息？

●產品說明書用語檢查清單

1）說明。 對問題的描述一般表現爲粉飾沒有仔細考慮的功能----可歸結於前文所述的屬性.從產品說明書上找出這樣的用語，仔細審視它們在文中是怎樣使用的.產品說明書可能會爲其掩飾和開脫，也可能含糊其詞----不管是哪種狀況均可視爲軟件缺陷.

2）老是，每一種，全部，沒有，從不.若是看到此類絕對或確定的，切實認定的敘述，軟件測試員就能夠着手設計針鋒相對的案例.

3）固然，所以，明顯，顯然，必然.這些話意圖誘使接受假定狀況.不要中了圈套.

4）某些，有時，經常，一般，慣常，常常，大多，幾乎.這些話太過模糊.「有時」發生做用的功能沒法測試.

5）等等，諸如此類，依此類推.以這樣的詞結束的功能清單沒法測試.功能清單要絕對或者解釋明確，以避免讓人迷惑，不知如何推論.

6）良好，迅速，廉價，高效，小，穩定.這些是不肯定的說法，不可測試.若是在產品說明書中出現，就必須進一步指明含義.

7）已處理，已拒絕，已忽略，已消除.這些廉潔可能會隱藏大量須要說明的功能.

8）若是...那麼...（沒有不然）.找出有「若是...那麼...」而缺乏配套的「不然」結構的陳述.想想「若是」沒有發生會怎樣.

相關的測試工具

· OpenSTA

主要作性能測試的負荷及壓力測試，使用比較方便，能夠編寫測試腳本，也能夠先行自動生成測試腳本，然後對於應用測試腳本進行測試。

· SAINT

網站安全性測試，可以對於指定網站進行安全性測試，並能夠提供安全問題的解決方案。

· CSE HTML Validator

一個有用的對於HTML代碼進行合法性檢查的工具

· Ab（Apache Bench）

Apache自帶的對於性能測試方面的工具，功能不是不少，可是很是實用。

· Crash-me

Mysql自帶的測試數據庫性能的工具，可以測試多種數據庫的性能

 

黑盒測試用例設計

黑盒測試（Black-box Testing，又稱爲功能測試或數據驅動測試）是把測試對象看做一個黑盒子。利用黑盒測試法進行動態測試時，須要測試軟件產品的功能，不需測試軟件產品的內部結構和處理過程。

採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。

黑盒測試注重於測試軟件的功能性需求，也即黑盒測試使軟件工程師派生出執行程序全部功能需求的輸入條件。黑盒測試並非白盒測試的替代品，而是用於輔助白盒測試發現其餘類型的錯誤。

黑盒測試試圖發現如下類型的錯誤：

1）功能錯誤或遺漏；

2）界面錯誤；

3）數據結構或外部數據庫訪問錯誤；

4）性能錯誤；

5）初始化和終止錯誤。

1、黑盒測試的測試用例設計方法

· 等價類劃分方法

· 邊界值分析方法

· 錯誤推測方法

· 因果圖方法

· 斷定表驅動分析方法

· 正交實驗設計方法

· 功能圖分析方法

等價類劃分：

是把全部可能的輸入數據，即程序的輸入域劃分紅若干部分（子集），而後從每個子集中選取少數具備表明性的數據做爲測試用例。該方法是一種重要的，經常使用的黑盒測試用例設計方法。

1） 劃分等價類： 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等效的。併合理地假定：測試某等價類的表明值就等於對這一類其它值的測試。所以，能夠把所有輸入數據合理劃分爲若干等價類，在每個等價類中取一個數據做爲測試的輸入條件，就能夠用少許表明性的測試數據。取得較好的測試結果。等價類劃分可有兩種不一樣的狀況：有效等價類和無效等價類。

有效等價類：是指對於程序的規格說明來講是合理的，有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。

無效等價類：與有效等價類的定義恰巧相反。

設計測試用例時，要同時考慮這兩種等價類。由於，軟件不只要能接收合理的數據，也要能經受意外的考驗。這樣的測試才能確保軟件具備更高的可靠性。

2）劃分等價類的方法：下面給出六條肯定等價類的原則。

① 在輸入條件規定了取值範圍或值的個數的狀況下，則能夠確立一個有效等價類和兩個無效等價類。

② 在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的狀況下，可確立一個有效等價類和一個無效等價類。

③ 在輸入條件是一個布爾量的狀況下，可肯定一個有效等價類和一個無效等價類。

④ 在規定了輸入數據的一組值（假定n個），而且程序要對每個輸入值分別處理的狀況下，可確立n個有效等價類和一個無效等價類。

⑤ 在規定了輸入數據必須遵照的規則的狀況下，可確立一個有效等價類（符合規則）和若干個無效等價類（從不一樣角度違反規則）。

⑥ 在確知已劃分的等價類中各元素在程序處理中的方式不一樣的狀況下，則應再將該等價類進一步的劃分爲更小的等價類。

3）設計測試用例：在確立了等價類後，可創建等價類表，列出全部劃分出的等價類：

輸入條件 有效等價類 無效等價類

而後從劃分出的等價類中按如下三個原則設計測試用例：

① 爲每個等價類規定一個惟一的編號。

② 設計一個新的測試用例，使其儘量多地覆蓋還沒有被覆蓋地有效等價類，重複這一步。直到全部的有效等價類都被覆蓋爲止。

③ 設計一個新的測試用例，使其僅覆蓋一個還沒有被覆蓋的無效等價類，重複這一步。直到全部的無效等價類都被覆蓋爲止。

邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。

（1）邊界值分析方法的考慮：

長期的測試工做經驗告訴咱們，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部。所以針對各類邊界狀況設計測試用例，能夠查出更多的錯誤。

使用邊界值分析方法設計測試用例，首先應肯定邊界狀況。一般輸入和輸出等價類的邊界，就是應着重測試的邊界狀況。應當選取正好等於，剛剛大於或剛剛小於邊界的值做爲測試數據，而不是選取等價類中的典型值或任意值做爲測試數據。

（2）基於邊界值分析方法選擇測試用例的原則：

1）若是輸入條件規定了值的範圍，則應取剛達到這個範圍的邊界的值，以及剛剛超越這個範圍邊界的值做爲測試輸入數據。

2）若是輸入條件規定了值的個數，則用最大個數，最小個數，比最小個數少一，比最大個數多一的數做爲測試數據。

3）根據規格說明的每一個輸出條件，使用前面的原則1）。

4）根據規格說明的每一個輸出條件，應用前面的原則2）。

5）若是程序的規格說明給出的輸入域或輸出域是有序集合，則應選取集合的第一個元素和最後一個元素做爲測試用例。

6）若是程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界上的值做爲測試用例。

7）分析規格說明，找出其它可能的邊界條件。

錯誤推測法

錯誤推測法： 基於經驗和直覺推測程序中全部可能存在的各類錯誤， 從而有針對性的設計測試用例的方法。

錯誤推測方法的基本思想： 列舉出程序中全部可能有的錯誤和容易發生錯誤的特殊狀況，根據他們選擇測試用例。 例如， 在單元測試時曾列出的許多在模塊中常見的錯誤。 之前產品測試中曾經發現的錯誤等， 這些就是經驗的總結。 還有， 輸入數據和輸出數據爲0的狀況。 輸入表格爲空格或輸入表格只有一行。 這些都是容易發生錯誤的狀況。 可選擇這些狀況下的例子做爲測試用例。

因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法，都是着重考慮輸入條件，但未考慮輸入條件之間的聯繫， 相互組合等。 考慮輸入條件之間的相互組合，可能會產生一些新的狀況。 但要檢查輸入條件的組合不是一件容易的事情， 即便把全部輸入條件劃分紅等價類，他們之間的組合狀況也至關多。 所以必須考慮採用一種適合於描述對於多種條件的組合，相應產生多個動做的形式來考慮設計測試用例。 這就須要利用因果圖（邏輯模型）。

因果圖方法最終生成的就是斷定表。 它適合於檢查程序輸入條件的各類組合狀況。

利用因果圖生成測試用例的基本步驟：

（1） 分析軟件規格說明描述中， 那些是緣由（即輸入條件或輸入條件的等價類），那些是結果（即輸出條件）， 並給每一個緣由和結果賦予一個標識符。

（2） 分析軟件規格說明描述中的語義。找出緣由與結果之間， 緣由與緣由之間對應的關係。 根據這些關係，畫出因果圖。

（3） 因爲語法或環境限制， 有些緣由與緣由之間，緣由與結果之間的組合狀況不不可能出現。 爲代表這些特殊狀況， 在因果圖上用一些記號代表約束或限制條件。

（4） 把因果圖轉換爲斷定表。

（5） 把斷定表的每一列拿出來做爲依據，設計測試用例。

從因果圖生成的測試用例（局部，組合關係下的）包括了全部輸入數據的取TRUE與取FALSE的狀況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增長而線性地增長。

前面因果圖方法中已經用到了斷定表。斷定表（DECision Table）是分析和表達多邏輯條件下執行不一樣操做的狀況下的工具。在程序設計發展的初期，斷定表就已被看成編寫程序的輔助工具了。因爲它能夠把複雜的邏輯關係和多種條件組合的狀況表達得既具體又明確。

斷定表驅動分析方法

斷定表一般由四個部分組成。

條件樁（ConDItion STub）：列出了問題得全部條件。一般認爲列出得條件的次序可有可無。

動做樁（Action Stub）：列出了問題規定可能採起的操做。這些操做的排列順序沒有約束。

條件項（Condition Entry）：列出針對它左列條件的取值。在全部可能狀況下的真假值。

動做項（Action Entry）：列出在條件項的各類取值狀況下應該採起的動做。

規則：任何一個條件組合的特定取值及其相應要執行的操做。在斷定表中貫穿條件項和動做項的一列就是一條規則。顯然，斷定表中列出多少組條件取值，也就有多少條規則，既條件項和動做項有多少列。

斷定表的創建步驟：（根據軟件規格說明）

① 肯定規則的個數。假若有n個條件。每一個條件有兩個取值（0，1），故有 種規則。

② 列出全部的條件樁和動做樁。

③ 填入條件項。

④ 填入動做項。等到初始斷定表。

⑤ 簡化、合併類似規則（相同動做）。

B.Beizer 指出了適合使用斷定表設計測試用例的條件：

① 規格說明以斷定表形式給出，或很容易轉換成斷定表。

② 條件的排列順序不會也不影響執行哪些操做。

③ 規則的排列順序不會也不影響執行哪些操做。

④ 每當某一規則的條件已經知足，並肯定要執行的操做後，沒必要檢驗別的規則。

⑤ 若是某一規則獲得知足要執行多個操做，這些操做的執行順序可有可無。

黑盒測試的優勢

一、基本上不用人管着，若是程序中止運行了通常就是被測試程序CRASh了

二、設計完測試例以後，下來的工做就是爽了，固然更苦悶的是肯定crash緣由

黑盒測試的缺點

一、結果取決於測試例的設計，測試例的設計部分來勢來源於經驗，OUSPG的東西很值得借鑑

二、沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來作的，還作不到針對被測試程序的狀態轉換來做

三、就沒有狀態概念的測試來講，尋找和肯定形成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來講，就更麻煩了，尤爲不是一個單獨的tEStcase形成的問題。這些在堆的問題中表現的更爲突出。

黑盒測試（功能測試）工具的選擇

那麼，如何高效地完成功能測試？選擇一款合適的功能測試工具並培訓一支高素質的工具使用隊伍無疑是相當重要的。儘管現階段存在少數不採用任何功能測試工具，從事功能測試外包項目的軟件服務企業。短時間來看，這類企業盈利情況尚可，但長久來看，它們極有可能被自動化程度較高的軟件服務企業取代。

目前，用於功能測試的工具軟件有不少，針對不一樣架構軟件的工具也不斷推陳出新。這裏重點介紹的是其中一個較爲典型自動化測試工具，即Mercury公司的WinRunner。

WinRunner是一種用於檢驗應用程序可否如期運行的企業級軟件功能測試工具。經過自動捕獲、檢測和模擬用戶交互操做，WinRunner能識別出絕大多數軟件功能缺陷，從而確保那些跨越了多個功能點和數據庫的應用程序在發佈時儘可能不出現功能性故障。

WinRunner的特色在於： 與傳統的手工測試相比，它能快速、批量地完成功能點測試； 能針對相同測試腳本，執行相同的動做，從而消除人工測試所帶來的理解上的偏差； 此外，它還能重複執行相同動做，測試工做中最枯燥的部分可交由機器完成； 它支持程序風格的測試腳本，一個高素質的測試工程師能借助它完成流程極爲複雜的測試，經過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用； 它針對於大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基於Windows平臺的應用程序實施功能測試而言帶來了極大的便利。

WinRunner的工做流程大體能夠分爲如下六個步驟：

1．識別應用程序的GUI

在WinRunner中，咱們能夠使用GUI Spy來識別各類GUI對象，識別後，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式： Global GUI Map File和GUI Map File per Test。其最大區別是後者對每一個測試腳本產生一個GUI文件，它能自動創建、存儲、加載，推薦初學者選用這種模式。可是，這種模式不易於描述對象的改變，其效率比較低，所以對於一個有經驗的測試人員來講前者不失爲一種更好的選擇，它只產生一個共享的GUI文件，這使得測試腳本更容易維護，且效率更高。

2．創建測試腳本

在創建測試腳本時，通常先進行錄製，而後在錄製造成的腳本中手工加入須要的TSL（與C語言相似的測試腳本語言）。錄製腳本有兩種模式： Context Sensitive和Analog，選擇依據主要在因而否對鼠標軌跡進行模擬，在須要回放時通常選用Analog。在錄製過程當中這兩種模式能夠經過F2鍵相互切換。

只要看看現代軟件的規模和功能點數就能夠明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點鼠標就能夠完成的階段。而性能測試則是控制系統性能的有效手段，在軟件的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮着重要做用。

3．對測試腳本除錯（debug）

在WinRunner中有專門一個Debug TOOlbar用於測試腳本除錯。能夠使用step、pause、breakpoint等來控制和跟蹤測試腳本和查看各類變量值。

4．在新版應用程序執行測試腳本

當應用程序有新版本發佈時，咱們會對應用程序的各類功能包括新增功能進行測試，這時固然不可能再來從新錄製和編寫全部的測試腳本。咱們能夠使用已有的腳本，批量運行這些測試腳本測試舊的功能點是否正常工做。能夠使用一個call命令來加載各測試腳本。還可在call命令中加各類TSL腳原本增長批量能力。

5．分析測試結果

分析測試結果在整個測試過程當中最重要，經過分析能夠發現應用程序的各類功能性缺陷。當運行完某個測試腳本後，會產生一個測試報告，從這個測試報告中咱們能發現應用程序的功能性缺陷，能看到實際結果和指望結果之間的差別，以及在測試過程當中產生的各種對話框等。

6．回報缺陷（defect）

在分析完測試報告後，按照測試流程要回報應用程序的各類缺陷，而後將這些缺陷發給指定人，以便進行修改和維護。

經常使用的功能測試方法

功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。經常使用的測試方法以下：

一、頁面連接檢查：每個連接是否都有對應的頁面，而且頁面之間切換正確。

二、相關性檢查：刪除/增長一項會不會對其餘項產生影響，若是產生影響，這些影響是否都正確。

三、檢查按鈕的功能是否正確：如update， cancel， delete， SAve等功能是否正確。

四、字符串長度檢查： 輸入超出需求所說明的字符串長度的內容， 看系統是否檢查字符串長度，會不會出錯。

五、字符類型檢查： 在應該輸入指定類型的內容的地方輸入其餘類型的內容（如在應該輸入整型的地方輸入其餘字符類型），看系統是否檢查字符類型，會否報錯。

六、標點符號檢查： 輸入內容包括各類標點符號，特別是空格，各類引號，回車鍵。看系統處理是否正確。

七、中文字符處理： 在能夠輸入中文的系統輸入中文，看會否出現亂碼或出錯。

八、檢查帶出信息的完整性： 在查看信息和update信息時，查看所填寫的信息是否是所有帶出。，帶出信息和添加的是否一致

九、信息重複： 在一些須要命名，且名字應該惟一的信息輸入重複的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的先後輸入空格，系統是否做出正確處理。

十、檢查刪除功能：在一些能夠一次刪除多個信息的地方，不選擇任何信息，按」delete」，看系統如何處理，會否出錯；而後選擇一個和多個信息，進行刪除，看是否正確處理。

十一、檢查添加和修改是否一致： 檢查添加和修改信息的要求是否一致，例如添加要求必填的項，修改也應該必填；添加規定爲整型的項，修改也必須爲整型。

十二、檢查修改重名：修改時把不能重名的項改成已存在的內容，看會否處理，報錯。同時，也要注意，會不會報和本身重名的錯。

1三、重複提交表單：一條已經成功提交的紀錄，back後再提交，看看系統是否作了處理。

1四、檢查屢次使用back鍵的狀況： 在有back的地方，back，回到原來頁面，再back，重複屢次，看會否出錯。

1五、search檢查： 在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確。若是能夠輸入多個search條件，能夠同時添加合理和不合理的條件，看系統處理是否正確。

1六、輸入信息位置： 注意在光標停留的地方輸入信息時，光標和所輸入的信息會否跳到別的地方。

1七、上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，並檢查系統是否可以作到。

1八、必填項檢查：應該填寫的項沒有填寫時系統是否都作了處理，對必填項是否有提示信息，如在必填項前加*

1九、快捷鍵檢查：是否支持經常使用快捷鍵，如Ctrl+C Ctrl+V Backspace等，對一些不容許輸入信息的字段，如選人，選日期對快捷方式是否也作了限制。

20、回車鍵檢查： 在輸入結束後直接按回車鍵，看系統處理如何，會否報錯。

 

Web測試中的界面測試用例設計

1、文本框、按鈕等控件測試

　　一、文本框的測試

　　如何對文本框進行測試：

　　a、輸入正常的字母或數字;

　　b、輸入已存在的文件的名稱;

　　c、輸入超長字符。例如在「名稱」框中輸入超過容許邊界個數的字符，假設最多255個字符，嘗試輸入256個字符，檢查程序可否正確處理;

　　d、輸入默認值，空白，空格;

　　e、若只容許輸入字母，嘗試輸入數字;反之，嘗試輸入字母;

　　f、利用複製，粘貼等操做強制輸入程序不容許的輸入數據;

　　g、輸入特殊字符集，例如，NUL及\n等;

　　h、輸入超過文本框長度的字符或文本，檢查所輸入的內容是否正常顯示;

　　i、輸入不符合格式的數據，檢查程序是否正常校驗，如程序要求輸入年月日格式爲yy/mm/dd，實際輸入yyyy/mm/dd，程序應該給出錯誤提示。

　　在測試過程當中所用到的測試方法：

　　a、輸入非法數據;

　　b、輸入默認值;

　　c、輸入特殊字符集;

　　d、輸入使緩衝區溢出的數據;

　　e、輸入相同的文件名;

　　二、命令按鈕控件的測試

　　測試方法：

　　a、點擊按鈕正確響應操做。如單擊肯定，正確執行操做;單擊取消，退出窗口;

　　b、對非法的輸入或操做給出足夠的提示說明，如輸入月工做天數爲32時，單擊「肯定」後系統應提示：天數不能大於31;

　　c、對可能形成數據沒法恢復的操做必須給出確認信息，給用戶放棄選擇的機會;

　　三、單選按鈕控件的測試

　　測試方法：

　　a、一組單選按鈕不能同時選中，只能選中一個;

　　b、逐一執行每一個單選按鈕的功能。分別選擇了「男」、「女」後，保存到數據庫的數據應該相應的分別爲「男」、「女」;

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

　　四、up-down控件文本框的測試

　　測試方法：

　　a、直接輸入數字或用上下箭頭控制，如在「數目」中直接輸入10，或者單擊向上的箭頭，使數目變爲10;

　　b、利用上下箭頭控制數字的自動循環，如當最多數字爲253時，單擊向上箭頭，數目自動變爲1;反之亦適用;

　　c、直接輸入超邊界值，系統應該提示從新輸入;

　　d、輸入默認值，空白。如「插入」數目爲默認值，點擊「肯定」;或刪除默認值，使內容爲空，單擊「肯定」進行測試;

　　e、輸入字符。此時系統應提示輸入有誤。

　　五、組合列表框的測試

　　測試方法：

　　a、條目內容正確，其詳細條目內容能夠根據需求說明肯定;

　　b、逐一執行列表框中每一個條目的功能;

　　c、檢查可否向組合列表框輸入數據。

　　六、複選框的測試

　　測試方法：

　　a、多個複選框能夠被同時選中;

　　b、多個複選框能夠被部分選中;

　　c、多個複選框能夠都不被選中;

　　d、逐一執行每一個複選框的功能。

　　七、列表框控件的測試

　　測試方法：

　　a、條目內容正確：同組合列表框相似，根據需求說明書肯定列表的各項內容正確，沒有丟失或錯誤;

　　b、列表框的內容較多時要使用滾動條;

　　c、列表框容許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標選中多項條目的狀況;

　　八、滾動條控件的測試

　　要注意一下幾點：

　　a、滾動條的長度根據顯示信息的長度或寬度及時變換，這樣有利於用戶瞭解顯示信息的位置和百分比，如word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應處於中間;

　　b、拖動滾動條，檢查屏幕刷新狀況，並查看是否有亂碼;

　　c、單擊滾動條;

　　d、用滾輪控制滾動條;

　　e、滾動條的上下按鈕。

　　九、各類控件在窗體中混和使用時的測試

　　a、控件間的相互做用;

　　b、tab鍵的順序，通常是從上到下，從左到右;

　　c、熱鍵的使用，逐一測試;

　　d、enter鍵和esc鍵的使用。

　　在測試中，應遵循由簡入繁的原則，先進行單個控件功能的測試，確保實現無誤後，再進行多個控件的的功能組合的測試。

　　ps：密碼輸入框測試時要特別注意進行字母大寫輸入的測試。

2、查找替換操做

　　案例演示：打開word中的「替換」對話框。

　　測試本功能有經過測試和失敗測試兩種狀況：

　　經過測試：

　　a、輸入內容直接查找、或查找所有;

　　b、在組合框中尋找已經查找過的內容、再次查找並確認文檔的內容正確，如已經查找過「測試用例」、再次進入不用從新輸入查找內容、直接在文檔中搜尋就能夠。

　　失敗測試：

　　a、輸入過長或太短的查詢字符串。如假設查詢的字符串長度爲1到255，那麼，輸入0、一、二、25六、255和254進行測試;

　　b、輸入特殊字符集。如在word中^g表明圖片、^表明分欄符、能夠輸入這類特殊字符測試;替換測試大致相同。

　　關於編輯操做窗口的功能測試的用例：

　　a、關閉查找替換窗口。不執行任何操做、直接退出;

　　b、附件和選項測試。假如設定「精確搜尋」、「向後」搜索等附件選項等等來測試;

　　c、控件間的相互做用。如搜尋內容爲空時、按鈕「搜尋所有」、「搜尋」、「所有替換」、「替換」都爲灰色。

　　d、熱鍵、Tab鍵。回車鍵的使用。

　　插入操做

　　一、插入文件

　　測試的狀況：

　　a、插入文件;

　　b、插入圖像;

　　c、在文檔中插入文檔自己;

　　d、移除插入的源文件;

　　e、更換插入的源文件的內容。

　　二、連接文件

　　測試方法：

　　a、插入連接文件;

　　b、在文檔中連接文檔自己;

　　c、移除插入的源文件：

　　d、更換插入的源文件的內容。

　　三、插入對象

　　要測試的內容：

　　a、插入程序容許的對象、如在word中插入excel工做表;

　　b、修改所插入對象的內容。插入的對象仍能正確顯示;

　　c、卸載生成插入對象的程序、如在word中插入excel工做表後卸載excel、工做表仍正常使用。

　　編輯操做

　　編輯操做包括剪切、複製、粘貼操做。

　　測試剪切操做的方法

　　a、對文本、文本框、圖文框進行剪切;

　　b、剪切圖像;

　　c、文本圖像混合剪切。

　　複製操做方法與剪切相似。

　　測試時，主要是對粘貼操做的測試方法是：

　　a、粘貼剪切的文本、文本框及圖文框;

　　b、粘貼所剪切的圖像;

　　c、剪切後，在不一樣的程序中粘貼;

　　d、屢次粘貼同一內容，如剪切後，在程序中連續粘貼3次;

　　e、利用粘貼操做強制輸入程序所不容許輸入的數據。

3、界面測試用例的設計方法

　　一、窗體

　　測試窗體的方法：

　　a、窗體大小，大小要合適，控件佈局合理;

　　b、移動窗體。快速或慢速移動窗體，背景及窗體自己刷新必須正確;

　　c、縮放窗體，窗體上的控件應隨窗體的大小變化而變化;

　　d、顯示分辨率。必須在不一樣的分辨率的狀況下測試程序的顯示是否正常。

　　進行測試時還要注意狀態欄是否顯示正確，工具欄的圖標執行操做是否有效，是否與菜單懶中圖標顯示一致;錯誤信息內容是否正確、無錯別字且明確等等。

　　二、控件

　　測試方法：

　　a、窗體或控件的字體和大小要一致;

　　b、注意全角、半角混合;

　　c、無中英文混合。

　　4、菜單

　　進行測試時要注意：

　　a、選擇菜單是否能夠正常工做、並與實際執行內容一致;

　　b、是否有錯別字;

　　c、快捷鍵是否重複;

　　d、熱鍵是否重複;

　　e、快捷鍵與熱鍵操做是否有效;

　　f、是否存在中英文混合;

　　g、菜單要與語境相關、如、不一樣權限的用戶登錄一個應用程序、不一樣級別的用戶能夠看到不一樣級別的菜單並使用不一樣級別的功能;

　　h、鼠標右鍵快捷菜單。

　　特殊屬性

　　a、安裝界面應有公司介紹或產品介紹、有公司的圖標;

　　b、主界面及大多數界面最好有公司圖標;

　　c、選擇「幫助」->「關於」命令、應看見相關版權和產品信息。

 

代替測試用例的檢查表

2004年末在大連出差的時候，幫一個項目作測試，順便寫下這個檢查表，這個檢查表對測試的初學者積累經驗比較有用，實際對於有經驗的測試人員尤爲對於測試業務管理信息系統，基本上大量的測試不須要再編寫測試用例，固然對業務流程、複雜邏輯仍是要設計詳細的測試用例的。若是你測試的系統是有大量人機交互的業務管理信息系統，並且你又比較懶惰，那就能夠使用這個檢查表檢查了。

所以我總結了這類系統中經常使用的測試的檢查項，供當時項目組的測試人員使用，如今再次整理出來發於博客。

1 針對測試組長或測試經理

1.1測試管理工做檢查表：

1. 檢查每輪測試開始時測試環境是否準備好（包括軟件硬件、測試基本數據等）；

2. 確保測試環境（數據和程序）與開發分離，除了測試組以外其餘人不能更新測試環境的數據和程序；

3. 每輪測試根據上一輪的狀況和整體測試計劃作分工調整；

4. 檢查case庫的填報狀況，抽查執行過的case；

5. 檢查BUG提交狀況，抽查提交的BUG是否規範；

6. 天天晚上統計BUG狀況，填寫天天的BUG報告；

7. 根據天天的測試狀況，決定是否開發組要發佈新的BUILD；

8. 每輪測試結束後填寫測試總結。

2  下面是針對測試執行人員的：

2.1輸入、編輯功能的驗證檢查點：

1. 必輸項是否有紅星標記，若是不輸入提示是否跟相應的Label對應，提示的順序是否跟Form輸入域的排列次序一致；

2. 輸入的特殊字符是否能正確處理：`~!@#$%^&*()_+-={}[]|\:;」’<>,./?；

web測試中共通測試用例

每頁顯示記錄數：

一、只能顯示1-999的正整數

二、輸入負數，自動去掉負號

三、輸入0，按默認20條/頁查詢

四、輸入小數，自動去掉小數點

五、輸入分數，自動去掉分數線

 

頁面顯示：

一、頁面頭部標題顯示正確

二、右鍵新窗口打開該功能，新窗口標題顯示正確

三、頁面全部按鈕按鈕顯示正確

四、頁面全部超連接顯示正確，連接進入後數據與進入前的一致

五、頁面總體佈局合理：列表顯示合理

 

上傳類控件驗證條件：

一、  文件類型驗證 

   a) 驗證是否對文件類型作校驗，例要求上傳文件而實際上傳圖片 

    b)不符合要求的文件應不容許提交，並有相應提示信息。

二、  文件內容格式驗證 

  a)  驗證是否對文件格式作校驗 

  b) 不符合文件格式要求的文件應不容許提交，並有相應提示信息。

三、  文件大小驗證 

  a)  驗證是否對文件大小作校驗 

   b) 不符合文件大小要求的文件應不容許提交，並有相應提示信息。

四、  空文件校驗 

  a)  驗證是否對空文件作校驗。

   b) 空文件不容許提交，並有相應提示信息

五、  文件路徑驗證 

   a) 驗證是否對上傳路徑下沒有上傳文件（先選擇上傳路徑，而後移除要上傳的文件）的狀況作處理 

   b) 操做不成功，提示相應路徑下文件不存在。

六、  文件路徑中文兼容性驗證 

    a)驗證文件路徑中包含中文字符時系統可否正常上傳 

   b) 能夠正常上傳文件