單元測試的實施 以VU為例

2021-04-22 19:36:46 字數 1988 閱讀 7242

單元測試由誰來做?單元測試由測試部門來做還是由開發部門來做,是乙個引起廣泛爭論的話題。我們的觀點是:由測試部門和開發部門共同來做:測試部門負責制定規範、培訓,並檢查測試效果;由開發部門負責具體的實施,最好是邊開發邊測試。

測試部門可能不具備實施單元測試的足夠人手,即使測試部門有足夠的人手,即使專案時間允許,完全由測試部門實施單元測試也會造成資源的較大浪費,因為測試人員要花很多時間來重新理解**,同時,充分的單元測試通常會發現很多細小的錯誤,程式設計師修改**時,又要再一次理解**;另一方面,如果等編碼基本完成再由測試部門進行單元測試,也就不能發揮單元測試對**整體結構的約束效果,測試部門拿到**時,往往會發現難於測試。當然,已經完成編碼的專案也不是不能進行單元測試,只不過可能要花費一定的時間成本對**進行整理重構,後文會有進一步的論述。

由開發人員實施單元測試,當然也有問題,主要有:一是程式設計師可能不喜歡做單元測試;二是開發部門可能擔心影響開發進度;三是由於思維定勢的原因,不容易保證測試的完整性。我們在設計vu的過程中,充分考慮了這三個問題,提供了切實可行的解決方法和工具。

很多開發人員不喜歡做單元測試,甚至抵制單元測試,對於這種現象,常見的說法是程式設計師太自信,覺得自己的**不會有錯,所以不願意進行單元測試。這種說法就好象在說程式設計師「自以為是,不負責任」,所以不願意做單元測試。事實是這樣的嗎?作為程式設計師,我們自己並無這種心理,也調查過一些程式設計師,沒有誰真的有這種心理,實際上,哪個程式設計師沒有翻江倒海地排查乙個小小錯誤的經歷?誰寫的**也不能保證毫無錯誤,人不是機器,即使程式設計時思維縝密到沒有任何疏漏,也還可能有「筆誤」呢。那麼,程式設計師為什麼不喜歡做單元測試呢?我們認為,主要還是程式設計師的工作特點造成的。程式設計是創造性的工作,程式設計的最大樂趣就在於看到了自己的勞動成果出現在眼前,這就使程式設計師常有一種「立即實現」的衝動;另一方面,程式設計師的思維往往是跳躍向前的,當程式設計師開始了程式設計思路之後,一般就不願意中斷思路,花較多時間去編寫測試**了;再一方面,跟測試工具也有一定關係,一般的單元測試工具只顯示「通過」,「失敗」兩種狀態,相對而言,在產品工程中直接****的執行結果更有吸引力,更容易產生成就感。

vu具有強有力的保證測試完整性的功能:輕鬆完成100%語句、條件、分支、路徑覆蓋,提供詳盡的測試報告和待測試檔案列表,隨時可以檢驗測試效果、找出遺漏**或未完成覆蓋的**,保證測試的完整性。

在具體的實施過程中,可以根據實際情況調整測試部門和開發部門的分工,例如,如果測試部門人手充裕,也可以由開發部門邊開發邊完成功能方面的測試,由測試部門完成白盒覆蓋和執行邊界測試。

單元測試的「單元」一般是指函式或類。以類為測試單元,如果模擬較複雜,測試會變得很複雜,即使是三五個成員變數,十個八個成員函式這樣乙個很普通的類,要考慮清楚類的功能,以類為考核物件進行完整的測試,也是很不容易的。我們認為,以函式為測試單元,更符合簡單實用的原則。物件導向的測試與面向結構的測試的主要區別在於,物件是有狀態的,物件導向的測試要考慮物件的狀態。物件的狀態是什麼?簡單點說就是成員變數的值,執行了某個操作後,物件的狀態有了變化,也就是物件的成員變數的值有了變化,我們可以把物件的狀態作為函式的輸入輸出的一部分:執行操作前物件的狀態也是一種輸入,執行操作後物件的狀態也是一種輸出。如果物件的每乙個操作,其輸出都是正確的,那麼,可以肯定這個物件在任何時候,其狀態都是正確的。

總的來說,單元測試越早越好。早到什麼程度?xp開發理論主張測試驅動開發,先編寫測試**,再進行開發,這樣的話,單元測試就不僅僅是測試,還是一種設計了。事物總有兩面性,這種方式不便於使用測試工具自動生成測試**,因為測試工具要先了解被測試物件的基本資訊才能生成測試**。我們主張,先編寫類的宣告,然後生成該類的測試類,先編寫函式的宣告,然後生成對應的測試函式,編寫產品函式的**時,每寫乙個功能點都執行測試,隨時補充測試用例,這樣可以最高效。

單元測試一般測試底層的業務類,中層的控制類,一般不測試邊界類(介面類),所以不要把業務**直接寫在邊界類裡。

除了很簡單的函式,例如getmember()/setmember(),其他函式都應該測試,而不要以是否公有來決定是否測試,因為私有函式也可能很複雜,同樣可能隱藏著錯誤。vu使用一種簡單的機制來區隔需測試的函式:在原始檔中編寫實現**的函式視為需測試的函式,在標頭檔案中編寫實現的函式(一般是簡單的內聯函式)視為不需要測試的函式。

單元測試的實施

關於單元測試的問題之前我們也進行過討論,但究竟如何實行 實行後能達到什麼樣的效果還沒有形成結論。下面是我的一些想法,大家一起 標準的單元測試應該完全由測試人員來完成,主要工作包括定義測試用例 編寫單元測試 測試 的執行和跟蹤 測試報告分析。依賴資源 需求文件 介面原型 設計文件 功能測試用例 生成製...

單元測試,測試用例 GO語言

資料夾目錄 split string split.go split string split test.go 執行測試函式 package split string import reflect testing 單元測試 可以和測試 放到一起,用同樣的包名 以測試 名開頭,以 test.go 結尾哦...

python單元測試用例設計

在剛學習程式設計的時候總是忘記處理一些特例 尤其是動態語言可以傳各種值 為了養成良好的程式設計和測試習慣,在編寫單元測試用例的時候,我們注意考慮下如下測試用例 等價類劃分 def binary search array,target if not array return 1 beg,end 0,l...