本文详解 testng 中断言失败时测试中断而非标记为失败的根本原因，提供标准断言写法、异常重抛技巧及推荐实践，确保测试状态准确、执行流程可控。
本文详解 testng 中断言失败时测试中断而非标记为失败的根本原因，提供标准断言写法、异常重抛技巧及推荐实践，确保测试状态准确、执行流程可控。
在基于 TestNG 的 API 自动化测试中，一个常见误区是：试图用 try-catch 包裹 Assert.assertEquals() 来“捕获失败并继续执行”，结果却导致测试被跳过（SKIPPED）而非失败（FAILED）。这不仅掩盖真实问题，还破坏测试报告的可信度与 CI/CD 流水线的稳定性。
根本原因在于：TestNG 的 org.testng.Assert.fail() 方法会主动抛出 SkipException（而非 AssertionError），从而将当前测试方法标记为 skipped；而直接 throw new AssertionError(...) 才能正确触发 TestNG 的失败机制。
✅ 正确做法一：优先使用 TestNG 内置带消息的断言（推荐）
无需任何 try-catch，简洁、语义清晰、状态准确：
// ✅ 推荐：一行断言，自动失败 + 自定义消息
Assert.assertEquals(statusCode, 200, "HTTP status code mismatch: expected 200, but got " + statusCode);
// 后续代码仍会执行（仅当启用 soft assertion 时）——但注意：标准 Assert 是 hard assertion，失败即终止当前方法
System.out.println(getJsonPath(response, "error.message[0].msg"));
Assert.assertEquals(
getJsonPath(response, "error.message[0].msg"),
"branch should be 3 to 50 character long",
"Error message mismatch for empty branch"
);⚠️ 注意：上述 Assert.assertEquals 属于 Hard Assertion —— 一旦失败，当前测试方法立即终止（后续语句不执行）。若你确实需要“收集多个断言结果并统一报告”（即软断言），应改用 SoftAssert：
✅ 正确做法二：使用 SoftAssert 实现“失败后继续执行”
适用于需验证多个独立检查点的场景（如响应字段校验、错误码、错误消息等）：
import org.testng.asserts.SoftAssert;
@Test
public void testBankAPIValidation() {
SoftAssert softAssert = new SoftAssert();
Response response = given().when().post(a.getGetBankAPI()).then().extract().response();
int statusCode = response.getStatusCode();
// 所有 assertXXX 调用均不会立即中断执行
softAssert.assertEquals(statusCode, 200, "Expected HTTP 200 OK");
softAssert.assertEquals(
getJsonPath(response, "error.message[0].msg"),
"branch should be 3 to 50 character long",
"Branch length validation error message incorrect"
);
// 必须显式调用 assertAll() 才会汇总并触发最终失败
softAssert.assertAll(); // ← 关键！此处才真正抛出 AssertionError（若任一检查失败）
}❌ 错误示例解析（原代码问题）：
try {
Assert.assertEquals(statusCode, 200);
} catch (AssertionError e) {
org.testng.Assert.fail("Actual value is not equal to Expected value for"); // ❌ 导致 SKIPPED！
}- Assert.fail() 抛出 SkipException → TestNG 认为“主动跳过”，非失败；
- printStackTrace() 仅输出日志，不改变测试状态，故报告仍为 PASS 或 SKIPPED；
- 失去原始 AssertionError 堆栈，难以定位根因。
? 进阶提示：
- 若必须手动处理异常（极少数场景），请重抛原始 AssertionError，保留上下文：
} catch (AssertionError e) { throw new AssertionError("Custom prefix: " + e.getMessage(), e); // ✅ 保留 cause & stack } - 避免在测试中混用 Thread.sleep()；改用显式等待或重试逻辑提升稳定性；
- 断言消息建议包含预期值、实际值、上下文路径（如 "error.message[0].msg"），便于快速排查。
总结：不要用 try-catch “吞掉”断言异常，而应借助 TestNG 原生能力（带消息断言 / SoftAssert）实现精准、可读、可维护的验证逻辑。 状态准确的测试，才是可靠质量门禁的第一道防线。
