【问题标题】:Techniques for assessing team test confidence?评估团队测试信心的技术?
【发布时间】:2009-09-19 12:38:49
【问题描述】:

我正在尝试确定我的开发团队对我们的自动化测试库(单元、集成、网络测试)的信心程度。我最希望得到以下问题的合理答案:

  • 您希望测试涵盖/不涵盖哪些重构?
  • 您是否相信绿色构建可以为验收测试环境自动部署?
  • 您是否相信绿色构建可以直接自动部署到生产环境?

我希望有一些预先存在的指标和调查问卷可以用来探索这个领域。我的目标是提高自动化部署的水平,但我真的只相信我们可以自动化开发人员信任/相信的事情。

有人知道探索这个的任何技术吗?

【问题讨论】:

    标签: testing automated-tests


    【解决方案1】:

    我不知道该领域有任何现有的工作。您的问题很好,并将它们放在每个问题 1-5 星的论文上,这应该会给您一个想法。其他需要考虑的因素:

    • 在测试后多久发现一次测试应该发现的错误?您可以使用错误数据库中的特殊字段来跟踪这一点
    • 开发人员多久运行一次测试?在这里,置信度 == 1/频率。如果他们相信测试,他们会经常进行测试。如果他们不相信它们,就不会运行它们,甚至不会将它们视为一种痛苦。
    • 在您的 CI 服务器上构建失败的频率如何?这通常表明测试很脆弱并且只能在开发人员的机器上运行,或者开发人员在提交之前没有运行测试。

    【讨论】:

    • 我们对发现的错误有相当不错的指标,尽管我们倾向于将测量重点放在滑入验收测试的回归上。测试电池的负载相当大(=耗时),因此我们实际上依靠 CI 来解决其中一些问题。我认为关注开发人员的看法可能与“硬”指标一样有价值,因为它们可能反映了您从测试中获得的价值
    【解决方案2】:

    您是否想过召开会议并询问他们?

    讨论它可能会带来数字和指标无法表达的潜在陷阱。

    【讨论】:

    • 是的,我们一直在讨论这个问题,我认为我们已经意识到我们的环境存在很多缺陷;) 评估个人和集体的测试信心确实可以引导各种方向。我真的认为我们在个人调查之后举行的会议可以促进整个团队的发展。
    【解决方案3】:

    直接问他们这些问题。

    特别重要的是关于“自动部署以供接受”的内容。看看是否会有很大的犹豫,如果是,你该如何解决。

    还有一个想法:考虑 3 天或 1 周的试用期,以便自动部署到接受。在它之后进行第二次讨论并评估它是如何进行的。努力进行自动化生产构建。

    周围显然有指标

    • 代码覆盖率
    • 回归
    • 错误发现与修复
    • 集成服务器发现的错误

    收集这些对团队来说可能是有趣的素材,但归根结底,正如您所说,这是一个信心问题,因此有些情绪化。什么数字会让他们更有信心。

    【讨论】: