DevOps是当前软件行业最热门的话题，无论是互联行业，还是传统行业，大家都在拥抱DevOps，享受引入DevOps后带来的团队效能提升。但是也有不少的团队对DevOps的理解还存在误区，导致在实践过程中困难重重，甚至最终失败，总结失败的原因不外乎以下几点：
·认为引入DevOps就是引入一套工具集合并在团队（企业）内部将工具集用起来。
·DevOps的实践本身也是一项系统化的工程，就目前的行业现状来说，想要直接复制成功的经验难度较高。
·有一些团队（企业）把通过DevOps能力成熟度认证作为DevOps的实践目标，只是针对DevOps能力成熟度进行DevOps建设，却忽略了当前自身的团队（企业）也要为之做出一些变革。
DevOps的实践落地即不是一个成功案例经验的复制，也不是一套工具的引入与使用，更不是单纯的获取能力成熟度认证，它本身是一项体系化的、持续化的工程，需要在实践的过程中不断的针对DevOps的各个环节进行优化。
从测试的角度来说，如果想要拥抱DevOps，则必须要向敏捷测试转型，本文将从测试环节出发，探讨测试在DevOps中的位置以及如何在团队中推动敏捷测试落地。
瀑布与敏捷
回顾整个计算机发展史，提升软件开发效率始终是无法回避的话题，从最初的打孔纸带到汇编语言，从汇编语言到高级语言，从面向过程到面向对象，从简单的编辑器到集成开发环境（IDE），从瀑布式模型再到敏捷模型，无数的先辈们在软件工程的道路上不断的总结与创新，试图找到一种“银弹”，以求能够完美的解决软件工程中的各种问题，瀑布式与敏捷便是先后两个不同时期的、为解决软件开发效率的产物。
1、瀑布式模型
在传统的瀑布式模型中，软件开发的各个阶段被严格的划分为：
·需求分析
·概要设计
·详细设计
·编码
·测试
......
·上线
瀑布式模型严格定义各个阶段的顺序与输出、输出，这导致如果模型中的前一个阶段没有完成，后一个阶段将会被阻塞以等待前一个阶段的产出物。
例如，如果想进行开发，则必须要有详细设计文档，如果要进行测试，则开发阶段的工作必须已经完成。
瀑布式模型强调流程与文档的重要性，期望每个阶段的人员重点关心自己所处阶段的工作，通过让团队成员专注于本职工作来提高效率。
2、敏捷模型
敏捷模型强调快速迭代、拥抱变化。敏捷宣言指出：
“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
尽管右项有其价值，我们更重视左项的价值”
敏捷宣言强调左侧，但是并不否认右侧，敏捷模型建议软件开发应该采用小步快跑的方式，优先关注能够快速、高效的推进软件开发工作进度的事项，对于软件的附属产出物则可以在事后再作补充。
因此，在成功实践了敏捷模型的团队可以更快速的响应需求的变化（这一点在软件开发中几乎是不可避免的）。因为采用了小步快跑的方式，所在实践中可以快速试错，从而降低风险。不过，敏捷模型相对于瀑布式模型也存在一些劣势，如：
·敏捷模型更关注的是沟通及软件本身，弱化了文档，如果项目团队的人员流动性较大，会给项目的维护带来不少的挑战。
·敏捷模型弱化了团队中每一个岗位的职能，也就是说，在敏捷团队中，项目经理、开发人员、测试人员不一定是固定不变的，岗位之间是可以轮换的，因此，敏捷团队对团队成员的能力也提出了更高的要求。
·敏捷模型需要快速响应变化，如果项目还存在大量未解决的技术瓶颈，将会大幅度拖慢项目的进度。
通过上面的对比，可以看出瀑布式与敏捷各自的优缺点只是相对的，在项目中具体要采用何种方式，还需要具体论证。回到测试本身，在两种模型下对测试工作的要求也不尽相同，但是两种模型下的最终目的都是一致的，即交付可靠的软件。
敏捷测试
敏捷宣言中的四条有三条都与协作有关，它非常强调灵活及快速的响应变化，这意味着将传统瀑布式模型下的测试团队融入到敏捷团队也变得的尤其重要，那么传统的测试人员，应该如何适应敏捷，融入到敏捷团队中呢？
1、划分合适的迭代周期
为了适应“敏捷”的小步快跑的节奏，团队通常需要在项目初期定义好项目的基线，基于基线，划分合适的迭代周期，所谓合适，就是基于项目的周期，团队的人员配备，资源等综合给出的估算。
迭代周期即不可过长，比如一个迭代周期长达一个季度，甚至半年、一年，这将导致迭代失控，迭代进度无法管控，完全失去了敏捷的意义；也不可过短，比如三天一个迭代周期，这对整体水平还未达到一定高度的团队来说，将是一个巨大的挑战，极有可能频繁的出现迭代延期，也会影响项目的进度管控，结果变成为了敏捷而敏捷。
2、灵活的调整测试计划
敏捷提倡灵活，对应到测试工作也是一样，事先确定一个最小化的测试范围。在实际的测试工作中，随时关注迭代的变化及进展，灵活的调整测试计划，快速响应变化，保证测试计划与迭代计划匹配。
3、单元测试是前提
想要切实提升测试工作的效率，必须在团队内强力推行单元测试，保证单测试的覆盖率达到99%（实际开发中可能会有部分业务功能无法使用单元测试覆盖）以上且都能通过测试，测试人员的工作应该聚焦在自动化测试，而不是为开发人员验证一个空指针异常。
把单元测试阶段就可以发现的问题延期到线上测试阶段，将大幅度的增加CD（持续部署）的频率，进而导致整个团队的效率降低。
4、提高测试的自动化程度
提高测试工作效率的另一个途径是提高测试自动化的程度，测试工作归根结底，就是重复的对功能做验证（回归测试），而做重复的事情正是计算机所擅长的。
通过使用自动化工具及脚本将测试人员从繁重的、重复的测试验证工作中解脱出来，不但可以让测试人员从技术能力的提升中获得成就感，而且对团队人员的留存也大有裨益。
5、脚本与数据分离
自动化测试的推广离不开测试脚本的编写，测试脚本的本质也是一段程序代码，想要提高测试效率，单纯的会编写脚本是不够的，必须要做好脚本与测试数据的解耦。
通过为脚本绑定参数化数据文件的方式，在一个测试脚本中对接口执行多个边界条件测试；或者在执行性能测试之前向测试数据库中批量的、随机的插入百万级数据，这些都能够大幅度减少测试人员准备测试数据的过程，提升自动化测试的效率。
6、全员测试
在敏捷的驱动下，整个团队中成员的具体职能划分不再像瀑布式那样明确，这说明在敏捷的团队中可以有专职的测试人员，也可以没有，因为整个团队都需要对软件的最终质量负责。
单元测试是由开发人员完成的；功能测试可以是团队中任何一个人：产品经理、开发人员、测试人员......；自动化脚本也可以由任何一个熟悉脚本编写的人来完成；这些完全取决于团队内每一个成员的能力侧重和工作进度。
7、持续集成、持续测试、持续反馈
在一个运作良好的敏捷团队，每天两次（中午午休时一次，晚上下班前一次）的CI（持续集成），CD（持续部署）是最低要求。这要求对开发迭代中的任务规模进行合理划分，以0.5个工作日（4小时）内完成能1~N个任务（保证单元测试覆盖）为最佳。测试人员也要擅于运行自动化测试，保证在4小时内完成上一次提交的开发任务的测试。
测试的目的在于检验软件功能是否满足需求设计，因此在测试的过程中发现软件缺陷（bug）是不可避免的，那么bug应该怎样处理呢？
传统的瀑布式模型中，测试人员发现bug通常会在一些缺陷管理平台上录入，平台通过邮件通知开发人员，开发人员复现bug，如果没有复现bug，可能需要找测试人员当面沟通了解bug复现的场景。
但是在敏捷模型下是怎样的呢？在如此高的构建部署频率下，遵循传统的bug处理流程势必会浪费大量的时间，敏捷宣言第一条就提到“个体和互动高于流程和工具”，它告诉我们，出现bug直接去找相应功能的开发人员，立即向他复现bug。开发人员在处理完缺陷后直接回复测试人员当前已修复的缺陷清单，测试人员进行验证即可。
相对于传统的测试，敏捷测试弱化了软件工程中阶段性的概念，持续集成、持续测试、持续的质量反馈，都是为了在最短的时候发现和解决软件的质量问题，提升效率。
8、完善的工具链支持
在上面讨论测试如何融入敏捷团队的要点中可以看出，人的因素占绝大多数，但是这并不说明工具不重要。
·为了管理迭代与测试计划，需要有一套能够适应敏捷的需求及测试计划管理工具。
·为了快速执行自动化脚本，需要有一套能够管理并快速执行脚本的工具。
·为了在执行脚本时动态的参数化文件以及性能测试时进行数据初始化与数据卸载，需要有一个测试数据的管理与生成工具。
·为了能够快速的进行CICD，需要有一套高效的流水线工具；建立这些工具链的生态并在团队内推广使用，也是敏捷测试的必备前提条件。
实践敏捷测试
一旦确定要在团队中推动敏捷开发，就需要从多个方向着手：工具平台、流程体系、规范制度、成员能力、组织架构，每一个方向都不可或缺。那么对于测试，应该如何参与呢？
1、提升沟通能力
敏捷宣言认为，面对面沟通是团队协作的最高效方式，它远比书面的文档更有效，这一点不只是针对测试，也针对团队中所有的成员。
当团队内有人对某一个业务有歧义时，最有效的方式就是找到与这个业务有关联的所有人员，展开一个快速高效的站立会议：说明问题、讨论解决方案、确认方案、实施，一气呵成，一步到位。所有的一切都以提升效率为第一要务。
2、提高编程能力
自动化测试是敏捷测试的基础。敏捷测试强调高效、持续，这离不开自动化的支持，而自动化的基础是代码、编程。
虽然目前市面上已经有不少的测试软件能够让测试人员不用掌握编程技能也可以进行自动化测试，但是涉及到复杂的业务场景、脚本与数据分离、错误排查等场景时，仍然需要具有较强编程能力。
可以说，测试人员编程能力的高低是自动化测试能否顺利推进的关键。
总结
在上述内容中，主要从两个方面论述了敏捷测试：
如何从传统测试转向敏捷测试？
如何实践敏捷测试？
实践敏捷测试并不是一蹴而就的，它是整个DevOps中必不可少的一环。对于工具，有许多开源的以及商业的工具可供选择；对于体系的建议，也有各种咨询及书籍论述。那么对测试人员自身，应该如何应对呢？
最重要的是针对DevOps及敏捷测试理念中对个人能力的各项要求查漏补缺，补足个人能力的短板。转型、改变总是痛苦的，但是当你全面转向DevOps时，自会感受其带来的好处。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
