關(guān)鍵字：單元測試
軟件測試是保證軟件產(chǎn)品質(zhì)量的重要手段之一。它是測量、評估軟件產(chǎn)品特點(diǎn)和能力的活動(dòng)�，F在，國內一些軟件企業(yè)對于軟件測試的重視程度還很不夠，認為測試工作非常簡(jiǎn)單，只是簡(jiǎn)單地操作所測的軟件產(chǎn)品而已。這種錯誤的思想嚴重影響了國內軟件質(zhì)量，應該引起我們的高度重視。 軟件測試階段可以分為若干個(gè)小的階段，階段的劃分有多種，我現在按流程順序將其分為四個(gè)階段：
· 單元測試：由項目小組完成
· 集成測試：由項目小組完成
· 系統測試：由專(zhuān)業(yè)測試小組完成
· 交接測試：用戶(hù)和開(kāi)發(fā)商共同完成。
測試的四個(gè)階段完全逆向檢測了軟件開(kāi)發(fā)的各個(gè)階段。單元測試主要是測試程序代碼，集成測試主要是對設計的檢測，系統測試主要測試了軟件的功能，交接測試主要是對用戶(hù)需求的一種檢測。但是每個(gè)測試階段仍要對其它測試階段的測試內容加以測試，只是測試重點(diǎn)不同。
在這篇文章中，我只對單元測試流程加以闡述，而不涉及具體的測試方法。關(guān)于測試方法（如：使用手工測試還是自動(dòng)測試）若有機會(huì )將在其它文章中進(jìn)行闡述。
在單元測試前，先讓我們明白以下幾個(gè)問(wèn)題，這可以使我們對單元測試更加清晰。
· 單元測試的目標： 確保模塊被正確地編碼
· 由誰(shuí)去做： 通常由程序人員測試
· 怎樣去測試： 功能測試可以用黑匣測試方法，代碼測試可用白匣測試方法
· 什么時(shí)候可以停止：當程序員感到代碼沒(méi)有缺陷時(shí)
· 記錄： 通常沒(méi)有記錄
我們在清楚以上問(wèn)題后就可以編寫(xiě)測試用例了。測試用例是輸入、執行條件和一個(gè)特殊目標所開(kāi)發(fā)的預期結果集合。它按測試目的不同可分為以下幾種類(lèi)型：
· 需求測試用例：測試是否符合需求規范
· 設計測試用例：測試是否符合系統邏輯結構
· 代碼測試用例：測試代碼的邏輯結構和使用的數據
需求測試用例通常是按照需求執行的功能逐條地編寫(xiě)輸入數據和期望輸出。一個(gè)好的需求用例是可以用少量的測試用例就能夠覆蓋所有的程序功能。
設計測試用例檢測的是代碼和設計是否完全相符。是對底層設計和基本結構上的測試。設計測試用例可以涉及到需求測試用例沒(méi)有覆蓋到的代碼空間（例如界面的設計）。
代碼測試用例是基于運行軟件和數據結構上的。它要保證可以覆蓋所有的程序分支、最小的語(yǔ)句和輸出。
以上三種用例所用的數據又可分為正常數據、邊緣數據和錯誤數據。
· 正常數據：在測試中所用的正常數據的量是最大的，而且也是最關(guān)鍵的。少量的測試數據不能完全覆蓋需求，但我們要從中提取出一些具有高度代表性的數據作為測試數據，以減少測試時(shí)間。
· 邊緣數據：邊緣測試是界于正常數據和錯誤數據之間的一種數據。它可以針對某一種編程語(yǔ)言、編程環(huán)境或特定的數據庫而專(zhuān)門(mén)設定。例如若使用SQL Server數據庫，則可把SQL Server關(guān)鍵字（如：’;AS;Join等）設為邊緣數據。其它邊緣數據還有：HTML的HTML;<>等關(guān)鍵字以及空格、@、負數、超長(cháng)字符等。邊緣數據要靠測試人員的豐富經(jīng)驗來(lái)制定。
· 錯誤數據：顯而易見(jiàn)，錯誤數據就是編寫(xiě)與程序輸入規范不符的數據從而檢測輸入篩選、錯誤處理等程序的分支。
由于執行測試用例的數據量巨大以及還要進(jìn)行回歸測試，所以可以考慮使用自動(dòng)測試工具，但提取測試數據仍要依靠編寫(xiě)測試用例人員的經(jīng)驗。并且，我們還要注意到自動(dòng)測試也許不能找到程序中所有錯誤，手動(dòng)測試所找到的錯誤會(huì )比自動(dòng)測試所找到的要多。
有了測試用例，我們就可以進(jìn)行測試了吧？許多公司也是這樣做的，但在這里我建議大家最好要先進(jìn)行代碼的審議。通過(guò)代碼審議找到的錯誤可以比測試用例測試所能找到的錯誤更加深入，并且發(fā)現錯誤的時(shí)間也比測試用例要早。代碼審議要以代碼標準（根各公司具體情況自行制定）為依據，一般情況下要檢查以下幾點(diǎn)：
· 代碼風(fēng)格和規則審核
· 程序設計和結構的審核
· 業(yè)務(wù)邏輯的審核
代碼風(fēng)格和規則的審核是在每個(gè)程序員完成一個(gè)模塊或類(lèi)的 時(shí)候要進(jìn)行編碼規范的檢查。要召開(kāi)審核會(huì )議讓所有的項目組人員都參加。在會(huì )前項目經(jīng)理要做一個(gè)檢查表，以表的內容為檢查依據，檢查表的內容主要是檢查的要點(diǎn)。在審核會(huì )上項目組的每一個(gè)人員都能看到自己和其他人員的編碼問(wèn)題，從而起到預防的作用。這些問(wèn)題都要被解決，并且解決的結果要在審議會(huì )上被確認。
進(jìn)行程序設計和結構的審議是因為開(kāi)發(fā)工具的不同和項目時(shí)間的限制而造成設計不詳細。比較深入的設計通常是在編碼階段完成的，但由于程序人員和設計人員的經(jīng)驗是不同的，所以會(huì )出現很大的問(wèn)題。我們引入了程序設計和結構審核來(lái)保證質(zhì)量。審核人員要有先進(jìn)的技術(shù)開(kāi)發(fā)經(jīng)驗。在審核之前也要一個(gè)審核列表，列出主要幾項，如：程序的概要、詳細設計。但僅局限于列表是不夠的，審議人員 還要審議程序的精巧度和具有創(chuàng )造力的方面，這只能靠經(jīng)驗而不能只靠列表中的內容來(lái)審議。對于不同的程序員所檢測代碼的寬度和深度也是不同的。項目經(jīng)理可以根據程序員經(jīng)驗的不同制定被審議人員的寬度和深度。例如：年輕的程序員要審議所有代碼。但有經(jīng)驗的就可適當減少。
業(yè)務(wù)邏輯性審議必須要在代碼完成后審議。業(yè)務(wù)邏輯審議實(shí)際上是審議單元模塊的功能。這些功能是以系統說(shuō)明為依據的。審議人員要有開(kāi)發(fā)的經(jīng)驗并且對系統也要熟悉。審議人員通過(guò)執行程序從而了解底層代碼的狀態(tài)。這階段的審議實(shí)際也包含了前兩種審議，因為審議者也可以通過(guò)最后的結果檢測單元模塊設計和結構的準確性。
以上三種審議都要耗費一定的時(shí)間和資源，但是它卻能更早地發(fā)現和解決不易顯現的錯誤。
審議通過(guò)后，我們終于可以使用用例來(lái)進(jìn)行代碼測試和調試了。代碼的調試是用來(lái)保證程序能按照系統需求正常運行的一種手段。但是我所提到的這種代碼調試并不是簡(jiǎn)單的調試，它要包括以下兩部分：
· 特征調試
· 代碼覆蓋調試
首先我們要先進(jìn)行特征調試。它是通過(guò)運行程序找到代碼中的錯誤，這與我們平時(shí)常進(jìn)行的調試相同。到程序能運行后，我們可使用已編好的三種類(lèi)型的用例并以正常數據測試用例進(jìn)行測試，若不能正常運行則要用調試工具調試。在這階段，我們要用大量正常數據去測試。測試后，該程序應可在絕大多數的正常數據中運行。
其次，我們要進(jìn)行代碼覆蓋測試，一直要達到以下目標為至：
· 測試到每一個(gè)最小語(yǔ)句的代碼
· 測試到所有的輸出結果
我們應該通過(guò)一步步的調試去運行每個(gè)程序的所有語(yǔ)句和分支。如果我們想要百分之百地覆蓋就應適當運用邊緣數據和錯誤數據。測試在這個(gè)階段的質(zhì)量是難以掌握的。它基于程序員的責任心和經(jīng)驗。當這階段完成后，每個(gè)程序員所測的深度也是不同的。因此，在這個(gè)測試階段之前，項目經(jīng)理（或測試工程師）應制定出測試指導和計劃書(shū)。它們至少應包括以下內容：
· 測試的主要對象
· 主要調試點(diǎn)
· 怎樣測試
· 什么時(shí)候可以完成
至今為至，我們已完成了代碼的審議和調試。如果我們是嚴格按照以上步驟做的，那就可以保證代碼沒(méi)有太多的錯誤，至少沒(méi)有使程序運行中斷的錯誤了。如果我們不能很好地執行代碼審議和正確的調試，那我們就不能順利地通過(guò)測試，有時(shí)我們還要不得不返回來(lái)做這些事。
好了，我們終于完成了單元測試的工作，程序員們可以喘口氣了，但不要忘記還有更加嚴格的集成測試要我們去做。
延伸閱讀
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/