【001】沒有人希望查看別人是如何設計測試類的。如果每個人都有不同的設計測試類的方法，光維護被測試的類就夠煩了，誰還顧得上維護測試類？
Junit是一個迴歸測試框架，所謂框架就是他的作者Erich Gamma 和 K ent Beck 定下了一些條條框框，你編寫的測試代碼必須遵循這個條條框框：繼承某個類，實現某個接口。其實也就是我們前面所說的規範。好在JUnit目前得到了大多數軟件工程師的認可。遵循JUnit我們會得到很多的支持。如果沒有一定的規範，測試類的編寫將會成爲另一個需要定義的標準。
【002】另外有一點我不想提，但是這個問題太明顯了，測試類的代碼多於被測試的類！這是否意味這雙倍的工作？
不！1）不論被測試類的方法如何複雜，測試代碼中的類的方法只會保持一樣的代碼量。2）提高軟件的質量並解決軟件熵這一問題並不是沒有代價的。測試代碼中的類就是代價。我們目前所能做的就是儘量降低所付出的代價：我們編寫的測試代碼要能被維護人員容易的讀取，我們編寫測試代碼要有一定的規範。
【003】什麼是軟件熵？
有一個聰明人提出了軟件熵（software entropy）的概念：一個程序從設計很好的狀態開始，隨着新的功能不斷地加入，程序逐漸地失去了原有的結構，最終變成了一團亂麻。
【004】怎麼樣編寫的測試代碼才能真正發現問題？
要注意編寫一定能通過的測試代碼（如以前舉的例子）並沒有任何意義，只有測試代碼能幫助我們發現bug，測試代碼纔有其價值。此外測試代碼還應該對工作代碼進行全面的測試。如給方法調用的參數傳入空值、錯誤值和正確的值，看看方法的行爲是否如你所期望的那樣。可以在網上搜索別人總結的一些經驗。
【005】什麼是斷言？
斷言是一個布爾語句，該語句不能爲假，如果爲假，則表明出現了一個bug。我是在使用Jmeter時知道這個詞語的，當時還納悶這個詞什麼意思？使用Rational或MI公司自動化測試工具的人一定知道其中的一個術語“檢查點”（或稱爲驗證點），我們可以把斷言理解爲檢查點或驗證點。
注：以下006-013摘自人民郵電出版社出版王東剛編著的《軟件測試與Junit實踐》一書，該書最大的特點在於“學以致用”，是作者經驗的積累，推薦閱讀。
【006】白盒測試用例應該怎麼寫?
不管哪種測試用例,都不可避免地再內容中涉及到三類數據:正常數據、邊界值和錯誤數據。由於執行測試用例的數量巨大以及還要進行迴歸測試，所以必須使用自動化測試工具，但提取測試數據仍要依靠編寫測試用例人員的經驗。
【007】類測試和傳統單元測試有什麼區別？
類測試和傳統測試略有不同，這是由於類的構造和其實現方式的特殊性造成的，所以對類的測試更爲複雜。傳統單元測試注重單元之間的接口測試，也就是說每個單元都有自己的輸入輸出接口，在調用中如果出現了嚴重錯誤，那麼這些錯誤也事因爲單元之間接口的實現引發的，和單元本身並沒有什麼直接關係。
而在面向對象的世界裏，每一個類就是一組最小的交互單元，其內部封裝了各種屬性和消息傳遞方式。類被實例化後產生了對象，每個對象都有相對的聲明週期和活動範圍，在這個範圍內，類測試除了測試類中包含的類方法，還要測試類的狀態，這是傳統單元測試所沒有的。
【008】類的測試用例需要注意什麼？
類的測試用例需要確保類實例完全滿足類的設計描述，對某個類進行測試除了要確保它能實現預定的設計外，還要關注這個類和其它類之間的特殊關係（可能是關聯、是實現或者是依賴於等），如果類的測試用例只能覆蓋優先的實現單元，則降低了整個測試用例的有效執行過程，或者需要投入更多的資源製作更多的測試用例來測試類，後期的測繪用例維護也是非常困難的。
【009】類的測試過程是怎麼樣的？
測試驅動驅動蓋該類的測試用例，根據測試用例的指定情況生成用例所需要的測試環境和實例。在這個測試環境中，測試驅動向實例發送一個或者多個需驗證消息，然後根據實例狀態變化、響應值、返回參數和結果，來判斷驗證消息是否通過。在所有測試用例驗證項目執行後，測試驅動釋放所有的已生成的實例和值域。
如果類包含了靜態屬性或者靜態方法，同樣需要對其進行測試。這些靜態屬性和方法屬於類本身，表明該類本身就是個對象，無須實例化就可以直接調用這些屬性和方法。
【010】類需要測試到什麼程度？
類的測試程度取決於測試了多少類實現和類描述，並且不同類的測試程度估算比較困難，比如接口類中包含了1組方法，有個具體類實現了它，我們在具體類的測試用例中加入了該接口方法的測試，如果該具體類的其他實例方法沒有和任何類交互，那麼改類的測試覆蓋率就是100％。每個類被實例化後都有自己的狀態，狀態影響操作的具體含義。對於任何一個類進行測試都需要進行綜合考慮，窮舉是一種無效率的工作方法，我們可以採用組合測試或者在多個測試用例中抽取重要的、覆蓋面最大的測試用例執行測試。
【011】如何確定類測試用例？
類測試用例的確定和構造取決於準確的類描述，而類描述可能包含類UML設計、類CRC卡片和類狀態機等工作。在類測試中介入了兩種工作角色（設計人員和實現人員），這樣避免了實現人員在類實現期間因誤解了類描述，而將錯誤帶入測試用例中，造成測試不準確或者測試失效現象。如果類沒有匹配的描述工作，請設計人員不上，雖然可以採用“逆向工程”導出類描述，但是這樣的類描述是欠缺的。
1、根據前置和後置狀態確定測試用例
測試用例根據前置和後置條件來確定，其具體實現形式爲各個測試方法體，並且在前置條件中指定輸入值（包括常見值和邊界值）來增加測試用例的測試覆蓋率，每一個測試用例都可以包含特殊的前置條件（即錯誤前置條件）來觀察測試用例失敗後的異常處理機制是否正確。根據類描述得出測試用例的前置和後置條件，並且根據前置和後置條件的不同組合方式產生不同的測試用例具體測試方法體。
2、根據狀態轉換確定測試用例
很多人習慣用狀態轉換圖來確定測試用例而不是根據測試用例的前置條件和後置狀態，在狀態圖中類關聯行爲明顯很容易被測試者辨別，但是這同樣要求測試這需要設定更多的特殊值驗證類關聯關係（例如使用極端的輸入值引起了補課預料的狀態崩潰），並且使用狀態轉換圖很難確定所有的測試用例。
3、根據代碼確定測試用例
【012】如何構造類測試驅動？
RUP中測試的概念是測試優先於設計，而在XP中則表現爲測試優先於編程。測試驅動的基本思想就是在對設計（或編碼）之前先考慮好（或寫好）測試代碼，這樣，測試工作就不僅僅是測試，而成爲設計（或代碼）的規範了。
類測試驅動器是運新幹一個或者多個測試用例的可執行程序，編寫類測試驅動有三種方法，分別是（1）調用Main方法、嵌入靜態測試方法和實現獨立測試類。（2）在類種嵌入靜態測試方法，通過調用該測試方法來收集每個測試用例的執行結果。（3）實現獨立的測試類。3種類測試驅動的編寫方法在執行測試用例和獲取執行後測試結果的效果是一樣的，建議使用第三種測試驅動編寫方式。
【013】類的測試方式有哪些？
類有三種不同的測試方式：
1、功能測試接口：測試用例根據類描述確定；
2、構造測試接口：測試用例着重測試類的構造（類可能包含多條構造方法）；
3、交互測試接口：測試用例測試發送消息對一個對象的操作是否正確。
確定這些測試接口是爲了後續維護的方便，它也體現了我們遵循何種規則來確定測試用例，並且關係到類的變化對測試用例的影響，表現了使用TestCase的行爲實現。
如果類在具體實例化過程種出現了變化，那麼就需要調整對應的測試驅動程序。
【014】Junit常用的接口和類
1、Test接口：運行測試和收集測試結果；
2、TestCase抽象類：定義測試中固定方法；
TestCase是Test接口的抽象實現（不能被實例化，只能被繼承）
3、Assert靜態類：一系列斷言方法的集合；
4、TestSuit測試包類：多個測試的組合
TestSuit類負責組裝多個TestCase,待測得類中可能包括對被測類的多個測試，而TestSuit負責收集這些測試，使我們可以在一個測試中，完成全部的對被測類的多個測試。
補充：一個測試成爲TestCase（測試用例）,而一組TestCase構成Testsuite（測試套件）。
【015】Junit編寫測試類的基本步驟：
1>擴展TestCase類；
2>覆蓋runTest()方法（可選）；
3>寫一些testXXXXX()方法；
【016】Junit一些具體的編寫測試代碼的技巧或較好的實踐方法：
1.不要用TestCase的構造函數初始化Fixture，而要用setUp()和tearDown()方法。
2.不要依賴或假定測試運行的順序，因爲JUnit利用Vector保存測試方法。所以不同的平臺會按不同的順序從Vector中取出測試方法。
3.避免編寫有副作用的TestCase。例如：如果隨後的測試依賴於某些特定的交易數據，就不要提交交易數據。簡單的會滾就可以了。
4.當繼承一個測試類時，記得調用父類的setUp()和tearDown()方法。
5.將測試代碼和工作代碼放在一起，一邊同步編譯和更新。（使用Ant中有支持junit的task.）
6.測試類和測試方法應該有一致的命名方案。如在工作類名前加上test從而形成測試類名。
7.確保測試與時間無關，不要依賴使用過期的數據進行測試。導致在隨後的維護過程中很難重現測試。
8.如果你編寫的軟件面向國際市場，編寫測試時要考慮國際化的因素。不要僅用母語的Locale進行測試。
9.儘可能地利用JUnit提供地assert/fail方法以及異常處理的方法，可以使代碼更爲簡潔。
10.測試要儘可能地小，執行速度快。