翻译整理自Dorothy Graham 和 Mark Fewster的文章
That’s no Reason To Automate, 发表在Better Software, July/August 2009.
并非全文翻译，只是根据自己的理解，提炼整理了文中的相关观点。
发现更多bug
- 目标背后的好想法
- 测试应该发现bug，所以自动化测试应该更快的发现它们
- 因为测试可以执行的更快，所以我们可以执行更多测试，发现更多bug
- 我们可以对系统测试更多，所以我们应该在那些不能执行手工测试的部分发现更多bug
- 测试质量决定是否发现bug
- 如果最初进行的是手工测试，发现的bug应当被修复
- 重复旧测试并不能比进行新测试发现更多bug
- 更好的目标
- 目标背后的好想法
- 我们有未利用的资源（夜晚和周末）
- 我们应该在睡觉的时候执行自动化
- 要达到这个目标太简单了，只要运行测试，而不管他是否值得运行
- 可以运行更多的自动化测试，但你需要证明需这些测试执行是有用的
- 衡量的方法之一是对所有的自动化测试，估算对应手工执行的时间，并进行衡量
- 更好的目标
- 目标背后的好想法
- 我们花钱在工具上了，所以应该在别处节省回来
我们想消减总的开支，而人员的开支比较高
- 我们花钱在工具上了，所以应该在别处节省回来
- 很多manager会持这个观点
- 当自动化引入，实际上很少出现减员
- 相反，需要更多拥有测试脚本开发能力的人员
- 自动化支持测试活动，而不是篡权
- 自动化测试不等于全自动测试，需要人力开发脚本，分析测试结果，维护测试套件
- 自动化可以提高测试执行的效率，但需要测试人员保证测试本身有效
- 这个目的是管理的目标,不是一个适合自动化的目标
- 更好的管理目标是确保每个人都是他们擅长执行任务。这不是一个自动化的目标,也不是降低测试成本。
- 它可能是有效目标，但它是关于管理的，与自动化无关。
- 更好的目标
- 目标背后的好想法
- 减少截止日期压力——任何可以节省时间的方式都是好的
- 测试是瓶颈，所以更快的测试会所有帮助
- 我们想更快的将产品发布上市
- 这是个很危险的目标，它混淆了“测试”和“测试执行”，所以也会产生问题
- 问题1：有很多容易的方法来达成目标：运行较短时间的测试，忽略长时间的测试，或者剪掉回归测试
- 问题2：缩短测试时间，很容易给人一种缩短总体测试时间的错觉：而自动化工具专注于测试执行，并不是整个测试过程
- 问题3：实际上，除了测试执行时间，还有很多因素会影响整体测试时间：自动化测试的设置和复位，确认缺陷并识别错误之处。手工测试时，你知道发现bug的上下文信息；而自动化测试只会告诉你差异之处，分析人员必须结合上下文信息，确认是否为真正的bug
- 导致测试时间增加的重要因素是软件的质量，这取决于开发人员，而不是手工或自动化测试人员
- 考虑维护成本：可能在第一个版本满足了目标，但是在接下来的版本中变的更糟
- 更好的目标
- 目标背后的好想法
- 对软件测得越多，就覆盖的越多
- 测试是好的，所以更多的测试更好
- 好的测试不等于运行的测试数量，而是和所运行测试的价值有关
- 自动化许多坏的测试，只能带来维护开销和少量回报
- 自动化最好的测试，才能在时间和金钱方面带来价值、
- 先从重要的部分开始自动化，当我们开始执行测试，会发现不同于计划部分的另外的测试需要进行自动化。自动化需要能够在方向上进行调整，而不必每次都从头开始
- 自动化测试期间，开始可能需要较长的时间（相比手工时间）去自动化一个测试，因此可能导致短期内会运行较少的测试
- 更好的目标
- 目标背后的好想法
- 需要衡量自动化工作的进展
- 需要衡量自动化的质量
- 更重要和基础的要点是，去了解目前的测试质量，而不是已经做了多少自动化
- 如果是些没什么用的坏测试，自动化它们也没什么用（只是执行的更快了）
- “Automated chaos is just faster chaos.”
- 如果目标是自动化50%的测试，是否自动化了正确的50%呢
- 多少比例的测试应当被自动化？首先要排除这样的测试：那些实际上不可能，或者完全不切实际的自动化。
- 自动化提供了支持测试的工具，不应当简单的自动化测试。
- 更好的目标
- 不要把测试目标和自动化目标混为一谈
- 选择更为合适的目标，并且衡量你实现的程度，这样你就能看出你的自动化成果是怎样使公司受益的
下面附上相应的思维导图