【问题标题】:How to report failures of automated tests with different severity?如何报告不同严重程度的自动化测试失败?
【发布时间】:2016-08-16 12:24:55
【问题描述】:

如何区分失败的关键测试(应立即解决)与失败但不太关键的测试(例如,打开错误默认选项卡的选项卡视图)?似乎大多数服务(我使用的是 CircleCI)只显示红色或绿色。

我觉得除了绿色和红色之外,我还需要一些中间的“橙色”颜色。是否有任何附加或技巧可以帮助我们区分关键测试失败和可接受的失败? (例如带有注释@non-critical?)

我正在使用 Cucumber 测试 Ruby on Rails 应用程序。

编辑

这里有两种可能有意义的方法(请随意提出其他方法):

  • 一个单一的构建警报不仅是“绿色”或“红色”,而且可能是“黄色/橙色”,具体取决于哪些测试失败

  • 许多构建,只能是绿色或红色,但会被标记

    “关键测试”构建成功,出现 0 个错误(绿色)

    “非关键”测试构建失败,出现 10 个错误(红色)

【问题讨论】:

    标签: ruby-on-rails testing cucumber automated-tests circleci


    【解决方案1】:

    更好的方法是将关键功能和非关键功能的执行分开。检测到严重故障会更快,并且您可以更频繁地运行它们。

    使用@critical 运行标记的关键功能:

    cucumber --tags @critical
    

    使用@critical 运行未标记的非关键功能:

    cucumber --tags ~@critical
    

    文档:
    https://github.com/cucumber/cucumber/wiki/Tags

    【讨论】:

    • 这是有道理的,但我从 OP 那里得到的印象是,他正在寻找一种方法来进一步分离 CI 测试运行的输出,就视觉反馈而言。分两次运行测试,一次是关键的,另一次是非关键的,这是一个很好的第一步。现在如何更改非关键故障的颜色。不知道。
    • 我团队中的业务人员喜欢对开发人员的工作进行视觉反馈。我的 CircleCI 构建结果被发送到一个松弛通道。所以你会建议也许使用像CircleCI-matrix 这样的东西来触发与标签集相对应的几个构建?
    • @Cyril Duchon-Doris,我从未使用过 circleci,但据我所知,可以为单个构建执行多个测试。然后,使用简单的脚本汇总结果并将报告推送到您的 slack 频道。
    • 啊,是的,我现在明白你的意思了。我想这不仅仅是一个“简单的脚本”,因为我仍然需要解析构建工件等。但我可能会找到互联网的例子。
    【解决方案2】:

    我强烈建议不要进行“非关键”测试。二进制通过/失败结果易于管理:一个套件要么通过且一切正常,要么失败并需要修复。每当我看到按重要性级别划分的测试套件时,团队立即开始只关注最重要组中的测试,并且允许更多不重要的测试失败。

    相反,如果某个测试被认为不够重要而无法修复,请将其删除。更好的是,如果某个功能被认为不够重要,无法进行测试,请将其删除或简化,这样就没有什么可测试的了。

    请注意,产品所有者和开发人员都可以就重要到需要修复的内容提出意见。例如,如果开发人员有一个 100% 代码覆盖率的标准,并且测试是提供部分覆盖率的唯一测试,那么开发人员坚持保持测试通过是正确的,即使它测试的功能不是t 被产品所有者认为是关键的。虽然这会暗示应该删除或简化该功能,以便开发人员也不需要测试。

    【讨论】:

    • 虽然这对于已经完善的应用程序来说可能很好,但我正在为一个有点敏捷的环境中的初创公司编码,由于时间限制,我们故意留下损坏的测试(实际上我们正在添加自动化测试到已经存在的应用程序)。我们确实希望“只关注最重要的测试”。我们可以承受一些损坏的功能,但如果计费系统出现故障,那就太糟糕了^^"
    • 更有理由决定哪些测试是关键的,哪些不是,并且永久禁用(或不编写)非关键测试。
    猜你喜欢
    • 1970-01-01
    • 2020-12-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-04-05
    • 1970-01-01
    相关资源
    最近更新 更多