本文主要以华为云的演变历程为案例，从工具角度为大家简要讲解敏捷转型过程中测试人员及测试团队都会经历哪些转变。

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

在2008年到2011年期间，产品逐渐向敏捷方向发展，这时有一部分研发工具平台已经陆陆续续转到云上去了，一些测试类的工具也需要转型。之前产品的交付是半年、两个月发一次，转型之后变成一个月，甚至两周发一次，但这时的转变并不彻底，与客户的交付过程仍然存在一些问题。

在2011年到2014年，华为全面把工具向平台化、服务化方向转型，这个时候一些商业模式才发生了根本性的变化，也就是说当需求上云了以后，用户才更加快速的介入进来。以前的项目是，每年年初接一次需求，而上云之后是时刻反馈需求，基于云平台，把一些功能快速的开发出来，然后频繁的和用户去商量，听取客户意见，牵引产品做快速迭代，这种交付方法使得交付周期一下变快了，之前是半年交付一次，现在是一周、两周，更有甚者，可能一两天就把功能发布出去了。从需求的角度来说发生了巨大变化，基本做到了小步快跑，快速试错。

需求变化了，产品的架构也发生了变化。 CS 的时候产品是单点的架构，后来慢慢转型到了SOA，到现在微服务的架构。第一轮敏捷升级，华为把业务部门和研发部门合到一起，在DevOps微服务转型的时候，把运营和运维合到一起。

然而需求变化了，架构变化了，团队也变了，这就导致了项目在过程中遗留了很多债务。从测试角度来说，这些债务主要有这么几类。第一类就是人。团队和个人、各个角色对测试的意识是不同的。比如说全功能团队对开发很重视，因为项目必须要交付产品，但是对测试方面不重视。所以测试人员自己会觉得是否自身发展到了瓶颈，没有办法再朝着测试的方向继续发展。测试人员最开始有些专项的能力，包括行动可靠性等等，他们会写一些自动化的脚本，拥有一些自动化的能力，但是在转型的过程中，他们会面临一些自动化的开发工具，需要对接自动化平台，需要有一定的开发能力，这对测试人员的自身素质提出了更高的要求。而对开发人员来说，首先是质量意识不足，第二是对于大部分开发人员来说白盒测试用例会写，但是黑盒测试用例不会写。另一方面开发在转型的过程中往往忽视了敏捷价值观，他们的思想还停留在传统的开发思想，开发做开发的事，质量跟我无关。这些其实并不是技能的问题，更多的还是思想意识上的欠缺。除了人的意识之外，前面还提到了技能意识，流程意识，例如过度依赖黑盒功能测试，我们在流程里面对测试的保障就是依赖黑盒子，结果测试、前端的UI测试，认为做到这些就能保证质量。还有一些问题，例如迭代速度很快，测试时间留得很少，所有工作量的评估只评估开发完的事情，没有评估从开发到测试，乃至上线的时间点。环境本身也有问题，测试环境部署时间比较长，测试人员在α、β生产各个节点上面做部署，然后做验证，使得部署耗费了很多时间。

下面让我们再看看测试，测试最重要的是要做什么。这里有两个关键的焦点：

• 第一点，测试就是一个质量活动，做测试就是要保证质量。
• 第二点，业务价值。测试要围绕业务价值去做，而不是说一个测试上来之后，就把测试相关的关系点、关联点全部做一遍。

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

• 自动化测试金字塔

  从这个金字塔可以看出在测试方面每一个环节的自动化能力和投入，在最底层单元测试方面，这个金字塔不代表测试用例的数量，而更应该关心单元测试的质量。例如项目中有一个非常重要的模块，要保证重要模块对应的覆盖率要达到标准。所以单元测试的重点不是在用例的数量上，一定要关心它本身的质量。在金字塔越底层做的事情，发现问题并将其解决的成本越低。而越向上一层，解决成本越高，效率也会越低。例如在界面测试层面发现了问题，对问题的定位要从界面到网络、模块A、模块B等等，需要涉及很多工作人员做问题定位。如果在单元测试层面发现问题，那么就是模块本身的问题了。对于金字塔里面所有基于代码、到单元测试、接口测试、界面测试、UI，还要尽量做到自动化。提交一行代码，能够自动把整个测试流程走遍，出去喝一杯咖啡之后，回来看到所有的测试结果在开发者眼前呈现。

  

• 常规安全与弹性安全

  在我们常规的设想中，通常是哪个地方不安全，就一定要把所有不安全的因素找出来，清除掉。这是常规的做法，也就是Safety-Ⅰ的小天平，指针在绿色一边是安全，在红色一边不安全。第一个做法是把不安全的红色因素一一剔除，这是一种非常理想的方法，但在实际工作中是不可能把整个系统中不安全的因子全部识别到的，这其中涉及能力、架构等各方面的原因。因而在此基础上演变出了弹性安全，就是通过场景模拟的方式将不安全因素尽量展现出来，从而基于这种不安全场景，给出快速的修复方案弥补这个不安全因素，从用户角度来讲是感知不到的。从产品来讲，它的商业目的和质量目的都可以达到，这就是所谓的弹性安全，即便发生了错误，能够及时快速的修复漏洞或者自我修复，达到正常工作的目的。

• 测试左移和测试右移

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

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

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

• 不同时期的测试策略

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

  • 在软件初期探索阶段，产品是一个不确定的状态，从前端的风格和整体的布局到后端的API都时刻在变化当中，而且变化比较频繁，因为自动化用例的生命周期比较短，所以在这个时候创建一些自动化测试用例是不太划算的。而这个时间段产品，往往特性是可控制的，只有几个测试，所以可以以手动为主，不考虑自动化，让产品能够快速识别错误点，让用户能用起来。
  • 到了产品扩张阶段，用户认可产品，这时候会出现两个现象。第一是用户量增长，第二是需求数量增长。这时候必须要考虑自动化。因为在这个阶段每一次迭代的全量验证成本会越来越大，而交付的速度也会越来越快。我们不可能每一轮上线的时候都做全部的测试，这时候旧的模块就需要自动化用例去保证。
  • 到提取阶段，产品已经到了需求的饱和期，产品的利益增长也到了饱和期，这时候要严格控制产品需求，自动化用例的职责变成守护，不允许变动引入额外的风险点、大的特性变动，导致对成熟的用户造成攻击。
• 团队规模对测试建设的影响

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

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

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

  

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

  

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

  

• 契约测试的价值

  团队之间一定要引入契约测试，这描述起来比较简单，它既是一种测试技术，也是一种测试规范。例如有两个服务分别是服务A和服务B，服务A依赖服务B的结构。这时签订一个契约，服务A基于这个Mock开发自己的业务逻辑，服务B基于测试来保证给A提供的结构是可用的，最终两个服务可以独立上线，A和B可以做远调。这就好像我们生活中的螺母和螺丝，它们分别由A和B厂商制造，但是他们会遵循一些契约，保证螺丝的长度、宽度、对应的型号和间距都会对应标准，最终两个厂商生产的螺丝和螺母能够正常工作，严丝合缝的合在一起。这就是契约测试的价值。

  

下面我们来看看在CodeArts中的几个实践。针对CodeArts，团队内部有几个专项的试点。第一是视角，测试本身不仅仅是某个细节功能点的测试，还要基于场景做测试用例，而且在必要的情况下，会有一些专门的人去对这些场景做手工测试，检验是否有问题。CodeArts本身就是打造开发者一站式的云上开发平台，提供整套的工具链，所以CodeArts团队内部追寻的DevOps下的开发实践就是狗粮文化，自己的狗粮自己吃，所有的测试活动、软件开发活动都在CodeArts里面进行，这样开发人员既是开发人员又是测试人员，他自己的思维会一直在转变，不断的打磨自己的产品，最终使产品精益求精。还有一个实践是分层自动化，CodeArts团队把所有的自动化专项流程打散，放到流水线里面，在编码或者再向前的环节，做一些安全的分析，在编码过程中做编码检视，还有单元测试用例来保证单元测试本身的用例指标。在后面的阶段，还有华为云的代码静态检查，会预先识别代码里面的规范，包括隐含的内存，通过对语句的分析能够找到问题，进行拦截。在部署到Alpha、Beta测试阶段，用CodeArts的 API服务 构造一些针对可靠性和安全的测试用例。针对生产环境的在线测试，进行在线拨测，还有后台的主动检测手段，包括前端、后端接口的检测。以及用户业务流下面关键分支上的日志，有异常日志要记录下来，然后基于日志进行分析，这些在使用过程中也会给我们进行一些质量的反馈。

最后，简单介绍一下华为云的测试服务。华为云的测试服务最开始是对内部的，有很多的测试工具。做到一定程度，也积累了很多的测试经验之后，对外发布了一些比较好的实践所带来的工具，例如现在已经上线的CodeArts的测试计划和 移动应用测试 以及解决方案，包括整体测试流程管理、测试的用例和需求双向可追溯，能够看到这个需求的测试状态；提供相应的自动化的能力，例如对安卓和IOS的测试，将软件包放在后台，对它进行系统化的兼容性测试，检测是否有兼容性的问题，能够涵概多少用户；接口测试，能够涵盖接口一层的自动化测试，APITest可以让开发人员投入到写测试用例，你可以通过鼠标加一些必要的参数进行编排，可以通过接口把场景构造出来；性能测试，模拟一些大并发的场景，会提供多种加压策略，能够实现在测试过程中对于用户的吞吐量、响应时间、负载能力，进行整体的分析。测试总览还提供完全可视化的看板，能够提供测试用例执行的情况汇总，帮助团队迅速掌握当前项目的需求和用例执行情况。

小结：本文结合华为云CodeArts团队内部近几年的测试能力发展的角度简单剖析了项目团队在DevOps转型过程中会遇到的问题，以及需要提升的能力。希望通过本文的解读能为各位在DevOps转型中迷失的从事测试工作的朋友们带来一定的启发。