單元測試的一些酌見 軟件測試
自從從事這個行業以來，積累了一些經驗，今天一吐為快，和大家交流一下
1、對于一個項目，應該怎樣劃分在項目中需要測試的類和方法?
舉個例子，一個基于被封裝后的struts和EJB項目，哪些需要測試?在我看來，大而全是沒有必要的。
個人覺得，Action的單元測試屬于比較沒有用處的一個。因為在畫面疏通的過程中，擔當者對Action的測試會更加的仔細一些，基本上可以替代非常麻煩的Action單元測試。同時對于Form的測試在沒有特殊的方法追加的情況下，也可以省略掉。
然后是Dao層的測試是需要做的，但是針對非框架組成部分的成員來說，測試SQL語句應該就足夠了。CMP以及共通Dao的相關測試應該由框架來保證。
然后是service層的測試，用來做框架內部調用的代碼的測試可以主動地忽略掉，由框架開發者做出足夠的測試就可以了。只針對業務邏輯的相關方法進行測試。在這里順便提一提設計上的一個問題。如果有通用的業務邏輯處理的話，建議直接使用工具類的形式來提供，而不要使用父類方法然后子類繼承的方式，非常的不利于單元測試。(有不同意見的可以批評指正。)
2、由誰來完成測試類?
我比較傾向于測試和功能代碼的擔當者不要是一個人。并且寫測試的人要比寫代碼的人更加的熟悉詳細設計。寫測試和代碼的人不一定是詳細設計者，寫代碼的人可以看著詳細設計寫代碼，不一定要非常的熟悉設計者的思路，完成詳細設計的功能就可以了(當然，這個是相對的)。但是寫測試的人卻要清楚的知道每一步發生了什么，輸入了什么樣的對象，得到了什么樣的對象，中間會有什么樣的處理。
首先，測試的工作量一點也不小，絕對不是捎帶手就能做了的�；旧洗笠稽c的業務出現變更的時候，原來的對于該項邏輯的單元測試代碼返工量是會比較大的。如果想要做好修復BUG或者是業務變更后的單元測試，耗費的時間比修復BUG和業務變更的時間長很多。對于這個說法，我不知道其他人是否也是這樣認為的?當然，在項目組長給你足夠的時間的情況下，這個問題不是問題。
其次，當測試和功能代碼的擔當者分開之后，在項目里面，對于同一塊業務，就有了至少兩個人熟悉，不會出現只有一個人很明白，其他人都不清楚的尷尬局面。
第三，旁觀者清的道理。寫測試的和寫功能代碼的人互相都會有想不全面的地方，有一定的互補性。這樣的測試，比較能夠測試出代碼中的冗余代碼。
基本上我現在接觸到的項目沒有一個符合TDD的要求。有了解TDD的前輩請對我前面的觀點進行無情的批判和打擊，謝謝。
4、 在任務分配中，測試代碼做成需要的時間和功能代碼做成需要的時間比例多少是合適的?
個人認為測試和功能代碼的時間配比成2:1是一點也不過分的。在大的業務邏輯里面，測試數據的準備需要花很長的時間。
文章來源于領測軟件測試網 http://www.k11sc111.com/
