我们正在一个自动化的持续集成/部署管道中进行工作。我们有数百个测试用例和4个阶段（红色，橙色，黄色，绿色）。
我面临的问题是测试可能会失败（错误，计时，卡住的进程等），并且将使整个回归运行失败。
我认为我们需要一些权重来确定通过/失败测试的数量，以将其视为“失败”构建。
有什么想法吗？您在管道上创建的内容？
谢谢， -M
答案 0 :(得分：0)
构建失败并不总是能够反映产品的质量，主要是在失败与测试基础架构问题有关的情况下。
通过构建一个易于维护和扩展的强大而稳定的框架，减少了与应用程序错误（时间，进程阻塞）无关的意外失败的风险。
当谈到与应用程序错误相关的失败时，失败的测试类型比失败的数量更为重要。这是缺陷严重性。您可以进行3次无重大影响的小故障，也可以进行1次至关重要的故障。您需要相应地标记测试。
此外，还有一个詹金斯plugin，可创建易于遵循的测试运行历史记录，您可以在其中查看上次运行中失败次数最多的测试数量。