自动化测试在提高结果质量、加速过程、增加测试覆盖率等方面，为软件测试过程提供了巨大的好处。
在本文中，我们列出了每个软件测试人员在自动化测试时必须记住的7个教训。
然而，在我们提供这些经验之前，必须记住两个基本规则：
1、在决定哪些测试将被自动化之前，应该首先设计测试
避免陷入自动化测试的陷阱，自动化测试很容易实现，但在发现缺陷方面却很薄弱。应该设计不同于手动测试的自动化测试，自动化测试的很大一部分力量来自于使用计算机去做一个人不能做的事情。
2、寻找机会，例如能够对成千上万个不同的数据文件重复相同的测试
防止陷入仅从现有(手动)测试计划中，进行自动化测试的陷阱，并错过测试自动化的大好机会。当设计手动测试时，不太可能考虑对成千上万个文件应用重复操作的测试；那是不可能完成的工作。
教训 01
Speed up the development process
加速开发过程
旨在降低测试成本的自动化测试，很少得到所需的关注和合作。
快速修复保持代码稳定。
保持代码稳定可以节省时间(多人不会在同一个bug上浪费时间)，并有助于重构和其他改进工作。
这里有两个支持快速开发的场景：
① 构建验证/冒烟测试
“冒烟测试”的含义是，一旦插上一块新板，打开电源，看到烟雾从板上冒出来，就应该关掉电源。
冒烟测试(也称为构建验证测试)，在有限的时间内广泛覆盖了所有的产品特性——通常是在午餐或晚上。如果关键特性不能有效运行，或者如果关键缺陷仍然没有被移除，测试团队就不用再浪费时间测试安装或者测试构建了。
② 自动化单元测试
简化了开发过程，防止了回溯，并保持了开发势头。
教训 02
100% automation is not a good thing
百分之一百的自动化不是一件好事
一些软件经理有一种误解，认为自动化测试总是等于更好的测试，他们要求所有的测试都必须自动化。
另一个需要破除的神话是，测试在按下按钮时，自动报告任何发现的错误。提供测试工具或者平台的第三方公司，助长了这种不负责任的幻想。只有手动和自动测试的适当结合才是获得更好的结果。
教训 03
Don’t equate manual testing to automated testing
手工测试不等价于自动化测试
虽然第2个教训告诉我们混合是必要的，但是也有必要弄清楚手动测试和自动化测试之间的区别。
自动化不会让计算机做你做的测试。它执行明确指定的测试，无法从我们的隐性知识和意识中获益。自动化测试每次运行都做同样的事情，速度相同，顺序相同，鼠标移动和按键点击完全相同。然而，手动测试员每次运行测试时，都会情不自禁地改变它。这些变化可以发现看不见的错误。有准备的头脑是一个奇妙的测试工具，超越了任何可以想象的自动化。
教训 04
Don’t estimate the value of a test in terms of how often you run it
不要根据你运行测试的频率来评估它的价值
测试的价值来自它提供的信息。
熟练的测试往往是很好地运用这些，来判断问题。
像所有测试活动一样，自动化测试的背后是成本和收益分析。如果分析错了，将会不恰当地分配资源。
教训 05
Automated regression tests find a minority of the bugs
自动化回归发现少数错误
各种调查指出，自动测试发现的错误数量少得惊人。
事实上，自动化回归测试，通常会在测试开发过程中发现比以后执行测试时更多的错误。然而，如果进行回归测试，并找到在不同环境中重用它们的机会(例如，不同的硬件平台或不同的软件驱动程序)，那么自动化测试更有可能发现问题。
教训 06
Automate for immediate impact
自动化带来的立竿见性的效果
太多人认为测试自动化意味着自动化手动测试。
结果是过分强调图形用户界面回归测试。
在不考虑测试用例条件下，把注意力集中在那些可产生很大的影响，但却需要很少付出的自动完成的任务上。此外，不必从头到尾自动化测试。
教训 07
Encourage the development of unit test suites
鼓励单元测试的开发
单元测试关注组成软件系统的最小单元:程序员创建的函数、类和方法。
真正的单元测试是孤立地测试单元。
创建服务来处理呼出呼叫，创建驱动程序来提供呼入呼叫。构建这些服务可能是一项重大工作。一种更流行的自动化单元测试，形式是通过在上下文中测试，来避免测试服务的开发(也称为单元集成测试)。
单元测试也被视为极限编程和其他敏捷方法的核心实践。
总结
Conclusion
上面的教训引出了两个重要的事情，每个测试人员都应该记住
- 如果没有良好的测试设计，自动化可能会导致大量的活动，但几乎没有价值。
- 在没有很好理解自动化可能性的情况下，设计测试，可能会忽略一些最有价值的自动化机会。