1. 敏捷项目vs传统瀑布项目的最大不同
快速交付，分拆交付，快速迭代，拥抱变化！
迭代故事点示意图：
不断增长的已完成story point时，谁敢拍胸脯说以前的功能百分比不出问题？谁又去承担这快节奏的回归测试的压力？
此时，自动化测试就成为重要的备选解决方案之一。
2 自动化测试对于敏捷项目的必要性
持续交付的需求 流线化测试流程使其更快以适应敏捷
代码的持续集成是基础，而自动化测试则是保障持续交付的重要步骤。
以装修铺地板砖为例，房间那么大肯定不是用一块整砖铺上去，每个房间面积不同工厂也不可能批量生产定制化的地砖，所以采用一块块的地砖（story）铺上去。这就是持续集成。铺的过程中还可能根据情况进行切割（变化）。为了检验是否铺的合格，工人不是铺完后再进行检测，一般每铺完一块就通过各种工具进行（测试），如果有问题（缺陷）就及时调整（fix defect）。这就形成了持续交付。当铺完最后一块地砖，这个工程步骤也随之宣告结束。
在测试环境部署完成进行测试时，敏捷项目对时间的苛求，快速测试、快速报告（例如自动化测试结果自动push到用例管理工具中）、持续部署对结果自动化的要求，都意味着离开统一的工具和自动化无法达成。
3.3 在敏捷环境中执行自动化测试的挑战及对策
不仅仅是敏捷开发的方法学引入到软件开发中，QA在项目中的角色也随之改变。既然是敏捷，那么不再是一群QA坐在角落里，等着开发团队交付功能进行测试。敏捷项目的自动化QA不仅要熟识传统自动化测试项目的知识，更要对敏捷开发方法学和流程有很好的了解。知晓敏捷测试的挑战，有助于自动化测试人员有针对性的制订措施予以克服或缓解。下面进列出一些主要的挑战及其对策。
3.3.1 不断/最后一分钟仍在改变的需求
敏捷项目中需求变更是一个永恒的话题。当sprint进行一半时需求的改变甚至被砍掉，是整个团队包括开发和测试团队的梦魇，而不断重复则会完全摧毁整个项目的成功交付。作为项目经理整体把控，建立变更控制的流程，通过相应的方法和工具来管理监控变更。
具体到自动化测试项目中，通常可采用下面的办法很好的管理变更。
1)把控backlog/test case（测试用例）完整度
所谓backlog完整度，是指供自动化的测试用例细节不明确、后续各种变化多等情况。
很多时候这项被忽略，往往拿到用例就开工，当自动化测试在敏捷项目中失败时回过头做教训总结时，很意外归结到此项的比例特别的高。
在开始编码前增加业务梳理的环节，最好由专人负责，确保自动化测试人员开始编码/学习业务的时候拿到的是相对完整的场景用例。
需要注意大多自动化测试的backlog来自于手工的测试用例，但供手工测试的用例有时一些描述是比较模糊的，在自动化前需要予以明确清晰的定义。
粗陋的backlog，退回或延迟自动化！！
2)自动化开发过程中严控变化
一旦BA业务梳理结束开发启动，这时需要尽量的控制变化，尽快的根据当前版本的backlog完成脚本的开发。如果发生变化，交由维护阶段进行。
这里说的严控变化，不能理解为说脚本开发过程中完全不能有变化，小的不影响进度的变化可以脚本开发人员酌情安排修改（需要上报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文件等等。
针对数据驱动的应用本身有很多关于利弊与方法的讨论，此处不详述，重点强调的是no hard coding并采用适合自己项目维护的方式。
7)（UI自动化）采用最佳实践进行元素定位
元素定位在自动化测试中是非常重要的部分，也是非常容易在软件开发过程中变化的部分，应尽可能的规避潜在变化。
定位方式优先级别（常规，有例外的情况）：
自定义的字段 (例如Automation ID) > CSS > X-path
如果ID和CSS能定位到，尽量避免使用X-path方式定位。
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、元素定位等等。
3.3.4 选择适合的自动化工具
因为敏捷项目的变更非常多，传统录制回放类的自动化工具显然不适合，需要采用更为灵活的工具，这也是Selenium等UI自动化测试工具近几年大加流行的原因之一。
再例如SoapUI，这是一个优秀的轻量级的API测试工具，其Pro版也可以进行一些性能安全的测试。对于脚本开发人员的语言能力要求比较低，容易上手。
3.4 自动化测试在敏捷项目中的应用
3.4.1 什么项目适合做
-
公司/软件类型
互联网、游戏等这种实际上大多都是拿用户做β测试的公司，遇到重大问题一般都需要在小时为单位的严格限制中进行解决。总不能慢慢的等着手工测试结果，或者不管不顾解决3个小问题冒出1个大问题来。
-
大型长期的软件产品
例如美国的人力管理软件公司Kronos、国内的财务软件公司用友等等，一个软件客户用10年，对外发布大版本的开发周期有的也是长达数年，大部分功能相对固定，大量沉积的丰富的API库。
对于敏捷项目，无非是在每个sprint里计划开发不同feature的脚本并进行执行。每个迭代的自动化测试执行可以囊括所有已开发完成的脚本。
4、延伸：DevOps不可或缺的测试自动化
4.1 关于DevOps
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发dev 应用程序/软件工程）、技术运营Operation 和质量保障QA部门之间的沟通、协作与整合。
DevOps可以实现持续部署，以解决持续提高的部署频率的需求。
4.2 DevOps实践模型
4.3 自动化测试in DevOps
DevOps作为敏捷开发项目的一种过程，快速的产品发布必然需要加强自动化测试的覆盖率、最大可能缩短开发周期、减小维护时间，传统的手工测试基本无法跟上高速产品发布的节奏。
这时，单纯将自动化代码放入CI中已不能满足要求，同时需要做到
-
产品功能点与测试用例科学对应（最小化原则）
-
测试用例彼此独立且容易复用（子用例）
-
产品代码/API与测试代码紧密关联结合
某些产品变化，无需修改自动化代码。例如用产品API进行数据初始化，当相关的UI变动时，并不会对自动化脚本造成影响。
-
测试整体自动化
测试自动化，不仅仅是进行自动化测试，更包括自动化代码的持续集成编译、自动部署、自动执行、自动化报告、自动搜集抓取相关log及异常等。
-
同开发团队达成一致，将自动化测试的结果作为将开发环节推进到测试环节的准入标准。
本文摘取自51testing微信公众号，结合自己工作对在捷开发中如何做自动化测试进行学习和总结