最全的測試用例

最全的測試用例，以下的最全的測試用例相關文章，可以繼續閱讀哦。

最全的測試用例【1】

一、文本框爲字符型

必填項非空校驗：

1、必填項未輸入--程序應提示錯誤;

2、必填項只輸入若干個空格，未輸入其它字符--程序應提示錯誤;

字段唯一性校驗：(不是所有字段都作此項校驗，視實際項目情況而定)

1、新增時輸入重複的字段值--必須提示友好信息;

2、修改時輸入重複的字段值--必須提示友好信息;

字段長度校驗：

輸入[最小字符數-1]--程序應提示錯誤;

輸入[最小字符數]--OK;

3、輸入[最小字符數+1]--程序應提示錯誤;

4、輸入[最大字符數-1]--OK;

5、輸入[最大字符數]--OK;

輸入[最大字符數+1]--程序應提示錯誤;

?字段爲特殊字符校驗：

1、輸入域如對某些字符禁止輸入時，限制是否成功，提示信息是否友好 ;

2、中文、英文、空格，數字，字符，下劃線、單引號 等所有特殊字符的組合 ;

3、所有特殊字符都必須進行測試

字段爲特殊代碼校驗：

輸入htm代碼：比如” 你好”;--必須以文本的形式將代碼顯示出來。

2、輸入JavaScript代碼：比如;--必須以文本的形式將代碼顯示出來。

多行文本框輸入：

1、是否允許回車換行 ;

2、保存後再顯示能夠保持輸入時的格式 ;

3、僅輸入回車換行，檢查能否正確保存;若能，查看保存結果。若不能，查看是否有正確提示 ;

4、僅輸入空格，檢查能否正確保存;若能，查看保存結果。若不能，查看是否有正確提示 。

二、文本框爲數值型

邊界值：

1、輸入[最小值-1]--程序應提示錯誤;

2、輸入[最小值]--OK;

3、輸入[最大值]--OK;

4、輸入[最大值+1]--程序應提示錯誤;

位數：

1、輸入[限制位數]--OK;

2、輸入[限制位數+1]--根據實際項目而定，是否自動四捨五入成限制位數，還是提示信息;

3、輸入[限制位數-1]--OK;

?異常值、特殊值：

1、輸入非數值型數據：漢字、字母、字符--程序應提示錯誤;

2、輸入負數--根據實際項目而定，如果不允許輸入負數，必須提示友好信息;

3、字段禁止直接輸入非數值型數據時，使用“粘貼”、“拷貝”功能嘗試輸入，並測試能否正常提交保存--只能使用“粘貼”、“拷貝”方法輸入的特殊字符應無法保存，並應給出相應提示 ;

4、全角數字和半角數字的情況--全角數字不能保存，提示友好信息，半角數字正常保存;

5、首位爲零的數值：如01=1--視實際項目情況而定;

三、文本框爲日期型

合法性檢查：

1、日輸入[0日]--程序應提示錯誤;

2、日輸入[1日]--OK;

3、日輸入[32日]--程序應提示錯誤;

4、月輸入[1、3、5、7、8、10、12月]、日輸入[31日]--OK;

5、月輸入[4、6、9、11月]、日輸入[30日]--OK;

6、月輸入[4、6、9、11月]、日輸入[31日]--程序應提示錯誤;

7、輸入非閏年,月輸入[2月]、日輸入[28日]，比如2009.2.28--OK;

8、輸入非閏年,月輸入[2月]、日輸入[29日]，比如2009.2.29--程序應提示錯誤

9、(閏年)月輸入[2月]、日輸入[29日]，比如2008.2.29--OK;

10、(閏年)月輸入[2月]、日輸入[30日]，比如2008.2.30--程序應提示錯誤;

11、月輸入[0月]--程序應提示錯誤;

12、月輸入[1月]--OK;

13、月輸入[12月]--OK;

14、月輸入[13月] --程序應提示錯誤;

格式檢查：

1、不合法格式：2009-09、 2009-09 -、200-2-2;

2、視具體項目而定是否合法：2009/09/01、2009.09.01 、20090901、2009-09-01 ;

異常值、特殊值：

1、輸入漢字、字母、字符--程序應提示錯誤;

四、文本框爲時間型

合法性檢查：

1、時輸入[24時] --程序應提示錯誤;

2、時輸入[00時] --OK;

3、分輸入[60分] --程序應提示錯誤;

4、分輸入[59分] --OK;

5、分輸入[00分] --OK;

6、秒輸入[60秒] --程序應提示錯誤;

7、秒輸入[59秒] --OK;

8、秒輸入[00秒] --OK;

?格式檢查：

不合法格式：12:30:、 123000;

2、視具體項目而定是否合法：12:30、 1:3:0;

異常值、特殊值：

1、輸入漢字、字母、字符--程序應提示錯誤;

2、系統中所涉及時間是否取服務器時間;

頁功能我們常碰到的一般有以下幾個功能：

1、首頁、上一頁、下一頁、尾頁。

2、總頁數，當前頁數

3、指定跳轉頁

4、指定每頁顯示條數

當然，有一些是少於多少頁，全部以數字的形式顯示，多於多少頁後，纔出現下一頁的控件。本文暫且用以上四點來做爲通用的用例來設計吧。

對於“首頁、上一頁、下一頁、尾頁”。翻頁鏈接或按鈕的測試，主要要檢查的測試點有：

1、有無數據時控件的顯示情況

2、在首頁時，首頁和上一頁是否能點擊

3、在尾頁時，下一頁和尾頁是否能點擊

4、在非首頁和非尾頁時，四個按鈕功能是否正確

5、翻頁後，列表中的記錄是否仍按照指定的排序列進行了排序

對於“總頁數，當前頁數總頁數，當前頁數”，主要要檢查的測試點有：

1、總頁數是否等於總的記錄數/指定每頁條數

2、當前頁數是否正確

針對以上測試用例如下：

step 1: 列表無記錄

expect: 1、四個翻頁控件變灰不可點擊

2、列表有相應的無數據信息提示

3、不可指定頁數

4、不可指定跳轉頁

5、總頁數顯示爲0

6、當前頁數顯示爲0

step 2: 列表的記錄數<=指定的每頁顯示條數

expect: 1、四個翻頁控件變灰不可點擊

2、總頁數顯示爲1

3、當前頁數顯示爲1

step 3: 列表的記錄數>指定的每頁顯示條數

expect: 1、默認在首頁，當前頁數爲1

2、列表的數據按照指定的排序列正確排序

3、記錄數與數據庫相符

4、總頁數=記錄數/指定的每頁顯示條數

step 4: 列表的記錄數>指定的每頁顯示條數，在首頁

expect: 1、首頁變灰不可點擊

2、上一頁變灰不可點擊

3、下一頁可點擊，從(每頁指定條數+1)條記錄開始顯示，當前頁數+1

4、尾頁可點擊，顯示最後頁的記錄

step 5: 列表的記錄數>指定的每頁顯示條數，在中間的某頁

expect: 1、首頁可點擊，顯示1到每頁指定條數的記錄

2、上一頁可點擊，顯示上一頁的記錄

3、下一頁可點擊，從後一頁的記錄

4、尾頁可點擊，顯示最後頁的記錄

5、列表的數據按照指定的排序列正確排序

6、當前頁數爲所在頁

step 6:列表的記錄數>指定的每頁顯示條數，在尾頁

expect: 1、首頁可點擊，顯示1到每頁指定條數的記錄

2、上一頁可點擊，顯示上一頁的記錄

3、下一頁變灰不可點擊

4、尾頁變灰不可點擊

5、列表的數據按照指定的排序列正確排序

6、當前頁數爲最後一頁的頁數

對於“指定跳轉頁”，主要要檢查的測試點有：

1、是否能正常跳轉到指定的頁數

2、輸入的跳轉頁數非法時的處理

對於“指定每頁顯示條數”，主要要檢查的測試點有：

1、是否有默認的指定每頁顯示條數

2、指定每頁的條數後，列表顯示的記錄數，頁數是否正確

3、輸入的每頁條數非法時的處理

針對以上測試用例如下：

step 7:輸入每頁顯示條數爲小於總記錄的正整數

expect: 1、每頁顯示條數更新成指定的條數

2、超過指定的條數的記錄分頁顯示

3、總頁數更新成列表的記錄數/每頁顯示條數

step 8:輸入每頁顯示條數爲0、負數、小數

expect: 1、提示“每頁顯示條數必須爲大於1的整數”

2、提示後每頁顯示條數恢復爲上次生效的條數

step 9:輸入每頁顯示條數大於或等於總記錄數的正整數時

expect: 1、四個翻頁按鈕變灰不可點擊

2、總頁數顯示爲1

3、當前頁數顯示爲1

step 10:輸入每頁顯示條數長度超過數據庫指定的長度<<>>

expect: 1、提示每頁顯示條數不能超過<<>>位

2、提示後每頁顯示條數恢復爲上次生效的條數

step 11:輸入每頁顯示條數爲非數值、非法值時

expect: 1、提示每頁顯示條數必須爲大於1的整數

2、提示後每頁顯示條數恢復爲上次生效的條數

step 12:輸入跳轉的頁數爲存在的頁數

expect: 1、正確跳轉到指定的頁數

step 13:輸入跳轉的頁數不存在或非法值

expect: 1、跳轉的頁數值置爲1，顯示第一頁的數據

1：易用性：

按鈕名稱應該易懂，用詞準確，屏棄沒楞兩可的字眼，要與同一界面上的其他按鈕易於區分，能望文知意最好。理想的情況是用戶不用查閱幫助就能知道該界面的功能並進行相關的正確操作。

易用性細則：

1):完成相同或相近功能的按鈕用Frame框起來，常用按鈕要支持快捷方式。

2):完成同一功能或任務的元素放在集中位置，減少鼠標移動的距離。

3):按功能將界面劃分局域塊，用Frame框括起來,並要有功能說明或標題。

4):界面要支持鍵盤自動瀏覽按鈕功能，即按Tab鍵的自動切換功能。

5):界面上首先應輸入的和重要信息的控件在Tab順序中應當靠前,位置也應放在窗口上較醒目的位置。

6):同一界面上的控件數最好不要超過10個，多於10個時可以考慮使用分頁界面顯示。

7):分頁界面要支持在頁面間的快捷切換，常用組合快捷鍵Ctrl+Tab

8):默認按鈕要支持Enter及選操作，即按Enter後自動執行默認按鈕對應操作。

9):可寫控件檢測到非法輸入後應給出說明並能自動獲得焦點。

10):Tab鍵的順序與控件排列順序要一直，目前流行總體從上到下，同時行間從左到右的方式。

11):複選框和選項框按選擇機率的高底而先後排列。

12):複選框和選項框要有默認選項，並支持Tab選擇。

13):選項數相同時多用選項框而不用下拉列表框。

14):界面空間較小時使用下拉框而不用選項框。

15):選項數叫少時使用選項框，相反使用下拉列表框。

16):專業性強的軟件要使用相關的專業術語，通用性界面則提倡使用通用性詞眼。

2： 規範性：

通常界面設計都按Windows界面的規範來設計，即包含“菜單條、工具欄、工具廂、狀態欄、滾動條、右鍵快捷菜單”的標準格式，可以說：界面遵循規範化的程度越高，則易用性相應的就越好。小型軟件一般不提供工具廂。

規範性細則：

1):常用菜單要有命令快捷方式。

2):完成相同或相近功能的菜單用橫線隔開放在同一位置。

3):菜單前的圖標能直觀的代表要完成的操作。

4):菜單深度一般要求最多控制在三層以內。

5):工具欄要求可以根據用戶的要求自己選擇定製。

6):相同或相近功能的工具欄放在一起。

7):工具欄中的每一個按鈕要有及時提示信息。

8):一條工具欄的長度最長不能超出屏幕寬度。

9): 工具欄的圖標能直觀的代表要完成的操作。

10):系統常用的工具欄設置默認放置位置。

11):工具欄太多時可以考慮使用工具廂。

12):工具廂要具有可增減性，由用戶自己根據需求定製。

13):工具廂的默認總寬度不要超過屏幕寬度的1/5。

14): 狀態條要能顯示用戶切實需要的信息，常用的有：

目前的操作、系統狀態、用戶位置、用戶信息、提示信息、錯誤信息等，如果某一操作需要的時間較長，還應該顯示進度條和進程提示。

15)：滾動條的長度要根據顯示信息的長度或寬度能及時變換，以利於用戶瞭解顯示信息的位置和百分比。

16)：狀態條的高度以放置五好字爲宜，滾動條的寬度比狀態條的略窄。

17)：菜單和工具條要有清楚的界限;菜單要求凸出顯示，這樣在移走工具條時仍有立體感。

18)：菜單和狀態條中通常使用5號字體。工具條一般比菜單要寬，但不要寬的太多，否則看起來很不協調。

19):右鍵快捷菜單採用與菜單相同的準則。

3：幫助設施：

系統應該提供詳盡而可靠的幫助文檔，在用戶使用產生迷惑時可以自己尋求解決方法。

幫助設施細則：

1)：幫助文檔中的`性能介紹與說明要與系統性能配套一致。(我們的系統幫助文檔都是系統的祖先時期的說明，讓人困惑)。

2)：打包新系統時，對作了修改的地方在幫助文檔中要做相應的修改。

3)：操作時要提供及時調用系統幫助的功能。常用F1。

4)：在界面上調用幫助時應該能夠及時定位到與該操作相對的幫助位置。也就是說幫助要有即時針對性。

5)：最好提供目前流行的聯機幫助格式或HTML幫助格式。

6)：用戶可以用關鍵詞在幫助索引中搜索所要的幫助，當然也應該提供幫助主題詞。

7)：如果沒有提供書面的幫助文檔的話，最好有打印幫助的功能。

8 )：在幫助中應該提供我們的技術支持方式，一旦用戶難以自己解決可以方便的尋求新的幫助方式。

4：合理性：

屏幕對角線相交的位置是用戶直視的地方，正上方四分之一處爲易吸引用戶注意力的位置，在放置窗體時要注意利用這兩個位置。

合理性細則：

1)：父窗體或主窗體的中心位置應該在對角線焦點附近。

2)：子窗體位置應該在主窗體的左上角或正中。

3)：多個子窗體彈出時應該依次向右下方偏移，以顯示窗體出標題爲宜。

4)：重要的命令按鈕與使用較頻繁的按鈕要放在界面上注目的位置。

5)：錯誤使用容易引起界面退出或關閉的按鈕不應該放在易點位置。橫排開頭或最後與豎排最後爲易點位置。

6)：與正在進行的操作無關的按鈕應該加以屏蔽(Windows中用灰色顯示，沒法使用該按鈕)。

7)：對可能造成數據無法恢復的操作必須提供確認信息,給用戶放棄選擇的機會。

8)：非法的輸入或操作應有足夠的提示說明。

9): 對運行過程中出現問題而引起錯誤的地方要有提示，讓用戶明白錯誤出處，避免形成無限期的等待。

10):提示、警告、或錯誤說明應該清楚、明瞭、恰當。

5：美觀與協調性：

界面應該大小適合美學觀點，感覺協調舒適，能在有效的範圍內吸引用戶的注意力。

美觀與協調性細則：

1): 長寬接近黃金點比例，切忌長寬比例失調、或寬度超過長度。

2): 佈局要合理,不宜過於密集，也不能過於空曠，合理的利用空間。

3): 按鈕大小基本相近，忌用太長的名稱，免得佔用過多的界面位置。

4): 按鈕的大小要與界面的大小和空間要協調。

5): 避免空曠的界面上放置很大的按鈕。

6)：放置完控件後界面不應有很大的空缺位置。

7): 字體的大小要與界面的大小比例協調, 通常使用的字體中宋體9-12較爲美觀，很少使用超過12號的字體。

8): 前景與背景色搭配合理協調，反差不宜太大，最好少用深色，如大紅、大綠等。常用色考慮使用Windows界面色調。

9): 如果使用其他顏色，主色要柔和，具有親和力與磁力，堅決杜絕刺目的顏色。

10): 大型系統常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。

11): 界面風格要保持一致，字的大小、顏色、字體要相同，除非是需要藝術處理或有特殊要求的地方。

12): 如果窗體支持最小化和最大化或放大時，窗體上的控件也要隨着窗體而縮放;切忌只放大窗體而忽略控件的縮放。

13)：對於含有按鈕的界面一般不應該支持縮放，即右上角只有關閉功能。

14): 通常父窗體支持縮放時，子窗體沒有必要縮放。

15)：如果能給用戶提供自定義界面風格則更好，由用戶自己選擇顏色、字體等。

6：菜單位置：

菜單是界面上最重要的元素，菜單位置按照按功能來組織。

菜單設測試細則：

1)：菜單通常採用“常用--主要--次要--工具--幫助”的位置排列，符合流行的Windows風格。

2):常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。

3):下拉菜單要根據菜單選項的含義進行分組，並切按照一定的規則進行排列，用橫線隔開。

4): 一組菜單的使用有先後要求或有嚮導作用時，應該按先後次序排列。

5): 沒有順序要求的菜單項按使用頻率和重要性排列，常用的放在開頭， 不常用的靠後放置;重要的放在開頭，次要的放在後邊。

6): 如果菜單選項較多，應該採用加長菜單的長度而減少深度的原則排列。

7): 菜單深度一般要求最多控制在三層以內。

8): 對常用的菜單要有快捷命令方式，組合原則見8。

9):對與進行的操作無關的菜單要用屏蔽的方式加以處理，如果採用動態加載方式即只有需要的菜單才顯示最好。

10)：菜單前的圖標不宜太大，與字高保持一直最好。

11):主菜單的寬度要接近，字數不應多於四個，每個菜單的字數能相同最好。

12)：主菜單數目不應太多，最好爲單排佈置。

。7:獨特性：

如果一味的遵循業界的界面標準，則會喪失自己的個性.在框架符合以上規範的情況下，設計具有自己獨特風格的界面尤爲重要。尤其在商業軟件流通中有着很好的遷移默化的廣告效用。

1):安裝界面上應有單位介紹或產品介紹，並有自己的圖標。

2):主界面，最好是大多數界面上要有公司圖標。

3):登錄界面上要有本產品的標誌，同時包含公司圖標。

4):幫助菜單的“關於”中應有版權和產品信息。

5):公司的系列產品要保持一直的界面風格，如背景色、字體、菜單排列方式、圖標、安裝過程、按鈕用語等應該大體一致。

8：快捷方式的組合

在菜單及按鈕中使用快捷鍵可以讓喜歡使用鍵盤的用戶操作得更快一些 在西文Windows及其應用軟件中快捷鍵的使用大多是一致的。

菜單中：

1):面向事務的組合有:

Ctrl-D 刪除 ;Ctrl-F 尋找 ;Ctrl H替換;Ctrl-I 插入 ;Ctrl-N 新記錄 ;Ctrl-S 保存 Ctrl-O 打開。

2)：列表:

Ctrl-R ，Ctrl-G定位;Ctrl-Tab下一分頁窗口或反序瀏覽同一頁面控件;。

3):編輯:

Ctrl-A全選;Ctrl-C 拷貝;Ctrl-V 粘貼;Ctrl-X 剪切;Ctrl-Z撤消操作;Ctrl-Y恢復操作。

4)文件操作:

Ctrl-P 打印;Ctrl-W 關閉。

5):系統菜單

Alt-A文件;Alt-E編輯;Alt-T工具;Alt-W窗口;Alt-H幫助。

6):MS Windows保留鍵:

Ctrl-Esc 任務列表 ;Ctrl-F4 關閉窗口; Alt-F4 結束應用;Alt-Tab 下一應用 ;Enter 缺省按鈕/確認操作 ;Esc 取消按鈕/取消操作 ;Shift-F1 上下文相關幫助 。

按鈕中：

可以根據系統需要而調節，以下只是常用的組合。

Alt-Y確定(是);Alt-C取消;Alt-N 否;Alt-D刪除;Alt-Q退出;Alt-A添加;Alt-E編輯;Alt-B瀏覽;Alt-R讀;Alt-W寫。

這些快捷鍵也可以作爲開發中文應用軟件的標準,但亦可使用漢語拼音的開頭字母。

9:安全性考慮：

在界面上通過下列方式來控制出錯機率，會大大減少系統因用戶人爲的錯誤引起的破壞。開發者應當儘量周全地考慮到各種可能發生的問題,使出錯的可能降至最小。如應用出現保護性錯誤而退出系統,這種錯誤最容易使用戶對軟件失去信心。因爲這意味着用戶要中斷思路,並費時費力地重新登錄,而且已進行的操作也會因沒有存盤而全部丟失。

安全性細則：

1)：最重要的是排除可能會使應用非正常中止的錯誤。

2)：應當注意儘可能避免用戶無意錄入無效的數據。

3)：採用相關控件限制用戶輸入值的種類。

4)：當用戶作出選擇的可能性只有兩個時,可以採用單選框。

5)：當選擇的可能再多一些時,可以採用複選框,每一種選擇都是有效的,用戶不可能輸入任何一種無效的選擇。

6)：當選項特別多時，可以採用列表框，下拉式列表框。

7)：在一個應用系統中,開發者應當避免用戶作出未經授權或沒有意義的操作。

8)：對可能引起致命錯誤或系統出錯的輸入字符或動作要加限制或屏蔽。

9):對可能發生嚴重後果的操作要有補救措施。通過補救措施用戶可以回到原來的正確狀態。

10):對一些特殊符號的輸入、與系統使用的符號相沖突的字符等進行判斷並阻止用戶輸入該字符。

11)：對錯誤操作最好支持可逆性處理，如取消系列操作。

12):在輸入有效性字符之前應該阻止用戶進行只有輸入之後纔可進行的操作。

13):對可能造成等待時間較長的操作應該提供取消功能。

14)：特殊字符常有;;’”><,`‘：“[”{、/|｝]+=)-(_*&&^%$#@!~,.。?/還有空格。

15)：與系統採用的保留字符衝突的要加以限制。

16)：在讀入用戶所輸入的信息時，根據需要選擇是否去掉前後空格。

17)：有些讀入數據庫的字段不支持中間有空格，但用戶切實需要輸入中間空格，這時要在程序中加以處理。

10:多窗口的應用與系統資源：

設計良好的軟件不僅要有完備的功能，而且要儘可能的佔用最底限度的資源。

1)： 在多窗口系統中，有些界面要求必須保持在最頂層，避免用戶在打開多個窗口時，不停的切換甚至最小化其他窗口來顯示該窗口。

2)：在主界面載入完畢後自動卸出內存，讓出所佔用的WINDOWS系統資源。

3)：關閉所有窗體，系統退出後要釋放所佔的所有系統資源 ，除非是需要後臺運行的系統。

4)：儘量防止對系統的獨佔使用。

1.輸入驗證 輸入驗證主要包括：數字輸入驗證、非法字符輸入驗證、輸入長度驗證、必填項驗證和信息提示 1.數字輸入驗證：分別輸入數字(正數、負數、零值、單精度、雙精度)、字符串、空白值、空值、臨界數值。不合法的輸入，系統給出必要的判斷提示信息

2.字符輸入驗證：分別輸入單字節字符、雙字節字符、大小寫字符、特殊字符、空白值、空值。不合法的輸入，系統給出必要的判斷提示信息

3.日期、時間輸入驗證：分別輸入任意字符、任意數字、非日期格式的數據、非正確日期(錯誤的閏年日期)、空值、空白值。不合法的輸入，系統給出必要的判斷提示信息。注：有些系統會不讓輸入當日以後或者以前的日期、時間;有些系統會通過JavaScript來自動填寫日期時間，這時需要注意是否能否人工主觀填寫輸入

4.多列表選擇框：測試是否能否多選，列表框中的數據是否能否顯示完全。當列表框的數據過多時，需要對數據有一定格式的排序

5.單列表下拉框：測試是否能否手工輸入，下拉框中的數據是否能否顯示完整。當下拉框的數據很多時，需要對數據有一定格式的排序。如果下拉框數據值過多時，下拉框可能會超出IE顯示範圍，此種情況不能夠被接收

6.大文本輸入框(textArea)：雖然它能夠滿足大數據量的輸入，但最好能夠顯示地標明輸入字符的長度限制，並且應該結合“字符輸入驗證”進行。需要注意的是，應該允許標點的存在

7.文件輸入框輸入驗證：該輸入框主要用做文件上傳操作。在測試過程中，應該注意輸入文件的擴展名。從測試角度來看，要求開發人員必須對擴展名進行輸入限制，並且在適當的地方輸入格式提示。當輸入是空值等不合法的輸入時，系統給出必要的判斷提示信息。另外，對於上傳的文件大小應該做限制，不宜太大

8.輸入字符長度驗證：輸入字符的長度是否超過實際系統接收字符長度的能力。當輸入超出長度時，系統給出必要的判斷提示信息

9.必填項驗證：輸入不允許爲空的時候，系統需要有提示用戶輸入信息功能

10.格式、規則輸入驗證：當輸入需要一定的格式時，系統需要有提示用戶輸入信息功能。比如身份證號碼可以輸入18位或者15位，部分身份證最後一位爲字母，身份證上生日與身份證號碼有一定規則

11.系統錯誤定位的輸入驗證：當輸入存在問題時，被系統捕獲到，此時頁面上的光標能夠定位到發生錯誤的輸入框

12.單選框、多選框的輸入驗證：單選框需要依次驗證單選框的值是否都有效;多選框需要依次驗證多選框的值是否都有效 13.驗證碼驗證：做驗證碼輸入驗證時，先結合“字符輸入驗證”進行測試，然後注意的地方是，當利用IE回退或者刷新時，顯示的驗證碼應該和實際系統驗證碼一致。如果驗證碼以圖片形式顯示，但圖片由於其他原因(如網絡)不能看到或者顯示不完整，系統應該允許進行重新獲取，最好不要做整個頁面刷新 2.操作驗證(CZ) 該用例庫主要針對頁面操作

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

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

3.檢查按鈕的功能是否正確：如增、刪、改、查等功能是否正確

4.重複提交表單：一條已經成功提交的記錄，用IE回退後再提交，看看系統是否做了處理

5.多次IE回退：檢查多次使用IE回退的情況，在有回退的地方，回退，回到原來頁面，再回退，重複多次，看是否出錯

6.快捷鍵檢查：是否支持常用快捷鍵，如Ctrl+C、Ctrl+V、Backspace等，對一些不允許輸入信息的字段，如選人、選日期對快捷方式是否也做了限制

7.回車鍵檢查：在輸入結束後直接回車鍵，看系統處理如何，能否報錯

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

9.其他驗證：在頁面上圖片的大小不宜太大，需要第三方軟件支持時，應該給出必要的信息，比如需要jre的支持，但用戶機器還沒有安裝jre，那麼此時在頁面上應該有顯著的標誌來提醒用戶進行安裝

3.登錄模塊測試用例 該用例庫主要針對登錄模塊。需要結合“訪問控制驗證(FWKZYZ)”用例庫 1.登錄名輸入：進行“輸入驗證”。需要注意登錄名是否區分大小寫和空格

2.密碼輸入：進行“輸入驗證”

3.提交操作：結合“訪問空值驗證(FWKZYZ)”。當輸入正確的登錄名和密碼後，該用戶能夠進入到指定的正確頁面。當輸入的登錄名和密碼有誤時，系統限制其登錄，並且給出適當的提示信息。當遇到錯誤時，應該進行“錯誤頁面測試”

4.重設操作：當進行重設操作時，當前頁面上所有輸入項被清空

4.增加操作測試用例(ZJ) 該用例庫主要針對增加操作

1.添加輸入內容，進行“輸入驗證” 2.應該限制重複增加，具體操作：利用網絡傳輸以及服務器的延遲，多次單擊“增加”按鈕，經常在數據庫發現重複提交的數據 3.當增加成功或者失敗後，應該有必要的信息提示 4.文件數據的增加：有些增加包含了數據庫數據的增加，和一些文件的增加，此時的數據會保存在兩個地方，所以測試時，需要對相關的數據做全面的驗證 5.文件數據驗證：進行“輸入驗證”值“文件輸入框輸入驗證”。注意：當上傳的文件爲中文文件名時，上傳到服務器後，可能會出現亂碼現象。現在一般的做法是將原文件名替換成字母和數字的組合，以克服漢字文件名的弊端，另外，可以增加文件的安全性 5.刪除操作測試用例(SC) 該用例庫主要針對刪除操作

1.選擇需要刪除的數據字段。有時候系統會根據ID來刪除，有時候系統會根據名稱來刪除，測試的時候應該多注意，一般要求按照ID來刪除，因爲根據名稱來刪除，名稱可能會存在重名問題 2.應該限制重複刪除。具體操作：利用網絡傳輸以及服務器的延遲，多次單擊“刪除”按鈕，經常在數據庫中發現重複提交的數據 3.當刪除的數據還有文件時，西藥去驗證存在數據庫中的數據，以及硬盤下的文件是否都被同時刪除 4.當數據被刪除成功或者失敗後，要有響應的信息提示 5.進行“操作驗證” 6.修改操作測試用例(XG) 該用例庫主要針對修改操作

1.打開需要修改的數據頁面，注意與增加頁面相比，只能修改部分數值，例如關鍵字等是不能被修改的，並且二者數據應該是一致的 2.增加頁面上的輸入限制與修改頁面的輸入限制應該一致 3.修改成功或者失敗後，應該有相應的信息提示 7.查詢操作測試用例(CX) 該用例庫主要針對查詢操作

1.條件輸入查詢，先進行條件輸入框的“輸入驗證” 2.條件組合查詢，將多個條件進行組合查詢，結果可以通過數據庫驗證。需要注意的是，整個數據查詢和條件查詢數據結果條數要一致，另外，如果遇到某天的查詢時間段，有的數據庫認爲一天不包括零點零分，有的數據庫認爲包括 3.所有查詢結果，必須進行一定順序的排列，可以按照ID或按照名稱來排列 4.當查詢成功或者失敗後，系統應給出必要的信息提示

8.翻頁操作測試用例(FY) 該用例庫主要針對翻頁操作

1.當數據量很大的時候，需要進行分頁顯示，每頁顯示的行數最好不要超過20行，每頁列表上最好有序號標識，行與行之間顏色要有一定區分，這樣有利於用戶的查找

2.翻頁按鈕應該包括：首頁、前一頁、後一頁、尾頁、當前X頁、共X頁，這些常用按鈕和顯示，並且按鈕都能正常翻頁

3.翻頁按鈕的每頁顯示的數據要準確，確保沒有查不出來的數據，最好的做法就是和數據庫結合起來驗證

4.頁面太多，翻頁數據不能全部顯示時，系統應該有完善的應對機制，比如值顯示當前頁的前三頁和該頁的後三頁的頁數碼 5.當翻到某頁時，系統應該有明顯的標識，標出該頁面所處的頁碼

9.錯誤頁面測試(CW) 錯誤頁面是在遇到系統異常的情況產生的友好界面

1.當系統遇到致命錯誤時，不能將服務器的調試信息出現在頁面上，因爲這樣做會帶來不安全，應該給出一個合適的提示信息

2.由於系統繁忙，無法及時給出正確信息時，系統可以給出友好的錯誤頁面，如：“請用戶稍後再試”等提示信息。

測試用例的4種設計方法【2】

一、什麼是測試用例?

測試用例是爲特定的目的而設定的一組測試輸入、執行條件和預期的結果。簡單的來說而是用例就是設計一個場景，使測試程序在這種場景下運行並且達到程序所設計的結果。ok 這就是用例了，so easy 吧 ! 迴歸主題，開始表述下測試用例的幾種設計方法。

二、測試用例的幾種設計方法

1.等價類劃分法

等價劃分法定義：把所有可能輸入數據，即程序的輸入域劃分若干部分(子集)，然後從每個子集中選取少量具有代表性的數據作爲測試用例。等價類可以劃分爲有效等價類和無效等價類。

如果輸入條件確定了取值範圍，或者說是值得個數，那麼我們就可以確定一個有效等價類和2個無效等價類。

例如：排序值可以從1到100 ，一個有效等價類就是:1<=排序值<=100，兩個無效等價類：排序值<1.排序值>100.

如果輸入條件是一個布爾量，那麼就可以確定一個有效等價類和一個無效等價類;

如果輸入條件是一組數組，那麼程序就要爲每一個輸入值進行判斷處理，從而每一個輸入值都要設計一個等價類，這組數據之外的值也需要設計一個等價類;

2.邊界值

長期測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出的範圍上，而不是發生在輸入輸出範圍的內部，例如:輸入範圍給定了是1-100，我們可以輸入-1，0，1，2，99，100，101等數值來進行測試，這就是邊界值的測試方法。報表的第一行和最後一行;屏幕光標最左邊和最右邊等等。

3.判定表分析法

基本概念：判定表就是分析和表達多種邏輯狀態下得不同執行情況

判定表方法較爲複雜，此處不做詳細介紹，感興趣的同學可以查閱資料。

4.錯誤推測法

基本概念：根據工作經驗和直覺來猜測程序有可能出現的問題，此類方法適合比較有經驗的測試工程師。

小結：以上就是測試工作中常用的幾種測試用例設計方法，測試用例的設計使原本枯燥乏味、重複性的測試工作，變成了一項創造性的勞動。測試用例是測試工作的靈魂，不管是黑盒測試、灰盒測試、白盒測試(自動化及性能測試)，首先掌握的就應該是測試用例的設計，測試用例的編寫不僅能提高測試人員對被測系統的瞭解熟悉程度，而且會提高測試覆蓋率，從而提高產品質量。所以，每一個測試新手必須要學會編寫測試用例，纔能有所提高。

如何編寫高質量的測試用例【3】

高質量的標準：

1、 覆蓋到所有的業務邏輯(包括正常邏輯和異常邏輯)

2、 覆蓋到所有的典型用戶場景

3、 覆蓋到所有的需求點

4、 測試目標明確，並且測試步驟能夠最快的達到測試目的或者測試時間很短

5、 沒有冗餘的用例

6、 測試用例能夠直接附帶測試策略，該模塊的策略指定人和用例執行人能夠非常清楚

如何達到該目標：

一、基於邏輯的用例設計過程：

A、用例編寫過程：

1、優先完成業務邏輯圖，需要在測試的角度上面去畫邏輯圖，包括數據流完整的輸入和輸出過程，並且自己能夠理解爲什麼這樣處理

2、根據自己的理解分析每個邏輯的處理是否完善，是否有沒有覆蓋到的地方，並提交缺陷預防bug

3、根據邏輯編寫測試用例，保證每個邏輯都能夠有對應的用例覆蓋

4、編寫邏輯用例的過程中思考如何去改進該用例的測試過程，比如：接口測試，自動化測試，腳本。並且，能夠及時讓研發提供對應的接口和調試方法

5、用例要按照10分鐘原則，即保證10分鐘內能夠執行完成

B、用例評審過程：

1、先講解整個業務邏輯圖，需要保證評審人員對於整個業務邏輯圖都非常清楚，並且能夠理解爲什麼這樣做

2、分析整個業務邏輯圖是否有沒有覆蓋到的場景或者分支情況(採用頭腦風暴的方式)

3、分析業務邏輯的異常處理情況(是否每個業務邏輯都有對異常情況進行處理，也採用頭腦風暴的方式)

4、是否將邏輯的用例分類比較合理，讓大家通過邏輯很容易就找到對應的用例

5、分析是否所有的邏輯都能夠找到對應的用例(通過邏輯找到對應的用例),包括前面沒有考慮到的邏輯

6、分析用例是否有冗餘，是否多個用例都是覆蓋的同一個邏輯(包括測試步驟和檢查點)

7、分析用例的測試方法是否有改進，是否能夠直接通過代碼靜態走讀、接口測試、自動化測試(包括編寫腳本)、引入工具等等來進一步提高我們的測試效率

C、友情提醒：

1、僅僅只能保證已有的邏輯沒有問題，但是可能出現部分情況沒有處理導致失效的情況，可以通過後面的場景用例和需求用例來補充覆蓋

2、邏輯裏面異常情況考慮不充分，導致測試用例也相對比較欠缺，可以通過對每個邏輯進行頭腦風暴，分析是否有其他異常情況，並且評審時重點評審這塊

3、研發的邏輯有可能本身就是錯誤的，但是如果順着研發的邏輯去編寫用例時會導致用例也有問題，達不到測試目的，所以需要從需求和設計的角度去提前分析邏輯是否有問題

4、過程中研發的邏輯可能變化比較快，這樣會導致邏輯測試用例也要經常變化，所以需要保證研發的編碼是與設計一致的，並且邏輯是儘量根據設計來進行的

另外，邏輯用例的設計可以在編碼中後期進行，這樣的改動會少點

二、基於場景的用例設計過程：

A、用例編寫過程：

1、搞清楚客戶的原始需求，爲什麼需要這個功能，能夠給客戶帶來的價值是什麼

2、查看需求說明書裏面的客戶使用的典型用戶場景，並且整合到場景用例裏面

3、在需求說明書的基礎上進一步分析客戶還可能有哪些實際的使用場景(主要是整個客戶的拓撲結構)

4、客戶會怎樣去配置該模塊以滿足什麼樣的需求(頭腦風暴)

5、過程中客戶會有哪些操作(頭腦風暴)

B、用例評審過程：

1、安排相關模塊專家、規劃經理和主管來進行評審，主要是分析還可能有哪些場景沒有考慮到，最好是能夠有具體的客戶

2、安排講解該模塊的場景，保證用例責任人對模塊場景是非常熟悉的，並且過程中分析是否可能會有其他情況，來進一步完善場景用例

C、友情提醒：

1、模塊用戶場景儘量是有真實的客戶，而不是自己yy出來的

2、模塊用戶場景最好是完整的客戶使用過程，而不是某一個測試點

3、並不是所有的模塊都有場景用例

三、基於需求的用例設計過程：

A、用例編寫過程：

1、參照需求表，並且對照前面的邏輯用例和場景用例，檢視是否覆蓋到所有需求，沒有的分析下原因，是否邏輯用例or場景用例考慮的還不充分，是的話補充到上面，不是的話則補充到需求用例裏面

2、充分利用相關的用例編寫技術，包括：邊界值分析法、等價類分析法、 錯誤類推測法、路徑覆蓋法、因果分析法、正交分析法等

3、分析用例是否能夠通過自動化or其他測試手段來覆蓋到

B、用例評審過程：

1、對照需求表來進行檢視，是否全部覆蓋到，不僅僅是測試用例，還包括測試步驟和期望結果，避免因爲依賴研發的邏輯來設計用例導致問題

2、評審該部分用例是否跟前面的邏輯用例和場景用例冗餘

3、分析用例是否能夠通過自動化or其他測試手段來覆蓋到

C、友情提醒：

1、基於需求的用例僅僅是針對前面沒有覆蓋到的用例的補充，所以這部分用例應該相對比較少，如果發現比較多的話可以分析下是否研發的一些邏輯沒有覆蓋到相關地方

四、模塊測試方法說明(提高該模塊的用例執行效率)：

1、將該模塊的業務邏輯圖放到用例的指定目錄，這樣方便給評審人員講解，以及後面相關人員的學習

2、將該模塊的排查和定位問題的方法給出來，並放到指定目錄，能夠有效指導後面人員排查和定位問題

3、將該模塊的測試思路和測試重點給出來，並放到指定目錄，能夠有效的指導該模塊的測試策略