為了實施測試而向被測試系統提供的輸入資料、操作或各種環境設定以及期望結果的乙個特定集合
組織性：避免盲目測試，提高測試效率
功能覆蓋：確保功能不被遺漏
重複性：專案進行期間對不同軟體版本進行多次重複執行測試
跟蹤：通過對測試用例統計，確定測試重點
測試確認：通過測試用例對測試過程進行監督，有效評估測試
功能模式
用例規約遍歷測試所有功能
優點：簡捷，易於理解
缺點：邏輯分析不嚴密，易產生遺漏
路徑分析模式
用例遍歷所有路徑
優點：測試完整，避免遺漏
缺點：模組間有聯絡，路徑數量極大
功能、路徑混合模式
主系統使用路徑分析模式，子系統模組間使用傳統功能測試
基本事件
參照設計規格說明書，根據關聯的功能、操作按路徑分析法設計測試用例
備選事件和異常事件
指導測試的實施
規劃測試資料的準備
編寫測試指令碼的"設計規格說明書"
評估測試結果的度量基準
分析缺陷的標準
1. word**形式
2. excel**形式
3. excel**與word**對比
word**
優點：對問題描述清晰，乙個用例一張**
缺點：用例過多的情況下產生大量文件，不利於檢視和管理
excel**
優點：將所有測試用例集中管理，易於維護，統計和跟蹤
缺點: 受限制於**空間較小，較複雜問題不易描述清楚
4. 更新和維護測試用例
刪除過時的測試用例
因為需求的改變等原因可能會使乙個基線測試用例不再適合被測試系統，這些測試用例就會過時。例如，某個變數的界限發生了改變，原來針對邊界值的測試就無法完成對新邊界測試。所以，在軟體的每次修改後都應進行相應的過時測試用例的刪除。
改進不受控制的測試用例
隨著軟體專案的進展，測試用例庫中的用例會不斷增加，其中會出現一些對輸入或執行狀態十分敏感的測試用例。這些測試不容易重複且結果難以控制，會影響回歸測試的效率，需要進行改進，使其達到可重複和可控制的要求
刪除冗餘的測試用例
如果存在兩個或者更多個測試用例針對一組相同的輸入和輸出進行測試，那麼這些測試用例是冗餘的。冗餘測試用例的存在降低了回歸測試的效率。所以需要定期的整理測試用例庫，並將冗餘的用例刪除掉
增添新的測試用例
如果某個程式段、構件或關鍵的介面在現有的測試中沒有被測試，那麼應該開發新測試用例重新對其進行測試。並將新開發的測試用例合併到基線測試包中
輸入預設值
輸入非法資料
輸入特殊字符集
輸入產生錯誤的合法資料組合
輸入使緩衝區溢位的資料
輸入不符合業務規則的無效輸出
輸出屬性修改後的結果
計算結果溢位
資料結構溢位
資料結構不符合約束
螢幕重新整理顯示
運算元與操作符不符
遞迴呼叫本身
資料共享或關聯功能計算出錯
介質忙或者不可用
更改檔案訪問許可權
檔名不合法
檔案系統載入
易見easy to discover：僅憑觀察，使用者就應知道裝置的狀態，該裝置供選擇可以採取的行動。
易學easy to learn：不通過幫助檔案或通過簡單的幫助檔案，使用者就能對乙個陌生的產品有清晰的認識。
易用easy to use：使用者不翻閱手冊就能使用軟體。
易用性原則：
規範性原則
合理性原則
美觀與協調性原則
幫助設施原則
選單位置原則
獨特性原則
快捷方式的組合原則
排錯性考慮原則
多視窗的應用與系統資源原則
易用性測試範圍：
導航測試
導航描述了使用者在乙個頁面內操作的方式，在不同的使用者介面控制之間，例如按鈕、對話方塊、列表和視窗等；或在不同的連線頁面之間。通過考慮下列問題，可以決定乙個應用系統是否易於導航：導航是否直觀？
系統的主要部分是否可通過主頁訪問？系統是否需要站點地圖、搜尋引擎或其他的導航幫助？
在乙個頁面上放太多的資訊往往起到與預期相反的效果。應用系統的使用者趨向於目的驅動，很快地掃瞄乙個應用系統，看是否有滿足自己需要的資訊，如果沒有，就會很快地離開。很少有使用者願意花時間去熟悉應用系統的結構,因此，應用系統導航幫助要盡可能地準確。
導航的另乙個重要方面是應用系統的頁面結構、導航、選單、連線的風格是否一致。確保使用者憑直覺就知道應用系統裡面是否還有內容，內容在什麼地方。
應用系統的層次一旦決定，就要著手測試使用者導航功能，讓終端使用者參與這種測試，效果將更加明顯。
圖形測試
在應用系統中，適當的**和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。乙個應用系統的圖形可以包括**、動畫、邊框、顏色、字型、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，**或動畫不要胡亂地堆在一起，以免浪費傳輸時間。應用系統的**尺寸要盡量地小，並且要能清楚地說明某件事情，一般都鏈結到某個具體的頁面。
（2）驗證所有頁面字型的風格是否一致。
（3）背景顏色應該與字型顏色和前景顏色相搭配。
（4）**的大小和質量也是乙個很重要的因素，一般採用jpg或gif壓縮。
內容測試
內容測試用來檢驗應用系統提供資訊的正確性、準確性和相關性。
資訊的正確性是指資訊是可靠的還是誤傳的。例如，在商品**列表中，錯誤的**可能引起財政問題甚至導致法律糾紛；資訊的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文字處理軟體來進行，例如使用microsoft word的"拼音與語法檢查"功能；資訊的相關性是指是否在當前頁面可以找到與當前瀏覽資訊相關的資訊列表或入口，也就是一般web站點中的所謂"相關文章列表"。
整體介面測試
整體介面是指整個應用系統的頁面結構設計，是給使用者的乙個整體感。例如：當使用者瀏覽應用系統時是否感到舒適，是否憑直覺就知道要找的資訊在什麼地方？整個應用系統的設計風格是否一致？
對整體介面的測試過程，其實是乙個對終端使用者進行調查的過程。一般應用系統採取在主頁上做乙個調查問卷的形式，來得到終端使用者的反饋資訊。對所有的可用性測試來說，都需要有外部人員（與應用系統開發沒有聯絡或聯絡很少的人員）的參與，最好是終端使用者的參與
易用性測試其他參考問題
按鈕支援回車鍵、tab鍵的切換
1、完成相同或相近功能的按鈕要能簡單聯絡在一起，常用按鈕要支援快捷方式。
2、按功能將介面劃分局域塊，並有功能說明或標題。
3、介面要支援鍵盤tab 鍵的自動切換功能。
4、完成同一功能或任務的元素要放在集中位置，減少滑鼠移動的距離。
5、同一介面上的控制項數最好不要超過10 個，多於10 個時可以考慮使用分頁介面顯示。
6、分頁介面要支援在頁面間的快捷切換，常用組合快捷鍵ctrl+tab
7、可輸入控制項檢測到非法輸入後應給出說明資訊
8、tab 鍵的順序與控制項排列順序要一直，目前流行總體從上到下，同時行間從左到右的方式。
9、預設按鈕要支援enter 操作，即按enter 後自動執行預設按鈕對應操作。
10、核取方塊和選項框按選擇機率的高底而先後排列。
11、核取方塊和選項框要有預設選項，並支援tab 選擇。。
12、選項數相同時多用選項框而不用下拉列表框
13、專業性強的軟體要使用相關的專業術語，通用性介面則提倡使用通用性詞眼。
14、介面空間較小時使用下拉框而不用選項框。
15、選項數較少時使用選項框，相反使用下拉列表框。
16、對於介面輸入重複性高的情況，該介面應全面支援鍵盤操作，即在不使用滑鼠的情況下採用鍵盤進行操作。
功能測試測試用例設計
註冊 登陸測試用例 一 註冊測試用例 測試編號 001 測試目標 驗證系統是否對必填項為空時做出正確的響應 測試環境 windows xp作業系統和瀏覽器ie6.0 測試步驟 1 開啟瀏覽器，在瀏覽器的位址列中輸入 使用者註冊 頁面的url，單擊 轉到 按鈕 2 在 使用者註冊 介面什麼都沒有輸入，...
測試用例設計思路
為了提高我們編寫測試用例的質量，以下列出了在拿到乙個頁面或模組後，編寫測試用例的思路。請大家參考，如有遺漏請及時補充。1.驗證系統滿足需求或設計中的規定的功能，也就是說首先應該驗證系統滿足正常的功能 通過測試 2.考慮設計中描述的異常情況處理，驗證設計中描述的異常錯誤處理是否實現。3.考慮許可權問題...
如何設計測試用例
a 99 b 10 c 109 a 100 b 10 c 110 a 101 b 10 c error a 10 b 99 c 109 a 10 b 100 c 110 a 10 b 101 c error 其實邊界值合等價類法聯絡是很密切的，大家想一想邊界值是如何產生的，是我們在劃分等價類過程中產...