无意翻到到 google test blog 的一篇旧文章

原文请参见：https://testing.googleblog.com/2007/10/automating-tests-vs-test-automation.html

Automating tests vs. test-automation

在过去的几年中，测试的实践经历远远超出了表面的变化。我们把我们的艺术变成了工程学，引进了过程模型，提出了最佳实践，并开发了工具来支持我们的日常工作，使每个测试工程师更有效率。一些工具的目标是测试执行。它们的目的是自动化测试人员通过系统的用户界面执行功能以验证其功能的重复步骤。我相信你已经看到了像 Selenium，WebDriver，Eggplant 或其他专有的解决方案，你学会了爱他们。

从坏处看, 我们在使用这些工具时会注意到一些问题:

(1).以这种方式脚本化手动测试要比手动执行它们要长得多。
(2).UI 是任何系统中最不稳定的接口之一, 因此在开发阶段我们可以很晚才开始自动化。
(3).测试的维护需要大量的时间。
(4).执行缓慢, 有时很繁琐。
(5).测试变得很古怪
(6).测试因错误的原因而中断。

当然，我们可以争辩说，这些问题都不是特别糟糕，自动化的好处仍然大于成本。这很可能是真的。我们学会了接受这些问题中的一些作为自动化的代价, 而另一些则通过一些常识解决方法来满足:

(1).自动化测试需要很长时间, 让我们只自动化重要的测试, 并在回归测试中再次执行。
(2).执行速度可能较慢, 但仍比手动测试快。
(3).测试不能因为错误的原因而中断 -- 当它们中断时, 我们发现了一个 bug。

在这篇文章的其余部分, 我想总结一下我在试图克服这些问题时的一些经验, 而不是围绕他们的工作, 而是消除他们的原因。

这些问题中的大多数都源于我们仅仅自动手动测试的事实。通过这样做，我们不考虑是否要增加计算能力，访问不同的接口，和更快的执行速度，使我们改变我们测试系统的方式。

考虑到一个系统公开暴露了不同的接口，例如用户界面、前端和后端接口、数据存储接口以及与其他系统的接口，很明显，我们需要查看每个接口，并测试它。不仅如此，我们不仅要考虑每个接口，还要避免在太多不同的地方测试功能。

让我介绍一个商店管理系统的示例, 它允许您向商店添加物料、查看当前库存和删除物料。一个简单的手动测试用例：添加项目将是去'添加' 对话框, 输入一个新的项目并且数量 1, 然后转到'显示'对话框, 以检查它是否在那里。若要自动执行此测试用例, 您可以通过用户界面精确地检测所有步骤。

可能我上面列出的大多数问题都会碰到。避免它们的一个方法是找出这个系统的内部是怎样工作的。
(1).是否有数据库？如果是这样, 则可能不应针对 UI 执行验证, 而应针对数据库进行。
(2).我们需要与供应商进行交互吗？如果是这样, 应该如何看待这种互动？
(3).通过 API 可以获得相同的功能吗？如果是这样，应该通过 api 进行测试, 并且应该检查 UI 是否正确地与 api 进行交互。

这可能会产生更多数量的测试, 其中一些在资源需求方面要小得多, 而且执行的速度远远快于完整的端对端测试。应用这些简单的问题将使我们能够:

(1).通过 API 编写更多的测试, 例如, 覆盖许多边界条件,
(2).在同一台机器上执行多线程测试, 让我们有机会发现竞争条件 (race-conditions),
(3).较早开始测试系统, 这样我们可以测试每个接口, 当接口变得比较稳定 (quasi-stable) 的时候,
(4).使测试和调试的维护更容易, 因为测试更接近问题的根源,
(5).需要更少的机器资源, 并且仍然在合理的时间内执行。

我不主张在完全没有 UI 测试。用户界面只是另一个接口，所以它也值得关注。不过,我认为我们目前的大部分测试工作都集中在 UI 上。一般的态度，UI 最值得关注，因为它是用户看到的，这是有缺陷的。即使是完美的 UI，如果底层功能已损坏， 也不会满足用户的要求。

我们也不应该放弃我们的端到端测试。它们是有价值的，没有这些端到端测试，没有系统可以被视为经过良好测试。同样， 我们需要问自己的问题是全部的端对端测试和较小的集成测试之间的比率。

不幸的是,没有免费的午餐。为了改变测试自动化的风格,我们也将需要改变我们的测试方法。成功的测试自动化需要:
(1).在开发周期的早期开始,
(2).将系统的内部结构考虑在内,
(3).和开发者保持反馈互动来影响系统设计。

这些观点中的一些要求在我们的测试方法上有很大的改变。只有当我们与开发人员作为团队一起工作时，它们才能实现。至关重要的是，在这个团队的不同角色之间有绝对的信息自由流动。

在以前的项目中，我们能够做到这一点是因为：
(1).消除测试工程师和开发工程师之间的任何空间分离。坐在旁边桌子上可能是促进信息交流的最好方式，
(2).使用与开发人员相同的工具和方法，
(3).参与日常会议和设计讨论。

这不仅有助于及早参与 (在开发过程中测试开发同时启动的项目)，而且还是提供连续反馈的好方法。列表中的某些项目要常面向开发的测试工程师, 因为开发团队更容易将它们识别为同行。

总而言之, 我发现一个成功的自动化项目需要：
(1).要考虑系统的内部细节和暴露的接口,
(2).要对每个接口 (包括 UI) 进行许多快速测试,
(3).要在尽可能低的级别验证功能,
(4).要有一组端到端的测试,
(5).和开发同时开始,
(6).克服开发和测试之间的传统界限 (空间、组织和过程边界),
(7).使用与开发团队相同的工具。

笔者加：
上面的总结非常好，可以作为后续实现自动化的原则
因为自动化确实带来了方便，但是也是有代价的 ，结合笔者自己的实践
(1).看不同的行业和项目，例如手机端游戏行业，周期短平快的项目，其实不适合实现自动化，一是代价特别大，二是根本来不及做就上线了，三是维护代价也不小
(2).看人力情况
(3).看项目组的优先级，有时候性能压力测试比这个级别更高
(4).适合自动化的，最好是企业级软件，这种软件每个版本周期比较长，一个 milestone 可能长达数年，这个时候自动化是特别有意义的，也能提升效率。

关于自动化，笔者有好的体验，也有不好的体验
好的体验：针对 daily builder 跑 BVT，每天下班前跑一次，上班来了之后，稍微看下，发出邮件，半小时搞定
不好的体验，费劲心力，写出来的自动化，还没正式开展，项目就取消了，结果没用上。