One thing that's possible special/peculiar about my scenario is that the job runs multiple TestNG suites and a subset of the tests (actual classes and methods) are run in every suite. These are the tests in the com.vmware.cloud.systemtests.tests.common.setup and com.vmware.cloud.systemtests.tests.common.teardown packages. (Each suite also runs suite-specific tests.)
What made me think to mention this is that in other jobs I'm seeing another duration-related anomalies related to these packages: The displayed duration of the package and of the test-containing classes they contain is wrong, although the displayed duration of each test method in the "Order of Execution by Test Method" table is correct. In the case of the former, the duration displayed for each class appears to be the time between the first execution of a test method in the class and the last execution of a test method in the class--across all the suites that were run in the job (instead of within each suite and then summed).
One thing that's possible special/peculiar about my scenario is that the job runs multiple TestNG suites and a subset of the tests (actual classes and methods) are run in every suite. These are the tests in the com.vmware.cloud.systemtests.tests.common.setup and com.vmware.cloud.systemtests.tests.common.teardown packages. (Each suite also runs suite-specific tests.)
What made me think to mention this is that in other jobs I'm seeing another duration-related anomalies related to these packages: The displayed duration of the package and of the test-containing classes they contain is wrong, although the displayed duration of each test method in the "Order of Execution by Test Method" table is correct. In the case of the former, the duration displayed for each class appears to be the time between the first execution of a test method in the class and the last execution of a test method in the class--across all the suites that were run in the job (instead of within each suite and then summed).