|
|
˙為什麼要進行測試?
應用程式開發好了以後為什麼要進行測試的原因就是,測試越完整,系統的客戶滿意度越高,測試越完整,花在除錯的時間越少,程式開發的速度也會比較快。您可以想像一下使用者使用文書排版工具進行文件編輯排版時,執行了很多資料操作的步驟之後文書排版工具發生執行時期的錯誤,您所輸入的資料和修改資料的動作都附諸流水,使用者的心中做何感想?就可以知道軟體測試的重要性了。 |
|
|
|
|
|
˙測試的迷思
關於軟體測試,有很多說法必須要釐清,其中有一種說法是:軟體的bug要少,得先有一個專業的測試團隊,但是有了專業的測試團隊後,程式開發者反而會比較不注意自己所寫的程式是否強固。這個問題要如何解決呢?或許效法某大軟體公司,把程式開發者程式中找到的Bug數目做一個統計排行,然後把程式中bug數目最多的程式開發者調去擔任測試工程式師一段時間以茲警惕是一種不錯的做法。有關軟體測試還有一種不正確的說法,那就是程式開發者不應該自己測試自己所寫的程式,如果程式開發者自己不測試自己所寫的程式,那如何能知道應用程式可以發揮所需要的功能呢?所以程式開發者還是必須負責對自己開發的程式碼執行單元測試。 |
| |
|
|
|
˙Bug被發現的時機與成本的關係
根據專家的研究,修正應用程式錯誤的成本,每經過一個軟體開發階段就會增加10倍,所以由程式開發者自己發現程式中的錯誤,修復應程式中的錯誤成本最低,由程式開發者測試自己的程式時發現錯誤,修復應程式中的錯誤成本次之,由測試團隊發現錯誤,修復應程式中的錯誤成本會越來越高,如果直到產品整合測試時才發現錯誤,修復應程式中的錯誤成本更高,如果由應用程式的使用者回報錯誤,不但公司的商譽受損,而且重新部署修復錯誤後的應用程式的成本已經高到不容易估算了,由此可見完整的軟體測試對應用程式的重要性。 |
| |
|
|
|
˙Test-First Development
測試應用程式是否有錯誤時可以利用一種稱為Test-First Development(又稱為Test-Driven Development - TDD)的方法對所開發的應用程式進行測試,這種測試做法的特性是先寫Test Case,因為程式碼尚未製作好,所以測試一定會失敗,接下來就會製作好程式碼,讓Test Case可以測試成功,Test Case測試成功後才能寫下一個Test Case,然後才能再下一個功能讓新的Test Case可以測試成功。使用這種做法可以在寫Test Case時順便完成應用程式的製作,所以寫碼階段完成後同時也完成單元測試的工作了,不會對程式開發者產生沈重的負擔,是一種輕量級的應用程式測試方法(Agile Methodologies)。 |
| |
|
|
|
˙認識Unit Test
單元測試是在軟體開發的寫碼階段中進行,用意在確保程式開發者所寫的程式碼可以達到預期的功能,或是測試處理例外的功能是否可以正常運作,因為每次只測試某單元或介面的某項功能,所以稱為單元測試。 對程式開發者所開發的程式執行單元測試的好處,除了可以提升程式碼的品質,可以在對程式碼執行Refactoring之後重新測試,確保程式碼沒有因為Refactoring之後產生新的bug。執行單元測試不但可以符合軟體開發的標準,同時執行單元測試後,也可以把Test Case留下來當做測試文件。 當我們在開發應用程式時可以結合Test-First Development的精神執行單元測試,一邊開發專案一邊進行測試,等測試工作完成,專案也做好了,不但開發好的程式碼可以交差,而且執行測試所建立的Test Case也可以留下來當做測試文件。 |
| |
|
|
|
˙什麼是NUnit?
使用人工對軟體進行測試是一件枯燥乏味的事情,每一次執行測試時都要重覆輸入相同的資料,並驗証測試的結果是否正確,不僅無聊,而且缺乏創意,因此很多人不願意擔任軟體測試的工作。不過這一切都會因為NUnit的出現而改觀,因為使用NUnit進行單元測試可以達到自動測試的效果,您可以製作好一堆Test Case,然後再交給NUnit進行自動測試即可,不會有枯燥乏味的感覺。 NUnit是所有.NET語言適用的單元測試工具,其遵循的是X-Unit的標準,和Java語言使用的JUnit具有類似的功能。NUnit提供命令列和圖形介面的測試工具,而且有公開的程式碼,讓您可以擴充其現有的功能,例如Nunit-AddIn和NUnitAsp就是擴充NUnit現有的功能,讓程式開發者可以直接從Visual Studio.NET的環境中直接執行自動單元測試,或是測試ASP.NET WebForm。 |