查看测试和配置问题

在项目概览页面查看问题

Project Overview 页面同样展示了在构建配置中测试失败的数量以及其他问题。当有问题的构建配置中的数据未展开时，测试数字下方的链接会将您引导至 当前问题 标签页（参见下方）。

当您展开构建配置数据时，问题摘要会出现。如果您的浏览器没有足够的横向空间，问题的展示将会缩短。

使用当前问题标签页

要查看项目中存在问题的构建配置和测试，打开 项目主页 ，然后前往 当前问题 标签页。

默认情况下，Current Problems 标签页会显示一个项目内所有构建配置的数据。要限制显示的数据，请使用 按构建配置筛选 下拉菜单。

从这个页面，您可以查看分为以下几组的项目问题：

构建配置问题
失败的测试
静音测试失败
构建问题

每个部分都可以展开，您可以使用上下箭头进一步深入到最小的相关项目。

出现在构建配置问题和构建问题部分的链接使您可以监控大量有用的数据，例如，您可以导航到构建结果，查看构建日志和更改。当您点击链接旁边的箭头时，会有更多选项可用。

未通过的测试和已静音的失败部分均具有分组选项，并允许在点击测试名称链接时查看可用的测试堆栈跟踪。您还可以查看测试历史，打开活动IDE中的测试，开始调查特定的测试失败，修复并取消静音测试或开始调查特定的测试失败。

不稳定测试

TeamCity 能够检测出不稳定的测试，并在给定项目的专用标签页上显示。

脆弱测试是指一种不稳定的测试（可以显示通过和失败的结果），其结果与代码无关。

脆弱测试检测基于以下启发式方法：

高翻转率（测试状态频繁更改）。在 TeamCity 中的翻转是测试状态的更改 —— 要么从 "OK" 变为 "失败"，要么反过来。翻转率"是这种"翻转"与给定测试的调用次数之间的比率，按代理，构建配置或在一定时间段（默认为7天）内进行测量。一个始终失败的测试，虽然其失败率达到100%，但其翻转率将接近于零；而一个每次调用都会“翻转”的测试，其翻转率将接近于100%。如果翻转率太高，TeamCity 将认为该测试是不稳定的。
如果在没有任何更改的新构建中，测试的状态“翻转”，即先前成功的测试在无更改的构建中失败，或者先前失败的测试在无更改的构建中通过，那么 TeamCity 将认为该测试是不稳定的。
在同一构建中多次调用的不同测试状态（不稳定的失败）：如果同一测试被多次调用并且测试状态发生了变化，TeamCity 将视该测试为不稳定的。
支持此启发式规则对于 TestNG 单元测试，配有 调用次数 [1][2] 大于 1。

如果在同一VCS更改上运行多种不同配置的构建，并且这些构建之间的测试结果不同，则不认为测试是易变的。这样的结果很可能是由环境问题引起的。

对于 JUnit 测试，可以一同使用第三方的 tempus-fugit 库和 JUnit。仅需在测试中添加 @Intermittent 注解，并使用 IntermittentTestRunner 测试运行器，如下面的最小示例所示：

import org.junit.Test;
import org.junit.runner.RunWith;
 
import com.google.code.tempusfugit.concurrency.IntermittentTestRunner;
import com.google.code.tempusfugit.concurrency.annotations.Intermittent;
 
@RunWith(IntermittentTestRunner.class)
public class MultipleViaTempusFugit {
    @Test
    @Intermittent(repetition = 10)
    public void test() {
        // ...
    }
}

如果这样的测试在单个构建中的多次调用中至少出现一次不稳定，Flaky Failure 启发式算法将会被触发。

此类测试在专用的项目选项卡，Flaky Tests，上显示，其中包括测试失败的总数，给定测试的翻转率以及将测试归类为易出错的原因。

您还可以在构建结果页面查看失败测试的扩展堆栈跟踪，以判断测试是否不稳定。

与任何失败的测试一样，您可以为一个易变的测试（或多个测试）分配调查任务。对于易出错的测试，解决方法会自动设置为 "手动"；否则，一旦测试成功，调查将自动被移除，这并不意味着易出错的测试已经被修复。

请注意，如果 branches 为 VCS 根设定，则只能在默认分支中检测到不稳定的测试。

查看测试已在何处修复

对于一些测试失败，TeamCity 可以显示 "Already Fixed In" （已在此构建修复）构建。这是在初始测试失败后成功运行的构建，该构建是在具有初始测试失败的构建之后运行的（对于相同的构建配置）。

在这里，after 的意思是：

经过成功测试的构建比最初失败的构建具有较新的更改。
如果这些更改是相同的，那么在失败的构建之后会运行较新的构建。

如果您运行一次历史构建，TeamCity 将不会将其视为后续构建（就更改而言）中的测试失败的 "Already Fixed In"（已在此构建修复）候选项。

当测试具有相同的名称时，它们被认为是相同的。如果构建中有多个名称相同的测试，TeamCity 会计算具有相同名称的测试的顺序号，并将其考虑在内。

请注意，在单次构建中，同一测试的所有调用都被计为 1。

查看测试首次失败的位置

TeamCity 会显示一些测试的 "First Failure" 构建。这是 TeamCity 首次检测到此测试在同一构建配置中首次失败的构建，这意味着从当前构建开始，TeamCity 将回溯构建历史，查找此测试首次失败的时间。未进行此测试的构建将被跳过，如果找到了成功的测试运行，搜索将停止。
在这里，回溯历史 意味着 TeamCity 检测到的更改进行构建分析；因此，历史构建将被正确处理。

在单次构建中运行多次的测试被视为一次测试（也就是说，同一测试的所有调用被视为一次）。

最后修改日期： 16日 7月 2024年