注：本文由云层原创，转载引用请注明出处！

在分布式互联网快速发展的今天，敏捷、DevOps已经逐步成为主流，与之配对的运维也在逐步走向自动化运维与AI智能运维，而测试在哪里？本文希望通过跟随互联网发展的过程逐步从瀑布模式带领大家走进分布式互联网架构，实现新人渐进成为合格敏捷测试人员（测试架构）的思想、技能、架构整体指导。

一、基本理念

1.敏捷的价值

    突然之间身边都是敏捷，都是DevOps，那么走到这一步的原因是什么呢？我们从这个浮躁的社会说起。

    快！可能是最近几年行业中说的最多的话，能不能再快一点是每个人都迫切的需求！在移动互联网下，信息已经以分钟为单位在大家的世界中进行，谁能更快的与用户行程连接，谁就控制了流量，得流量得天下。

    敏捷就是这样应运而生的。敏捷可以理解成快速感知+快速反馈，圈内在说到5G淘汰4G的关键是很多应用需要5G的低延迟来解决行业中的技术基础例如无人驾驶。而敏捷的一切就是围绕快速实现价值而来的。

二、VUCA的行业背景

    VUCA的概念经常被提及，由于时代的变化，我们从可以预估未来5年变成了我们无法预估未来1年的情况。

    VUCA是volatility（易变性），uncertainty（不确定性），complexity（复杂性），ambiguity（模糊性）的缩写。VUCA这个术语源于军事用语并在20世纪90年代开始被普遍使用。随后被用于从盈利性公司到教育事业的各种组织的战略这种新兴思想中去。

    拼多多就在这个我们看不到行业空间（JD、TMall、Taobao电商全方位包含）的情况下3年就上市了纳斯达克，以前需要10年才能做到的现在只需要3年。而下一个“热点”还需要多久？也许起来只有1个月，消失只需要1天。如果还是按照瀑布的做法，还没交付就结束了。参考安卓、大数据、区块链等技术热点，谁能比别人早一点，那么就能活下来，而快速转型紧跟变化的能力成为了核心。

总结：通过内容给读者交付最快的知识价值。围绕文化（人）、组织（流程）、自动化（技术）来实现价值流的全生命周期跟踪。

三、敏捷的核心价值观

    “如果要做成功一件事情，那么一定要坚持做一件事情。”

    坚持、信念或文化是能够做成功一件事情很重要的部分，那么敏捷到底是什么呢？这里可以从两个角度来谈一下：

敏捷宣言

    本文不想重复那些网络上那些敏捷宣言中的条目，如果大家都阅读过仔细想想强调的还是沟通与实现。很多内容都是与瀑布模式的对比，在敏捷中反对一次性计划、一次性交付的模式，强调尽快的交付用户价值。而要做到这点依赖于团队文化，个人能力。

快速交付

    如果想要尽快交付用户价值，加速交付的速度是基础，在敏捷（例如Scrum模式）中通过迭代规划、控制团队体积及整合业务与研发团队的方式来解决了交付周期的过长问题。配合持续集成体系大大加速了用户价值交付的速度，从某些角度来说敏捷迭代也可以认为是小瀑布模型，只是多个小瀑布能够组成未来的版本火车。

    敏捷可能是一些理念（敏捷宣言），也可能是一种思想（快速交付），最后落地会成为一种实践（Scrum）。黑猫白猫能抓住老鼠的就是好猫，既然传统的模式解决不了现在的未知领域未知解决方案，那么敏捷的模式真的帮助我们快速试错了，所以我们需要坚定的走向敏捷。

四、DevOps更快的解决问题

    Devops的异军突起其实蛮出乎大家意料的，在我的看法中是软件开发流程与快速交付的冲突到达了无法和解的结果。“杀一个程序员祭天”或者“开发一个能够根据手机壳颜色自动同步APP主题颜色”这样的段子层出不穷，也正是矛盾下IT人员的内心写照。

    一边是产品经理不断的希望满足客户快速增长和难以填补的内心“空虚”，另一方面是研发团队无法在这样的快速迭代下持续稳定工作。

    其实敏捷给了很多解决方案给大家，但是DevOps流行的根本是适应了当前互联网所需要的很多技术走向。在我看来敏捷偏管理、DevOps偏技术，在很多角度DevOps确实有效的解决了很多问题，大大加速了产品交付的速度，而这些东西的体现更直接的原因是“持续交付”的实现，而DevOps不仅仅是持续交付。

组织的变化

    文化会在组织上非常明显的体现，我们可以说敏捷打通了业务、开发和测试，让业务作为"猪"加入，减少了产品经理被群殴的风险。而DevOps为了实现持续交付进一步的整合了运维团队，让价值交付的速度进一步提升（一切没有发布到生产环境可以随时上线的都是在制品）。既然DevOps团队是敏捷（自制）的、独立完整的，那么作为沟通的代价就大大降低，从而实现精炼战队。

DevOps让每一个交付都直接在线而不是仅仅的待交付物。

流水线对测试的依赖

    在持续集成、持续交付流水线中，基于微服务和容器云技术，已经很好的解决了自动化运维、部署及架构的拆分。一个个毛线团已经被拉了开，做任何事情可以清楚的知道有哪些问题了，但是下手越来越难，维护也越来越难。这时候会发现任何一点变化都会有很多的“补丁”来在“稳定”的架构上植入一个新特性，而在这里对测试的需求就越发急迫，传统的手工测试已经成为流水线发布的巨大瓶颈，而自动化测试只重其型不重其意的问题，导致大量的实践效果并不理想。

    通过Jenkins这样的工具，让每一次代码提交可以快速构建、测试、发布。

持续集成

    强调在针对代码进行尽快的集成来尽早发现问题，通过CI持续集成服务器完成报告提交。

    通过持续集成可以尽快的发现代码问题，而这依赖于测试的反馈，包括TDD和代码扫描等保障手段。

持续交付

    与持续集成不同的地方在于在测试环境都和上线还是有距离的，所以持续交付要求能够快速把代码发布到生产环境通过灰度发布、蓝绿部署都方式来在线评估质量（手动）。

持续部署

    与持续集成不同的地方在于在测试环境都和上线还是有距离的，所以持续交付要求能够快速把代码发布到生产环境通过灰度发布、蓝绿部署都方式来在线评估质量（自动）。

持续测试

    在上面的一切中如何有效保证每一次发布的质量，所对应的的TEST过程就是我们所需要在持续部署中的持续测试。在这个持续测试的过程中就会涉及到测试环境、测试数据、测试工具等内容。

为系统制造问题

    从构建测试环境到与生产1:1预生产环境再到在生产环境上做测试，这些都是为了更好的获取问题并解决问题的手段。而故障植入可能是异常测试的互联网化最佳实践，既然问题是无法通过测试完全发现的，那么将可能的主要情况模拟出来，学会控制风险。而为系统设置故障，同样也是对测试设计的巨大挑战。

    无论是敏捷还是DevOps都对测试提出了更高的要求，在这种日日迭代，随时发布的情况下测试如何紧跟步伐呢？请耐心的慢慢一步步下来。

五、测试与行业发展

    做测试很多年了，看着互联网行业的发展，经历了很多事情，而软件测试也从点点点的手工执行开始走上设计之路，再从设计测试进步到技术革命。

    过了很多年，测试技术和薪水也都不能同日而语，而就算这样在有了自动化测试团队、非功能测试团队、强大的自动化持续集成体系，但每次一次上线还如此的惊心动魄，常常看到朋友圈的小伙伴凌晨3点还在加班。

    自动化了测试，真的有效么？如果深入做过自动化都知道做自动化并不见得会提升质量，而且它的维护成本很高，做着做着就会发现陷入了一个怪圈，自己会开始否定自己做自动化测试的意义。问题的关键并不是做了自动化测试没有，而是没有做足够好的自动化测试，导致针对测试结果的反馈不够迅速，最终导致形式自动化。

有效自动化与无效自动化

    有效的自动化并不是指有了自动化框架可以被触发为自动化了，而是包含了从自动构建待测试代码，自动发布到测试平台，自动对该测试平台进行测试，自动提交测试报告，这样一个完成的回馈链，并且确保整个回馈链的时间在合适的范围内（快速5分钟，中度3-5个小时）。通过这样的自动化能够让开发部门能够快速得到反馈并且获取该反馈中所需要的相关信息（被测代码分支、测试环境、测试脚本内容、缺陷信息），这样的自动化流程需要一下3个条件：

1.开发规范化，确保编译发布是可以自动化的

2.测试环境规范化，确保测试环境的构建是可以被赋能的（运维）

3.测试方法规范化，确保测试的脚本和内容是规范可控的

4.测试用例、数据自动化，基于大数据、AI等技术的辅助测试

而在这个支撑基础下如何提升测试设计能力，将自动化测试的用例质量提升，从而将测试的有效性逐步提高。

测试运维的兴起

    TestOps测试运维并不是突然出现的，早在若干年前测试人员就需要对测试环境负责，只有测试人员明白需要什么样的环境，什么样的数据，什么样的异常。由于互联网化的技术瓶颈，逐渐测试人员丧失了本地化类生产环境及测试环境的维护能力，导致等待环境成为了一个影响测试效率与质量的瓶颈。另一方面由于缺乏运维的监控能力，导致在系统出现问题时无法排查相关的日志及数据，在第一时间对问题进行快照跟踪，从而错过了定位修复缺陷的最佳时机。

    在行业中也看到了有提出QA on Production的概念，在生产环境上进行测试、监控、维护，而这样的职位也可以叫做QAOPS（大家可以自行百度了解）。

    测试运维就是用来解决这些问题的，构建自动化测试环境流水线，让测试可以简单快捷的构建测试环境，提高测试执行效率，进一步构建测试服务并延伸至整个产品从客户需求到研发到客户使用的全过程，做到全生命周期持续反馈。

    在当前DevOps的大体系下，TestOps作为持续反馈的最佳技能栈角色，承担了持续测试的重担。

测试的三大阶段

    回顾行业发展，对于测试的发展，我总结了三个大的发展阶段：

1.被动型

    在这个阶段中测试只是一个上线前的验证过程。代表用户先去试用软件，减少用户使用软件的问题，这也和当时应用架构有关，几乎都是基于介质安装的，导致更新的代价非常大。

    在这个阶段中，测试部门会逐步成为一个严重的瓶颈，需要测试的内容越来越多，但是遗漏的问题并没有有效控制，成为了鸡肋（食之无味，弃之可惜）一样的部门，不做测试不行，做了也并不解决所有问题。

2.技术型

    在这个阶段中测试人员通过技术提升了测试效率和测试质量。在整个服务端架构体系的出现后，更新的方式从客户端变为了服务端，对于质量的理解和功能增加的速度也大幅提升，引入测试工具、进行测试开发是必然选择。

    在这个阶段中测试部门得到了一定的尊重，但是随着版本的快速递增，测试团队自身的效率已经开发到了比较高的阶段，但是由于测试环境、版本、数据等原因，导致大量的等待，影响了测试本身更好的发挥。另一方面技术与业务的平衡出现了拐点，导致为了技术而技术的测试，在没有测试设计的支持下无法有效的发现问题。

3.赋能型

    在这个阶段中测试人员已经可以将测试作为一种服务赋能给别的部门。全生命周期质量保证，敏捷团队的出现，质量成为了所有人员都应该重视的内容，将测试能力赋能团队成为了需要。赋能包括测试本身的设计和执行能力，在这个阶段中通过需求的介入制定对应的实例化、Acceptance Criteria验收标准及Definition Of Done完成定义，将我会怎么测在一开始就提供给了相关人员，而测试平台的构建可以让测试被相关人员自行执行，从而改变了测试人员本身的角色。

    在这个阶段中工程效能团队的诞生，TestOps测试运维和测试开发都会作为工程质量效能团队的一员，将测试团队从成本部门变为赋能团队，为第三方提供质量保证的服务。

4.测试敏捷化之路

    既然敏捷是潮流，敏捷是无法阻挡的，作为测试怎么走下去。通过某位朋友说的一句话“只有被淘汰的职位，没有被淘汰的职能”来描述比较贴切。

敏捷测试

    敏捷测试可能是我们最容易被想到的内容，基于敏捷的思想体系，针对其进行测试的配对。那么在敏捷测试中与敏捷配对会遇到的问题就包括：

1.用户故事的优先级及估算

2.用户故事Acceptance Criteria验收标准及Definition Of Done 完成定义

3.进入Sprint Backlog的需求内容评审

4.Sprint中需求被实现的确认

5.迭代总结

    这些都是在敏捷中测试可以介入的内容，从过去一个小的测试部门到成为Dev团队的一份子，测试工作从简单的步骤4，升级为了1-5（在DevOps中还有扩充）。

    作为“猪”的一员，测试的能力提升会大大增强团队速率的稳定性，并且为任务提供DOD完成定义来帮助大家更好的评估工作量，并且更快反馈问题，从而降低研发周期。

    在DevOps体系中提出了持续测试（持续反馈）的概念，来强调测试的重要性。

测试敏捷化

    在时代的变化下，敏捷测试可能有些跟不上了，因为在DevOps下，面临着持续交付下的测试，延伸了发布后的验证过程，持续测试成为了大家聊到的话题，而进一步测试敏捷化被提了出来。在过去传统的瀑布型测试中，测试人员总是被动的，固定流程的流动：

1.等待需求写测试用例

2.等待环境写自动化测试脚本

3.等待发布执行手工&自动化测试

4.提交缺陷报告及测试报告

这种做法已经很难满足研发、需求、运维的敏态需要。测试敏捷化以交付业务价值、共同目标、测试无所不在、跨团队协作、自我进化的思想，来提升自我。

官方定义：

测试敏捷化是指在与软件生命周期所有交付品质相关的活动中，通过对组织、文化、流程、技术等要素进行优化与改进，使得测试能够贯穿于研发全过程并与上下游团队高效协作；能够在业务与技术水平上持续提升，达到自我驱动、灵活赋能、快速交付、高效稳定的最终目标。

写在后面：定义会随着时间的推移而逐渐变化，测试的工作也在调整，但是不忘初心永远是每一个测试人员的座右铭。时刻保持着对交付产品的质量之心，关注软件前后端的技术发展匹配对应的质保体系，这份心才是确保自己不被淘汰的关键。

ps :下一篇会继续给大家分享敏捷相关的内容，觉得本文不错可以关注小编哟~要想深入学习交流可以加微信：xiang520and 或者QQ群：243771258一起探讨。