|
by Peter Varhol 來自發賽特網站 我以前曾經談到過關于程序的性能以及性能測試的問題，即以提供工具和技術為目標，通過使用JavaServer Pages （JSP）使用戶提高分布式程序的開發。通過性能測試能夠確保程序滿足用戶關于實現有效的互用性的需求。同樣地，加載測試還能夠確保在用戶大量增加時持續滿足所有用戶的需求。 然而測試是一個比普通的性能測試和加載測試內容更廣泛的行為，它是所有軟件開發過程中的必須過程。同時它能幫助你養成一個良好的測試習慣，即使是對一種新技術的研究也是如此。通過測試能夠看到你的代碼會在哪里出錯，然后可以根據提示信息對出錯的地方進行更正，并以此提高你這方面的技術。 為了使程序開發更為嚴謹，你就得接受更大的挑戰。測試不僅是為了找到程序的錯誤，更確切地說，你應該把出錯的定義加以擴大，使它不但包括程序的錯誤，還包括在什么地方不能滿足用戶的需求，以及程序是否按照你希望的那樣運行。如果你寫代碼是為了自己的程序，那么你也許能夠容忍程序無法實現你所有需求，或是看起來有點怪。而如果是作為商業目的，則能否滿足用戶需求以及提供完美的用戶體驗將成為決定全部工作成功與否的關鍵。 為了滿足用戶的需求，必須對程序進行測試，這不僅是為了保證質量，而且是為了保證程序和既定的目標相符合。話雖如此，但在實踐中卻很難做到，因為用戶常常沒有一個清楚的需求，而且開發人員也很少能專心地研究這些這些需求。在一個高價程序開發環境下，開發小組要求具備有追溯能力（traceability）的軟件以實現按需求進行編碼以及全程跟蹤直至完成。 很難實現既滿足質量要求又符合用戶需求的測試，這常常是程序做得很爛的借口，同時也是企業對程序開發的某種商業托詞。這些情況的發生往往不是因為軟件開發的很失敗，而是因為測試程序出了問題。 這就是為什么我要強調測試驅動開發的原因了。我曾花時間研究過整套測試的方法，結果我選擇了測試驅動開發。測試驅動開發是由Peter Coad定義的一個開發式樣： 編寫和保持一套詳盡的單元測試。 要先建立相關的單元測試和驗收（acceptance）測試，然后根據測試編寫代碼。 由測試來決定如何編寫代碼。 這種觀點強調在寫程序之前先寫測試，這會使開發人員更清楚應該在程序中加入何種性能，以及如何使這些性能良好地運行。編寫適合的測試會使開發人員清除各種矛盾以滿足用戶需求。 對大多數程序代碼的編寫來說，這種觀點是正確的，由于許多需求并不明確或并不完整，開發人員不得不花時間把它弄清楚或是根據以往的實踐經驗來選擇一個較好的辦法。如果所有不明確的問題都能在寫測試的時候首先被解決，那么就會使之后復雜的編寫代碼工作變得很輕松。 先寫測試還會帶來一些心理上的影響。如果開發人員在寫代碼之前先寫測試，他們就會更多地考慮到用戶的需求，而如果讓他們先寫代碼，那么他們自然會傾向于如何避免被測出程序上的錯誤。 順便提一下，如今測試驅動開發已經成為了軟件開發過程中不可或缺的一部分，而它是在15年前由the Department of Defense所定義的。由于該標準符合當時的情況，所以編寫代碼通常是整個過程的最后一步，你很清楚該寫哪一類型的代碼以及如何對它進行修改。盡管這樣會多花些時間，但結果通常能滿足最后的需求。 極端編程（Extreme Programming） 采用測試驅動開發是極端編程（Extreme Programming，簡稱XP）的一個特點。把它叫做極端編程 （www.extremeprogramming.org）可能有些用詞不當，因為它代表了傳統標準下定義的非傳統編程式樣，但它卻很符合通常的軟件工程實踐（software engineering practice）。一般來說，XP提倡將一個軟件項目劃分為一系列小的迭代期（increment），每個迭代期（周期為幾天）完成項目的一個小部分。迭代期確定的最終原則是讓用戶盡早拿到一個可用的早期版本，以便用戶提供反饋信息，并對項目進行互動性地更改或添加新的代碼。 XP還鼓勵配對編程（paired programming），就是讓能力相當的開發人員坐在一起編寫代碼，這通常能夠實現高度交互式編程。這樣做的目的是讓一對開發人員共同研究一個項目以實現其能力互補。 測試也是XP開發的重要一項。開發人員能從代碼的逐一測試中得到有用的反饋信息。單元測試是XP開發方法中的基石，開發人員必須確保在交貨前，所有的代碼均進行并通過了單元測試，以及所有功能均滿足用戶的需求。 然而XP并不適用于所有的項目或所有開發小組，比如無法將整個項目劃分為若干各迭代期或者開發人員的技能無助于合作編碼等。在某些情況下，開發條件無法保證對變化需求做出及時的響應。 此時你仍然可以采取測試驅動的辦法，而無須貿然使用XP。測試驅動開發使測試工作和開發工作的重要性處于同一級別，減少事后發現錯誤的情況。 測試框架是測試驅動開發的關鍵，尤其是在需要用大量測試來實現需求的情況下。如果你完全靠手工來執行測試，那么它會變成一個花費大量時間而且單調無味的工作。測試框架能夠使你的測試和開發環境相融合，指導測試程序，收集并顯示相關信息。 對于測試框架的選擇，我建議使用JUnit，它是一個來自于SourceForge Java foundry或者 www.junit.org 的open-source項目，它是由Erich Gamma 和 Kent Beck編寫的一個基于Java的測試框架，使單元測試融合到一個更大的測試框架里面以便更容易地增加、管理、執行測試，以及分析測試結果。 比如，你可以通過在TestCase的子類中增加一個名為myTest（）的測試方法來對它進行測試，JUnit測試方法是一個不帶任何參數的普通的方法。為了執行連續的多重測試，JUnit提供一個名為TestSuite的對象，它可以同時運行任意數量的測試。TestSuite對象中還可以包括多個小的TestSuites，以便每個開發人員能夠單獨處理其中一個TestSuite，然后再很方便地將它們結合到這個大的TestSuite中。 為了能夠自動執行測試，JUnit提供了一種工具，它可以用來定義suite運行并顯示其結果。為了使你的suite對于TestRunner是可存取的，你必須定義一個返回測試suite的靜止方法。JUnit提供兩種TestRunner類型。第一個是基于文本的TestRunner，該版本能夠以最快速度存取，而且適用于無需立即知道單個的測試是否成功的時候。另一個是圖解TestRunner，它在進入測試時顯示一個對話框，并在執行期間提供一個圖解過程指示。 TestRunner可以用在加載和卸載的配置中。在加載配置中，TestRunner在每一次運作中重新加載測試類。其結果是在改變代碼之后你無需重新啟動TestRunner，它能夠很好地實現stop-change-start這一連續動作。而在卸載配置中你必須在每次運行之后重新啟動TestRunner。 測試工作會逐漸減少在找出程序錯誤方面的功能，而越來越多地被用在衡量軟件的質量上。它能夠提供一種獲得數據的方法，該數據可以用在對開發過程的反饋中。但要實現這一點，你必須有一個良好的測試體系。 |
