使用TestNG组或JUnit类别对测试进行分组的用例是什么？
我通常使用JUnit类别按功能将测试分组：单元测试，集成测试等。但是在我目前的团队中，我们只是进行了一次交谈，团队决定我们希望一直运行所有测试，因为他们看不到将测试分组的任何好处。
所以我很想知道这里的人是否将他们的测试分组以及为什么。
答案 0 :(得分：0)
有多种测试，JUnit和TestNG都支持它们。 对于单元测试，您可以全部运行它们并在几秒钟或几分钟内获得反馈。 当涉及到集成测试或端到端测试时，由于时间因素，您可能希望对测试进行分组。
比方说，您有单元测试，API测试，甚至还有GUI测试。
虽然每个构建都可以运行单元测试，但其他测试可能会花费很长时间。
示例：
在一个项目中，我进行了300多个GUI测试，并花了两个小时才能并行运行它们。当我们为特定组件引入修补程序时，我们需要尽快部署它-我们将仅对该组件运行回归测试。那时候分组就可以处理了。
另一个例子： 在我当前的项目中，我有数据驱动的API测试。要测试组件，我必须执行5000个带有自动测试的请求，这最多需要30分钟。它仅用于1个组件，目前我们大约有14个。想象一下，运行一个完整的测试套件。
对于每次构建都进行完全回归的各种测试的解决方案对于持续集成/持续开发而言将是困难的。
另一种方法是仅运行冒烟测试，但是您仍然必须将测试分组或创建特定的Runner类（就像JUnit运行器或Cucumber运行器一样）以仅运行测试的一部分。
如果开发的版本不包含由于质量下降引起的错误，则自动化测试的全部目的是提供快速反馈。如果我们要等待几个小时的反馈。如果我们不能拥有它，我们将不得不延迟每个版本/构建（取决于我们运行这些测试的时间），甚至可能与我们与客户达成的SLA发生冲突。
更具体： 假设我们在支付系统中存在一个严重错误，并且根据SLA，我们必须在8小时内修复此类严重错误。开发人员修复了该错误，创建了一个应用程序构建以部署到测试环境，并且我们希望确保没有引入任何新的错误。自动化测试（包括单元测试，API测试和GUI测试）的完全回归可能要花费几个小时，但是我们只有这几个小时才能将更改介绍给客户（生产环境）。除了运行整个测试套件，我们还可以运行有关付款的一组测试。
希望有帮助