摘要
本文主要围绕自动化测试对敏捷开发的意义进行分析，对比自动化测试在传统瀑布项目和敏捷开发项目中的不同点，展开解析自动化测试在敏捷项目中的应用的各大要素，最后延伸到DevOps中的测试自动化，探讨在不同情况下这些因素对项目的影响和意义，以期正确合理的在采用敏捷模式的项目中组织规划自动化测试。
1、背景Background
前段时间在一次项目评审会议上，公司的一群大佬们（博士级别的高管、首席架构师，摩拜ing）进行了一些有意思的讨论，针对几个项目自动化测试到底能带来什么样的价值，是否值得做。
省钱？未必！
省时？未必！
那为啥要做自动化？
按理好像一目了然的答案却没有当场得出结论。什么样的自动化才是我们想要的？
本文对自动化测试在现在大多采用敏捷开发模式的项目中的应用进行分步解析。提出理念和观点，期望留给大家针对自身项目特点的思考，引出进一步的问题和结论。
迷惑
场景一：
你是一个10个人的中型自动化测试组的leader，为了赶在项目开发中把自动化测试实时用起来，半年来带着团队熬更守夜的写了大量的自动化测试代码。这时架构师发现产品升级后原来采用的自动化框架存在一些关键的技术性缺陷，导致自动化脚本意外错误率很高，需要全面升级框架。但升级会导致原有脚本几乎不能复用，重构的成本跟新写差不多。整个团队陷入了空前的沮丧气氛中。
场景二：
你管理着几个主要采用手工测试的项目，希望引入自动化测试，但对于具体什么地方用怎么用考虑的不是很清晰。不过既然大家都在用，不会是什么坏事吧，那就安排下去各个项目开始实行。人力物力投入了，但不清晰的定位和计划安排，自动化测试逐渐在产品开发流程中变成鸡肋，让大家愈发对其实用性产生了质疑。
场景三：
你是一个产品研发项目的项目经理，正在项目中实施自动化测试，以期在多迭代中减少测试的effort。高级管理层非常支持这项安排，特意多投入了一位架构师帮助搭建自动化测试框架，你也安排了相应的人员进行自动化脚本的开发。但产品开发过程中由于需求的变更、一些初期未评估到的技术难点导致工期一再延误，作为PM需要最优先考虑产品上线时间。在自动化测试覆盖率不够同时尚未进行到CI阶段的情况下，你已经在犹豫是否要推迟甚至暂停自动化测试的实施。已经投入的人力物力是另一个如何向高级管理层汇报交代的问题。
从事自动化测试的你，是否觉得这样的场景似曾相识？
2、自动化测试对项目的常规意义
你为什么做自动化测试？
The direction is always more important than the speed!
仔细回溯思考下，你的项目为什么要做自动化测试？而你的目的会决定自动化测试规划和实施的不同走向。
罗列一些实施自动化测试的意义，这些基本是业界的共识。
· 省时
· 省力
· 极大的提升测试覆盖率
例如多设备、多配置、多系统、多数据指标采集。
· 增加测试频度，第一时间发现潜在缺陷
例如同样的工作量，手工做一周一轮，自动化一天几轮。
· 增加测试精确度
精确到秒、毫秒、像素级别的测试结果的可能性。
· 实施手工不能/极难实现的测试内容
例如监测达万级十万级用户系统的性能，模拟多用户并发操作，更快捷的进行数据准备。
· 替代手工测试
实时测试报告推送，减少沟通环节，缩短沟通周期
……
上述认知相关但不是本文的重点，故不再详述仅供回顾。
值得注意的是，在为探寻自动化测试的目的采访不同公司的软件项目时，除了上述答案外，有意思的是还有不少是归入了“不知道”、“别人做我们也试下。应该有效果吧”、 “老板让做做看”、“除了日常工作外，想给老板/客户特别展示下其他的成果”……
危险的信号已经亮起！你都不知道为啥要做自动化，或者为了自动化而自动化，如何能够有针对性进行后续的规划和监控？
自动化测试的投资回报率ROI (Return On Investment)
谈到自动化测试项目的初衷和决策，很多时候都会引到ROI的话题上。本文不做详述，对此感兴趣的可以参看笔者在51testing的分析《自动化测试投资回报率模型及其应用》或其他相关文章。
3、自动化测试对敏捷开发的意义及应用
3.1、敏捷项目vs传统瀑布项目的最大不同
现在100个软件公司的开发模式恐怕有90个都采用敏捷，一张图简洁说明：
快速交付，分拆交付，快速迭代，拥抱变化！
图3.1 迭代故事点示意图
可当看到上述不断增长的已完成story point时，谁敢拍胸脯说以前的功能百分比不出问题？谁又去承担这快节奏的回归测试的压力？
此时，自动化测试就成为重要的备选解决方案之一。
3.2、自动化测试对于敏捷项目的必要性
持续交付的需求
流线化测试流程使其更快以适应敏捷
如下图，代码的持续集成是基础，而自动化测试则是保障持续交付的重要步骤。
以装修铺地板砖为例，房间那么大肯定不是用一块整砖铺上去，每个房间面积不同工厂也不可能批量生产定制化的地砖，所以采用一块块的地砖（story）铺上去。这就是持续集成。铺的过程中还可能根据情况进行切割（变化）。为了检验是否铺的合格，工人不是铺完后再进行检测，一般每铺完一块就通过各种工具进行（测试），如果有问题（缺陷）就及时调整（fix defect）。这就形成了持续交付。当铺完最后一块地砖，这个工程步骤也随之宣告结束。
在测试环境部署完成进行测试时，敏捷项目对时间的苛求，快速测试、快速报告（例如自动化测试结果自动push到用例管理工具中）、持续部署对结果自动化的要求，都意味着离开统一的工具和自动化无法达成。
3.3、在敏捷环境中执行自动化测试的挑战及对策
不仅仅是敏捷开发的方法学引入到软件开发中，QA在项目中的角色也随之改变。既然是敏捷，那么不再是一群QA坐在角落里，等着开发团队交付功能进行测试。敏捷项目的自动化QA不仅要熟识传统自动化测试项目的知识，更要对敏捷开发方法学和流程有很好的了解。知晓敏捷测试的挑战，有助于自动化测试人员有针对性的制订措施予以克服或缓解。下面进列出一些主要的挑战及其对策。
3.3.1、不断/最后一分钟仍在改变的需求
敏捷项目中需求变更是一个永恒的话题。当sprint进行一半时需求的改变甚至被砍掉，是整个团队包括开发和测试团队的梦魇，而不断重复则会完全摧毁整个项目的成功交付。其实在《项目管理知识体系指南(PMBOK?指南)》中对此已经有了教科书模板式的方向指导，作为项目经理整体把控，建立变更控制的流程，通过相应的方法和工具来管理监控变更。
具体到自动化测试项目中，通常可采用下面的办法很好的管理变更。
1)把控backlog/test case（测试用例）完整度
所谓backlog完整度，是指供自动化的测试用例细节不明确、后续各种变化多等情况。
很多时候这项被忽略，往往拿到用例就开工，当自动化测试在敏捷项目中失败时回过头做教训总结时，很意外归结到此项的比例特别的高。
在开始编码前增加业务梳理的环节，最好由专人负责，确保自动化测试人员开始编码/学习业务的时候拿到的是相对完整的场景用例。
需要注意大多自动化测试的backlog来自于手工的测试用例，但供手工测试的用例有时一些描述是比较模糊的，在自动化前需要予以明确清晰的定义。
粗陋的backlog，退回或延迟自动化！！
2)自动化开发过程中严控变化
一旦BA业务梳理结束开发启动，这时需要尽量的控制变化，尽快的根据当前版本的backlog完成脚本的开发。如果发生变化，交由维护阶段进行。
笔者经历的一个加拿大的自动化测试项目，提供了生鲜的反面示例：
十个人的自动化测试团队，不小的规模，新的客户总监到来后，认为自动化脚本要实时适应产品变化，要求自动化脚本的开发环境要基于当前的集成环境，以适配最新的变化，同时交付的标准为连续3天在最新的环境中执行结果通过。
理想很完美，现实很残酷。
原本1人天完成1个脚本的产量，在新的流程中3个月10人团队的产量为：0！对的，一条脚本最后都没有成功交付！这是一个暂时失败的项目，在这3个月里面。留下的是自动化开发人员彻夜的加班和抱怨。
除了产品本身不稳定的问题，这个从上到下的决定，最大的弊端是忽略了敏捷项目不断甚至实时的变化会带来开发过程中不断的修改、代码重构，增加的海量调试时间，脚本交付过程中产品有变立刻打回去修改重新交付，如此循环。
3个月后客户方项目发起人更换，审视了当前项目的困难和危机，采纳了脚本开发维护分离的建议，项目经理得以将变更安排到维护阶段专人集中处理，产量瞬间逆转，也没有出现自动化执行维护阶段脚本长时间无法适配产品的情况。
这里说的严控变化，不能理解为说脚本开发过程中完全不能有变化，小的不影响进度的变化可以脚本开发人员酌情安排修改（需要上报lead/PM知晓），特别大的backlog的变化应停止脚本开发，退回BA重新进行业务梳理，而不是一味根据原有版本的用例完成。
3)保持相对唯一/独立的产品环境
唯一是指脚本开发过程中的产品环境版本不变。例如保持2周一升级。这样不仅有利于开发，还能保证交付的脚本验收是在同一个环境下；
独立是指开发基于的产品环境和产品实际集成环境彼此独立分离，互不影响。这样不仅保证功能的不变，还能避免不同数据带来的风险。
注意：持续交付讲究的是类产品(production-like)环境下进行交付，这里的方法与其不冲突。只是针对脚本开发阶段，脚本交付使用后仍然处于类产品环境下运行是最佳的。
4)选择适合项目情况的代码管理
多人协同开发环境下，代码管理就尤为重要。
下图举了一个基于Git的分支管理的简单示例，
Fork仓库的应用也有很多很好的实践。
5)主动管理变化，尽量使变化有计划的集中发生
除前述外，如果预期自动化基于的测试用例有频繁变化，可以采取分离/克隆用例库的方法，根据项目安排同步最新的用例。
关于分离/克隆用例库：自动化测试基于的测试用例不一定是最新的测试用例，可以分别置放于不同的位置（suite/folder/DB）,定期或者有计划的进行同步（利用测试用例管理工具的自动同步功能）。
6)采取方便后期维护的方式控制变更
不要hard coding (Step Reporting, Assertions, etc)，数据驱动，测试数据和脚本step分离，采用适用的数据管理方式以方便后期更改和维护，例如CSV/XML/JSON/TXT文件、枚举类class文件等等。
CSV
数据种类特别复杂庞大时，采用CSV是优选，但一旦数据量级达到一定级别（例如成千上万）后，数据变更后查找对应的数据并进行修改是个眼力活。
ENUM
可读性很高，方便维护修改，但不太适合数据种类很多的情况。
针对数据驱动的应用本身有很多关于利弊与方法的讨论，此处不详述，重点强调的是no hard coding并采用适合自己项目维护的方式。
7)（UI自动化）采用最佳实践进行元素定位
元素定位在自动化测试中是非常重要的部分，也是非常容易在软件开发过程中变化的部分，应尽可能的规避潜在变化。
定位方式优先级别（常规，有例外的情况）：
自定义的字段 (例如Automation ID) > CSS > X-path
如果ID和CSS能定位到，尽量避免使用X-path方式定位。
8)其他 (详见自动化测试最佳实践)
3.3.2、User Story（用户故事）中缺乏足够的细节信息
有时产品/项目经理建的story中只有一些关于new feature (新功能) 的大致描述缺乏细节行为动作和功能合格准则，然后要求开发根据这些概念进行原型开发。
解决方案：
与产品经理/负责人协作来完善story的细节和接收准则。
与自己任务息息相关的事情需要最大程度的参与。在中大型的自动化测试团队中，这项任务往往会分拆出专门的角色由BA进行。
确保所有相关干系人对于story的描述和接收准则清楚明了，在开发之前。
特别强调在开发之前，做正确的事情高于正确的做事。自动化测试大多很依赖开发完成的产品/功能，如果开发有问题，会导致测试不可信/采纳。
否则，拒绝自动化测试，进行high-level场景的手工测试。
自动化测试是非常精准的测试类型，用于替代手工测试和回归测试，目前的自动化测试手段大多做不到那么人工智能。
3.3.3、Continuous Testing持续测试
对于敏捷而言，测试不是一个阶段而是一项项目活动。因为周期短，开发/产品经理更期望尽早的得到对于功能完整度的反馈。而对于测试人员来说，关注点不仅仅是新开发功能的正确程度，也包括对不破坏既有功能的确认。
一些解决方案：
“盲写”自动化脚本
参考产品原型图、高保图或需求文档先行进行脚本开发，并优先进行page/API object的开发，然后再进行case层级的组装，不管是UI还是API的测试。笔者所处的项目也有工期特别紧张的时期，自动化测试脚本开发时往往产品功能未就位，就利用“盲写”进行快速跟进。“盲写”必然伴随着一些临时的hard code或者伪代码，这时添加comment （注释）就尤为重要，以提醒后期维护时进行替换。
“盲写”最后的校验环节比较重要，需要等功能完成后再进行校验调试，特别注意真实数据的替换、case步骤的最终顺序是否调整、clean-up、元素定位等等。
敏捷中测试与开发并行进行，越早看到接近最终交付成果的产品越有利于帮助测试人员理解和验证脚本的正确性。
可以鼓励开发尽早部署新功能给脚本开发人员作为参考。
o即便只是部分功能；
o查看开发个人分支(branch)的版本，不一定等待部署到集成的环境中。
3.3.4、选择适合的自动化工具
因为敏捷项目的变更非常多，传统录制回放类的自动化工具显然不适合，需要采用更为灵活的工具，这也是Selenium等UI自动化测试工具近几年大加流行的原因之一。
例如SoapUI，这是一个很好的轻量级的API测试工具，其Pro版也可以进行一些性能安全的测试。对于脚本开发人员的语言能力要求比较低，容易上手。所以比较流行。但对于很多功能稍复杂的软件而言，其API用例/方法难以复用，维护麻烦、缺乏数据驱动测试、在同一工程/用例上跨team协同工作困难等缺点凸显。中大型软件的敏捷项目因为这些缺点就会谨慎的选择此类型工具。
当然，考虑既有人员能力/复用的限制，也有不少公司采用开发+手工测试人员一同进行自动化测试脚本开发/维护的情况，得益于类似于Cucumber等工具的使用或在自动化框架中的集成。
3.4、自动化测试在敏捷项目中的应用
3.4.1、什么项目适合做
任何软件项目都可以采用自动化测试，本文的论述对象主要集中在软件功能较多的大中型软件项目上。某些通过开发轻量级小工具以达成自动化测试目的的项目不在本文论述范围内，其实施自动化的意义通常相对简单也已囊括在前述章节的范围中。
迭代周期短
现在很多大中型敏捷项目均以1~4周为1个迭代周期，更有很多前沿的领头羊已经进入以天甚至小时为单位的更新征途中。互联网时代行业的王者都是对市场变化最敏感的少数几家。
迭代周期越短，代码集成频率越高，出错几率越高。
良好的代码规范和最佳实践是预防措施，而自动化测试则是检验环节。迭代周期越短，越需要重点考虑自动化测试的应用。
对质量的敏感程度
根据软件的应用场景、对象等等，虽然有常规的代码规范作为基础保障，实际上每个软件项目对质量的要求还是有高低之分，有的甚至接近苛刻。
还记得二战降落伞制造的那个故事吗？
“二战初期，美军降落伞合格率为99.9%，每一千个就有一个出事，军方要求必须达到100%。于是军方改变了质检制度，从每批降落伞中随机挑出一个，首先让厂商负责人亲自从飞机上跳下。奇迹出现了，不合格率很快降为零。”
一般来说，很多军工项目的软件的质量标准就非常严格。
公司/软件类型
互联网、游戏等这种实际上大多都是拿用户做β测试的公司，遇到重大问题一般都需要在小时为单位的严格限制中进行解决。总不能慢慢的等着手工测试结果，或者不管不顾解决3个小问题冒出1个大问题来。
用户体量大或用户群体影响力强
例如微软，他的产品覆盖全球，每个更新都会牵动不同人群的目光。当然微软绝对不只是只靠测试自动化这一个手段来做质量检测的。
例如苹果，光一个系统的小版本发布就会引来诸多的关注，这些关注不仅仅是最终用户，还包括整个生态圈里的众多厂商。如果你的公司是苹果网游软件排行榜前10，系统更新后你的游戏不适配，那个时候对“时间就是金钱”的体会会让你痛彻心扉。
软件功能的量级
功能量级决定测试用例数量，数量越大，自动化测试的价值越能够体现。
当然不是说轻量级软件（测试用例量级不大）的就不用，如果在别的因素（例如更新/迭代频率）影响程度更高的情况下也是有必需的。
大型长期的软件产品
例如美国的人力管理软件公司Kronos、国内的财务软件公司用友等等，一个软件客户用10年，对外发布大版本的开发周期有的也是长达数年，大部分功能相对固定，大量沉积的丰富的API库。
对测试的重视程度较高
在美国，由于对于质量和流程控制的重视，测试、变更等等与质量有关的预算在许多公司会高达总营收的10%到20%。
这里提一个有意思的题外话，日韩企业相对对于质量检测的预算比例平均低于美国企业，但其很多软件产品的质量仍然位于全球前列，其得益于“零缺陷”和“全面质量管理”的管理思想的发扬光大，预算更多投入在了源头以遏制缺陷的产生。有兴趣的朋友可以去看看日韩企业质量管理相关分析。
…
3.4.2、什么阶段适合做
测试在越早的阶段开始越好这是共识，这里讲的测试不单纯包括实施、执行，更为重要的是前期的计划。所以下述不仅囊括从不同角度区分的阶段，也包括开展自动化测试的重点。
从软件生命周期来说，下表给出典型的自动化测试项目实施在每个阶段的重点。
从测试阶段来讲，
在错误的阶段实施自动化测试，或者实施错误的测试重点/类型，自然会导致本文开始出现的场景。工具和手段本身没有错，错的是人如何去安排。
对于敏捷项目，无非是在每个sprint里计划开发不同feature的脚本并进行执行。每个迭代的自动化测试执行可以囊括所有已开发完成的脚本。
需要注意的是
往往测试的周期较开发会滞后几天；
自动化测试检测出来的缺陷在敏捷项目中可以根据项目安排来进行修复，例如可以当前sprint修复，或者集中安排指定的sprint进行修复。
4、延伸：DevOps不可或缺的测试自动化
提到自动化测试，不能不再说说DevOps。
4.1、关于DevOps
（来自百科）
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
DevOps可以实现持续部署，以解决持续提高的部署频率的需求。
图4.1 举例采用DevOps公司的部署数据
4.2、DevOps实践模型
4.3、自动化测试in DevOps
DevOps作为敏捷开发项目的一种过程，快速的产品发布必然需要加强自动化测试的覆盖率、最大可能缩短开发周期、减小维护时间，传统的手工测试基本无法跟上高速产品发布的节奏。
这时，单纯将自动化代码放入CI中已不能满足要求，同时需要做到
产品功能点与测试用例科学对应（最小化原则）
测试用例彼此独立且容易复用（子用例）
产品代码/API与测试代码紧密关联结合
某些产品变化，无需修改自动化代码。例如用产品API进行数据初始化，当相关的UI变动时，并不会对自动化脚本造成影响。
测试自动化，不仅仅是进行自动化测试，更包括自动化代码的持续集成编译、自动执行、自动化报告、自动搜集抓取相关log及异常等。
假设/前提
本文中提到或涉及部分自动化测试的最佳实践，作为示例举证但不完全。
论述的自动化测试更多适用场景针对具有一定复杂度的软件。
Enjoy automation testing! Make your test interesting!
版权声明：本文出自51Testing原创，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
