单元测试概述
蓋種測試
??????? 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 ?????????????????????????????? ┃
┠──────┼───────────────────────────┨
┃前置條件 ? │操作員登錄營銷管理系統 ????????????????????? ┃
┠──────┼───────────────────────────┨
┃測試方法 ? │等價類劃分（相應還有“錯誤推測法”、“邊界值分析”等）??????????? ┃
┠──────┼───────────────────────────┨
┃輸入數據 ???│username：51testing 性別：男金額：10元描寫敘述：aaaaaaa ???????????? ┃
┠──────┼───────────────────────────┨
┃運行步驟 ? │①.進入【營銷下發】頁面?！ ????????????????????????? ┃
┃ ? ???? │②.點擊『添加』button。 ??????????????????????????? ┃
┃ ? ???? │③.輸入相應數據； ?????????????????????????? ┃
┃ ??? ?? │④.點擊『確定』button； ?????????????????????????? ┃?
┃ ????? ?│⑤.在后臺數據庫(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、比較測試：將已經發版的相似產品或原有的老產品與測試的產品同一時候執行比較?；蚺c已往的測試結果比較
?
說明：針對不同的測試類型和測試階段，測試用例編寫的側重點有所不同。
?
1、? 當中第1、2、6、8、9、13項為模塊（組件、控件）測試、組合（集成）測試、系統測試都涉及并重點測試的方面。
?
2、? 單元（模塊）測試（組件、控件）測試：重點測試第5項。
?
3、? 組合（集成）測試：重點進行接口間數據輸入及邏輯的測試，即第4項。
?
4、? 系統測試：重點測試第3、7、10、11、12、14項。
?
5、? 當中壓力測試和可移植性測試假設是公司的系列產品，能夠選用當中有代表性的產品進行一次代表性測試就可以。
?
6、? GMPS基礎測試用例設計完畢后，其它的測試項目僅僅編寫設計與之不同部分的測試用例。
?
7、? 對于每一個測試項目測試的測試用例不是一成不變的，隨著測試經驗的積累或在測試其它項目發現有測試不充分的測試點時。能夠不斷的補充完好測試項目的測試用例。
?
?
?
?
?
?
?
?
。
?
?
?
?
?
?
?
?
?
?
?
?
?
總結
