單元測試簡析 ZT

   軟體測試是保證軟體産品品質的重要手段之一。它是測量、評估軟體産品特點和能力的活動。現在，國内一些軟體企業對于軟體測試的重視程度還很不夠，認為測試工作非常簡單，隻是簡單地操作所測的軟體産品而已。這種錯誤的思想嚴重影響了國内軟體品質，應該引起我們的高度重視。 　　軟體測試階段可以分為若幹個小的階段，階段的劃分有多種，我現在按流程順序将其分為四個階段：

　　· 單元測試：由項目小組完成

　　· 內建測試：由項目小組完成

　　· 系統測試：由專業測試小組完成

　　· 交接測試：使用者和開發商共同完成。

　　

    測試的四個階段完全逆向檢測了軟體開發的各個階段。單元測試主要是測試程式代碼，內建測試主要是對設計的檢測，系統測試主要測試了軟體的功能，交接測試主要是對使用者需求的一種檢測。但是每個測試階段仍要對其它測試階段的測試内容加以測試，隻是測試重點不同。

    在這篇文章中，我隻對單元測試流程加以闡述，而不涉及具體的測試方法。關于測試方法（如：使用手工測試還是自動測試）若有機會将在其它文章中進行闡述。

    在單元測試前，先讓我們明白以下幾個問題，這可以使我們對單元測試更加清晰。

　　· 單元測試的目标：　確定子產品被正确地編碼

　　· 由誰去做：　　　　通常由程式人員測試

　　· 怎樣去測試：　　　功能測試可以用黑匣測試方法，代碼測試可用白匣測試方法　

　　· 什麼時候可以停止：當程式員感到代碼沒有缺陷時

　　· 記錄：　　　　　　通常沒有記錄

    我們在清楚以上問題後就可以編寫測試用例了。測試用例是輸入、執行條件和一個特殊目标所開發的預期結果集合。它按測試目的不同可分為以下幾種類型：

　　· 需求測試用例：測試是否符合需求規範

　　· 設計測試用例：測試是否符合系統邏輯結構

　　· 代碼測試用例：測試代碼的邏輯結構和使用的資料

    需求測試用例通常是按照需求執行的功能逐條地編寫輸入資料和期望輸出。一個好的需求用例是可以用少量的測試用例就能夠覆寫所有的程式功能。

    設計測試用例檢測的是代碼和設計是否完全相符。是對底層設計和基本結構上的測試。設計測試用例可以涉及到需求測試用例沒有覆寫到的代碼空間（例如界面的設計）。

    代碼測試用例是基于運作軟體和資料結構上的。它要保證可以覆寫所有的程式分支、最小的語句和輸出。

以上三種用例所用的資料又可分為正常資料、邊緣資料和錯誤資料。

　　· 正常資料：在測試中所用的正常資料的量是最大的，而且也是最關鍵的。少量的測試資料不能完全覆寫需求，但我們要從中提取出一些具有高度代表性的資料作為測試資料，以減少測試時間。

　　· 邊緣資料：邊緣測試是界于正常資料和錯誤資料之間的一種資料。它可以針對某一種程式設計語言、程式設計環境或特定的資料庫而專門設定。例如若使用sql server資料庫，則可把sql server關鍵字（如：';as;join等）設為邊緣資料。其它邊緣資料還有：html的html;<>等關鍵字以及空格、@、負數、超長字元等。邊緣資料要靠測試人員的豐富經驗來制定。

　　· 錯誤資料：顯而易見，錯誤資料就是編寫與程式輸入規範不符的資料進而檢測輸入篩選、錯誤處理等程式的分支。

    由于執行測試用例的資料量巨大以及還要進行回歸測試，是以可以考慮使用自動測試工具，但提取測試資料仍要依靠編寫測試用例人員的經驗。并且，我們還要注意到自動測試也許不能找到程式中所有錯誤，手動測試所找到的錯誤會比自動測試所找到的要多。

    有了測試用例，我們就可以進行測試了吧？許多公司也是這樣做的，但在這裡我建議大家最好要先進行代碼的審議。通過代碼審議找到的錯誤可以比測試用例測試所能找到的錯誤更加深入，并且發現錯誤的時間也比測試用例要早。代碼審議要以代碼标準（根各公司具體情況自行制定）為依據，一般情況下要檢查以下幾點：

　　· 代碼風格和規則稽核

　　· 程式設計和結構的稽核

　　· 業務邏輯的稽核

    代碼風格和規則的稽核是在每個程式員完成一個子產品或類的 時候要進行編碼規範的檢查。要召開稽核會議讓所有的項目組人員都參加。在會前項目經理要做一個檢查表，以表的内容為檢查依據，檢查表的内容主要是檢查的要點。在稽核會上項目組的每一個人員都能看到自己和其他人員的編碼問題，進而起到預防的作用。這些問題都要被解決，并且解決的結果要在審議會上被确認。

    進行程式設計和結構的審議是因為開發工具的不同和項目時間的限制而造成設計不詳細。比較深入的設計通常是在編碼階段完成的，但由于程式人員和設計人員的經驗是不同的，是以會出現很大的問題。我們引入了程式設計和結構稽核來保證品質。稽核人員要有先進的技術開發經驗。在稽核之前也要一個稽核清單，列出主要幾項，如：程式的概要、詳細設計。但僅局限于清單是不夠的，審議人員 還要審議程式的精巧度和具有創造力的方面，這隻能靠經驗而不能隻靠清單中的内容來審議。對于不同的程式員所檢測代碼的寬度和深度也是不同的。項目經理可以根據程式員經驗的不同制定被審議人員的寬度和深度。例如：年輕的程式員要審議所有代碼。但有經驗的就可适當減少。

    業務邏輯性審議必須要在代碼完成後審議。業務邏輯審議實際上是審議單元子產品的功能。這些功能是以系統說明為依據的。審議人員要有開發的經驗并且對系統也要熟悉。審議人員通過執行程式進而了解底層代碼的狀态。這階段的審議實際也包含了前兩種審議，因為審議者也可以通過最後的結果檢測單元子產品設計和結構的準确性。

    以上三種審議都要耗費一定的時間和資源，但是它卻能更早地發現和解決不易顯現的錯誤。

    審議通過後，我們終于可以使用用例來進行代碼測試和調試了。代碼的調試是用來保證程式能按照系統需求正常運作的一種手段。但是我所提到的這種代碼調試并不是簡單的調試，它要包括以下兩部分：

     · 特征調試

　  · 代碼覆寫調試

    首先我們要先進行特征調試。它是通過運作程式找到代碼中的錯誤，這與我們平時常進行的調試相同。到程式能運作後，我們可使用已編好的三種類型的用例并以正常資料測試用例進行測試，若不能正常運作則要用調試工具調試。在這階段，我們要用大量正常資料去測試。測試後，該程式應可在絕大多數的正常資料中運作。

    其次，我們要進行代碼覆寫測試，一直要達到以下目标為至：

　　· 測試到每一個最小語句的代碼

　　· 測試到所有的輸出結果

    我們應該通過一步步的調試去運作每個程式的所有語句和分支。如果我們想要百分之百地覆寫就應适當運用邊緣資料和錯誤資料。測試在這個階段的品質是難以掌握的。它基于程式員的責任心和經驗。當這階段完成後，每個程式員所測的深度也是不同的。是以，在這個測試階段之前，項目經理（或測試工程師）應制定出測試指導和計劃書。它們至少應包括以下内容：

　　· 測試的主要對象

　　· 主要調試點

　　· 怎樣測試

　　· 什麼時候可以完成

    至今為至，我們已完成了代碼的審議和調試。如果我們是嚴格按照以上步驟做的，那就可以保證代碼沒有太多的錯誤，至少沒有使程式運作中斷的錯誤了。如果我們不能很好地執行代碼審議和正确的調試，那我們就不能順利地通過測試，有時我們還要不得不傳回來做這些事。

    好了，我們終于完成了單元測試的工作，程式員們可以喘口氣了，但不要忘記還有更加嚴格的內建測試要我們去做。