自动化价值的量化

Question

在过去的6个月里，我用一个崭新的appium/webdriver框架替换了几个旧的框架，其中一个使用了企业工具集。一切都进行得很好，测试人员和管理层都买了好东西。我们以前花了40小时以上的测试运行现在更容易管理了。我们正在规划下一年的计划，并确定测试工程团队的里程碑。管理层已经看到了减少夜间运行时间、使用开放源码工具和创建更易于使用的框架的价值，但他们现在要求我向他们提供指标，或者我在其他公司实现的一些工具/流程的价值。

这可能不是问所有这些的最好的地方，但我希望这里的人可能经历过类似的事情。有没有人有任何方法来评价：

• 比较报告/使用来自多个源的组合日志文件运行历史记录，以使测试人员/开发人员能够更快地诊断故障。
• 更有规律地/在签入时运行测试，而不是每晚运行，或者只运行受影响的测试。
• 减少片状试验或重新运行片状试验
• 机器人可以自动分割测试并引发缺陷。
• 更有规律的安全/性能测试，而不是发布时
• 应用程序的星型增长
• 代码覆盖率统计
• 仪表板

干杯，詹姆斯

Answer 1

是啊，我自己也经历过很多。一般来说，可靠的自动化和易于诊断的故障可以极大地提高速度和信心，并节省费用。我通常尝试创建自动化，这是CI管道的一部分，有以下两个目标：

1. 确保我至少涵盖了每个功能的快乐路径，以获得对所有功能质量的即时反馈，而不是等待几天或几周无法发现问题的手动回归。
2. 包括接近100%的所有回归测试的具体功能，以减少总体成本和时间回归测试。

为了具体地解决你们的问题：

• 比较报告/使用来自多个源的组合日志文件运行历史记录，以使测试人员/开发人员能够更快地诊断故障
  • 使您的团队能够更快地诊断故障是确保自动化增加价值的关键。花费更多的时间来诊断故障意味着您需要更长的窗口来运行测试和查看结果，您可以通过以下几个方面来衡量这一点:您为您的团队成员支付了多少额外的调查费用，以及为更长的反馈循环进行市场的时间损失。

• 更有规律地/在签入时运行测试，而不是每晚运行，或者只运行受影响的测试。
  • 这直接影响到你意识到问题的速度，并帮助你精确地确定导致问题的确切签入。您可以根据开发团队花在开发团队上的时间来衡量这一点，以确定哪些签入导致了缺陷。

• 减少片状试验或重新运行片状试验
  • 重新运行的片状测试实际上可以掩盖缺陷的间歇性问题。我通常会提醒你不要那样做。如果您谈论的是由自动化问题引起的片状测试，您应该修复它们，而不是重新运行它们。花时间解决这些问题，减少噪音，建立对自动化结果的信心，并节省时间来确定产品中是否确实存在缺陷。你可以用花在调查片状测试故障上的时间来衡量这一点--或者更糟的是，忽略那些故障，让一个真正的缺陷溜走。

• 自动分割测试并引发缺陷的机器人
  • 我对这件事有复杂的感觉。我喜欢自动分割测试的想法，比如对堆栈跟踪进行评估，并找出可能是由于相同的根本原因造成的类似故障，但是自动引发缺陷可能有点棘手，我通常不会这样做。测量分段测试的值可以再次花费几个小时来调查故障。如果你一晚有30次失败，每一次都需要10分钟来确定发生了什么，但你可以立即将其中的20次分组回到一个根本原因，那么你就节省了3个多小时的调查时间。

• 更常规的安全性/性能测试，而不是发布时
  • 这似乎是个不需要思考的问题。一次安全漏洞对一家公司来说可能是一场灾难。直至并包括大量的客户外流和破产。糟糕的性能或内存泄漏导致应用程序冻结或崩溃，同样也会产生巨大的影响。即使你避免了半夜把人拖进办公室的一次火灾演习，这一次也会自食其果。

• 应用程序的星光增长
  • 不知道你这么说是什么意思。

• 代码覆盖率统计
  • 我喜欢使用代码覆盖率统计数据来实现自动化。最重要的是，它帮助我告诉我应该把我的测试集中在哪里，以及哪些领域没有涵盖。它还帮助我确定哪些测试是真正等价的，并减少了重复测试的数量。您可以通过减少由于覆盖更多代码路径而减少的缺陷来度量这一点。

• 仪表板
  • 这些通常对管理、沟通状态更有用。您可以用更少的时间手动与管理人员沟通状态来衡量这一点。