TestNG从入门到进阶：Java自动化测试框架核心能力与实战指南

如果你在Java技术栈里做测试开发，TestNG这个框架基本是躲不掉的。做接口自动化，很多人选TestNG；做Selenium、Appium的UI自动化，TestNG同样是很常见的那一层调度骨架。它不负责发HTTP请求，也不操作浏览器，它管的是更底层但又更关键的事：测试用例怎么组织、按什么顺序执行、数据怎么传进去、结果怎么聚合出来，以及整套测试计划能不能灵活地拆成多套场景跑。

这篇文章我打算换个聊法，不给你罗列一堆注解API就完事，而是从“它解决什么问题”“实际项目里怎么搭”“哪些坑我踩过”三个维度，把TestNG从入门到进阶拆开讲。刚开始学自动化测试的，照着我这份内容能把基础框架搭起来；已经在写用例但觉得项目结构越来越乱的，看完也能找到一些优化方向。TestNG看着简单，但真正把它用顺，里面有不少门道。

1. 先搞懂TestNG的定位：它凭什么成为Java自动化的主力

1.1 从JUnit到TestNG：纠结框架之前先看设计差异

Java生态里测试框架不是只有TestNG，JUnit的名气也不小。很多人一开始会有疑问：既然JUnit存在了这么多年，为什么做自动化测试时还是大量项目选择TestNG？

这里面有个历史背景。JUnit早期版本设计时主要面向单元测试，一个测试类里面一堆@Test方法，跑完看结果，简单直接。但自动化测试发展到接口和UI层面，情况就不一样了：你需要一套用例能根据环境切换参数，需要一批用例作为冒烟测试快速执行、另一批用例放到回归阶段跑，需要用例之间有先后依赖，需要在套件级别做初始化。JUnit 4时期这些能力要么缺失，要么用起来很别扭。

TestNG这个名字里的NG就是Next Generation，它从设计之初就瞄准了比单元测试更复杂的测试场景。它的核心思路是：测试用例不仅可以用注解描述，还可以通过XML文件在外部声明式配置。测试方法能分组、能参数化、能有依赖关系、能并发执行，这些能力对接口自动化和UI自动化来说几乎是量身定做的。虽然后来JUnit 5也补上了不少功能，但TestNG在项目里的存量生态和调度灵活性依然很能打。

我做接口自动化测试框架选型时对比过两边的体验。TestNG的参数化用@DataProvider直接返回Object二维数组，对业务数据的表达能力非常直接；分组能力配合testng.xml，能把一套代码拆成冒烟、回归、全量多套执行计划。对于一个中大型自动化项目，这种灵活度是真的省心。

1.2 TestNG到底强在哪：一张表看清核心能力

TestNG的能力可以分成几个维度，我习惯把它们看作自动化测试框架的基础设施清单：

这张表把TestNG的轮廓勾出来了。你看，TestNG的定位不是一个简单的“跑@Test方法”工具，而是一个完整的测试执行引擎。你写自动化测试时遇到的大多数工程问题，比如环境切换、数据准备、失败定位、CI集成，TestNG都提供了对应的解决方案。这也是为什么很多Java自动化测试岗位的JD里都写着“熟悉TestNG或同类测试框架”。

2. 十分钟跑通第一个TestNG用例：环境搭建与最小实践

2.1 Maven依赖与IDEA配置

搭TestNG环境不需要太折腾。基础要求是JDK 8以上，然后有个Java工程，Maven还是Gradle都行。我日常用Maven比较多，下面以Maven工程为例。

在pom.xml里加上TestNG依赖：

<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>7.10.2</version> <scope>test</scope> </dependency>

这里scope用test就够了，测试框架只需要在测试编译和执行阶段出现在classpath里。如果以后想让测试代码参与打包或者需要TestNG的注解参与某个运行时逻辑，再调整scope。

接着建议在pom.xml里配一下maven-surefire-plugin，让mvn test命令能正确加载testng.xml：

<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>3.2.5</version> <configuration> <suiteXmlFiles> <suiteXmlFile>testng.xml</suiteXmlFile> </suiteXmlFiles> </configuration> </plugin> </plugins> </build>

IDE方面，IDEA对TestNG的支持很完整，新建测试类的时候可以直接生成TestNG的@Test方法模板，右键就能运行。Eclipse需要装TestNG插件，现在用的人少了，就不展开了。

2.2 第一个测试类、断言与三种运行方式

写一个最简单的测试类感受一下。先准备一个被测试类：

public class Calculator { public int add(int a, int b) { return a + b; } public int divide(int a, int b) { if (b == 0) { throw new IllegalArgumentException("除数不能为0"); } return a / b; } }

对应测试类：

import org.testng.Assert; import org.testng.annotations.Test; public class CalculatorTest { @Test public void testAdd() { Calculator calculator = new Calculator(); Assert.assertEquals(calculator.add(2, 3), 5); } @Test public void testDivide() { Calculator calculator = new Calculator(); Assert.assertEquals(calculator.divide(10, 2), 5); } }

注意断言方法我用的org.testng.Assert，不是JUnit的org.junit.Assert。两边的类名容易搞混，import错了编译都不会报错，但写多了就会出现一些莫名其妙的行为差异。我之前见过同事把JUnit的@BeforeEach混在TestNG类里，结果初始化逻辑根本没执行，用例各种空指针，排查了半天才发现是注解引错了包。

运行方式有三种：

• IDEA里直接在测试类或方法上右键Run，适合开发调试阶段快速验证。
• 通过testng.xml驱动运行，适合项目级统一执行。
• 通过mvn test命令行运行，适合本地验证和CI流水线集成。

三种方式对应不同阶段，不是非此即彼。

2.3 testng.xml：把测试计划的控制权从代码手里拿回来

testng.xml是TestNG的核心配置入口，TestNG能够灵活地组织测试计划，很大程度靠它。先看一个最简配置：

<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd"> <suite name="计算器测试套件"> <test name="基础运算测试"> <classes> <class name="com.example.CalculatorTest"/> </classes> </test> </suite>

suite是整套测试计划的根节点，test是suite下面的执行单元。一个suite可以包含多个test，每个test可以配置不同的参数、分组、监听器，指向不同的测试类。这个结构意味着你可以在一个执行计划里灵活组合不同模块的用例。

我见过不少团队把测试类的选择完全交给IDE或代码里的注解，testng.xml反而没有发挥出应有的作用。实际上，当你需要控制“线上回归只跑哪些模块”“冒烟测试跑哪些用例”“哪个环境用什么baseUrl”时，testng.xml是比改代码更安全、更直观的入口。

3. 注解体系拆分：把测试生命周期握在自己手里

3.1 生命周期注解：一个用例从头到尾经历了什么

TestNG的注解体系非常丰富，上手第一步是理解生命周期注解的执行顺序。直接看代码：

import org.testng.annotations.*; public class LifecycleDemoTest { @BeforeSuite public void beforeSuite() { System.out.println("BeforeSuite：整个套件执行前"); } @BeforeTest public void beforeTest() { System.out.println("BeforeTest：当前test标签执行前"); } @BeforeClass public void beforeClass() { System.out.println("BeforeClass：当前测试类执行前"); } @BeforeMethod public void beforeMethod() { System.out.println("BeforeMethod：每个测试方法执行前"); } @Test public void caseA() { System.out.println("caseA"); } @Test public void caseB() { System.out.println("caseB"); } @AfterMethod public void afterMethod() { System.out.println("AfterMethod：每个测试方法执行后"); } @AfterClass public void afterClass() { System.out.println("AfterClass：当前测试类执行后"); } @AfterTest public void afterTest() { System.out.println("AfterTest：当前test标签执行后"); } @AfterSuite public void afterSuite() { System.out.println("AfterSuite：整个套件执行后"); } }

执行顺序是：

BeforeSuite -> BeforeTest -> BeforeClass -> BeforeMethod -> caseA -> AfterMethod -> BeforeMethod -> caseB -> AfterMethod -> AfterClass -> AfterTest -> AfterSuite

对应到实际自动化项目里，各个注解有明确的用武之地。@BeforeSuite适合做全局环境初始化，比如创建数据库连接池、准备测试环境的基础数据；@BeforeMethod适合做每个用例的前置动作，比如接口自动化里的登录拿token，UI自动化里的启动浏览器并打开目标页面；@AfterMethod适合做清理动作，比如删除测试中创建的数据、关闭浏览器。把初始化逻辑放进合适的生命周期方法里，用例本身就能保持干净，只关注业务验证。

这里有个很容易踩的坑：如果多个@BeforeMethod注解分散在父类和子类中，它们的执行顺序并不是绝对可靠的。不要在一个类里写多个有强依赖关系的@BeforeMethod，这种隐式顺序一旦出问题，排查成本很高。如果一个用例需要多步前置条件，要么把逻辑合并到一个方法里，要么用分组和依赖机制显式表达。

3.2 硬断言与软断言：一个字符写错就能误报一整天

TestNG断言分两种，硬断言（Assert）和软断言（SoftAssert）。

硬断言直接用Assert类，一个断言失败，当前测试方法立刻终止，后续代码不执行。这种风格适合一个测试方法只验证一个核心业务规则的场景，失败了就明确告诉你“这一步就不对了，后面的别测了”。

软断言则适合一个用例里需要连续验证多个字段的场景。比如接口返回一个用户对象，你要同时校验用户名、年龄、手机号等多个字段，希望所有校验跑完，最后汇总哪些失败。SoftAssert就是干这个的：

import org.testng.annotations.Test; import org.testng.asserts.SoftAssert; public class SoftAssertDemoTest { @Test public void testUserInfo() { SoftAssert softAssert = new SoftAssert(); softAssert.assertEquals("zhangsan", "lisi", "用户名不一致"); softAssert.assertEquals(25, 30, "年龄不一致"); // 其他校验... softAssert.assertAll(); } }

注意最后那句softAssert.assertAll()一定不能漏。漏掉的话，软断言里积累的失败信息不会被抛出，测试结果依然显示通过。这个问题非常隐蔽，我在实际项目里见过不止一次——某个用例明明日志里打印了好几行“断言失败”，但测试报告显示绿色通过，找了一圈才发现是assertAll没调用。

我的建议是：能用硬断言的地方优先用硬断言，一个方法只验证一个核心点，这样失败时定位最直接。软断言留给“接口返回的复杂对象需要批量校验字段”的场景，并且把assertAll放在finally块里或者方法最后一行，确保一定会执行。

3.3 注解驱动的几个隐藏细节

除了生命周期的常用注解，TestNG还有几个日常会用到的注解属性，值得单独说。

@BeforeMethod、@AfterMethod这些配置方法支持alwaysRun属性。配置成alwaysRun = true后，即使测试方法因为依赖失败被跳过，配置方法也依然会执行。这个在UI自动化里很有用：某个用例挂了导致后续依赖用例被跳过，但你仍然希望浏览器能被正确关闭，这时候@AfterMethod(alwaysRun = true)就是保底方案。

enabled = false可以直接临时禁用某个测试方法，效果等同于注释掉，但是保留在代码里更方便后续恢复。我习惯用这个属性来标记“还没有调通或者正在重构”的用例，而不是直接删除代码。

timeOut属性可以给测试方法设置超时时间，单位毫秒。接口自动化时，如果某个接口偶发性耗时很长，设置timeOut能避免整个回归卡住不动。预期异常用expectedExceptions属性声明，适合测试那些“应该抛出特定异常”的负向用例。

还有@Factory注解可以配合构造器动态创建测试实例，这个相对进阶，用的场景没有DataProvider频繁，入门阶段先了解有这么个东西就行。

4. 数据驱动测试：把测试数据和测试逻辑分开

4.1 @Parameters + XML：适合少量固定参数的场景

数据驱动是自动化测试进阶的一大门槛。TestNG提供了多种传参方式，先看最简单的@Parameters。

在测试方法上声明参数名，然后在testng.xml的test或suite级别定义parameter：

import org.testng.annotations.Parameters; import org.testng.annotations.Test; public class ParameterDemoTest { @Test @Parameters({"baseUrl", "env"}) public void testOpenPage(String baseUrl, String env) { System.out.println("环境：" + env + "，地址：" + baseUrl); } }

testng.xml中这样配：

<suite name="参数示例"> <test name="环境参数"> <parameter name="baseUrl" value="https://example.com"/> <parameter name="env" value="staging"/> <classes> <class name="com.example.ParameterDemoTest"/> </classes> </test> </suite>

这种方式适合参数数量少、并且不经常变化的场景，典型的就是环境地址切换。同一个套件里定义不同的test标签，每个test配不同的baseUrl，一套代码就能在不同环境跑。

不过有个限制：@Parameters只能支持基本类型和String，并且参数值来自XML，无法做到从文件动态读取大量数据。如果测试数据有几十上百组，@Parameters就不合适了。

4.2 @DataProvider：数据驱动的主力方式

@DataProvider是TestNG数据驱动的核心。它返回一个Object二维数组，每一行就是一组参数，TestNG会自动用每组参数调用一次测试方法。

import org.testng.annotations.DataProvider; import org.testng.annotations.Test; public class LoginDataProviderTest { @DataProvider(name = "userData") public Object[][] userData() { return new Object[][]{ {"zhangsan", "123456"}, {"lisi", "654321"} }; } @Test(dataProvider = "userData") public void testLogin(String username, String password) { System.out.println("登录账号：" + username + "，密码：" + password); // 这里写实际的登录验证逻辑 } }

这段代码跑起来，testLogin会被执行两次，分别使用两行数据。

@DataProvider还有一个细节：如果返回类型是数组，数据量大的时候所有数据会一次性加载到内存。对于几十上百组数据完全没问题，但要处理几万组数据时，可以考虑返回Iterator<Object[]>实现懒加载，按需取下一组数据。不过实际自动化测试场景里，大部分时候Object[][]已经足够。

如果多个测试方法要共用同一个DataProvider，而它们的方法参数数量和类型不同，可以在DataProvider方法里加一个Method参数，根据方法名返回不同的数据。这个需求常见于多个接口用例共用一套数据源的场景，但要注意数据和方法参数的匹配，否则运行时会直接报参数数量不匹配的错。

DataProvider定义在其他类中时，记得在@Test注解的dataProviderClass属性里指定那个类的class对象，否则TestNG找不到数据源。

4.3 从Excel/JSON读测试数据

真实项目里测试数据很少硬编码在代码里，更多是放在Excel、JSON或YAML里，由测试人员维护。

用Excel作为数据源是接口自动化的常见做法。Apache POI是主流方案，先在pom.xml加上依赖：

<dependency> <groupId>org.apache.poi</groupId> <artifactId>poi-ooxml</artifactId> <version>5.2.5</version> </dependency>

然后在DataProvider里读取Excel文件：

import org.apache.poi.ss.usermodel.*; import org.apache.poi.xssf.usermodel.XSSFWorkbook; import org.testng.annotations.DataProvider; import java.io.InputStream; public class ExcelDataProvider { @DataProvider(name = "excelUserData") public Object[][] excelUserData() throws Exception { try (InputStream in = getClass().getClassLoader().getResourceAsStream("test-data.xlsx"); Workbook workbook = WorkbookFactory.create(in)) { Sheet sheet = workbook.getSheetAt(0); // getLastRowNum返回最后一行的索引，所以数组长度是getLastRowNum() Object[][] data = new Object[sheet.getLastRowNum()][]; for (int i = 0; i < sheet.getLastRowNum(); i++) { Row row = sheet.getRow(i + 1); data[i] = new Object[]{ row.getCell(0).getStringCellValue(), row.getCell(1).getStringCellValue() }; } return data; } } }

这里要注意文件的读取路径。用getResourceAsStream从classpath读文件，文件放在src/test/resources目录下，这样不管本地跑还是CI里跑路径都不会出问题。千万别把绝对路径写死在代码里，换台机器就废了。

还有一层需要注意：Excel里的单元格类型。如果某个单元格是数字类型，直接getStringCellValue会抛异常。稳妥的做法是在读取时判断getCellType()，或者统一在Excel里把数据列设为文本格式。这个细节看着小，实际跑数据驱动时非常容易中招。

JSON数据源可以用Jackson或Fastjson解析，整体思路类似：先把JSON文件读成List，再转换成Object[][]返回。核心原则是一样的——测试逻辑与测试数据分离，数据变化时不用改代码。

5. 分组、依赖与并发：用TestNG的调度能力管理用例

5.1 分组：一套代码拆出冒烟、回归、全量多套计划

TestNG的分组功能是我认为它优于很多其他框架的重要一点。一个测试方法可以归属于一个或多个分组：

import org.testng.annotations.Test; public class GroupDemoTest { @Test(groups = {"smoke", "login"}) public void testLogin() { System.out.println("执行登录用例"); } @Test(groups = {"regression", "order"}) public void testCreateOrder() { System.out.println("执行创建订单用例"); } @Test(groups = {"smoke"}) public void testHomePage() { System.out.println("执行首页用例"); } }

然后在testng.xml中通过groups节点控制本次执行包含哪些分组：

<suite name="分组示例"> <test name="冒烟测试"> <groups> <run> <include name="smoke"/> </run> </groups> <classes> <class name="com.example.GroupDemoTest"/> </classes> </test> </suite>

这样配置后，即使GroupDemoTest里有一百个方法，本次执行只跑分组名包含smoke的用例。冒烟测试跑smoke，回归测试跑regression，全量测试不配置include直接跑所有，三套执行计划共用一份代码，维护成本非常低。

分组名最好提前定好规范。我见过项目里有人用业务模块做分组名，有人用执行阶段做分组名，还有人用平台类型做分组名，结果混在一起后include的规则越来越绕。建议以执行阶段为主线划分：smoke、regression、full，再按需叠加模块分组，避免分组名体系混乱。

5.2 依赖与顺序：显式依赖往往是最好的反模式

TestNG支持通过dependsOnMethods和dependsOnGroups声明方法依赖：

@Test public void testLogin() { Assert.assertTrue(true); } @Test(dependsOnMethods = "testLogin") public void testCreateOrder() { System.out.println("依赖登录成功后创建订单"); }

这么写的效果是：testCreateOrder一定会排在testLogin之后执行，如果testLogin失败，testCreateOrder会被标记为SKIP，而不是继续执行。这个机制看起来很好用，但在实际项目中我建议谨慎使用，尤其是不要用方法依赖去串联一长串业务流。

原因在于，一旦方法依赖链变长，任何一个前置方法失败，后面所有依赖的方法都会变成SKIP，最终测试报告里出现一大片黄颜色的跳过。问题定位时你还得沿着依赖链逐个查看哪一环先挂了，排查成本很高。

更好的做法是：用@BeforeMethod做前置条件准备，比如登录状态初始化；业务流验证尽量在同一个测试方法内完成；如果确实要拆成多个用例，优先保证每个用例独立，不依赖其他用例的执行结果。依赖机制留给那些真正意义上“没有前置结果就无法执行”的场景，而不是拿它当执行顺序控制器的默认方案。

另外需要留意，如果在testng.xml中设置了preserve-order="true"，同时你又用了dependsOnMethods，这两种顺序控制方式叠加后可能出现预期之外的执行序列。总体上建议执行顺序以XML为准，方法依赖只做最低限度的前置校验，不要两套机制混用。

5.3 并发执行：parallel参数真的不能乱配

TestNG的并发能力是它的一大卖点，配置方式在suite标签上：

<suite name="并发示例" parallel="methods" thread-count="3">

parallel可以取值methods、tests、classes、instances，分别对应方法级别并发、test标签级别并发、类级别并发、实例级别并发。thread-count指定线程数。

我日常用得最多的是parallel="tests"和parallel="methods"。接口自动化时，如果用例之间没有共享数据，methods并发可以显著缩短执行时间。UI自动化时则要慎重，多个浏览器实例并行对机器资源要求高，而且WebDriver实例如果是静态共享的，多线程一起操作会直接把会话搞乱。

先看一个并发时线程安全的经典问题。如果用静态变量保存WebDriver：

public class WebDriverFactory { private static WebDriver driver; public static WebDriver getDriver() { if (driver == null) { driver = new ChromeDriver(); } return driver; } }

在并发模式下，多个线程同时调用getDriver()，driver会被创建多次或互相覆盖，用例执行时轻则串测试，重则直接报“session is null”。解决办法是使用ThreadLocal：

public class WebDriverFactory { private static final ThreadLocal<WebDriver> DRIVER = new ThreadLocal<>(); public static WebDriver getDriver() { if (DRIVER.get() == null) { DRIVER.set(new ChromeDriver()); } return DRIVER.get(); } public static void quitDriver() { if (DRIVER.get() != null) { DRIVER.get().quit(); DRIVER.remove(); } } }

ThreadLocal保证每个线程拿到的WebDriver是独立的，互不干扰。这个模式在接口自动化里同样适用，比如每个线程保存独立的登录token，避免用户A的token被用户B覆盖。

并发还会带来测试数据隔离问题。多个线程同时跑同一批用例，如果它们操作的是同一条测试数据，结果可能互相影响。规避手段有两种：一种是并发用例使用不同的数据分组，比如每个线程跑不同的用户账号；另一种是每个用例自己创建测试数据，用完后清理。后者更彻底，但实现成本高一些，需要根据项目情况取舍。

还有@DataProvider自带的并发属性。dataProvider="xxx"的测试方法如果数据量很大，可以在TestNG XML里配置data-provider-thread-count，让TestNG用多个线程并行消费数据。这个机制在某些批量接口校验场景里很实用，但要注意数据提供者返回的数据必须天然隔离，否则并发执行时容易出现数据覆盖问题。

6. 失败重试与测试报告：让框架自己“靠谱”

6.1 失败重试：用IRetryAnalyzer解决偶发失败

自动化测试最烦的一件事是偶发失败。接口偶发超时、页面元素加载慢、第三方服务抖动，都会导致用例在不该挂的时候挂掉。TestNG的失败重试机制可以把这种偶发失败自动消化掉。

先实现一个重试分析器：

import org.testng.IRetryAnalyzer; import org.testng.ITestResult; public class RetryAnalyzer implements IRetryAnalyzer { private int retryCount = 0; private static final int MAX_RETRY_COUNT = 2; @Override public boolean retry(ITestResult result) { if (retryCount < MAX_RETRY_COUNT) { retryCount++; return true; } return false; } }

retry方法返回true表示要重试，返回false表示不再重试。上面这个实现最多重试2次，加上首次执行一共跑3次。

单独使用需要在每个@Test注解上写retryAnalyzer属性：

@Test(retryAnalyzer = RetryAnalyzer.class) public void testCase() { // ... }

如果一个项目里有几百个测试方法，每个都写一遍显然不现实。更好的做法是通过注解转换器全局设置：

import org.testng.IAnnotationTransformer; import org.testng.annotations.ITestAnnotation; import java.lang.reflect.Constructor; import java.lang.reflect.Method; public class RetryListener implements IAnnotationTransformer { @Override public void transform(ITestAnnotation annotation, Class testClass, Constructor testConstructor, Method testMethod) { annotation.setRetryAnalyzer(RetryAnalyzer.class); } }

然后在testng.xml里注册：

<suite name="重试示例"> <listeners> <listener class-name="com.example.RetryListener"/> </listeners> <test name="测试"> <classes> <class name="com.example.ExampleTest"/> </classes> </test> </suite>

这样所有@Test方法自动启用重试机制，不用在每个方法上重复声明。

重试机制也不是越多越好。重试次数太多会成倍拉长回归时间，尤其是UI自动化这种单用例耗时长的情况。我一般建议接口自动化最多重试2次，UI自动化最多重试1次。同时要给被测环境留足“稳定余量”，如果某个用例连续多次重试仍然失败，那大概率不是偶发问题，而是环境或脚本本身有bug，这时候应该让真实失败暴露出来，而不是靠重试掩盖。

这里还有一个隐蔽的坑：IRetryAnalyzer实例是每个测试方法单独创建的，但测试方法执行多次时，retryCount的状态是否会被正确重置，不同版本的TestNG表现有差异。稳妥的做法是在重试逻辑里通过ITestResult判断当前方法是否已经重试过，或者干脆把重试分析器的实例设计成每次都是全新的。遇到“重试次数比预期多”或者“重试不符合预期”的情况，先检查retryCount的累计状态。

6.2 监听器：把测试过程完整“接”出来

监听器是TestNG扩展机制中最强大的一环，可以说，自定义报告、失败截图、失败分析、与CI系统对接，都离不开监听器。

以ITestListener为例，它可以在测试方法执行的不同阶段插入自定义逻辑：

import org.testng.ITestListener; import org.testng.ITestResult; public class TestResultListener implements ITestListener { @Override public void onTestStart(ITestResult result) { System.out.println("开始执行：" + result.getName()); } @Override public void onTestSuccess(ITestResult result) { System.out.println("执行成功：" + result.getName()); } @Override public void onTestFailure(ITestResult result) { System.out.println("执行失败：" + result.getName()); // 这里可以加截图逻辑、日志打印、失败信息收集 } @Override public void onTestSkipped(ITestResult result) { System.out.println("执行跳过：" + result.getName()); } }

UI自动化里最典型的用法是失败截图。在onTestFailure里拿到当前线程的WebDriver，然后截图保存到指定目录：

@Override public void onTestFailure(ITestResult result) { Object instance = result.getInstance(); // 从实例中获取当前WebDriver，具体方式取决于你的框架设计 WebDriver driver = WebDriverFactory.getDriver(); if (driver != null) { File screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); // 保存到自定义目录，命名带上时间戳 } }

这里WebDriverFactory.getDriver()能返回当前线程对应的driver，前提是我们前面用了ThreadLocal方案。如果你的driver是普通的静态变量，在并发模式下这个截图逻辑会拿到别的线程的driver，截图内容就可能不对。监听器和并发模式的配合，是很多框架在并发后出现截图错乱、报告数据混乱的根源。

监听器还可以实现IInvokedMethodListener，在方法调用前后做通用处理；IAnnotationTransformer可以动态修改测试方法注解；IConfigurationListener可以监听@BeforeSuite这些配置方法的执行结果。这些扩展点结合使用，基本能覆盖自动化测试框架的大部分定制需求。

6.3 Allure报告集成：从命令行堆日志到可视化报告

测试报告做得好不好，直接影响团队对自动化测试的信任度。默认的TestNG输出是一个简单的HTML报告和test-output目录，信息量有限，看起来也不够直观。我建议集成Allure Report，它和TestNG配合很成熟，生成的报告在团队协作和CI展示上体验很好。

pom.xml加依赖：

<dependency> <groupId>io.qameta.allure</groupId> <artifactId>allure-testng</artifactId> <version>2.25.0</version> </dependency>

然后在测试类上挂监听器：

import io.qameta.allure.Allure; import io.qameta.allure.Attachment; import io.qameta.allure.Step; import io.qameta.allure.testng.AllureTestNG; import org.testng.annotations.Listeners; import org.testng.annotations.Test; @Listeners({AllureTestNG.class}) public class AllureDemoTest { @Step("登录操作：{username}") public void login(String username, String password) { // 登录逻辑 } @Attachment(value = "请求响应", type = "application/json") public String attachResponse(String response) { return response; } @Test public void testLoginFlow() { login("zhangsan", "123456"); attachResponse("{\"code\":0}"); } }

通过@Step注解，测试报告里会生成友好的步骤名称，不再是一堆只有方法名的调用记录。@Attachment能把接口请求响应、截图等关键信息嵌到报告里，失败排查时不用再去翻Tomcat控制台或者日志文件。

执行测试后，目录下会生成allure-results目录，然后在命令行执行：

allure serve target/allure-results

就能在浏览器里打开可视化报告。接入Jenkins时，可以直接用Allure插件收集结果，每次构建后报告自动更新，团队查测试结果就不用再等截图或复制日志了。

7. 常见问题与避坑实录：这些坑我替你踩过了

7.1 高频问题速查表

7.2 几条项目级别的经验

第一个经验是测试隔离。每个用例尽量独立运行，不依赖其他用例留下的状态。这句话很多人写框架时认同，实际设计用例时却容易犯。比如“先创建订单再查询订单”这类流程，如果查询用例依赖创建用例已经执行过并留下了订单数据，一旦执行顺序调整，查询用例就挂了。更好的做法是查询用例自己准备数据，通过接口造数或者数据库插入，用完清理。TestNG提供了分组和依赖机制，但它们应该是备用手段，而不是常态。

第二个经验是日志一定要打足。在接口自动化里，每个请求的URL、请求头、请求体、响应体都应该记录到日志中；在UI自动化里，每个关键操作（打开页面、点击按钮、填写输入框）都应该有日志输出。很多测试人员习惯只在断言失败时看一眼控制台输出，这种方式在用例量少的时候够用，用例量上来了根本没法排。TestNG配合log4j2或slf4j加一个简单的日志封装，就能把执行过程完整记录下来，失败时对照日志定位问题会快很多。

第三个经验是报告和监听器要提前设计，不要等到用例写完再补。很多入门者先写一堆用例，等发现报告不好看了、失败不好分析了，才想起来要集成Allure，这时候再往测试代码里塞注解和监听器，改动面会非常大。正确的顺序是先搭好TestNG + 监听器 + Allure的骨架，再往里面填充用例。框架先行，业务用例才能在统一的规范下生长。

最后再分享几个实际体会

我在多个项目里用TestNG搭过自动化框架，从最初几十个用例到后来上千个用例，最大的体会是：TestNG的难点不在于某个注解不会用，而在于怎么把它的调度能力用得恰到好处。

数据驱动这块，我建议一开始就把@Parameters和@DataProvider的分工想清楚。环境参数走XML，业务数据走DataProvider，尽量别混用，不然维护的人会搞不清某个参数到底该改哪里。

分组方面，我吃过一个亏：早期为了追求灵活性，给用例打了十几个分组标签，结果真正跑CI的时候include规则变得极其复杂，别人根本看不懂。后来收敛成smoke、regression、full三套主分组加少量模块子分组，整个执行计划一下子清爽了。

如果你正在搭建自己的第一个测试框架，先把testng.xml、监听器、重试、数据驱动这四件事做扎实，再考虑并发和复杂扩展。这几个能力用顺之后，TestNG就能真正成为你自动化项目的稳定底座。