一些常用模塊的測試用例

1、登錄　　2、添加　　3、查詢　　4、刪除

1、登錄

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

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

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

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

⑤用戶名或密碼為空

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

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

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

⑨輸入的數據前存在空格

⑩輸入正確的用戶名密碼

以后按[enter]是否能登陸

2、添加

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

②留出一個必填數據為空

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

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

⑤是否支持table鍵

⑥按enter是否能保存

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

3、刪除

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

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

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

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

⑤什么也不輸入

⑥是否支持table鍵：tab鍵

⑦是否支持enter鍵

4、查詢

精確查詢：

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

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

③輸入格式或范圍不符合要求的數據，看是否有錯誤提示：如日期格式：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錯誤。

軟件測試全棧專題系列課程https://edu.csdn.net/combo/detail/2221

Jmeter高級性能測試實戰https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自動化測試課程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782零基礎新手入門軟件測試必知必會https://edu.csdn.net/course/detail/32598

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

GUI的整體標準包括以下四個方面：

1.規范性

2.合理性

3.一致性

4.界面定制性

一、GUI設計的規范

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

1.便于用戶操作：戶使用起來能夠建立起精確的心里模型，使用熟練了一個界面后，切換到另外一個界面能夠很輕松的推測出各種功能

2.使用戶感覺到統一、規范，在使用軟件的過程中愉快輕松的完成操作，提高對軟件的認知

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

二、GUI布局的合理性

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

1.界面布局

a.屏幕不能擁擠

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

*? 整個項目，采用統一的控件間距，通過調整窗體大小達到一致，即使在窗體大小不變的情況下，寧可留空部分區域，也不要破壞控件間的行間距。

b.控件按區域排列

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

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

c.有效組合

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

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

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

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

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

2.界面顏色搭配

　　使用恰當的顏色，可以使軟件的界面看起來更加規范：

a.統一色調

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

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

c.遵循對比原則

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

d.整個界面色彩盡量少的使用類別不同的顏色

e.顏色方案也許會因為顯示器、顯卡、操作系統等原因顯示出不同的色彩

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

e.顏色方案也許會因為顯示器、顯卡、操作系統等原因顯示出不同的色彩

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

三、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（見附件）列出了常用的快捷鍵及其功能。

四、GUI界面操作可定制性

　　界面的可定制性大致可分為以下幾個特性：

1.界面元素可定制

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

2.工具欄可定制

　　不同用戶對常用工具的使用是不同的，因此允許用戶建立新的工具欄，選擇要顯示的工具欄，定制工具欄上的按鈕等功能在軟件系統中經常被用到

3.統計檢索可定制

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

GUI所包含各類元素標準的定制

GUI的元素大致可分為以下幾個方面：

1.?窗口

2.?菜單

3.?圖標

4.?控件

5.?鼠標

6. 文字

7. 聯機幫助

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

一、GUI窗口的標準

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

好的GUI窗口應該具備以下標準：

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

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

3.若窗口無法顯示，所有內容能夠改變大小、移動和滾動

4.活動窗口能夠反顯加亮

5.窗口能夠正確的關閉

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

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

8.當窗口被覆蓋并重新調用后，窗口能夠正確再生

9.如果使用多任務，所有的窗口能夠被實時更新

軟件測試全棧專題系列課程https://edu.csdn.net/combo/detail/2221

??Jmeter高級性能測試實戰https://edu.csdn.net/course/detail/35834

RobotFramework+Jmeter接口自動化測試課程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782

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

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

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

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

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

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

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

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

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

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

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

二、GUI菜單的標準

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

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

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

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

4.圖形布局一致

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

三、GUI圖標的標準

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

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

2.不同的目標采用不同的圖標

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

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

5.圖標的外形與實際功能相似，應盡量避免抽象。這樣的圖標可以使用戶很輕松、容易地認識圖標的作用

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

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

四、GUI中控件的標準

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

1.控件元素的間距

a.單個元素間距

*? 輸入框之間垂直間距為5px

*? Label文本標簽和輸入元素之間水平間距為8-22px

*? 復選框、單選按鈕之間垂直間距為8px

*? 多種元素混合垂直排列時，復選框和單選按鈕邊上的間距無論在什么情況下都為8px

b.元素分組間距

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

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

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

*? 復選框組、單選框組的組水平間距為15px

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

五、鼠標在GUI中的標準

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

1.在整個交互的過程中，可以識別鼠標操作

2.多次點擊鼠標后，仍能夠正確識別

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

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

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

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

7.對于相同種類的元素采用相同的操作激活

8.采用動態圖標形象的表示出當前的操作，如用水漏表示系統忙，用手型表示可以點擊等

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

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

11.鼠標光標樣式統一，盡量使用系統標準，杜絕出現重復的情況

六、GUI文字的標準

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

1.字體

a.使用統一字體，如規定軟件系統的中文字體為“宋體”，英文及數據采用“Times New Roman”

b.所有控件、描述信息盡量使用大小統一的字體屬性，除了特殊提示信息、加強顯示等例外情況

2.文字表達

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

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

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

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

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

e.根據用戶不同采用相應的詞語語氣語調

七、GUI聯機幫助的標準

　　幫助文檔適用于以下三種情況：

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

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

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

　　幫助文檔的標準要求：

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

*? 必須闡述功能通過什么方法可以在軟件中實現

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

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

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

對于一個需要面對用戶的軟件產品來說，最直觀的UI和使用感受也是產品能否獲得用戶認可的關鍵一環。個人認為，在毒霸的產品傳統中，從設計到開發再到測試，對產品的易用性和GUI的規范往往給予的關注較少。我在測試過程中就遇到了很多影響使用心情的非關功能方面的 BUG。希望此文可以在毒霸的易用性和GUI方面的測試中給同學們提供一些參考。

易用性測試

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

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

(1) 易理解性測試

(2) 易學性測試

(3) 易操作性測試

(4) 吸引性測試

(5) 易用的依從性測試

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

　　由于易用性缺陷的主觀性，因此測試人員和UI設計人員經常產生不同意見。UI通常被當作創造者的作品，而測試人員說某處是錯誤，就可能挫傷“藝術家”。易用性是軟件缺陷中的敏感問題。

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

1、用戶界面測試

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

2、優秀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. 對于范圍的查詢采用全閉的形式。

軟件測試全棧專題系列課程https://edu.csdn.net/combo/detail/2221Jmeter高級性能測試實戰https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自動化測試課程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782零基礎新手入門軟件測試必知必會https://edu.csdn.net/course/detail/32598

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

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

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

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

(1)等價類劃分法

(2)邊界值法

(3)功能圖與判定表法

(4)錯誤推測法

(5)用戶場景法

(6)......

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

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

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

(1)測試用例的測試目標

(2)測試用例的被測功能點描述

(3)測試用例的測試運行環境

(4)測試用例的執行方法(包括測試步驟，輸入測試數據或測試腳本)

(5)測試期望的結果

(6)執行測試的實際結果

(7)其他輔助說明

從以上幾點，我們可以看到輸入測試數據只是設計測試用例的一個步驟，而不是全部。

測試用例的設計是一項復雜的測試工作，測試用例的設計方法需要考慮測試的目標，被測試軟件的特性，測試者人力資源的技術和能力，測試組織形式，測試進度、測試成本等多個方面。

網站測試清單

通用

◇ 所有測試是否運行在干凈系統上？

◇ 系統是否正常運行？

◇ 是否顯示正確輸出？

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

◇ 普通用戶是否能輕松地操作該系統？

◇ 是否易學易用？

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

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

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

◇ 當系統需要提交或修復時，開發人員是否可以在限期內完成？

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

◇ 系統是否能使硬件、網絡及人力資源得到有效利用？

◇ 系統是否能匹配相關的技術水平？

◇ 系統是否能匹配適當調整的需求？

◇是否可以有效驗證系統的工作方式是適當的？

◇ 本系統內一些組成部分是否可以被其他的系統再利用？

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

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

◇ 是否可以方便地獲取信息？

◇ 網站是否能被搜索？

可用性、界面及導航

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

◇ 是否可以快速登陸主頁？

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

◇ 如果按操作方法進行操作是否可以得到預期結果？

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

◇ 是否所有窗體都有導航欄？

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

◇ 是否導航欄僅作用于使用中的文本？

◇ 用戶是否可以在不用鼠標的情況下使用導航欄功能？

◇ 視力障礙者是否可以使用網站？紅綠色盲，少于 20/20

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

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

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

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

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

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

◇所有圖片是為頁面添彩，還是浪費網速？

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

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

◇ 是否對所有的參考網站或電子郵件地址都設置了超鏈接？

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

◇ 網站在 1024x 768、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。在該目錄下有很多資料，其中有些都是已過期頁面。如果該公司每個月都要更改產品價格信息，并且保存過期頁面。那么只要翻看了一下這些記錄，就可以估計他們的邊際利潤以及他們為了爭取一個合同還有多大的降價空間。如果某個客戶在談判之前查看了這些信息，他們在談判桌上肯定處于上風。

軟件測試全棧專題系列課程https://edu.csdn.net/combo/detail/2221Jmeter高級性能測試實戰https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自動化測試課程https://edu.csdn.net/course/detail/36152????????Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782

??零基礎新手入門軟件測試必知必會https://edu.csdn.net/course/detail/32598

●登錄

現在的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） 劃分等價類： 等價類是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。并合理地假定：測試某等價類的代表值就等于對這一類其它值的測試。因此，可以把全部輸入數據合理劃分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可以用少量代表性的測試數據。取得較好的測試結果。等價類劃分可有兩種不同的情況：有效等價類和無效等價類。

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

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

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

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 指出了適合使用判定表設計測試用例的條件：

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

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

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

④ 每當某一規則的條件已經滿足，并確定要執行的操作后，不必檢驗別的規則。

⑤ 如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。

黑盒測試的優點

1、基本上不用人管著，如果程序停止運行了一般就是被測試程序CRASh了

2、設計完測試例之后，下來的工作就是爽了，當然更苦悶的是確定crash原因

黑盒測試的缺點

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

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

3、就沒有狀態概念的測試來說，尋找和確定造成程序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）

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

常用的功能測試方法

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

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

2、相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。

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

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

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

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

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

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

9、信息重復： 在一些需要命名，且名字應該唯一的信息輸入重復的名字或ID，看系統有沒有處理，會否報錯，重名包括是否區分大小寫，以及在輸入內容的前后輸入空格，系統是否作出正確處理。

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

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

12、檢查修改重名：修改時把不能重名的項改為已存在的內容，看會否處理，報錯。同時，也要注意，會不會報和自己重名的錯。

13、重復提交表單：一條已經成功提交的紀錄，back后再提交，看看系統是否做了處理。

14、檢查多次使用back鍵的情況： 在有back的地方，back，回到原來頁面，再back，重復多次，看會否出錯。

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

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

17、上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，并檢查系統是否能夠做到。

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

19、快捷鍵檢查：是否支持常用快捷鍵，如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、輸入相同的文件名;

2、命令按鈕控件的測試

　　測試方法：

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

b、對非法的輸入或操作給出足夠的提示說明，如輸入月工作天數為32時，單擊“確定”后系統應提示：天數不能大于31;

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

3、單選按鈕控件的測試

　　測試方法：

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

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

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

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

　　測試方法：

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

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

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

d、輸入默認值，空白。如“插入”數目為默認值，點擊“確定”;或刪除默認值，使內容為空，單擊“確定”進行測試;

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

5、組合列表框的測試

　　測試方法：

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

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

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

6、復選框的測試

　　測試方法：

a、多個復選框可以被同時選中;

b、多個復選框可以被部分選中;

c、多個復選框可以都不被選中;

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

7、列表框控件的測試

　　測試方法：

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

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

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

8、滾動條控件的測試

　　要注意一下幾點：

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

b、拖動滾動條，檢查零基礎新手入門軟件測試必知必會https://edu.csdn.net/course/detail/32598刷新情況，并查看是否有亂碼;

c、單擊滾動條;

d、用滾輪控制滾動條;

e、滾動條的上下按鈕。

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

a、控件間的相互作用;

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

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

d、enter鍵和esc鍵的使用。

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

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

二、查找替換操作

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

　　測試本功能有通過測試和失敗測試兩種情況：

　　通過測試：

a、輸入內容直接查找、或查找全部;

b、在組合框中尋找已經查找過的內容、再次查找并確認文檔的內容正確，如已經查找過“測試用例”、再次進入不用重新輸入查找內容、直接在文檔中搜尋就可以。

　　失敗測試：

a、輸入過長或過短的查詢字符串。如假設查詢的字符串長度為1到255，那么，輸入0、1、2、256、255和254進行測試;

b、輸入特殊字符集。如在word中^g代表圖片、^代表分欄符、可以輸入這類特殊字符測試;替換測試大體相同。

　　關于編輯操作窗口的功能測試的用例：

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

b、附件和選項測試。假如設定“精確搜尋”、“向后”搜索等附件選項等等來測試;

c、控件間的相互作用。如搜尋內容為空時、按鈕“搜尋全部”、“搜尋”、“全部替換”、“替換”都為灰色。

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

　　插入操作

1、插入文件

　　測試的情況：

a、插入文件;

b、插入圖像;

c、在文檔中插入文檔本身;

d、移除插入的源文件;

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

2、鏈接文件

　　測試方法：

a、插入鏈接文件;

b、在文檔中鏈接文檔本身;

c、移除插入的源文件：

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

3、插入對象

　　要測試的內容：

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

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

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

　　編輯操作

　　編輯操作包括剪切、復制、粘貼操作。

　　測試剪切操作的方法

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

b、剪切圖像;

c、文本圖像混合剪切。

　　復制操作方法與剪切類似。

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

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

b、粘貼所剪切的圖像;

c、剪切后，在不同的程序中粘貼;

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

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

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

1、窗體

　　測試窗體的方法：

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

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

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

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

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

2、控件

　　測試方法：

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

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

c、無中英文混合。

　　四、菜單

　　進行測試時要注意：

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

軟件測試全棧專題系列課程https://edu.csdn.net/combo/detail/2221Jmeter高級性能測試實戰https://edu.csdn.net/course/detail/35834RobotFramework+Jmeter接口自動化測試課程https://edu.csdn.net/course/detail/36152Fiddler接口抓包神器使用教程https://edu.csdn.net/course/detail/32782零基礎新手入門軟件測試必知必會https://edu.csdn.net/course/detail/32598

總結

以上是生活随笔為你收集整理的常用测试用例模板大全的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。