最全的測試用例
最全的測試用例，以下的最全的測試用例相關文章，可以繼續閱讀哦。
最全的測試用例【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、將該模組的測試思路和測試重點給出來，並放到指定目錄，能夠有效的指導該模組的測試策略