实现自动化测试，首先不是一个技术问题
自动化测试常常是研发团队首先想要建设的内容，因为自动化测试的好处是明显的，但真正实施自动化测试之时才发现，这条路上的“坑”比想象的要多得多。想要少遇到这些“坑”，首先要用正确的姿势打开“自动化”。
自动化常常是测试团队首先想要做的技术建设，因为自动化的好处是明显的：
这个工作输出的成果—--工具、脚本框架、自动化用例都是可以长期重复使用的，是“实在”的、“可见”的成果。
自动化在质量守护和问题快速反馈上起了决定性的作用：大部分需要长期更新维护的软件，都需要自动化能力帮助防止质量劣化、支持重构。
自动化几乎是测试活动的终极形式：当某一类测试内容已经被研究透彻，形成了一定的规律和模式，那就可以进一步实现自动化测试。因而自动化也是团队技术进步的标志之一。
和测试设计一样，研发团队开始引入自动化测试的契机，常见的是两种：
出问题了。比如测试周期太长，或者产品频频出现升级后老特性出错。这时研发团队通常会要求实现自动化测试。
有人有时间了。在项目间歇期，或者某个项目计划不那么紧迫的时间段，测试团队自发的想要进行技术能力建设。
如果是出于第一种原因做自动化测试，方法不对，很容易“事与愿违”。
比如测试周期（或者说是测试效率），研发主管们的逻辑是，如果测试执行的事情机器做了，那么人应该空出来了，或者相同的人可以做其他更多的事情了，那样就可以“减员增效”。
而测试经理们真正做的时候就会发现，做自动化很难做到解放人力的地步，即使做到了，那也需要走非常长的路，很可能需要3年以上的时间，经历过：
工具和架构成型à生产自动化用例使之达到必要的覆盖à自动化与用例产生的足够快开发者也能轻易使用à开发者测试达到较高覆盖à遗留到专业测试团队的缺陷减少à需要的测试工作减少à减员增效。
在这个过程中的大部分时候，测试团队甚至需要更多的人。症结在哪里呢？现在的测试技术和工具还很难做到“新特性开发就绪的时候，自动化用例也就绪”，即使在使用MBT的团队中，也只有部分场景能做到。大部分时候，由于接口和处理顺序都是在最后关头才确定的，自动化来不及适配。
又比如保证老特性质量，研发主管们的逻辑是，既然自动化主要是覆盖老特性，那么已经实现自动化的老特性，在“未来”的应用中就应该不再有问题。但是现实是：老革命总是遇到新问题。也许是和新特性组合起来会有问题，也许是修改了某个数据会影响到新特性，也许是用户的使用方式比较特别升级后受到了影响，也许是某个参数有了新的可能取值。这些都不是仅仅依靠覆盖老特性可以发现的。
如果是出于第二种原因做自动化测试，是不是就不用和研发主管沟通工作目标了呢？并不是，测试需要和研发主管们就工作价值达成一致，是因为实现自动化测试需要获得研发各个角色的支持，比如：
需求工程师的支持，可以确保需求的变动第一时间通知到测试；
系统工程师的支持，可以帮助测试工程师明确哪些新、老特性是需要组合使用的；
开发主管的支持，可以确保对开发环节的规范性要求能落实。
因此，无论出于什么原因，在启动自动化测试建设的时候，就需要明确对于研发整体或测试环节而言，自动化将在成本、效率或质量上发挥什么作用，自动化测试的目标绝不应该是“自动化率”。
自动化价值发掘
测试自动化成功开展工作的要素中，技术是最根本的，如果根本没有完成工作所需的技术手段，或者当前的技术手段应用成本太高、不可靠，那么一切都是空谈，这里先假设技术不是问题。
大部分的研发经理心中，进度是第一位的，其次是成本，最后是质量，当然人员队伍最好稳定。天下武功，唯快不破：进度 > 成本 > 质量 > 人。
大部分时候测试想做的事情是关乎质量的，有时候做些工具什么的可能可以节约成本，或者可以从繁琐的操作中抽身出来以便做些需要脑子的工作，而通常测试项目不会对进度太有利。
前面已经提到，自动化测试要支持研发全面提速，有一个漫长的过程，绝不是一蹴而就的。
那么，研发经理不关注质量吗？应该不是，研发经理对质量的要求是有“底线的”：作为卖点的新特性，或者作为最基本能力的老特性不能正常使用；客户蒙受损失（比如数据丢失）或退出服务的投诉较多；服务质量、性能明显下降……。
针对基本应用场景的自动化，目的就是防止底线失守。这是自动化的价值之一，不过，通常这类问题只在新产品中常见。
最后，我们是否将研发经理和测试经理的观点看的太对立了？质量和进度有没有可能统一？测试能否让整个研发进程又快又高质量？让上线过程又快又可控？让客户反馈又快又准确……
听上去有点乌托邦，但是确实有自动化的相关概念就是为了达到这个目的的，耳熟能详的比如CI、ATDD等。
在业界，也不乏帮助自动化服务于研发流程的案例，比如开发快速的构造测试用例；或者能够让使研发过程变成代码提交后，全自动化验证；或者可以用于产品上线后是否“健康”的在线自动检测。
从零开始的自动化，这些价值看上去像是空中楼阁。但如果自动化建设伊始，就只从测试的视角看问题，那么，最终实现的自动化方案也就只有测试环节、具备测试技能的人能用。
仅仅为了测试覆盖而实现的自动化，与为了上述目的实现的自动化，二者在方法、工具、实现难度上差别非常大：也许是写一个用例要配置很多信息，或者是对环境有诸多要求，或者是选择的接口层次不合适，或者是工具过于厚重不便携带，或者是模拟的方法仿真度不高。
所以无论起点在哪里，目标都是最重要的。当然，目标还是要一步一步的实现的，首先做个测试能用的，这也是不错的选择。
自动化的策略选择
自动化的价值就是自动化实施的目标，目标确定以后，就要确定自动化的策略，简单的说就是“根据产品、项目、客户的特点，确定自动化的范围、优先级，及其实现和使用的时机。”
说到自动化范围，通常的反应会是确定哪些特性，或者哪些测试类型（功能、性能、安全）实现自动化。但是可自动化的范围其实比这个广，如环境准备、错误检测、测试条件和数据准备、测试执行数据采集和分析、缺陷定位信息整合、代码检查和提交等，也都可能实现自动化。即使是功能测试的自动化，也不是只有按特性这一个维度，还可以按“层次”（例如单元、集成、系统等）或者“接口”（例如消息、RPC、UI等）确定自动化范围。
和其他任何的策略一样，自动化的策略首先取决于目标。
例如，如果你的目标是防止产品上线后，系统的基本功能出错。那么策略选择上就应该是：建立所有基本功能的应用场景基线，并尽可能实现这些场景100%自动化测试；至少在产品发布前实现这些自动化用例；在每次启动测试、产品发布之前都将这些自动化用例全部测试一遍。
其次，自动化策略也是各种因素权衡的结果。
自动化的范围肯定是覆盖越广越好，但同时，范围也受工作量、开发的规范程度、自动化工具和技术成熟度、质量问题的分布等因素影响。
自动化实现的时机，通常是越早实现价值越大，在新代码编写的同时就实现的自动化，可以作为代码质量门槛使用，在开发的早期拦截更多缺陷。但同时，早期实现的自动化会面临由于接口变更、业务流程变更等因素导致的自动化用例不可用，或者自动化实现工作量被成倍放大的风险。
自动化用例执行的时机，通常是越早越好、越多越好，因为原则上研发的任何一个环节都可能引入缺陷。但是，你该不会真的以为自动化只是消耗一点计算资源，不需要任何人工的参与吧？
自动化具体的策略选择和方案设计，恐怕需要一本书来写，这里只抛个砖，留待大家自己探索了。
总之，自动化，首先不是一个技术问题，从选择工具开始并不是它的正确打开方式。你首先要明确自动化的目标，比如针对目前严重的问题改善质量；帮助实现高质量、快速的软件研发；帮助产品上线后尽快、安全、稳定的运行……。然后才是制定策略、确定方案、选择工具。
《软件测试价值提升之路》一书中，对于对新、老特性自动化能产生的价值、可采取的策略，以及实施中需要完成的工作、需要注意的问题做了更进一步的讨论，同学们也可以参考：
作者简介：杨晓慧 《软件测试价值提升之路》作者，前华为技术有限公司-软件公司首席测试专家。1999年进入华为公司，先后主持过产品测试、测试流程改造、测试工程师职业发展等工作。2007年以后主管软件公司的测试技术架构设计、实现、应用，通过帮助产品持续积累和提升测试技术能力，实现研发的效率和质量提升。