本文翻譯自IBM DeveloperWorks上的一篇文章，該文講述了測試分類(test categorization)的概念，本身這個概念很簡單，但是卻實際的解決我們常見的問題，在我們的測試龐大到一定地步的時候，測試的運行時間過長，維護成本很高，我們如何能夠保證持續集成(CI)的正常運行？那就是通過測試分類。所以我翻譯了這片文章，希望對大家有所幫助。
原文：In pursuit of code quality: Use test categorization for agile builds
原文作者：Andrew Glover is president of Stelligent Incorporated, which helps companies address software quality with effective developer testing strategies and continuous integration techniques that enable teams to monitor code quality early and often. Check out Andy's blog for a list of his publications.
大家都同意開發人員的測試很重要，但是為什么要花這么長的時間運行測試呢？這個月，Andrew Glover將給我們講述對于系統來說需要保證運行的三類測試，并且告訴你如何根據分類整理和運行測試。結果將會奇跡般的減少build的時間，即使是面對當今龐大的測試集。
如果不太難過的話，假想一下你是一個2002年初剛剛建立的公司的開發人員。在淘金熱潮中，你和你的同事已經決定使用最流行最強大的Java API來開發一個龐大的數據驅動的Web應用程序。你可你的管理團隊堅定的信仰敏捷過程。從第一天開始，就使用JUnit編寫測試，并且通過Ant build腳本盡可能頻繁的運行它們。最后，你們還會使用cron（*nix下的一個定時運行腳本的任務）來進行nightly build。再然后，某些人可能會下在CruiseControl然后把測試寫成套件，然后在每次check-in時執行（持續集成）。
現在回到今天。
經過了前幾年的磨練，你的公司已經開發了數量巨大的代碼，當然也有同樣龐大的JUnit測試。一年前所有的事情都運轉良好，當你的測試套件有超過2000個測試，人們開始注意到build過程可能要執行三個小時以上。幾個月以前，你停止通過代碼提交來處罰持續集成（CI）運行單元測試，因為CI服務器會因此過渡繁忙。你改為進行nightly測試（每日測試），第二天早上開發人員可能會頭疼測試為何失敗。單元測試工具
最近，測試套件似乎很難在晚上運行一次以上了——這是為什么呢？它們永遠運行不完！沒有人會用幾個小時的時間來等待確認代碼運行是正常的（或不正常）。所以，整個的測試會在晚上運行，對么？
因為你如此頻繁的運行測試，他們總是充滿了問題。（譯者注：你會開始懷疑是不是測試也出了問題，是否想測試你的測試？）從而，你和你的團隊開始懷疑單元測試的價值：如果代碼質量并不那么重要，為什么我們要承受這種痛苦？假如你可以用敏捷的方法運行它們的話，你們完全同意這是單元測試的基本價值。
嘗試測試分類（test categorization）
你需要的是一個讓你的build轉變到更敏捷狀態的策略。你需要一種解決方案來允許你在一天內多次運行測試，讓那些已經需要三個小時完成的測試回到原先的狀態。
在你嘗試使用這個策略讓你的測試套件恢復原形之前，思考一下“單元測試”的基本概念可能會有所幫助�！拔壹矣幸恢粍游铩焙汀拔蚁矚g汽車”這樣的陳述不是非常明確，所以，不幸的是，“我們編寫單元測試”也不明確�，F在，但愿測試泛指一切。
思考前面的兩個關于動物和汽車的陳述：它們產生了很多疑問。例如，你家里有什么動物？是貓、蜥蜴還是熊？“我家有一只熊”與“我家有一只貓”完全不同。同樣的，“我喜歡汽車”對于與汽車銷售商交談時沒有幫助。你喜歡哪種車：運動車、卡車或者大貨車？不同的答案會將你引入不同的路徑。
同樣，對于開發人員進行測試，根絕測試類型分類是有所幫助的。這樣做更加精確，能夠允許你的團隊以不同的頻度運行不同類型的測試。分類是避免惱人的運行所有“單元測試”的三小時build的關鍵方法。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
