实现自动化测试，首先不是一个技术问题
背景介绍
自动化常常是测试团队首先想要建设的内容，因为自动化的好处是明显的，但真正实现自动化测试的时候才发现，这条路上的“坑”比想象的多得多。想要少遇到这些“坑”，首先要用正确的姿势打开“自动化”。
自动化常常是测试团队首先想要做的技术建设，因为自动化的好处是明显的：
这个工作输出的成果—--工具、脚本框架、自动化用例都是可以长期重复使用的，是“实在”的、“可见”的成果。
自动化在质量守护和问题快速反馈上起了决定性的作用：大部分需要长期更新维护的软件，都需要自动化能力帮助防止质量劣化、支持重构。
自动化几乎是测试活动的终极形式：当某一类测试内容已经被研究透彻，形成了一定的规律和模式，那就可以进一步实现自动化测试。因而自动化也是团队技术进步的标志之一。
和测试设计一样，研发团队开始引入自动化测试的契机，常见的是两种：
1、出问题了。比如测试周期太长，或者产品频频出现升级后老特性出错。这时研发团队通常会要求实现自动化测试。
2、有人有时间了。在项目间歇期，或者某个项目计划不那么紧迫的时间段，测试团队自发的想要进行技术能力建设。
如果是出于第一种原因做自动化测试，方法不对，很容易“事与愿违”。比如测试周期（或者说是测试效率），研发主管们的逻辑是，如果测试执行的事情机器做了，那么人应该空出来了，或者相同的人可以做其他更多的事情了，那样就可以“减员增效”。
而测试经理们真正做的时候就会发现，做自动化很难做到解放人力的地步，即使做到了，那也需要走非常长的路，很可能需要3年以上的时间，经历过：
工具和架构成型生产自动化用例使之达到必要的覆盖
自动化与用例产生的足够快开发者也能轻易使用
开发者测试达到较高覆盖
遗留到专业测试团队的缺陷减少
需要的测试工作减少
减员增效。
在这个过程中的大部分时候，测试团队甚至需要更多的人。症结在哪里呢？现在的测试技术和工具还很难做到“新特性开发就绪的时候，自动化用例也就绪”，即使在使用MBT的团队中，也只有部分场景能做到。大部分时候，由于接口和处理顺序都是在最后关头才确定的，自动化来不及适配。
又比如保证老特性质量，研发主管们的逻辑是，既然自动化主要是覆盖老特性，那么已经实现自动化的老特性，在“未来”的应用中就应该不再有问题。但是现实是：老革命总是遇到新问题。也许是和新特性组合起来会有问题，也许是修改了某个数据会影响到新特性，也许是用户的使用方式比较特别升级后受到了影响，也许是某个参数有了新的可能取值。这些都不是仅仅依靠覆盖老特性可以发现的。
如果是出于第二种原因做自动化测试，是不是就不用和研发主管沟通工作目标了呢？并不是，测试需要和研发主管们就工作价值达成一致，是因为实现自动化测试需要获得研发各个角色的支持，比如：
1、需求工程师的支持，可以确保需求的变动第一时间通知到测试；
2、系统工程师的支持，可以帮助测试工程师明确哪些新、老特性是需要组合使用的；
3、开发主管的支持，可以确保对开发环节的规范性要求能落实。
因此，无论出于什么原因，在启动自动化测试建设的时候，就需要明确对于研发整体或测试环节而言，自动化将在成本、效率或质量上发挥什么作用，自动化测试的目标绝不应该是“自动化率”。
自动化价值挖掘
测试自动化成功开展工作的要素中，技术是最根本的，如果根本没有完成工作所需的技术手段，或者当前的技术手段应用成本太高、不可靠，那么一切都是空谈，这里先假设技术不是问题。
大部分的研发经理心中，进度是第一位的，其次是成本，最后是质量，当然人员队伍最好稳定。天下武功，唯快不破：进度 > 成本 > 质量 > 人。
大部分时候测试想做的事情是关乎质量的，有时候做些工具什么的可能可以节约成本，或者可以从繁琐的操作中抽身出来以便做些需要脑子的工作，而通常测试项目不会对进度太有利。前面已经提到，自动化测试要支持研发全面提速，有一个漫长的过程，绝不是一蹴而就的。
那么，研发经理不关注质量吗？应该不是，研发经理对质量的要求是有“底线的”：作为卖点的新特性，或者作为最基本能力的老特性不能正常使用；客户蒙受损失（比如数据丢失）或退出服务的投诉较多；服务质量、性能明显下降……。
针对基本应用场景的自动化，目的就是防止底线失守。这是自动化的价值之一，不过，通常这类问题只在新产品中常见。
最后，我们是否将研发经理和测试经理的观点看的太对立了？质量和进度有没有可能统一？测试能否让整个研发进程又快又高质量？让上线过程又快又可控？让客户反馈又快又准确……
听上去有点乌托邦，但是确实有自动化的相关概念就是为了达到这个目的的，耳熟能详的比如CI、ATDD等。
在业界，也不乏帮助自动化服务于研发流程的案例，比如开发快速的构造测试用例；或者能够让使研发过程变成代码提交后，全自动化验证；或者可以用于产品上线后是否“健康”的在线自动检测。
从零开始的自动化，这些价值看上去像是空中楼阁。但如果自动化建设伊始，就只从测试的视角看问题，那么，最终实现的自动化方案也就只有测试环节、具备测试技能的人能用。
仅仅为了测试覆盖而实现的自动化，与为了上述目的实现的自动化，二者在方法、工具、实现难度上差别非常大：也许是写一个用例要配置很多信息，或者是对环境有诸多要求，或者是选择的接口层次不合适，或者是工具过于厚重不便携带，或者是模拟的方法仿真度不高。
所以无论起点在哪里，目标都是最重要的。当然，目标还是要一步一步的实现的，首先做个测试能用的，这也是不错的选择。
自动化的策略选择
自动化的价值就是自动化实施的目标，目标确定以后，就要确定自动化的策略，简单的说就是“根据产品、项目、客户的特点，确定自动化的范围、优先级，及其实现和使用的时机。”
说到自动化范围，通常的反应会是确定哪些特性，或者哪些测试类型（功能、性能、安全）实现自动化。但是可自动化的范围其实比这个广，如环境准备、错误检测、测试条件和数据准备、测试执行数据采集和分析、缺陷定位信息整合、代码检查和提交等，也都可能实现自动化。即使是功能测试的自动化，也不是只有按特性这一个维度，还可以按“层次”（例如单元、集成、系统等）或者“接口”（例如消息、RPC、UI等）确定自动化范围。
和其他任何的策略一样，自动化的策略首先取决于目标。例如，如果你的目标是防止产品上线后，系统的基本功能出错。那么策略选择上就应该是：建立所有基本功能的应用场景基线，并尽可能实现这些场景100%自动化测试；至少在产品发布前实现这些自动化用例；在每次启动测试、产品发布之前都将这些自动化用例全部测试一遍。
其次，自动化策略也是各种因素权衡的结果。自动化的范围肯定是覆盖越广越好，但同时，范围也受工作量、开发的规范程度、自动化工具和技术成熟度、质量问题的分布等因素影响。
自动化实现的时机，通常是越早实现价值越大，在新代码编写的同时就实现的自动化，可以作为代码质量门槛使用，在开发的早期拦截更多缺陷。但同时，早期实现的自动化会面临由于接口变更、业务流程变更等因素导致的自动化用例不可用，或者自动化实现工作量被成倍放大的风险。
自动化用例执行的时机，通常是越早越好、越多越好，因为原则上研发的任何一个环节都可能引入缺陷。但是，你该不会真的以为自动化只是消耗一点计算资源，不需要任何人工的参与吧？
自动化具体的策略选择和方案设计，恐怕需要一本书来写，这里只抛个砖，留待大家自己探索了。
总之，自动化，首先不是一个技术问题，从选择工具开始并不是它的正确打开方式。你首先要明确自动化的目标，比如针对目前严重的问题改善质量；帮助实现高质量、快速的软件研发；帮助产品上线后尽快、安全、稳定的运行……。然后才是制定策略、确定方案、选择工具。
杨晓慧老师在近期也发表了《软件测试价值提升之路》一书中，其中对新、老特性自动化能产生的价值、可采取的策略，以及实施中需要完成的工作、需要注意的问题做了更进一步的讨论，同学们也可以参考。
杨晓慧，前华为技术有限公司-软件公司首席测试专家，1999年进入华为公司，先后参与和主持过多项产品测试、测试流程改造、测试工程师职责定义等工作。工作覆盖测试策略、测试设计、测试评估和过程管理等软件测试工程的各个方面，在自动化、可靠性验证、可服务性验证、可测试性设计等领域上都有丰富的经验。2007年以后主管软件公司的测试技术架构设计、实现、应用，通过帮助产品持续积累和提升测试技术能力，实现研发的效率和质量提升。
实现自动化测试，首先不是一个技术问题相关推荐
- 一个技术总监的忠告：精通那么多技术，你为何还是受不到重用？
这篇文章我们继续说架构师大刘的故事: 老田升职了,年薪涨到了百万级别!这时大刘在加班搞技术攻坚的时候,听别的同事聊了那么一嘴.大刘心里不是滋味儿.老田和大刘其实在这家公司之前就是同事了,老田能到这家公 ...
- 一个技术总监的忠告：精通那么多技术有毛用啊，你还不是不被重用？
这篇文章我们继续说架构师大刘的故事: 老田升职了,年薪涨到了百万级别! 这是大刘在加班搞技术攻坚的时候,听别的同事聊了那么一嘴. 大刘心里不是滋味儿.老田和大刘其实在这家公司之前就是同事了,老田能到这 ...
- 《快速搞垮一个技术团队的20个“必杀技”》
来源| 技术领导力(ID:jishulingdaoli) 前几天老K组局,约了几位沪上互联网公司技术大佬,共同研讨一个话题:如何快速搞垮一个技术团队?你没看错,这是一直困扰我的问题. 聊下来发现,这个 ...
- SAP PM 初级系列21 - 一个技术关闭的维修工单不能再被修改了！
SAP PM 初级系列21 - 一个技术关闭的维修工单不能再被修改了! 维修工单号:102333362已经被Techical completion了, 试图执行IW32去修改它, 系统提示说:Noti ...
- 沈向阳：微软每一个技术研发都会进行AI伦理道德评审
2019-10-20 13:47:43 第六届世界互联网大会在乌镇开幕,微软全球执行副总裁沈向洋出席大会并发表演讲. 他提到,微软一直努力打造负责任的人工智能,今天,微软的每一个技术产品.每一项服务的 ...
- 如何搞垮一个技术大牛？
作者| Mr.K 来源| 技术领导力(ID:jishulingdaoli) IT界有个说法:杀死一个技术大牛,不用枪,只需要改三次需求.技术大牛的死法,就是那样朴实无华且枯燥. 俗话说得好,搞垮一个技 ...
- java webservice报文过长_工作1-5年的Java程序猿到底需要怎样的一个技术栈？
工作1-5年的Java程序猿到底需要怎样的一个技术栈? 前言: 具有1-5年开发经验的程序员 需要学习的内容其实还有很多很多. 今天跟大家交流一下希望分享出来的对大家能够有帮助,这是我这些年总结出的一 ...
- 对linux做一个简单介绍,对“Fork”做一个技术方面的简介
使用过 GitHub 的人大多知道它上面有个"Fork"的功能,用来将某个仓库克隆到你的账户之下,从而可以对其进行修改.衍生,也可以比较方便的将你的修改推回到原来的仓库(所谓的上游 ...
- python脚本语言采用声音作为手段_LKJ自动化测试脚本定义及生成技术研究
LKJ 自动化测试脚本定义及生成技术研究 白鸿钧,张明凯,李冠军,杨清祥 [摘 要] 摘要:为实现对列车运行控制系统软件的自动化测试,在通用脚本语 言的基础上定义专用的脚本语言,讨论专用脚本语言的结构 ...
- 如何成为一个技术“牛人”
今天给浙江大学过来的几个还没有毕业的研究生做面试,这些研究生是想来公司实习的.在面试的过程中,一个学生问我"我们有C/C++.JAVA等等多种语言,我如何才能成为某一方面的一个技术牛人呢?这 ...
最新文章
- Rocksdb Iterator实现：从DBIter 到 TwoLevelIter 的漫长链路
- shell %% , ##,#,% 用法
- mysql datetime 默认值_老大让我整理下公司内部MySQL使用规范，分享给大家
- 四川网络推广介绍什么样的网站架构更能吸引蜘蛛爬行抓取？
- iOS—OC——C——野指针
- 如何成为出色的项目经理：成功的五个关键因素
- 试解析Tomcat运行原理（一）--- socket通讯(转)
- 交叉编译及树莓派（或其他平台）交叉编译工具链的安装
- 循环彩灯实验c语言程序,实验3LED指示灯循环控制.doc
- 当众讲话第二章当众讲话的基本原则
- 用linux上网有什么优点,Linux系统的介绍，有什么优点，怎么使用
- velocity map list 数组操作
- [NLP]OpenNLP块检测器(Chunker)的使用
- 极域电子教室忘记密码或无法卸载怎么办
- mysql 左连接与右连接的区别吗_数据库左连接和右连接有什么区别
- w10计算机用户名密码忘了,电脑w10系统开机密码忘了
- 技嘉1080显卡体质测试软件,技嘉AORUS GTX 1080 Gaming Box
- Unity基础学习——光照系统
- 修真院教学模式四大体系之开发流程
- 软考是什么？-最全软考详解