本文翻译自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转变到更敏捷状态的策略。你需要一种解决方案来允许你在一天内多次运行测试，让那些已经需要三个小时完成的测试回到原先的状态。
在你尝试使用这个策略让你的测试套件恢复原形之前，思考一下“单元测试”的基本概念可能会有所帮助。“我家有一只动物”和“我喜欢汽车”这样的陈述不是非常明确，所以，不幸的是，“我们编写单元测试”也不明确。现在，但愿测试泛指一切。
思考前面的两个关于动物和汽车的陈述：它们产生了很多疑问。例如，你家里有什么动物？是猫、蜥蜴还是熊？“我家有一只熊”与“我家有一只猫”完全不同。同样的，“我喜欢汽车”对于与汽车销售商交谈时没有帮助。你喜欢哪种车：运动车、卡车或者大货车？不同的答案会将你引入不同的路径。
同样，对于开发人员进行测试，根绝测试类型分类是有所帮助的。这样做更加精确，能够允许你的团队以不同的频度运行不同类型的测试。分类是避免恼人的运行所有“单元测试”的三小时build的关键方法。
文章来源于领测软件测试网 https://www.ltesting.net/
