【精彩回顾】DevOps测试之道

2018年DevOpsDays深圳大会精彩回顾,华为云DevCloud专家和大家分享DevOps测试之道。

我讲的这个主题主要是讲DevOps测试之道,但是叫“道”,我有一个担忧,我讲完之后,大家可能会睡得很爽。所以我们讲道的时候,更重要的是结合一些实践去讲,这样可能会有一些代入感。

我也想统计一下,在座各位哪些做过专职的软件测试?真的不少,谢谢。有开发人员做过单元测试吗?好的。今天这个题就讲对了,我们就细讲一下,在一个DevOps情况下,全站的能力下,我们的测试和开发各个角色应该怎么样关注测试和关注质量?从我自己的角度。

我2008年加入华为,至今工作10年了,一直在负责华为内部和外部的基于研发和测试工具平台和能力。当前在我们华为云的软件开发服务DevCloud这边负责整个云测的产品交付和解决方案,以及整个产品本身的质量,都在我这边负责。

我讲一下2008年到2018年,我们从工具角度研发来讲经历了哪些。我2008年刚刚入职的时候,我们做的工具更多是CS架构,用户去使用我们的工具,都是要去装一个客户端。我当时就去做基于视窗的客户端。那个时候我们的一个项目的立项,就是在年初做一个立项,就会把内部一些需求全部收集到,包括一些用户的反馈,我们把需求做了全年的排序,到年终发布产品给用户,两个月之后出一个补丁,年底出一个正式的版本。当时版本交付的节奏还是比较慢的,但是对质量要求比较强。因为我的版本上来之后,补丁要定两个月,如果用户在这个时间点发现问题,对不起只能等两个月,这时候用户不接受,所以我们要保证质量稳定。在2008年到2011年,我们的产品逐渐向敏捷方向发展,这时有一部分研发平台工具已经陆陆续续转到云上去了,一些测试类的工具也要转,做得敏捷岛编程,强制把一些实践上来了。以前是半年、两个月发一次,这次就一个月,甚至两周发一次。但是对不起,两周发一次到不了用户这边,能够形成产品化,但是还是有问题。在2011年到2014年,公司全面把我们的工具往平台化、服务化方向转型,这个时候我们的一些商业模式才发生了根本性的变化,就是说我们的需求从上云的时候,用户才更加快速的介入进来,以前的工具我做的时候,每年年初接一次需求,上云之后是时刻反馈的需求,我们就是基于这个云,把一些功能快速的开发出来,和用户去商量,说这样做行吗?用户说不行,你帮我改。这样快速做迭代,交付周期一下变快了,之前是半年交付一次,现在是一周、两周,更有甚者,可能一两天我们就把功能发布出去了。商业模式下的需求上就产生了比较大的变化。小步快跑,快速试错。

需求变化了,我们的架构也发生了变化。CS的时候我们是单点的架构,后来慢慢转型到了SOA,现在云化我们做云服务的架构。第一轮敏捷升级,我们把业务部门和研发部门合到一起,在DevOps微服务转型的时候,我们把运营和运维合到一起,后续各个角色怎么关注质量会有专项去讲。

求变化了,架构变化了,团队也变了,导致了我们也遗留了很多债务。这个债务里面,我们整理了一下,测试方面大概有这么几类,这全部都是比较细的债务,大概分几类。第一类主要就是人、团队和个人、各个角色对测试的意识是不同的。比如说我们的全功能团队对开发很重视,因为我们必须要交付产品,但是对测试方面不重视,这是一个现状,就是这样的。所以测试人员自己也觉得我是否发展受到了瓶颈,没有办法再基于这个方向继续发展。测试人员最开始有些专项的能力,包括行动可靠性等等,我们会写一些自动化的脚本,会做一些自动化的能力,但是在基于转型的时候,我会面临一些自动化开发的工具,对接自动化平台,种种这些事情要求我们的测试人员做一些转型,要有一定的编程能力。开发人员本身第一是质量不足,第二是如果是白盒子用例我会写,但是黑盒子我不会写,这不是技能问题,就是意识问题,也有忽视了流程敏捷价值观,人的思想停留在老的思想,还是开发做开发的事。除了人的意识之外,刚才讲到了技能意识,还有流程意识,例如过度依赖黑盒子功能测试,我们流程里面对测试的保障就是依赖黑盒子,结果测试、前端的UI测试,到这里就行了。还有迭代速度很快,测试时间留得很少,所有工作量的评估就评估开发完的事情,没有评估从开发到测试,乃至上线的时间点。还有环境本身也有问题,我们测试环境部署时间比较长,测试人员在α、β生产各个节点上面做部署,然后做验证。部署耗费了很多时间,我很恼火,我还没有做事,版本就反反复复的测试。

我们再讲测试本身要做什么,就是测试最重要的是要做什么。这里有两个关键的焦点,第一,测试就是一个质量活动,我做测试就是要保证质量,这没有任何问题,还有其他人测试不是为了质量吗?应该不是,它本身就和质量绑在一起。第二是业务价值,就是我的这个是要围绕我的业务价值去做,而不是说一个测试上来之后,就把测试相关的关系点、关联点全部搞一遍,这里可以举很多例子,例如我做一个在线线上支付的功能,最关心的肯定是安全,所以我的用例关键点就围绕安全大做文章,一定把安全保证好。我要做一个线上商城要怎么办?我的面向用户是老百姓,要让我妈妈、婆婆会用,我要关注易用性。除此之外,什么双十一、双十二抢购,还要关注性能。有些人去做这些开源社区,开元框架关心什么呢?扩展性、兼容性这些。所以瞄准了我的产品本身的业务价值,产品到底要做什么,然后去做质量关键点,到底是基于性能还是基于安全发力,制订相关的测试策略,然后落地。落地之后还要基于一些不良的效果不断的做一些反馈、循环,去校验整体的测试,达到预期结果。这就是我们的测试焦点。

这是一个非常经典的图,大家从各个地方也见到过,我们一定要从源头保障质量。这个图可能女孩子看起来有一点害怕,这是我们的BUG,很形象,这个东西就是很讨厌。如果是在我们没有编码之前,在设计阶段就把这个BUG发现解决,那么它的成本是最低的,如果要是到了生态环境再发现,那么各个环节的投入比重是越来越高的。但是传统的测试一般会关心发现问题,例如黑盒子测试里面有哪些问题,不会关心有什么拦截手段,其实这里有一些实践。例如我怎么样通过质量管控来保障我在设计阶段、需求分析阶段就能够拦截一些问题,这都有一些实践。例如完整的用户需求的描述需求,我们的测试人员是从需求设计开始入手,写需求测试实际用例,还有一点比较重要,我们不仅仅是瞄准功能需求,这很好对齐,影响大家架构重构的很多是性能问题,为什么侯凡专题去讲性能?我们的性能在生产环境发现之后,大家是否想完了,这个东西上不去了,要改架构,成本非常高。所以我们早期就拉架构师做性能建模分析等等,这是比较重要的。还有所有质量的活动不应该做成专题,我开发就是开发,开发之后交给测试团队,反正他们会有专题保障。现在DevOps更强调是把质量测试过程给打散,放到开发每一个环节,让全员参与进来。当然,基于这个我们作到了各个环节自动化,否则大家都不愿意参与。这就是自动化最基本的要求。

接下来我们讲自动化本身。这个图是一个非常有名的自动化金字塔图,我们基于DevOps,金字塔上面还有一些解读,例如手工测试等等。这个金字塔本身就是每一个环节的自动化能力和投入,在最底层单元测试方面,我们要做得足够好,这个金字塔不代表我的测试用例的数量,例如我单元测试写一千个用例,我更关心单元测试的质量。例如我们有一个非常重要的模块,我要保证重要模块对应的复合率要达到,重要的用户进来的分支要达到分支的覆盖。所以基于这个,单元测试不是在用例的数量上,大家一定要关心它本身的质量。在金字塔越底层做的事情,发现问题解决成本越低。而越向上一层,解决成本越高,效率也会越低。例如在界面测试发现了问题,我的定位要从界面到网络、模块A、模块B等等,会拉很多工作人员做定位。如果在单元测试发现,就是模块本身的问题,这是比较容易理解的。里面所有基于代码、到单元测试、接口测试、界面测试、UI,还是强调自动化。做到什么结果呢?我提交一行代码,能够自动把整个测试流程走遍,我出去喝一杯咖啡之后,回来看到所有的测试结果在我眼前呈现。

接下来讲一下质量相关的点是常规安全与弹性安全,它与传统观点是一个冲击。我们常规的设想,是哪个地方不安全,我一定要把所有不安全的因素找出来,清除掉。这是我们常规的做法,也就是Safety-1的小天平,指针在绿色一边是安全,在红色一边不安全。第一个做法是把不安全的红色因素一一剔除,这是一种非常理想的方法,但实际上我们是不可能把整个系统中不安全的因子全部识别到的,有能力、架构等等复杂的原因,没有任何一个人能够说哪个地方不安全能够全部去除。所以演变出了弹性安全,就是我可能经过一些内部的折腾,反复的去把不安全的场景模拟出来,基于这种不安全场景,我们给出快速的修复方案,把它加入天平里面,如果不安全的因素进来了,我用快速应对的方案能够弥补这个不安全,对于用户来讲是不感知的,对产品来讲,它的商业目的和质量目的都可以达到,这就是我们想讲的弹性安全,即便发生了错误,能够及时快速的修复或者自己修复,达到正常工作的目的,我们也可以。所以我们在这往来有很多实践,但是这个弹性安全本身在业界有一个基于安全的实践,就是我们在搭的自己的服务的时候,有的时候会接受D-Dos攻击,一般是硬扛,能扛得住这个流量,如果达不到一个G,就可能被冲死了。现在不同,有攻击时,我直接把IP干掉,引流到新的IP。大家可能会想黑客会追随进入另外一个IP,这是有成本的的,需要10分钟的时间,结合我们的快速感知,感知到他是攻击的源头,立刻在我们这里做一些防护。你给后端人员足够的时间去准备,而你的前端又没有受到任何影响,因为我直接换了一个IP,客户可以访问,没有任何问题,这就是一个很好的实践。

接下来讲测试左移和测试右移。左移就是前移,我们有自己的测试人员和开发工程师做过白盒子用例和黑盒子用例。我们想的实践是尽量把活动向前移,也就是说突破黑盒子向前走一步,越走越好。例如BDD行为开发,我们基于这个场景直接设计出符合这个场景的用例,来匹配这个设计。契约测试本身,服务和为服务本身之间有耦合,我们可以通过契约测试解耦,以防导致问题。还有我们有一些自己的能力,来提前介入一些自测试活动。测试右移是指我们现在的测试只到了版本发布之前,测好之后出一个软件包,我们要把软件包布到生产,我们尽可能到线上运营,都要去做测试。这里也有一些实践,这个灰度测试是指在这个过程中,我们把需求特性布到线上,我们测完之后再给线上用户。还有线上拨测、主动线上监控,用户的一些行为轨迹里面发现的错误问题我们能够快速的捕捉到,主动推送给相关的责任人,让他去关注并且解决。所以线上的过程可以通过一些测试手段,不断的反馈给真正的开发人员,让他知道当前产品的整体表现,他就会快速的针对产品作出一些应对方案。

接下来我们讲一下不同时期的测试策略。刚才讲了这么多的测试活动,还讲了这么多自动化的活动,那么是否说这个团队进来的时候,哪怕一两个人,就要把整个自动化能力构建起来?其实这也是一个过程,我们先从软件的成熟周期来讲,后面会再从组织人员构成上面,我们看一下怎么构建测试自动化的能力。在软件初期探索阶段,我们的产品是一个不确定的产品,就是说它里面从前端的风格和整体的布局到后端的API都会有一些变化,而且变化比较频繁,这个时候一些自动化测试用例的写作是不太划算的,不经济的,因为你的自动化用例的生命周期比较短。而这个时间段产品的特点是小的产品,特性是可控制的,也就是那么几个测试,所以我们以手动为主,不考虑自动化,让产品能够快速识别错误点,让用户能用起来。就到了扩张阶段,用户认可我的产品,这时候有两个现象。第一是用户量指数增长,第二是我们接到的需求有呈指数量增长。这时候必须要考虑自动化。我每一次迭代的全量验证成本会越来越大,而交付的速度也会越来越快,这就是一个悖论。我们不可能每一轮上线的时候都做全部测试,这时候老的方面就需要用例去保证。所以我们引入了自动化测试能力。到提取阶段,产品已经到了需求的饱和期,产品的利益增长也到了饱和期,这时候要严格控制产品需求,可能会解决一些问题,这时候自动化用例的职责变成守护,不允许我的变动引入额外的风险点、大块的特性变动,对成熟的用户造成攻击。这是三个方向,每个不同的产品阶段有不同的测试策略。

接下来再讲一下整个团队规模对测试建设的影响。如果说我们的团队规模在5个人以下,节就是处于探索阶段,这时我们的质量活动可以仅仅局限于测试的自组织阶段,只是做一些基础类测试管理类活动,把缺陷管理起来,做一些回归。其实这部分主要是建立一个测试管理的流程和机制,并没有接触到自动化测试,因为人数在这里,团队规模在这里。随着项目的进一步扩大,有5-10人的团队规模,处于扩张阶段,这时测试工作量突然增加,可能会有专门的测试人员进来,这个测试人员就会去和开发人员进行串联,在这里做好,然后他把需求转化成自动化测试的用例,持续搭建集成,逐步演进一些测试手段。这个阶段已经开始做一些自动化的尝试,这是在自动化测试阶段。团队进一步增大,一个人可能搞不定工作量的时候,会招聘更多的测试人员,成立专门的测试团队,这个团队就从自动化测试转向测试自动化,把很多的管理工作做进来,*都会进行一些管理。在这个管理过程中,我们会做一些产品的对接,包括一些开发,实现一些自动化的整体能力,不仅仅是自动化执行了。

 经过上面几个演进周期之后,我们的测试团队具备了很多的测试自动化经验,这个时候我们面向云化的转型,大家很关心的就是基于DevOps的全功能团队,我们之前转型的这些人在做什么?回到微服务的架构本身,我们有运营产品,还有SL对应的SPE,很多角色、开发、运维在这里。刚刚原有10-15人的测试专项团队做什么?面临一个比较重要的转型,我们要把测试专项能力向服务化能力转型。这时候测试专员就会在团队建站初期进行赋能,包括测试工程师搭建,早期的测试用例怎么写,我们会有一些模板放在这里,你导入就可以。后面还有针对专项的,非功能性测试的专项,我们也会进行专项能力的赋能。还有对所有团队进行测试流程的评审,包括他自己的测试策略、测试计划、自己团队的测试用例,我们都会做一些评审,再看一下整个团队里面流程上还有哪些改进的,我们的整个专项测试团队就会向服务化进行转型。所以这里是一个全圆参与的过程,如果说我在2008年做的是半年发布一次或者两个月发布一次,或者每100天发布一次,可以有专门的团队,因为我有时间。但是在10天或者每天发布一个版本的时候,就要开发和设计一起去保证。但是如果每天发布10次、100次,就要把测试过程中所有的人参与的环节全部杜绝掉,做到自动化。

我们要讲一个理念,就是测试自动化。什么叫测试自动化?刚才讲了很多自动化测试,这是测试的执行部分,例如我们把一些测试执行的人工测试手段做成自动化测试,但是测试自动化不仅仅是只是执行,还包括了从环境的获取到生成测试数据、执行自动化测试,最终生成结果。如果有问题,我会自动推给相关的人,不是自己还要提个单给谁沟通,自动提单给对应的组织解决。自动生成测试报告,测试人员直接拿到测试结果。就是这样的过程。

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

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

这就是我们的测试不断前移的过程。这个材料主要是讲服务的团队,全功能团队会越来越多的介入到测试里面来,但是我们一些测试的专职的事情要足够做到服务化,这对我们现在的专职测试人员是有挑战的,我们以前做了很多专项活动,花费了大多的人力和成本,这些成本需要通过一些服务化的能力,我们要使用一些开源或者软件开发人员的能力,能够降低人力投入成本,能够实现自动化测试,那么我们全功能团队就可以用上了。还有性能测试、安全测试都可以慢慢向前面转移的,Chaos测试可以构造一些故障脚本,通过API方式向大家去。拨测也是一样的,做成7×24不断循环执行的过程。

讲了这么多,我做华为云的测试产品,最开始是对内部的,有很多的测试工具,做到一定程度之后,我们也积累了很多的测试经验。在这里,我们对外发布了一些我们认为比较好的实践所带来的工具,例如现在我们提供的,当前已经上线,包括DevCloud的云测和移动应用测试以及实现解决方案,能够很好的为大家创造便利性,解决问题。包括整体测试流程管理、测试的用例和需求、虚线能够双向可追溯,能够看到这个需求到底是否测试,或者是否测试错了。通过自动化的能力,例如对安卓和IOS的测试,拿一个软件包放在后台,对它进行系统化的兼容性测试,看是否有兼容性的问题,能够涵概多少用户,还有接口测试,能够涵盖接口一层的手段,还有性能测试,模拟一些大并发的场景。我们提供完全可视化的看板,能够提供测试执行的情况。

接下来都是我们的一些看板,例如这是我们的管理看板和对应的测试看板。APITest可以让开发人员投入写这种测试用例,而且是非语言类的,你可以通过鼠标加一些必要的参数进行编排,我们就能够通过这个接口把场景构造出来。如果我们的产品是微服务,可以把它导入进来,整个过程是非常简单通俗的。

性能测试也是围绕接口测试,但是会提供多种加压策略,能够是现在测试过程中我们能够对于用户的吞吐量、响应时间、负载能力,整体做一个结构分析。这就是刚才讲到的兼容测试,能够看到终端数安装是否失败,甚至一些问题失败的原因,包括系统截图等等,供大家进行问题追溯。

 

华为云DevCloud作为一站式云端DevOps平台,集成华为近30年研发实践和前沿理念,面向开发者提供研发工具服务,让软件开发简单高效。现支持5人以下额度范围内,可以免费使用,并且可以预约免费的产品演示和技术交流,详情查看华为云官网

发布了877 篇原创文章 · 获赞 5228 · 访问量 66万+
展开阅读全文

没有更多推荐了,返回首页

分享到微信朋友圈

×

扫一扫,手机浏览