企业在敏捷和DevOps的逐步转型过程中，测试如何应对挑战，如何有的放矢进行测试，建立适合产品自身发展阶段、产品特点的敏捷测试能力。

敏捷和DevOps

敏捷和DevOps转型始终是被业务目标和客户需求驱动的。市场竞争环境越来越激烈，新商业模式的创新和变现时间窗口越来越短，催生更多的企业采取精益创业的方式，捕捉市场需求后，尽量缩短TTM产品面世时间，快速推出MVP产品并快速响应客户需求迭代产品。

以华为为例，在2008年左右的时候，华为的项目还是采用传统的交付方式。例如，在年初开始一个项目，在项目立项之初就会把客户的需求全部收集好，包括一些用户的反馈，并把需求做了全年的排序。年中的时候发布产品给用户，两个月之后再出一个补丁，最终年底出一个正式的版本。当时版本交付的节奏还是比较慢的，但是对质量要求比较强。因为产品发布给客户以后，下一个补丁需要两个月，如果用户在这个期间发现产品问题，他们只能再等两个月，而在这期间如果用户不接受我们的产品，会导致项目前功尽弃，所以对产品的质量有严格的要求。

产品逐渐向敏捷方向发展，这时有一部分研发工具平台已经陆续转到上云，一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。后来越来越多的工具向平台化、服务化方向转型，这个时候一些商业模式发生了根本性的变化，也就是说当需求上云了以后，用户更加快速的介入进来。基于云平台，把一些功能快速的开发出来，然后频繁的和用户去商量，听取客户意见，牵引产品做快速迭代，这种交付方法使得交付周期一下变快了，之前是半年交付一次，现在是一周、两周，更有甚者，可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化，基本做到了小步快跑，快速试错。

测试债务

从瀑布到敏捷再到DevOps，在开发和测试生产率和需求交付效率提升的过程中，不同的组织或多或少面临一些积压问题没有解决，影响测试能力和测试价值的持续提升。

从对测试的重视程度上看，有的公司存在重开发、轻测试的情况，测试人员职业发展受限；手工测试人员不熟悉编程，开发人员对测试重视不足；测试工作量高，但人员配比低。

从部门组织和流程和文化上看，测试人员对需求理解不足，测试和开发之间的部门墙导致信息不透明、沟通协作滞后和不足，质量向速度过分妥协，以及忽视敏捷文化和价值观的培养塑造。

从测试和产品技术和方法上看，产品耦合度高、可测试性差，测试过于依赖黑盒功能测试，测试策略、方法不恰当，测试环境部署时间长，频繁升级等。

测试的焦点：业务价值的质量

测试首先是一个质量活动，做测试就是要保证质量；其次是一个工程性的活动，即在有限的时间、人力、资源投入内获得尽可能大的产出价值。质量有多个维度，需要有一个焦点：业务价值的质量，也就是产品“对客户呈现的价值”的质量。测试围绕业务价值去做，确定质量在功能、安全性、性能、易用性、兼容性等多个维度上的权重和优先级，而不是说一个测试上来之后，就把测试相关的关系点、关联点全部做测试。

让我们来看几个例子：例如现在正在做一个线上支付的功能，对这个功能最关心的方面肯定是安全，所以相关的测试用例关键点就应该围绕安全大做文章，一定把安全保证好；再比如，现在要做一个线上商城，面向用户是老百姓，不仅要让年轻人会用，也要让老人都会用，那么就要关注易用性；除此之外，电商举办大规模抢购促销活动，那就还需要关注性能。因此，测试要求瞄准产品本身的业务价值，确定产品的目标，相应的制定质量关键点，制订相关的测试策略，然后实践落地。落地之后还要基于一些不良的效果不断的进行反馈、循环，校验整体的测试过程是否达到预期结果，这就是我们的测试焦点。

常规安全与弹性安全

在我们常规的设想中，通常是哪个地方不安全，就一定要把所有不安全的因素找出来、清除掉。这是常规的做法，但却偏向于理想，在实际工作中是不可能把整个系统中不安全的因子全部识别到的，这其中涉及能力、架构等各方面的原因。

因此，在此基础上演变出了弹性安全，即通过场景模拟的方式将不安全因素尽量展现出来，从而基于这种不安全场景，给出快速的修复方案弥补这个不安全因素，从用户角度来讲是感知不到的。从产品来讲，它的商业目的和质量目的都可以达到，这就是所谓的弹性安全，即便发生了错误，能够及时快速的修复漏洞或者自我修复，达到正常工作的目的。

测试左移和测试右移

左移就是前移，尽量把活动向前移。例如BDD（Behavior Driven Development，行为驱动开发），基于场景直接设计出符合这个场景的用例，来匹配这个设计；契约测试，服务和服务本身之间有耦合，我们可以通过契约测试解耦，以防导致问题。

测试右移是指要把测试活动的覆盖范围尽量向后蔓延。通常的测试只进行到了版本发布之前，测好之后发布一个软件包，而测试右移要把软件包发布到生产环境，以及到线上运营环节，都要去做测试。

在这两个方面也有一些相应的实践，例如线上拨测，主动线上监控用户的一些行为，并从行为轨迹里面快速捕捉相应的问题，主动推送给相关的责任人，让他去关注并且解决。线上的过程可以通过一些测试手段，不断的反馈给真正的开发人员，让他知道当前产品的整体表现，开发人员就会快速的针对产品作出应对方案。

产品发展不同时期的测试策略

是否在团队组建之初，就要把整个自动化测试的能力构建起来呢？其实这有一个过程，下面从软件的成熟周期的角度，看一下如何构建测试自动化的能力。

在软件初期探索阶段，产品是一个不确定的状态，从前端的风格和整体的布局到后端的API都时刻在变化当中，而且变化比较频繁，由于自动化用例的生命周期比较短，所以在这个时候创建一些自动化测试用例是不太划算的。而这个时间段的产品，往往特性是可控制的，只有几个测试，因此可以以手动为主，不考虑自动化，让产品能够快速识别错误点，让用户能用起来。

到了产品扩张阶段，用户认可产品，这时候会出现两个现象：第一是用户量增长，第二是需求数量增长。这时候必须要考虑自动化，因为在这个阶段每一次迭代的全量验证成本会越来越大，而交付的速度也会越来越快。我们不可能每一轮上线的时候都全部用手工做测试，这时候旧的模块就需要自动化用例去保证。

到产品提取阶段，产品已经到了需求的饱和期，产品的利益增长也到了饱和期，这时候要严格控制产品需求，自动化用例的职责变成守护，不允许变动引入额外的风险点、大的特性变动，导致对成熟的用户造成攻击。

团队规模对测试建设的影响

当团队规模在5个人以下，团队处于探索阶段，这时质量活动可以仅仅局限于测试的自组织阶段，只是做一些基础类测试管理活动，把缺陷管理起来，做一些回归测试。在这个阶段主要是建立一个测试管理的流程和机制，并没有接触到自动化测试。

随着项目的进一步扩大，逐渐增长到5-10人的团队规模，这时测试工作量突然增加，可能会有专门的测试人员进来，这个测试人员会去和开发人员进行串联，把需求转化成自动化测试的用例，搭建持续集成，逐步演进一些测试手段。——这个阶段已经开始做一些自动化的尝试。

团队进一步增大，一个人可能搞不定工作量的时候，会招聘更多的测试人员，成立专门的测试团队，这个团队就从自动化测试转向测试自动化，把更多的管理工作做进来。在这个管理过程中，我们会做一些产品的对接，包括开发专门的工具，实现自动化的整体能力，不仅仅是自动化执行了。

经过上面几个演进周期之后，测试团队具备了很多的测试自动化经验，这个时候可以进行面向云化的转型，现在很多团队都在进行DevOps转型，最关心的方面就是组建DevOps的全功能团队。那么之前转型的这些人在做什么？原有10-15人的测试专项团队做什么？在这个阶段团队要把测试专项能力向服务化能力转型：测试专员会在团队创建初期进行赋能，包括测试工程搭建、早期的测试用例怎么写、标准化模板的编制、针对非功能性测试的专项能力的赋能；所有团队进行测试流程的评审，包括测试策略、测试计划、测试用例的评审，再看一下整个团队里面流程上还有哪些改进的；从各个方面整个专项测试团队向服务化进行转型，帮助所有团队完成自动化转型。

自动化测试和测试自动化

这里要澄清一个概念，就是测试自动化（Test Automation）。

测试自动化的目的是减少手工测试和手工操作。测试自动化不仅仅包括自动化测试执行（Automated Testing），还包括其它所有可以减人力投入的活动，例如自动化创建测试环境、自动化部署被测系统、自动化监控、自动化数据分析等。很多自动化测试只是测试的执行部分，例如把一些测试执行的人工测试手段做成自动化测试。但是测试自动化不仅仅是只是执行，还包括了从环境的获取到生成测试数据、执行自动化测试，最终生成结果。如果有问题，会自动推送给相关的人，对应的组织解决。自动生成测试报告，测试人员直接拿到测试结果。