DevOps敏捷测试之道

在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厂商制造，但是他们会遵循一些契约，保证螺丝的长度、宽度、对应的型号和间距都会对应标准，最终两个厂商生产的螺丝和螺母能够正常工作，严丝合缝的合在一起。这就是契约测试的价值。

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

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

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