allure 默认将同一测试方法的多次执行（如参数化测试）视为重试（retries），导致即使部分数据失败，套件层级仍显示为“通过”。本文详解其成因及正确配置方案，确保失败数据真实反映在顶层状态中。
在使用 Allure 生成测试报告时，一个常见却易被忽视的问题是：参数化测试（如 TestNG @DataProvider 或 JUnit5 @ParameterizedTest）中，只要有一个测试数据执行失败，期望该测试用例在 Suites 视图中整体标记为“Failed”，但实际却显示为“Passed”——仅在 Retries 标签页中可见失败记录。
这并非 Allure 的 Bug，而是由结果数据源混淆或报告生成路径错误导致的典型配置问题。
? 根本原因：混用了非 Allure 原生结果目录
Allure 专为解析其自身生成的 JSON 格式结果文件（如 test-result-*.json）而设计。若错误地将 surefire-reports/（JUnit XML）或 testng-reports/ 等第三方测试框架原始报告目录传给 allure serve，Allure 会尝试“尽力解析”，但无法识别参数化粒度与失败传播逻辑，从而将整个方法视为单次执行，并忽略重试语义——最终套件状态仅取决于最后一次执行结果（常为成功），造成误导。
✅ 正确做法：始终使用 target/allure-results/（Maven）或 build/allure-results/（Gradle）作为唯一输入目录。
# ✅ 正确：服务 Allure 原生结果目录（推荐） allure serve target/allure-results/ # ❌ 错误：服务 Surefire 的 XML 报告（会导致状态误判） allure serve target/surefire-reports/
? 提示：allure-results/ 目录由 allure-java-commons 在测试运行时自动写入（需配置监听器），每个参数化执行都会生成独立的 .json 文件，Allure 才能准确聚合并识别“任一失败即整体失败”。
? 配置验证清单（以 Maven + TestNG 为例）
确认 allure-maven 插件未启用冲突配置
检查 pom.xml 中是否误配置了指向 surefire-reports。 -
确保测试监听器已注册
TestNG 需启用 AllureTestNg 监听器：<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>3.0.0-M9</version> <configuration> <suiteXmlFiles> <suiteXmlFile>testng.xml</suiteXmlFile> </suiteXmlFiles> <properties> <property> <name>listener</name> <value>io.qameta.allure.testng.AllureTestNg</value> </property> </properties> </configuration> </plugin> 检查构建后目录结构
运行 mvn clean test 后，确认 target/allure-results/ 下存在多个 *-result.json 文件（每个参数化实例一个），而非空或仅有 environment.xml。
✅ 效果验证
完成上述配置后重新生成报告：
- Suites 页面中，该测试方法名称旁将显示 ? Failed（而非? Passed）；
- 点击进入详情页，可查看所有参数化执行记录，失败项高亮标红；
- “Retries” 标签页依然保留，但此时它已成为辅助诊断入口，不再主导状态判定。
⚠️ 注意：Allure 不支持“部分成功即整体通过”的自定义策略。其设计哲学是——同一逻辑单元（方法）的多次执行，任一失败即代表该单元不可靠。这是保障报告可信度的关键原则。
通过严格区分数据源、使用原生结果目录并校验监听器配置，即可彻底解决参数化测试状态显示不一致问题，让 Allure 报告真正成为质量决策的可靠依据。
