聊到 Java 生态的自动化测试框架TestNG 是一个绕不开的名字。这些年我既做过 Java 接口自动化测试框架也做过基于 Selenium 的 Web 自动化测试框架最后兜兜转转执行引擎几乎都落在 TestNG 上。放在三年前我可能会劝你用更轻量或者更时髦的方案但当你面对上千条用例、要分组跑、要数据驱动、要失败重跑、要并发执行的时候TestNG 给出的管理能力是最直接的那一套。这篇文章不是 API 文档的翻译而是把我从一个只会写Test的入门状态到把 TestNG 真正用进自动化测试框架之后踩过和填过的坑完整梳理一遍。适合正在从 JUnit 迁移、刚搭建 Java 接口自动化测试框架或者想用 Selenium 做 UI 自动化的测试开发、测试工程师参考。你看完可以直接照着搭建也可以拿我的选型和避坑经验去对比你现在的方案。1. TestNG 在自动化测试里的定位不是能跑用例而已1.1 从“能跑用例”到“能管用例”差距在哪很多测试新手从 JUnit 起步或者直接把 TestNG 当成一个“支持注解的 main 方法”写一条测试就Test一句跑到哪里算哪里。但实际上TestNG 名字里的 NG 是 Next Generation它在设计之初就强调测试的组织和管理。一个能跑用例的框架只解决“执行”问题TestNG 更多解决的是在一堆用例里如何分组、排序、跳过、重跑、并发、数据驱动、按需组合执行的问题。等到用例数量从几十条涨到几百条你会发现真正决定一个自动化测试框架好不好用的往往不是它能不能跑而是它能不能让你的用例在一个可控的编排体系里稳定运行。这也是为什么很多 Java 接口自动化测试框架即使内部有自己的二次封装执行层依然选择 TestNG。因为它已经帮你把用例调度、生命周期管理、结果收集这些最繁琐的底座工作做掉了。1.2 TestNG 与 JUnit 的选型对比一个老测试的视角每次在测试团队里讨论框架选型都免不了和 JUnit 对比一轮。我不是全盘否定 JUnit很多纯单元测试场景它非常合适只是在自动化测试框架这个场景下两者的侧重点不一样。能力TestNGJUnit 4JUnit 5分组执行原生支持 groups套件 XML 里可 include/exclude 灵活过滤没有原生分组依赖 Suite 或 CategoryTag注解配置在 properties 文件用例依赖dependsOnMethods/dependsOnGroups硬依赖且支持失败后跳过没有直接对应机制没有方法级依赖只有执行顺序控制数据驱动DataProvider支持Object[][]和IteratorObject[]参数化能力较弱ParameterizedTestMethodSource也很好用并发调度suite / test / class / method 四级并行XML 里直接控制4.x 并发能力有限通过junit-platform.properties开启配置较绕监听器ITestListener、IAnnotationTransformer、IRetryAnalyzer等体系完整TestWatcher能力有限Extension 模型灵活但学习成本更高报告集成默认生成 test-output 报告Allure 适配成熟依赖第三方插件适配也不错我个人的结论比较主观但很明确JUnit 5 在单元测试层面越来越完善但 TestNG 在端到端、接口、UI 自动化这种需要灵活排布的场景依然是最顺手的。尤其是你要做 Java 接口自动化测试框架DataProvider groups 监听器这三个能力的组合非常直接几乎没有竞争对手能替代。1.3 自动化测试最常遇见的三个痛点正好是 TestNG 的主场自动化测试做久了你会发现真正耗费时间的往往不是写断言而是处理这三类问题用例执行顺序怎么控制比如登录必须先于下单执行哪些用例属于冒烟、哪些属于回归怎么在运行时过滤测试数据怎么准备、前后置逻辑放在哪里才不会出现互相污染。TestNG 在框架层已经给出一整套标准答案依赖用dependsOnMethods分组用groups前后置用BeforeSuite到AfterSuite这一系列注解数据用DataProvider或外部文件接入。这套东西你如果只用Test是感受不到价值的但一旦用例数量到几百上千条它带来的可维护性差距会非常明显。2. 工程搭建和第一个用例Maven 依赖、测试文件、testng.xml 的组合2.1 依赖版本怎么选稳定大于最新如果你用 Maven最基础的依赖是下面这段。版本建议不要盲目追新TestNG 7.x 系列中7.5 以后对 JDK 8 和 JDK 11/17 的支持都比较好。目标 JDK 8 的项目用 7.5.x 或 7.6.x 完全足够JDK 11 可以直接上 7.10.2。dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version7.10.2/version scopetest/scope /dependency这里有一个细节经常坑到人如果项目里还有 JUnit 的传递依赖测试类里 import 的Test可能引成org.junit.Test而不是org.testng.annotations.Test。一旦引错用例要么不执行要么执行了也不按 TestNG 的规则走。我建议在 pom 中对 junit 做 exclude或者通过 Surefire 插件排除旧版本。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.1.2/version configuration suiteXmlFiles suiteXmlFiletestng.xml/suiteXmlFile /suiteXmlFiles /configuration /plugin2.2 第一个测试类的代码结构和最小执行流程先看一个最基础的脚本长什么样。这里用BeforeMethod做环境初始化AfterMethod做清理Test里只写断言逻辑。import org.testng.annotations.BeforeMethod; import org.testng.annotations.AfterMethod; import org.testng.annotations.Test; public class DemoTest { BeforeMethod public void setUp() { System.out.println(打开浏览器或初始化HTTP客户端); } Test public void testLogin() { System.out.println(执行登录接口验证); } AfterMethod public void tearDown() { System.out.println(清理数据或关闭连接); } }执行流程非常简单读取 testng.xml 或扫描Test注解类 - 按生命周期执行BeforeMethod-Test-AfterMethod- 生成 test-output 目录报告。这套流程一旦跑通后面的扩展就顺理成章了。2.3 testng.xml 的三种常见运行方式第一种是纯 Maven 运行。如果你没在 testng.xml 中做特殊配置Maven Surefire 默认会扫描 src/test/java 下的所有测试类直接执行mvn test第二种是显式指定套件文件适合需要控制分组、并行和监听器时使用mvn test -DsuiteXmlFiletestng.xml第三种是在 IDEA 里右键运行 testng.xml调试单条用例或某个分组特别方便开发阶段我基本都用这种方式。这里建议 testng.xml 放在项目根目录或 test/resources 下不要在 src 里又让 Surefire 重复扫描。被扫描两遍你的用例就会重复执行两次数据全部错乱。3. 注解和生命周期把测试用例的前后置做得干净利落3.1 8 个核心生命周期注解的职责划分TestNG 的注解体系并不复杂核心的生命周期注解一张表就能说清楚注解作用范围典型用途BeforeSuite/AfterSuite整个 suite全局环境准备、清理临时目录BeforeTest/AfterTest当前test标签内连接池准备、读取环境配置BeforeClass/AfterClass当前 class实例化页面对象、HTTP 客户端BeforeMethod/AfterMethod每个测试方法前后数据清理、登录态准备实际项目中我遵循一个原则能放到高一级的初始化就别放到方法级。比如 HTTP 客户端的创建放在BeforeClass登录 token 获取可以放在BeforeMethod但如果所有方法共用同一个 base token放BeforeClass会更快。不要让BeforeMethod每次都去创建重量级对象否则并发执行时资源争用会非常明显。3.2 priority、dependsOnMethods、groups 的组合使用规则priority是软排序数字小优先执行dependsOnMethods是硬依赖上一个失败下一个直接跳过不会白白浪费时间。Test(priority 1) public void testCreateOrder() { // 创建订单 } Test(priority 2, dependsOnMethods testCreateOrder) public void testPayOrder() { // 支付依赖订单存在 }当testCreateOrder失败时testPayOrder会被标为 SKIP而不是直接报错。这在接口自动化里非常合理下游用例依赖上游数据上游失败后下游再跑也是白跑。不过不要滥用dependsOnMethods一旦用例之间形成很深的方法链你很难判断哪个方法失败导致了一堆跳过。我的习惯是只对“数据强依赖”的用例使用比如先登录再下单业务相互独立的优先用分组来管理。3.3 为什么我推荐“一个业务场景一条用例而不是一个接口一条用例”刚开始做 Java 接口自动化的同学容易陷入“一个接口写一个Test”的思路结果就是用例数量巨大但大多数只是接口返回 200 就通过根本测不到业务逻辑。我后来改成“一个业务场景对应一条测试用例里面按顺序调用多个接口用断言校验链路正确性”反而更贴近用户视角也更容易发现前后端集成的问题。比如“用户下单并支付成功”这条用例内部可能包含创建订单、查询订单、支付、查询支付结果四个接口。如果拆成四条Test还要处理顺序依赖放在一条里数据上下文连续失败时定位更直观。TestNG 的定位本来就是“灵活组织”而不是“强制拆分”具体怎么组织应该由业务决定。4. 数据驱动是核心玩法DataProvider 从入门到实战4.1 Parameters 与 DataProvider 的选择逻辑Parameters更适合静态配置类数据比如被测环境地址。在 testng.xml 里定义 parameter然后在测试方法里接收即可parameter namebaseUrl valuehttps://api.test.example.com/Test Parameters({baseUrl}) public void testBaseUrl(String baseUrl) { // 使用 baseUrl }DataProvider则适合批量、可枚举的测试数据比如登录用例的合法/非法账号、支付用例的边界金额。我的选择标准很单一单条配置用Parameters多条数据组合、需要循环执行同一套逻辑时用DataProvider。两者不是替代关系而是使用场景天然不同。4.2 接口自动化的数据驱动写法一个登录接口的数据驱动示例DataProvider(name loginData) public Object[][] loginDataProvider() { return new Object[][]{ {user1example.com, 123456, 200, success}, {user1example.com, wrong, 401, invalid_credentials}, {, 123456, 422, email_required} }; } Test(dataProvider loginData) public void testLogin(String email, String password, int expectedStatusCode, String expectedMsg) { Response response given() .contentType(ContentType.JSON) .body({\email\:\ email \,\password\:\ password \}) .post(/api/login); Assert.assertEquals(response.getStatusCode(), expectedStatusCode); Assert.assertEquals(response.jsonPath().getString(msg), expectedMsg); }有几个细节需要留意Object[][]的每一行代表一次独立执行只要有一个数据行失败不会影响其他数据行这对用例隔离很有帮助。如果数据量特别大返回IteratorObject[]比Object[][]更省内存尤其是从 Excel 或数据库读取上万条数据时不要一次性全部装载。DataProvider 方法如果定义在另一个类中需要使用dataProviderClass属性同时该 DataProvider 方法必须是static。4.3 用 CSV/Excel 管理测试数据的完整实现真实项目里测试数据往往会交给测试同事维护把数据从代码中抽出来放到 CSV 或 Excel是很常见的做法。CSV 最简单用 OpenCSV 就能读Excel 则需要 Apache POI。我通常这样设计数据文件放在src/test/resources/testdata/login_data.csv工具类DataLoader统一读取返回ListMapString, StringDataProvider 里把 List 转换成Object[][]或IteratorObject[]。public static IteratorObject[] getLoginData() throws IOException { InputStream is DataLoader.class.getClassLoader() .getResourceAsStream(testdata/login_data.csv); Reader reader new InputStreamReader(is, StandardCharsets.UTF_8); CSVReader csvReader new CSVReader(reader); ListString[] rows csvReader.readAll(); ListObject[] data new ArrayList(); for (String[] row : rows) { data.add(new Object[]{row[0], row[1], Integer.parseInt(row[2]), row[3]}); } return data.iterator(); }这里有一个认知误区要说明不是所有用例都适合数据驱动。UI 自动化里如果每条数据都要重新登录、重新打开页面数据驱动虽然能跑但耗时成倍增加。我一般是接口层尽量数据驱动UI 层只对核心功能做少量数据覆盖更多从 page object 角度控制用例粒度。5. 断言与失败处理让结果真正可追溯5.1 核心断言方式与常见误用TestNG 的断言都基于Assert类最常用的几个Assert.assertEquals(actual, expected)判断相等注意实际值和期望值的位置不要写反否则失败信息没法看Assert.assertTrue(condition)条件为真Assert.assertNotNull(object)对象不为空Assert.fail(自定义信息)主动失败常用于 catch 分支。在接口自动化里我强烈建议把状态码校验和响应体关键字段校验都做掉。只校验状态码 200 是最常见的假通过接口返回 200 但 body 里是错误码这种情况我遇到过太多次。断言信息最好带上业务描述比如Assert.assertEquals(resp.getCode(), 0000, 订单创建失败响应为 resp)日志里看起来才直观。5.2 软断言 SoftAssert 的适用场景默认的Assert一旦失败当前测试方法立即终止。有些场景我们希望尽量多收集失败信息比如表单校验接口一次返回多个字段错误或者 UI 页面上有多个元素需要同时断言。这时可以用SoftAssertSoftAssert softAssert new SoftAssert(); softAssert.assertEquals(response.code(), 200); softAssert.assertEquals(response.jsonPath().getString(name), TestUser); softAssert.assertAll(); // 最后统一抛出收集到的所有失败软断言绝不能用成“不管失败都继续跑”。assertAll()如果不调用测试会一直显示通过这是非常危险的情况。我一般只在单个测试方法中明确需要继续收集错误信息时才使用并且最后一定记得调用assertAll()。5.3 Selenium 自动化场景下的失败截图与证据管理这条经验主要结合 Selenium 自动化测试框架来说。TestNG 本身不负责截图但它的ITestResult接口可以很方便地和截图逻辑绑定。在监听器的onTestFailure里拿到 driver 实例并截图保存public class ScreenshotListener extends TestListenerAdapter { Override public void onTestFailure(ITestResult tr) { Object instance tr.getInstance(); if (instance instanceof WebDriverProvider) { WebDriver driver ((WebDriverProvider) instance).getDriver(); File src ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); String fileName target/screenshots/ tr.getTestClass().getName() . tr.getMethod().getMethodName() - System.currentTimeMillis() .png; // 将 src 复制到 fileName } } }截图文件命名建议带上时间戳和测试方法名。还有一个容易忽略的问题配置了 retry 的用例如果第一次失败后重试成功监听器仍可能把第一次失败截图也保存下来最后报告中就会出现“既失败又通过”的矛盾记录。我建议在重试监听器里手动标记最终结果只有当最终失败时才保存失败截图。6. 并发与稳定性从串行到并行的关键改造6.1 并发粒度怎么选suite/test/class/method 的差异TestNG 支持多级并发配置方式是在 testng.xml 的suite标签上声明parallel和thread-countsuite nameParallelSuite parallelmethods thread-count4不同粒度有不同含义suite 级多个 suite 并行test 级一个 testng.xml 里的不同test标签并行class 级不同测试类并行method 级同一测试类内不同方法并行。我的经验是接口自动化最常用 class 级或 methods 级并行UI 自动化尽量用 class 级并行每个线程一个独立的 WebDriver。method 级并行在同一个浏览器实例里跑很容易互相干扰除非你每个方法都重新创建 driver那样成本又太高。6.2 并发环境下的数据隔离与线程安全并发测试最大的风险不是代码写错而是测试数据互相污染。比如多个线程同时调用创建用户接口各自写入同一个数据库字段后跑的覆盖前者断言就会莫名其妙失败。解决思路有三个层面数据随机化每次运行生成唯一标识比如 UUID 或时间戳后缀每个线程一条独立数据通道用ThreadLocal保存当前线程的上下文全局状态用ConcurrentHashMap或AtomicInteger不要用普通 HashMap 和静态变量。TestNG 的 DataProvider 本身也支持并发可以在注解里写DataProvider(name parallelData, parallel true)但这并不代表数据源线程安全。尤其是从 Excel 读数据时如果 DataProvider 内部维护了共享游标并发读取会出问题。建议把数据一次性读进内存后不再做可变状态修改。6.3 一次因共享测试数据引发的随机失败排查我接手过一个 Java 接口自动化测试框架testng.xml 里配了parallelmethods thread-count8跑起来经常会有一两条用例随机失败失败信息都是“账号已被占用”。最后排查发现测试数据是从一个共享的 Excel 文件读出来的里面预置了 20 组账号所有线程共用这批账号。看起来每个线程都拿到了不同数据但由于另一个模块的清理任务会把“已用数据”标记回未用状态于是两个线程就可能拿到同一个账号。最后的解决办法是把数据预生成环节挪到测试执行前每次运行用随机时间戳生成新账号调用接口时带上 UUID 后缀从源头杜绝数据复用。这件事给我的启发是并发问题很多时候不是 TestNG 配置写错而是测试数据的设计没有跟上“并行”这个前提。7. 监听器体系让框架自动处理重试、截图和报告7.1 监听器比硬编码可靠核心监听器接口一览TestNG 监听器大概分这么几类ITestListener监听测试开始、成功、失败、跳过等IAnnotationTransformer动态改写注解常用于给用例统一加重试ISuiteListener/IInvokedMethodListener监听 suite 级和方法级事件IReporter自定义报告生成TestNG 默认报告引擎就是通过它实现。监听器有两种配置方式在 testng.xml 里通过listeners配置或者在测试类上直接写Listeners({自定义监听器.class})。如果同一个监听器在 xml 和注解里都配置了会导致逻辑重复执行。我在项目里一般统一在 xml 里配置维护成本最低。7.2 失败自动重试IRetryAnalyzer IAnnotationTransformer 实现稳定的自动化测试框架必须处理网络抖动导致的失败。UI 自动化尤其明显页面加载慢一秒元素没找到用例就挂了。直接改超时时间不够因为偶发的慢不一定每次都出现在同一个元素上。TestNG 的推荐做法是配合IRetryAnalyzer和IAnnotationTransformer实现自动重试。public class RetryAnalyzer implements IRetryAnalyzer { private int retryCount 0; private static final int MAX_RETRY 2; Override public boolean retry(ITestResult result) { if (retryCount MAX_RETRY) { retryCount; return true; } return false; } }再通过IAnnotationTransformer把这个重试器统一挂到所有Test方法上public class RetryListener implements IAnnotationTransformer { Override public void transform(ITestAnnotation annotation, Class testClass, Constructor testConstructor, Method testMethod) { annotation.setRetryAnalyzer(RetryAnalyzer.class); } }写完之后必须验证两件事失败后是不是真的重试了重试结果到底算 PASS 还是 FAIL。TestNG 的规则是重试后最终成功整个用例结果算 PASS但 testng-results.xml 里会保留失败记录。也就是说你看到通过不代表一次都没失败过如果团队要求严格需要自己根据结果里的失败次数再做过滤。7.3 接入 Allure 报告让 Java 接口自动化测试框架的结果更直观TestNG 默认会生成 test-output 下的 HTML 报告信息比较朴素。我目前的项目统一用 Allure 报告配置也比较简单dependency groupIdio.qameta.allure/groupId artifactIdallure-testng/artifactId version2.24.0/version /dependency跑完测试后生成 allure-results 目录然后用命令行生成报告allure generate allure-results -o allure-report --clean allure open allure-report在测试代码里可以用Step、Attachment这类注解把接口请求参数、响应体、截图等内容加进报告中可读性比默认报告高非常多。这里提醒一句TestNG 7.x 和 Allure 2.24 搭配时如果 JDK 版本不一致可能出现模型序列化异常。先让本机环境跑通一个最小 Demo再统一升级到正式项目不要一上来就全量迁移。8. 把 TestNG 用进 Java 接口自动化测试框架后的几条实战体会8.1 一套能稳定跑几个月的项目目录结构这是我比较推荐的精简结构src/test/java/ ├── config/ # 环境配置读取如 ConfigLoader ├── api/ # 接口客户端封装如 ApiClient ├── testcase/ # 具体的测试类和 DataProvider ├── listener/ # 重试、截图、Allure 监听器 └── utils/ # Excel/CSV 读取、随机数据生成 src/test/resources/ ├── testng.xml └── testdata/这个结构的好处是测试用例只负责业务描述和断言请求怎么发、数据怎么生成、失败怎么处理都有专门的层去管。后续要做平台化或者对接 CI/CD这套结构也不需要大改。8.2 git 管理和版本升级容易忽略的细节代码库维护中我强烈建议把test-output、allure-results、allure-report加入.gitignore。每次跑完测试都会生成一大批文件如果都提交到 Git合并冲突会比代码冲突还烦。还有testng-results.xml里会记录本机路径团队成员各自跑一遍又提交上去等于留了一堆无效记录。另外升级 TestNG 版本时要注意三个兼容点注解扫描方式变化7.x 开始对 JDK 模块化支持更好但老的 6.x 写法不要直接照搬监听器接口签名变化某些旧版本的IAnnotationTransformer方法和 7.x 的签名不完全一致升级后编译器会直接报出来逐个改就好JDK 8 项目如果同时用 LombokTestNG 7.10 和较旧的 Lombok 版本组合可能触发编译异常建议先锁定插件版本再升级 TestNG。8.3 一个最值得养成的断言习惯最后分享一个小技巧。很多人在写断言时喜欢用 JSONPath 直接取深层嵌套字段一旦接口结构调整断言就全挂。我会在测试代码里提供统一的结构化响应模型把关键字段解析成 Java 对象断言时直接 getter 访问。这样 TestNG 的失败信息、Allure 的步骤描述都会清晰很多字段重命名时也能提前在编译期暴露问题。这是我用了 TestNG 这几年觉得最值得养成的习惯。 
长河君 · 2026/9/29 1:30:27 · 阅读 1.2k TestNG自动化测试框架实战：数据驱动、并发调度与Allure报告集成
聊到 Java 生态的自动化测试框架TestNG 是一个绕不开的名字。这些年我既做过 Java 接口自动化测试框架也做过基于 Selenium 的 Web 自动化测试框架最后兜兜转转执行引擎几乎都落在 TestNG 上。放在三年前我可能会劝你用更轻量或者更时髦的方案但当你面对上千条用例、要分组跑、要数据驱动、要失败重跑、要并发执行的时候TestNG 给出的管理能力是最直接的那一套。这篇文章不是 API 文档的翻译而是把我从一个只会写Test的入门状态到把 TestNG 真正用进自动化测试框架之后踩过和填过的坑完整梳理一遍。适合正在从 JUnit 迁移、刚搭建 Java 接口自动化测试框架或者想用 Selenium 做 UI 自动化的测试开发、测试工程师参考。你看完可以直接照着搭建也可以拿我的选型和避坑经验去对比你现在的方案。1. TestNG 在自动化测试里的定位不是能跑用例而已1.1 从“能跑用例”到“能管用例”差距在哪很多测试新手从 JUnit 起步或者直接把 TestNG 当成一个“支持注解的 main 方法”写一条测试就Test一句跑到哪里算哪里。但实际上TestNG 名字里的 NG 是 Next Generation它在设计之初就强调测试的组织和管理。一个能跑用例的框架只解决“执行”问题TestNG 更多解决的是在一堆用例里如何分组、排序、跳过、重跑、并发、数据驱动、按需组合执行的问题。等到用例数量从几十条涨到几百条你会发现真正决定一个自动化测试框架好不好用的往往不是它能不能跑而是它能不能让你的用例在一个可控的编排体系里稳定运行。这也是为什么很多 Java 接口自动化测试框架即使内部有自己的二次封装执行层依然选择 TestNG。因为它已经帮你把用例调度、生命周期管理、结果收集这些最繁琐的底座工作做掉了。1.2 TestNG 与 JUnit 的选型对比一个老测试的视角每次在测试团队里讨论框架选型都免不了和 JUnit 对比一轮。我不是全盘否定 JUnit很多纯单元测试场景它非常合适只是在自动化测试框架这个场景下两者的侧重点不一样。能力TestNGJUnit 4JUnit 5分组执行原生支持 groups套件 XML 里可 include/exclude 灵活过滤没有原生分组依赖 Suite 或 CategoryTag注解配置在 properties 文件用例依赖dependsOnMethods/dependsOnGroups硬依赖且支持失败后跳过没有直接对应机制没有方法级依赖只有执行顺序控制数据驱动DataProvider支持Object[][]和IteratorObject[]参数化能力较弱ParameterizedTestMethodSource也很好用并发调度suite / test / class / method 四级并行XML 里直接控制4.x 并发能力有限通过junit-platform.properties开启配置较绕监听器ITestListener、IAnnotationTransformer、IRetryAnalyzer等体系完整TestWatcher能力有限Extension 模型灵活但学习成本更高报告集成默认生成 test-output 报告Allure 适配成熟依赖第三方插件适配也不错我个人的结论比较主观但很明确JUnit 5 在单元测试层面越来越完善但 TestNG 在端到端、接口、UI 自动化这种需要灵活排布的场景依然是最顺手的。尤其是你要做 Java 接口自动化测试框架DataProvider groups 监听器这三个能力的组合非常直接几乎没有竞争对手能替代。1.3 自动化测试最常遇见的三个痛点正好是 TestNG 的主场自动化测试做久了你会发现真正耗费时间的往往不是写断言而是处理这三类问题用例执行顺序怎么控制比如登录必须先于下单执行哪些用例属于冒烟、哪些属于回归怎么在运行时过滤测试数据怎么准备、前后置逻辑放在哪里才不会出现互相污染。TestNG 在框架层已经给出一整套标准答案依赖用dependsOnMethods分组用groups前后置用BeforeSuite到AfterSuite这一系列注解数据用DataProvider或外部文件接入。这套东西你如果只用Test是感受不到价值的但一旦用例数量到几百上千条它带来的可维护性差距会非常明显。2. 工程搭建和第一个用例Maven 依赖、测试文件、testng.xml 的组合2.1 依赖版本怎么选稳定大于最新如果你用 Maven最基础的依赖是下面这段。版本建议不要盲目追新TestNG 7.x 系列中7.5 以后对 JDK 8 和 JDK 11/17 的支持都比较好。目标 JDK 8 的项目用 7.5.x 或 7.6.x 完全足够JDK 11 可以直接上 7.10.2。dependency groupIdorg.testng/groupId artifactIdtestng/artifactId version7.10.2/version scopetest/scope /dependency这里有一个细节经常坑到人如果项目里还有 JUnit 的传递依赖测试类里 import 的Test可能引成org.junit.Test而不是org.testng.annotations.Test。一旦引错用例要么不执行要么执行了也不按 TestNG 的规则走。我建议在 pom 中对 junit 做 exclude或者通过 Surefire 插件排除旧版本。plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.1.2/version configuration suiteXmlFiles suiteXmlFiletestng.xml/suiteXmlFile /suiteXmlFiles /configuration /plugin2.2 第一个测试类的代码结构和最小执行流程先看一个最基础的脚本长什么样。这里用BeforeMethod做环境初始化AfterMethod做清理Test里只写断言逻辑。import org.testng.annotations.BeforeMethod; import org.testng.annotations.AfterMethod; import org.testng.annotations.Test; public class DemoTest { BeforeMethod public void setUp() { System.out.println(打开浏览器或初始化HTTP客户端); } Test public void testLogin() { System.out.println(执行登录接口验证); } AfterMethod public void tearDown() { System.out.println(清理数据或关闭连接); } }执行流程非常简单读取 testng.xml 或扫描Test注解类 - 按生命周期执行BeforeMethod-Test-AfterMethod- 生成 test-output 目录报告。这套流程一旦跑通后面的扩展就顺理成章了。2.3 testng.xml 的三种常见运行方式第一种是纯 Maven 运行。如果你没在 testng.xml 中做特殊配置Maven Surefire 默认会扫描 src/test/java 下的所有测试类直接执行mvn test第二种是显式指定套件文件适合需要控制分组、并行和监听器时使用mvn test -DsuiteXmlFiletestng.xml第三种是在 IDEA 里右键运行 testng.xml调试单条用例或某个分组特别方便开发阶段我基本都用这种方式。这里建议 testng.xml 放在项目根目录或 test/resources 下不要在 src 里又让 Surefire 重复扫描。被扫描两遍你的用例就会重复执行两次数据全部错乱。3. 注解和生命周期把测试用例的前后置做得干净利落3.1 8 个核心生命周期注解的职责划分TestNG 的注解体系并不复杂核心的生命周期注解一张表就能说清楚注解作用范围典型用途BeforeSuite/AfterSuite整个 suite全局环境准备、清理临时目录BeforeTest/AfterTest当前test标签内连接池准备、读取环境配置BeforeClass/AfterClass当前 class实例化页面对象、HTTP 客户端BeforeMethod/AfterMethod每个测试方法前后数据清理、登录态准备实际项目中我遵循一个原则能放到高一级的初始化就别放到方法级。比如 HTTP 客户端的创建放在BeforeClass登录 token 获取可以放在BeforeMethod但如果所有方法共用同一个 base token放BeforeClass会更快。不要让BeforeMethod每次都去创建重量级对象否则并发执行时资源争用会非常明显。3.2 priority、dependsOnMethods、groups 的组合使用规则priority是软排序数字小优先执行dependsOnMethods是硬依赖上一个失败下一个直接跳过不会白白浪费时间。Test(priority 1) public void testCreateOrder() { // 创建订单 } Test(priority 2, dependsOnMethods testCreateOrder) public void testPayOrder() { // 支付依赖订单存在 }当testCreateOrder失败时testPayOrder会被标为 SKIP而不是直接报错。这在接口自动化里非常合理下游用例依赖上游数据上游失败后下游再跑也是白跑。不过不要滥用dependsOnMethods一旦用例之间形成很深的方法链你很难判断哪个方法失败导致了一堆跳过。我的习惯是只对“数据强依赖”的用例使用比如先登录再下单业务相互独立的优先用分组来管理。3.3 为什么我推荐“一个业务场景一条用例而不是一个接口一条用例”刚开始做 Java 接口自动化的同学容易陷入“一个接口写一个Test”的思路结果就是用例数量巨大但大多数只是接口返回 200 就通过根本测不到业务逻辑。我后来改成“一个业务场景对应一条测试用例里面按顺序调用多个接口用断言校验链路正确性”反而更贴近用户视角也更容易发现前后端集成的问题。比如“用户下单并支付成功”这条用例内部可能包含创建订单、查询订单、支付、查询支付结果四个接口。如果拆成四条Test还要处理顺序依赖放在一条里数据上下文连续失败时定位更直观。TestNG 的定位本来就是“灵活组织”而不是“强制拆分”具体怎么组织应该由业务决定。4. 数据驱动是核心玩法DataProvider 从入门到实战4.1 Parameters 与 DataProvider 的选择逻辑Parameters更适合静态配置类数据比如被测环境地址。在 testng.xml 里定义 parameter然后在测试方法里接收即可parameter namebaseUrl valuehttps://api.test.example.com/Test Parameters({baseUrl}) public void testBaseUrl(String baseUrl) { // 使用 baseUrl }DataProvider则适合批量、可枚举的测试数据比如登录用例的合法/非法账号、支付用例的边界金额。我的选择标准很单一单条配置用Parameters多条数据组合、需要循环执行同一套逻辑时用DataProvider。两者不是替代关系而是使用场景天然不同。4.2 接口自动化的数据驱动写法一个登录接口的数据驱动示例DataProvider(name loginData) public Object[][] loginDataProvider() { return new Object[][]{ {user1example.com, 123456, 200, success}, {user1example.com, wrong, 401, invalid_credentials}, {, 123456, 422, email_required} }; } Test(dataProvider loginData) public void testLogin(String email, String password, int expectedStatusCode, String expectedMsg) { Response response given() .contentType(ContentType.JSON) .body({\email\:\ email \,\password\:\ password \}) .post(/api/login); Assert.assertEquals(response.getStatusCode(), expectedStatusCode); Assert.assertEquals(response.jsonPath().getString(msg), expectedMsg); }有几个细节需要留意Object[][]的每一行代表一次独立执行只要有一个数据行失败不会影响其他数据行这对用例隔离很有帮助。如果数据量特别大返回IteratorObject[]比Object[][]更省内存尤其是从 Excel 或数据库读取上万条数据时不要一次性全部装载。DataProvider 方法如果定义在另一个类中需要使用dataProviderClass属性同时该 DataProvider 方法必须是static。4.3 用 CSV/Excel 管理测试数据的完整实现真实项目里测试数据往往会交给测试同事维护把数据从代码中抽出来放到 CSV 或 Excel是很常见的做法。CSV 最简单用 OpenCSV 就能读Excel 则需要 Apache POI。我通常这样设计数据文件放在src/test/resources/testdata/login_data.csv工具类DataLoader统一读取返回ListMapString, StringDataProvider 里把 List 转换成Object[][]或IteratorObject[]。public static IteratorObject[] getLoginData() throws IOException { InputStream is DataLoader.class.getClassLoader() .getResourceAsStream(testdata/login_data.csv); Reader reader new InputStreamReader(is, StandardCharsets.UTF_8); CSVReader csvReader new CSVReader(reader); ListString[] rows csvReader.readAll(); ListObject[] data new ArrayList(); for (String[] row : rows) { data.add(new Object[]{row[0], row[1], Integer.parseInt(row[2]), row[3]}); } return data.iterator(); }这里有一个认知误区要说明不是所有用例都适合数据驱动。UI 自动化里如果每条数据都要重新登录、重新打开页面数据驱动虽然能跑但耗时成倍增加。我一般是接口层尽量数据驱动UI 层只对核心功能做少量数据覆盖更多从 page object 角度控制用例粒度。5. 断言与失败处理让结果真正可追溯5.1 核心断言方式与常见误用TestNG 的断言都基于Assert类最常用的几个Assert.assertEquals(actual, expected)判断相等注意实际值和期望值的位置不要写反否则失败信息没法看Assert.assertTrue(condition)条件为真Assert.assertNotNull(object)对象不为空Assert.fail(自定义信息)主动失败常用于 catch 分支。在接口自动化里我强烈建议把状态码校验和响应体关键字段校验都做掉。只校验状态码 200 是最常见的假通过接口返回 200 但 body 里是错误码这种情况我遇到过太多次。断言信息最好带上业务描述比如Assert.assertEquals(resp.getCode(), 0000, 订单创建失败响应为 resp)日志里看起来才直观。5.2 软断言 SoftAssert 的适用场景默认的Assert一旦失败当前测试方法立即终止。有些场景我们希望尽量多收集失败信息比如表单校验接口一次返回多个字段错误或者 UI 页面上有多个元素需要同时断言。这时可以用SoftAssertSoftAssert softAssert new SoftAssert(); softAssert.assertEquals(response.code(), 200); softAssert.assertEquals(response.jsonPath().getString(name), TestUser); softAssert.assertAll(); // 最后统一抛出收集到的所有失败软断言绝不能用成“不管失败都继续跑”。assertAll()如果不调用测试会一直显示通过这是非常危险的情况。我一般只在单个测试方法中明确需要继续收集错误信息时才使用并且最后一定记得调用assertAll()。5.3 Selenium 自动化场景下的失败截图与证据管理这条经验主要结合 Selenium 自动化测试框架来说。TestNG 本身不负责截图但它的ITestResult接口可以很方便地和截图逻辑绑定。在监听器的onTestFailure里拿到 driver 实例并截图保存public class ScreenshotListener extends TestListenerAdapter { Override public void onTestFailure(ITestResult tr) { Object instance tr.getInstance(); if (instance instanceof WebDriverProvider) { WebDriver driver ((WebDriverProvider) instance).getDriver(); File src ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE); String fileName target/screenshots/ tr.getTestClass().getName() . tr.getMethod().getMethodName() - System.currentTimeMillis() .png; // 将 src 复制到 fileName } } }截图文件命名建议带上时间戳和测试方法名。还有一个容易忽略的问题配置了 retry 的用例如果第一次失败后重试成功监听器仍可能把第一次失败截图也保存下来最后报告中就会出现“既失败又通过”的矛盾记录。我建议在重试监听器里手动标记最终结果只有当最终失败时才保存失败截图。6. 并发与稳定性从串行到并行的关键改造6.1 并发粒度怎么选suite/test/class/method 的差异TestNG 支持多级并发配置方式是在 testng.xml 的suite标签上声明parallel和thread-countsuite nameParallelSuite parallelmethods thread-count4不同粒度有不同含义suite 级多个 suite 并行test 级一个 testng.xml 里的不同test标签并行class 级不同测试类并行method 级同一测试类内不同方法并行。我的经验是接口自动化最常用 class 级或 methods 级并行UI 自动化尽量用 class 级并行每个线程一个独立的 WebDriver。method 级并行在同一个浏览器实例里跑很容易互相干扰除非你每个方法都重新创建 driver那样成本又太高。6.2 并发环境下的数据隔离与线程安全并发测试最大的风险不是代码写错而是测试数据互相污染。比如多个线程同时调用创建用户接口各自写入同一个数据库字段后跑的覆盖前者断言就会莫名其妙失败。解决思路有三个层面数据随机化每次运行生成唯一标识比如 UUID 或时间戳后缀每个线程一条独立数据通道用ThreadLocal保存当前线程的上下文全局状态用ConcurrentHashMap或AtomicInteger不要用普通 HashMap 和静态变量。TestNG 的 DataProvider 本身也支持并发可以在注解里写DataProvider(name parallelData, parallel true)但这并不代表数据源线程安全。尤其是从 Excel 读数据时如果 DataProvider 内部维护了共享游标并发读取会出问题。建议把数据一次性读进内存后不再做可变状态修改。6.3 一次因共享测试数据引发的随机失败排查我接手过一个 Java 接口自动化测试框架testng.xml 里配了parallelmethods thread-count8跑起来经常会有一两条用例随机失败失败信息都是“账号已被占用”。最后排查发现测试数据是从一个共享的 Excel 文件读出来的里面预置了 20 组账号所有线程共用这批账号。看起来每个线程都拿到了不同数据但由于另一个模块的清理任务会把“已用数据”标记回未用状态于是两个线程就可能拿到同一个账号。最后的解决办法是把数据预生成环节挪到测试执行前每次运行用随机时间戳生成新账号调用接口时带上 UUID 后缀从源头杜绝数据复用。这件事给我的启发是并发问题很多时候不是 TestNG 配置写错而是测试数据的设计没有跟上“并行”这个前提。7. 监听器体系让框架自动处理重试、截图和报告7.1 监听器比硬编码可靠核心监听器接口一览TestNG 监听器大概分这么几类ITestListener监听测试开始、成功、失败、跳过等IAnnotationTransformer动态改写注解常用于给用例统一加重试ISuiteListener/IInvokedMethodListener监听 suite 级和方法级事件IReporter自定义报告生成TestNG 默认报告引擎就是通过它实现。监听器有两种配置方式在 testng.xml 里通过listeners配置或者在测试类上直接写Listeners({自定义监听器.class})。如果同一个监听器在 xml 和注解里都配置了会导致逻辑重复执行。我在项目里一般统一在 xml 里配置维护成本最低。7.2 失败自动重试IRetryAnalyzer IAnnotationTransformer 实现稳定的自动化测试框架必须处理网络抖动导致的失败。UI 自动化尤其明显页面加载慢一秒元素没找到用例就挂了。直接改超时时间不够因为偶发的慢不一定每次都出现在同一个元素上。TestNG 的推荐做法是配合IRetryAnalyzer和IAnnotationTransformer实现自动重试。public class RetryAnalyzer implements IRetryAnalyzer { private int retryCount 0; private static final int MAX_RETRY 2; Override public boolean retry(ITestResult result) { if (retryCount MAX_RETRY) { retryCount; return true; } return false; } }再通过IAnnotationTransformer把这个重试器统一挂到所有Test方法上public class RetryListener implements IAnnotationTransformer { Override public void transform(ITestAnnotation annotation, Class testClass, Constructor testConstructor, Method testMethod) { annotation.setRetryAnalyzer(RetryAnalyzer.class); } }写完之后必须验证两件事失败后是不是真的重试了重试结果到底算 PASS 还是 FAIL。TestNG 的规则是重试后最终成功整个用例结果算 PASS但 testng-results.xml 里会保留失败记录。也就是说你看到通过不代表一次都没失败过如果团队要求严格需要自己根据结果里的失败次数再做过滤。7.3 接入 Allure 报告让 Java 接口自动化测试框架的结果更直观TestNG 默认会生成 test-output 下的 HTML 报告信息比较朴素。我目前的项目统一用 Allure 报告配置也比较简单dependency groupIdio.qameta.allure/groupId artifactIdallure-testng/artifactId version2.24.0/version /dependency跑完测试后生成 allure-results 目录然后用命令行生成报告allure generate allure-results -o allure-report --clean allure open allure-report在测试代码里可以用Step、Attachment这类注解把接口请求参数、响应体、截图等内容加进报告中可读性比默认报告高非常多。这里提醒一句TestNG 7.x 和 Allure 2.24 搭配时如果 JDK 版本不一致可能出现模型序列化异常。先让本机环境跑通一个最小 Demo再统一升级到正式项目不要一上来就全量迁移。8. 把 TestNG 用进 Java 接口自动化测试框架后的几条实战体会8.1 一套能稳定跑几个月的项目目录结构这是我比较推荐的精简结构src/test/java/ ├── config/ # 环境配置读取如 ConfigLoader ├── api/ # 接口客户端封装如 ApiClient ├── testcase/ # 具体的测试类和 DataProvider ├── listener/ # 重试、截图、Allure 监听器 └── utils/ # Excel/CSV 读取、随机数据生成 src/test/resources/ ├── testng.xml └── testdata/这个结构的好处是测试用例只负责业务描述和断言请求怎么发、数据怎么生成、失败怎么处理都有专门的层去管。后续要做平台化或者对接 CI/CD这套结构也不需要大改。8.2 git 管理和版本升级容易忽略的细节代码库维护中我强烈建议把test-output、allure-results、allure-report加入.gitignore。每次跑完测试都会生成一大批文件如果都提交到 Git合并冲突会比代码冲突还烦。还有testng-results.xml里会记录本机路径团队成员各自跑一遍又提交上去等于留了一堆无效记录。另外升级 TestNG 版本时要注意三个兼容点注解扫描方式变化7.x 开始对 JDK 模块化支持更好但老的 6.x 写法不要直接照搬监听器接口签名变化某些旧版本的IAnnotationTransformer方法和 7.x 的签名不完全一致升级后编译器会直接报出来逐个改就好JDK 8 项目如果同时用 LombokTestNG 7.10 和较旧的 Lombok 版本组合可能触发编译异常建议先锁定插件版本再升级 TestNG。8.3 一个最值得养成的断言习惯最后分享一个小技巧。很多人在写断言时喜欢用 JSONPath 直接取深层嵌套字段一旦接口结构调整断言就全挂。我会在测试代码里提供统一的结构化响应模型把关键字段解析成 Java 对象断言时直接 getter 访问。这样 TestNG 的失败信息、Allure 的步骤描述都会清晰很多字段重命名时也能提前在编译期暴露问题。这是我用了 TestNG 这几年觉得最值得养成的习惯。