背景介绍
　　自动化常常是测试团队首先想要建设的内容，因为自动化的好处是明显的，但真正实现自动化测试的时候才发现，这条路上的“坑”比想象的多得多。想要少遇到这些“坑”，首先要用正确的姿势打开“自动化”。
　　自动化常常是测试团队首先想要做的技术建设，因为自动化的好处是明显的：
　　这个工作输出的成果—--工具、脚本框架、自动化用例都是可以长期重复使用的，是“实在”的、“可见”的成果。
　　自动化在质量守护和问题快速反馈上起了决定性的作用：大部分需要长期更新维护的软件，都需要自动化能力帮助防止质量劣化、支持重构。
　　自动化几乎是测试活动的终极形式：当某一类测试内容已经被研究透彻，形成了一定的规律和模式，那就可以进一步实现自动化测试。因而自动化也是团队技术进步的标志之一。
　　和测试设计一样，研发团队开始引入自动化测试的契机，常见的是两种：
　　1、出问题了。比如测试周期太长，或者产品频频出现升级后老特性出错。这时研发团队通常会要求实现自动化测试。
　　2、有人有时间了。在项目间歇期，或者某个项目计划不那么紧迫的时间段，测试团队自发的想要进行技术能力建设。
　　如果是出于第一种原因做自动化测试，方法不对，很容易“事与愿违”。比如测试周期（或者说是测试效率），研发主管们的逻辑是，如果测试执行的事情机器做了，那么人应该空出来了，或者相同的人可以做其他更多的事情了，那样就可以“减员增效”。
　　而测试经理们真正做的时候就会发现，做自动化很难做到解放人力的地步，即使做到了，那也需要走非常长的路，很可能需要3年以上的时间，经历过：
　　工具和架构成型生产自动化用例使之达到必要的覆盖自动化与用例产生的足够快开发者也能轻易使用开发者测试达到较高覆盖遗留到专业测试团队的缺陷减少需要的测试工作减少减员增效。
　　在这个过程中的大部分时候，测试团队甚至需要更多的人。症结在哪里呢？现在的测试技术和工具还很难做到“新特性开发就绪的时候，自动化用例也就绪”，即使在使用MBT的团队中，也只有部分场景能做到。大部分时候，由于接口和处理顺序都是在最后关头才确定的，自动化来不及适配。
　　又比如保证老特性质量，研发主管们的逻辑是，既然自动化主要是覆盖老特性，那么已经实现自动化的老特性，在“未来”的应用中就应该不再有问题。但是现实是：老革命总是遇到新问题。也许是和新特性组合起来会有问题，也许是修改了某个数据会影响到新特性，也许是用户的使用方式比较特别升级后受到了影响，也许是某个参数有了新的可能取值。这些都不是仅仅依靠覆盖老特性可以发现的。
　　如果是出于第二种原因做自动化测试，是不是就不用和研发主管沟通工作目标了呢？并不是，测试需要和研发主管们就工作价值达成一致，是因为实现自动化测试需要获得研发各个角色的支持，比如：
　　1、需求工程师的支持，可以确保需求的变动第一时间通知到测试；
　　2、系统工程师的支持，可以帮助测试工程师明确哪些新、老特性是需要组合使用的；
　　3、开发主管的支持，可以确保对开发环节的规范性要求能落实。
　　因此，无论出于什么原因，在启动自动化测试建设的时候，就需要明确对于研发整体或测试环节而言，自动化将在成本、效率或质量上发挥什么作用，自动化测试的目标绝不应该是“自动化率”。
　　自动化价值挖掘
　　测试自动化成功开展工作的要素中，技术是最根本的，如果根本没有完成工作所需的技术手段，或者当前的技术手段应用成本太高、不可靠，那么一切都是空谈，这里先假设技术不是问题。
　　大部分的研发经理心中，进度是第一位的，其次是成本，最后是质量，当然人员队伍最好稳定。天下武功，唯快不破：进度>成本>质量>人。

　　大部分时候测试想做的事情是关乎质量的，有时候做些工具什么的可能可以节约成本，或者可以从繁琐的操作中抽身出来以便做些需要脑子的工作，而通常测试项目不会对进度太有利。前面已经提到，自动化测试要支持研发全面提速，有一个漫长的过程，绝不是一蹴而就的。
　　那么，研发经理不关注质量吗？应该不是，研发经理对质量的要求是有“底线的”：作为卖点的新特性，或者作为最基本能力的老特性不能正常使用；客户蒙受损失（比如数据丢失）或退出服务的投诉较多；服务质量、性能明显下降……。
　　针对基本应用场景的自动化，目的就是防止底线失守。这是自动化的价值之一，不过，通常这类问题只在新产品中常见。
　　最后，我们是否将研发经理和测试经理的观点看的太对立了？质量和进度有没有可能统一？测试能否让整个研发进程又快又高质量？让上线过程又快又可控？让客户反馈又快又准确……
　　听上去有点乌托邦，但是确实有自动化的相关概念就是为了达到这个目的的，耳熟能详的比如CI、ATDD等。
　　在业界，也不乏帮助自动化服务于研发流程的案例，比如开发快速的构造测试用例；或者能够让使研发过程变成代码提交后，全自动化验证；或者可以用于产品上线后是否“健康”的在线自动检测。
　　从零开始的自动化，这些价值看上去像是空中楼阁。但如果自动化建设伊始，就只从测试的视角看问题，那么，最终实现的自动化方案也就只有测试环节、具备测试技能的人能用。
　　仅仅为了测试覆盖而实现的自动化，与为了上述目的实现的自动化，二者在方法、工具、实现难度上差别非常大：也许是写一个用例要配置很多信息，或者是对环境有诸多要求，或者是选择的接口层次不合适，或者是工具过于厚重不便携带，或者是模拟的方法仿真度不高。
　　所以无论起点在哪里，目标都是最重要的。当然，目标还是要一步一步的实现的，首先做个测试能用的，这也是不错的选择。
　　自动化的策略选择
　　自动化的价值就是自动化实施的目标，目标确定以后，就要确定自动化的策略，简单的说就是“根据产品、项目、客户的特点，确定自动化的范围、优先级，及其实现和使用的时机。”
　　说到自动化范围，通常的反应会是确定哪些特性，或者哪些测试类型（功能、性能、安全）实现自动化。但是可自动化的范围其实比这个广，如环境准备、错误检测、测试条件和数据准备、测试执行数据采集和分析、缺陷定位信息整合、代码检查和提交等，也都可能实现自动化。即使是功能测试的自动化，也不是只有按特性这一个维度，还可以按“层次”（例如单元、集成、系统等）或者“接口”（例如消息、RPC、UI等）确定自动化范围。
　　和其他任何的策略一样，自动化的策略首先取决于目标。例如，如果你的目标是防止产品上线后，系统的基本功能出错。那么策略选择上就应该是：建立所有基本功能的应用场景基线，并尽可能实现这些场景100%自动化测试；至少在产品发布前实现这些自动化用例；在每次启动测试、产品发布之前都将这些自动化用例全部测试一遍。
　　其次，自动化策略也是各种因素权衡的结果。自动化的范围肯定是覆盖越广越好，但同时，范围也受工作量、开发的规范程度、自动化工具和技术成熟度、质量问题的分布等因素影响。
　　自动化实现的时机，通常是越早实现价值越大，在新代码编写的同时就实现的自动化，可以作为代码质量门槛使用，在开发的早期拦截更多缺陷。但同时，早期实现的自动化会面临由于接口变更、业务流程变更等因素导致的自动化用例不可用，或者自动化实现工作量被成倍放大的风险。
　　自动化用例执行的时机，通常是越早越好、越多越好，因为原则上研发的任何一个环节都可能引入缺陷。但是，你该不会真的以为自动化只是消耗一点计算资源，不需要任何人工的参与吧？
　　自动化具体的策略选择和方案设计，恐怕需要一本书来写，这里只抛个砖，留待大家自己探索了。

　　总之，自动化，首先不是一个技术问题，从选择工具开始并不是它的正确打开方式。你首先要明确自动化的目标，比如针对目前严重的问题改善质量；帮助实现高质量、快速的软件研发；帮助产品上线后尽快、安全、稳定的运行……。然后才是制定策略、确定方案、选择工具。