測試的覆蓋種類
1.語句覆蓋：語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次。
2.判定覆蓋（也叫分支覆蓋）：設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。
3.條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次。
4.判定——條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次，並且每個可能的判斷結果也至少執行一次。
5.條件組合測試：設計足夠的測試用例，運行所測程序，使程序中每個判斷的所有條件取值組合至少執行一次。
6.路徑測試：設計足夠的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。
用例的設計方案主要的有下面幾種：條件測試，基本路徑測試，循環測試。通過上面的方法可以實現測試用例對程序的邏輯覆蓋，和路徑覆蓋。
測試的目的是檢查程序的行爲是否符合設計規格，程序的行爲就是某種輸入時會產生什麼輸出，因此，一個典型的測試用例完成以下工作：設定輸入數據、執行程序、驗證輸出是否符合預期。
函數的輸入數據一般包括：
A、參數；
B、成員變量，只考慮函數需要讀取的成員變量；
C、全局變量，只考慮函數需要讀取的全局變量；
以上三項，當涉及到複雜數據類型時，只考慮函數需要讀取的域，例如，一個結構對象，有十個域，而函數只讀取其中一個域，則不必考慮其他九個域。
D、其他數據，如函數需要讀取文件或數據庫中的數據，則要先在文件或數據庫中設置好這些數據。
顯然，所有可能輸入都進行測試，既不可能也無意義，我們應該用一定的規則選擇有代表性的數據作爲輸入。輸入可分爲三大類：正常輸入，邊界輸入，非法輸入，每大類還可再分爲若干小類，劃分小類的依據是：同一小類中每個數據都具有等價的測試效果，也就是說，小類中取任取一個數據作爲輸入，如果測試通過，可以肯定同小類的其他輸入也可以測試通過，這就是平常說的“等價類法”。
正常輸入
例如字符串的Trim函數，功能是將字符串前後的空格去除，那麼正常的輸入可以有四類：
前面有空格；
後面有空格；
前後均有空格；
前後均無空格。
邊界輸入
上例中空字符串可以看作是邊界輸入。
再如一個表示年齡的參數，它的有效範圍是0-100，那麼邊界輸入有兩個：0和100。
非正常輸入
垃圾數據或使代碼不能完成正常功能的數據，如一個文件操作的函數，非正常輸入有這麼幾類：
文件不存在；
目錄不存在；
文件正在被其他程序打開；
權限錯誤。
預期輸出
一個完整的測試用例應該有預期輸出，預期輸出就是程序運行後的預期結果，通常表現在對某些數據的修改，即預期輸出要自動判斷程序所改寫的數據的結果值是否符合預期。程序可能修改的數據包括：
A、返回值；
B、輸出參數；
C、成員變量，只考慮函數所改寫的成員變量；
D、全局變量，只考慮函數所改寫的全局變量；
以上四項，當涉及到複雜數據類型時，只考慮函數所改寫的域，例如，一個結構對象，有十個域，而函數只改寫了其中一個域，則不必考慮其他九個域。
E、其他數據，如函數改寫文件或數據庫中的數據，也是一種輸出，不過通常難於自動判斷是否符合預期，可用人工查看來代替。
Test Case Template
┃用例編號 │ BOSS_ FS_ MARKETING_NEW_01P ┃
┠──────┼───────────────────────────┨
┃測試優先級 │高（還有“較高、中、較低、低”幾個等級） ┃
┠──────┼───────────────────────────┨
┃用例摘要 │新增營銷記錄 ┃
┠──────┼───────────────────────────┨
┃測試類型 │功能性測試（對應還有“安全性測試”等） ┃
┠──────┼───────────────────────────┨
┃用例類型 │基本事件（對應還有“備選事件”、“異常事件”） ┃
┠──────┼───────────────────────────┨
┃用例設計者 │songfun ┃
┠──────┼───────────────────────────┨
┃設計日期 │2005-04-25 ┃
┠──────┼───────────────────────────┨
┃對應需求編號│REQ_ MARKETING_NEW_01 ┃
┠──────┼───────────────────────────┨
┃對應UI │Marketing.htm ┃
┠──────┼───────────────────────────┨
┃對應UC │UC_ MARKETING_NEW_01 ┃
┠──────┼───────────────────────────┨
┃版本號 │Build v0.1 ┃
┠──────┼───────────────────────────┨
┃對應開發人員│Frank ┃
┠──────┼───────────────────────────┨
┃前置條件 │操作員登錄營銷管理系統 ┃
┠──────┼───────────────────────────┨
┃測試方法 │等價類劃分（對應還有“錯誤猜測法”、“邊界值分析”等） ┃
┠──────┼───────────────────────────┨
┃輸入數據 │用戶名：51testing 性別：男金額：10元描述：aaaaaaa ┃
┠──────┼───────────────────────────┨
┃執行步驟 │①.進入【營銷下發】頁面； ┃
┃ │②.點擊『增加』按鈕； ┃
┃ │③.輸入相應數據； ┃
┃ │④.點擊『確定』按鈕； ┃
┃ │⑤.在後臺數據庫(test/test@testDB)輸入查詢語句驗證： ┃
┃ │ select * from MarketingTab where ID='1001' ┃
┃ │ ┃
┠──────┼───────────────────────────┨
┃預期輸出 │㈠.執行步驟④後，頁面彈出添加成功提示信息框； ┃
┃ │㈡.執行步驟⑤後查詢數據庫，記錄確實添加成功且數據無誤 ┃
┃ │ ┃
┠──────┼───────────────────────────┨
┃實際結果 │符合預期 ┃
┠──────┼───────────────────────────┨
┃測試日期 │2005-05-01 ┃
┠──────┼───────────────────────────┨
┃結論 │ ┃
┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。測試數據應該選用少量、高效的測試數據進行儘可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試數據，測試用例應覆蓋方面：
1、 正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用 例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。
2、 容錯性（健壯性）測試：程序能夠接收正確數據輸入並且產生正確（預期）的輸出， 輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示
並進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。
3、 完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部信息（數據庫或文件）的完整。
4、 接口間測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。
5、 數據庫測試：依據數據庫設計規範對軟件系統的數據庫結構、數據表及其之間的數據調用關係進行測試。
6、 邊界值分析法：確定邊界情況（剛好等於、稍小於和稍大於和剛剛大於等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。
7、 壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄運行。。。進行測試。
8、等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。
9、錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。
10、效率：完成預定的功能，系統的運行時間（主要是針對數據庫而言）。
11、可理解（操作）性：理解和使用該系統的難易程度（界面友好性）。
12、可移植性：在不同操作系統及硬件配置情況下的運行性。
13、迴歸測試：按照測試用例將所有的測試點測試完畢，測試中發現的問題開發人員 已經解決，進行下一輪的測試。
14、比較測試：將已經發版的類似產品或原有的老產品與測試的產品同時運行比較，或與已往的測試結果比較
說明：針對不同的測試類型和測試階段，測試用例編寫的側重點有所不同。
1、 其中第1、2、6、8、9、13項爲模塊（組件、控件）測試、組合（集成）測試、系統測試都涉及並重點測試的方面。
2、 單元（模塊）測試（組件、控件）測試：重點測試第5項。
3、 組合（集成）測試：重點進行接口間數據輸入及邏輯的測試，即第4項。
4、 系統測試：重點測試第3、7、10、11、12、14項。
5、 其中壓力測試和可移植性測試如果是公司的系列產品，可以選用其中有代表性的產品進行一次代表性測試即可。
6、 GMPS基礎測試用例設計完成後，其他的測試項目只編寫設計與之不同部分的測試用例。
7、 對於每個測試項目測試的測試用例不是一成不變的，隨着測試經驗的積累或在測試其他項目發現有測試不充分的測試點時，可以不斷的補充完善測試項目的測試用例。
。