作者以自己的实际经验，得出自动化测试的七个步骤，将有效达到自动化测试的目的。
步骤一：改进软件测试过程
作者更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。
作者举了很多方面的实例，在无需构建自动化测试系统的情况下，也能大幅度的提高测试效率。目的就是为了使测试过程简单并有效率，任何有用的方法都可以使用。测试过程中出现的困难和费时问题时，解决它们就是提高测试效率，就是改进。
步骤二：定义需求
作者认为，最开始应该有一份自动化测试需求，用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。
这里有一段有关于手工测试的描述，总结的很好：
手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源，建立测试环境，执行测试用例。测试过程中，如果有什么异常的情况发生，手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果，记录测试结果，复位被测试的软件系统，准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况，研究测试过程可疑的现象，寻找测试用例执行失败的过程，设计并执行其他的测试用例帮助定位软件缺陷。“红字部分”自动化测试是很难做到的。
作者认为,千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分，部分的采用自动化测试是最好的方法。定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。
步骤三：验证概念
作者认为：你需要尽可能快地验证你采用的测试工具和测试方法的可行性，站在产品的角度验证你所测试的产品采用自动化测试的可行性。回归测试是最宜采用自动化测试的环节。
这里有个观点很吸引我的注意力，测试环境建立也能进行自动化。作者认为：“对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。”
步骤四：支持产品的可测试性
作者认为：从本质上看， API 接口和命令行接口比 GUI 接口容易实现自动化。如果希望自动化测试不会因为图形界面发生变化而被中断，就应该采用命令行接口或者 API 接口的测试。采用可编程的接口是最可靠的。 采用 API 接口的方式，还可以实现独立的产品模块的单元测试自动化。
步骤五：具有可延续性的设计
作者认为：自动化测试是一个长期的过程，为了与产品新版本的功能和其他相关修改保持一致，自动化测试需要不停的维护和扩充。有很多存在问题的测试用例表面上执行通过了，实际上却执行失败了，并且没有记录任何错误日志，这就是失败的自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。（也就是手工测试用例还不成熟完善的情况下进行自动化测试的结果）
应该集中精力关注可以延续使用的测试套，从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性、测试库、数据驱动测试（我的公司的自动化测试用到了这个方法）、启发式确认。（介于本人没有自动化测试的经验，作者所说的这几方面无法理解和掌握，各位还是看原文吧）
步骤六：有计划的部署
有计划的自动化测试部署，保证你的测试套能够被产品相关人员获取到，你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。
步骤七：面对成功的挑战
持续在在自动化投入，你会面临成功的挑战，当自动化测试成为测试过程可靠的基础后，自动化测试的道路将会越来越平坦。
如果你不想再体验一次自学时找不到资料，没人解答问题，坚持几天便放弃的感受的话，可以常去一些技术论坛、群。多和别人交流，探讨一些技术上的问题。在这里向大家推荐学习交流群 779450660，群里有技术大牛解惑答疑,还有各类资源（面试题，视频教程，PDF文档）