翻译整理自Dorothy Graham 和 Mark Fewster的文章
That's no Reason To Automate, 发表在Better Software, July/August 2009.

并非全文翻译，只是根据自己的理解，提炼整理了文中的相关观点。

发现更多bug

目标背后的好想法
- 测试应该发现bug，所以自动化测试应该更快的发现它们
- 因为测试可以执行的更快，所以我们可以执行更多测试，发现更多bug
- 我们可以对系统测试更多，所以我们应该在那些不能执行手工测试的部分发现更多bug
测试质量决定是否发现bug
如果最初进行的是手工测试，发现的bug应当被修复
重复旧测试并不能比进行新测试发现更多bug
更好的目标
- 帮助测试人员发现更多的回归bug

在夜间和周末运行回归测试

目标背后的好想法
- 我们花钱在工具上了，所以应该在别处节省回来
  我们想消减总的开支，而人员的开支比较高
很多manager会持这个观点
当自动化引入，实际上很少出现减员
相反，需要更多拥有测试脚本开发能力的人员
自动化支持测试活动，而不是篡权
自动化测试不等于全自动测试，需要人力开发脚本，分析测试结果，维护测试套件
自动化可以提高测试执行的效率，但需要测试人员保证测试本身有效
这个目的是管理的目标,不是一个适合自动化的目标
更好的管理目标是确保每个人都是他们擅长执行任务。这不是一个自动化的目标,也不是降低测试成本。
它可能是有效目标，但它是关于管理的，与自动化无关。
更好的目标
- 总的自动化测试成本，必须显著低于被自动化测试所节省的总测试成本
- 这可能部分的被以下指标所衡量：帮助人们每小时所提高的测试运行数或覆盖范围
- （这段我翻译的太拗口，大家看原文去吧）

目标背后的好想法
- 减少截止日期压力——任何可以节省时间的方式都是好的
- 测试是瓶颈，所以更快的测试会所有帮助
- 我们想更快的将产品发布上市
这是个很危险的目标，它混淆了“测试”和“测试执行”，所以也会产生问题
问题1：有很多容易的方法来达成目标：运行较短时间的测试，忽略长时间的测试，或者剪掉回归测试
问题2：缩短测试时间，很容易给人一种缩短总体测试时间的错觉：而自动化工具专注于测试执行，并不是整个测试过程
问题3：实际上，除了测试执行时间，还有很多因素会影响整体测试时间：自动化测试的设置和复位，确认缺陷并识别错误之处。手工测试时，你知道发现bug的上下文信息；而自动化测试只会告诉你差异之处，分析人员必须结合上下文信息，确认是否为真正的bug
导致测试时间增加的重要因素是软件的质量，这取决于开发人员，而不是手工或自动化测试人员
考虑维护成本：可能在第一个版本满足了目标，但是在接下来的版本中变的更糟
更好的目标
- 对于工具所支持的测试活动，减少花费在它上面的时间
- 这对自动化来说是一个持续的目标，去改善手动和现有自动化测试。
- 它可以通过计算指定测试活动的时间，进行衡量。

目标背后的好想法
- 需要衡量自动化工作的进展
- 需要衡量自动化的质量
更重要和基础的要点是，去了解目前的测试质量，而不是已经做了多少自动化
如果是些没什么用的坏测试，自动化它们也没什么用（只是执行的更快了）
“Automated chaos is just faster chaos.”
如果目标是自动化50%的测试，是否自动化了正确的50%呢
多少比例的测试应当被自动化？首先要排除这样的测试：那些实际上不可能，或者完全不切实际的自动化。
自动化提供了支持测试的工具，不应当简单的自动化测试。
更好的目标
1. 自动化应当为测试提供有价值的支持
2. 可以这样衡量：测试人员有多经常使用自动化人员提供的内容，包括执行自动化测试和其他支持。
3. 通过自动化，增加了无需手工验证的数量

下面附上相应的思维导图

错误的自动化测试目标.png