#1 楼
我能想到的最简单的方法是，通过不必对自动化测试所涵盖的所有场景进行回归测试，来基于质量检查人员节省了多少小时。如果答案是他们不会对它进行回归测试，那答案应该是。理想的情况是整个应用程序应该从一个发行版到另一个发行版进行测试，但这在大多数情况下是不可能的。这是自动化测试真正发挥作用的地方。您可以让QA主题专家来编写方案，然后不必担心再次进行测试。#2 楼
我确信自动化测试会有所帮助，并且肯定应该有一个ROI。问题是，由于存在几种不同的类型，因此对于您进行的自动化测试，您将获得哪种ROI。节省时间-这种方法应该比其他类型的方法更具可量化性投资回报率。将手动测试执行与自动执行进行比较所节省的时间对于建立一个好的案例很有用。
可重复性-自动化测试的执行方式与每次执行时完全相同。这看起来似乎不是很大的回报，但是请考虑如果不存在这些测试，则需要手动执行多少个步骤，然后考虑该工作可能会犯多少个错误。
可跟踪性-自动化测试（通常）提供了某种类型的执行证据。它可以是传统的日志，也可以是执行后的简单通过/失败输出，但是无论哪种方式，自动化测试都可以更好地跟踪执行过程中所测量的内容，并提供比手动测试器更少的变化。
可用性-自动化测试可以手动启动，也可以在一天中的任何时间自动运行。他们不会感到疲劳，生病或休假，并且可以在没有特殊安排的情况下被安排到周末工作。
这些只是我脑海中的一小部分，但是您将是确定这些测试对您最有利的方面的最佳人选。坐下来，认真考虑一下这些测试为您的项目提供的积极补充。
评论
如果您要查找错误，那么可重复性实际上是一个缺点-手动测试随附的自然人为变异可提供更大的覆盖范围。如果您主要想要的是合理地确保故障指示自上次运行以来发生的某些更改，那么这很好，这通常是您从回归套件中获得的。您可以编写自动化来引入变化。
– testerab
2011年5月11日20:33
@testerab是真的应该发现自动错误的自动化测试吗？如您所说，回归测试主要是为了确保旧错误不会出现。探索性测试（实际上无法完全用自动化测试代替）将发现新的错误并充分利用人为的变化。
–史蒂文
2011年5月11日在22:27
绝对同意，探索是发现更多错误的地方：但是探索不必纯粹是手工的。它只需要有人脑在某个地方循环。本文有趣，读物：developsense.com/blog/2010/09/…
– testerab
2011年5月11日23:57
我们的回归套件不是要发现新的错误，而是要清楚地表明该版本足以执行进一步的测试。我认为拥有确定性回归套件和另一套用于模糊测试的套件非常重要，这将试图发现新的缺陷。
–stuartf
2011年5月17日在21:40
#3 楼
我很快就能想到应该可以衡量的三个好处。（1）使测试人员摆脱重复回归测试的单调乏味，使他们能够专注于新的开发和需要关注的领域。累加他们不花时间进行回归的时间，并说明如何处理新项目。
（2）加速测试窗口。特别是当R＆D频繁检查代码时，尽早发现回归问题可以使他们在引入错误时的窗口更窄。想想看，如果我可以说Test X在3天前通过并在今天失败了，那么开发人员只需担心3天的代码，而不用担心3个月的时间。跟踪与手动回归相比，捕获它们的速度。
（3）为较小的发行版提供了更好的测试级别。在具有很小的测试窗口的Service Pack，补丁程序和修补程序中，您并不总是有时间手动运行回归测试，但是如果它们是自动化的，则您现在可以选择在短时间内运行那些测试。计算在Service Pack中运行从未有过的回归测试的数量。
#4 楼
我无法确定OP是测试人员还是开发人员。我假设他们是测试人员。由于相对成本和回报是投机性的，因此很难衡量自动化测试的投资回报率。
这是我的亲身经历。在某些情况下，自动化测试可能是重现问题或验证更改使产品更好的唯一方法。在大多数测试中，自动测试会发现手动测试可能已经发现的错误。
有能力编写自动化测试的测试人员要比没有自动化测试的人员贵。倾向于自动化的测试人员可能会有意或无意识地避免测试难以自动化的功能。
从弄清质量保证组织的回报率开始可能更有意义。整体。
评论
答案应该根据谁提出的问题而改变吗？看来这是客观地问到的，这没关系。
–corsiKa♦
2011年5月10日20:56
@glowcoder我对质量保证组织的回报率的评论与OP的问题无关，如果OP从编写QA组织之外的开发人员的角度询问，即谁编写自动化测试。同理，我对编写自动化测试的测试人员的评论。
–user246
2011年5月10日22:45
#5 楼
在将错误发布给客户之前，很难为捕获错误付出任何代价。这可能是一个小问题，可以在下一个版本中予以纠正，或者它可能是使您无法在办公室疯狂地尝试解决的问题，以便尽快将其提供给客户。如果您依靠自动化来检查功能，以便避免在发货前手动检查该功能，那么我相信可以为以下内容计算投资回报率：
您的团队在类似的客户问题上花费了很多时间，无论是紧急情况还是其他原因。
#6 楼
第一个问题：您为什么觉得需要对此进行量化？是否要求您提供指标？定性评估在这里会更有价值吗？对我来说，听起来还好像您关注的是错误的水平-即针对的小组太小：并不是要使测试人员更有效，或开发人员更有效，但要使整个团队更有效。您可以从开发人员那里得到有关如何帮助他们的反馈吗？是否有任何您可以做的事而您以前做不到的事（例如，无需花3周的时间进行回归测试即可在2天之内解决紧急更改，或者在项目中途添加功能）让您保持/赢得主要客户），这会吸引您的利益相关者吗？
如果不链接Cem Kaner关于度量的论文，我就无法写出关于度量的答案。
评论
没有太多人要求我提供数据，但是，我希望能够在新项目中证明这种方法的合理性，并且像管理人员总是谈论节约和成本。
–stuartf
2011年5月10日在21:13
尽管您提供的数字不是很好的方法，但是您可以将自己陷进一个大坑中-一旦您踏上那条路，他们便成为目标。有时最好抵制在报告中添加模糊图表的诱惑。
– testerab
2011年5月10日在21:19
问题是测试人员所做和提供的大部分内容是主观的，没有直接的成本，因此很难说服bean计数器。
– MichaelF
2011年5月13日在20:07
#7 楼
我不认为这是一门精确的科学，因此您需要做出一些假设。但是，如果您能投入一些数字，金钱或时间，那么花费多少钱才能找到开发中的bug（dc），测试（tc）和产品（pc）。然后，您可以给出一些不同的场景，例如，自动化减少了使用x在开发中，通过y测试和在z生产中发现的错误数量。那么您的估算值为total savings = x*dc + y*tc + z*pc - (cost of automation)。这是一个非常简单的入门模型。我还没有使用过它，但是如果我要为自动化编写ROI，那将是我的起点。
#8 楼
请记住，在大多数情况下，自动化测试只会捕获“血统测试人员”已经掌握的东西。这是一件好事，因为我们希望他们考虑要测试的新方法和事物，而不是一遍又一遍地重复。我们在上一家公司的规则是尝试进入我目前的公司）是针对每个错误的，都有一个测试可以抓住它。这有很大的影响。如果您有一个错误，并且发布了一个补丁，内容为“嘿，客户，我们已经在听您了！我们已修复了您报告的错误！对我们来说是！”然后事实证明您并没有真正修复它，不仅因为没有修复而使他们发疯，还失去了客户的信任。
所以-您的客户有多少？相信你值得吗？
评论
无价是真正的答案，但是，我很高兴知道实际成本。
–stuartf
2011年5月10日21:16
#9 楼
有一些在线服务可以计算投资回报率：1。投资回报率计算器
2。投资回报率计算器2
评论
我使用了这种方法，我们大约花费了5800小时。这样节省了大约28000小时执行的项目团队表格，总共节省了22200小时（再次大约）！
–stuartf
2011年5月17日在21:42