SAP成都研究院姚瑶:软件质量保证工作的变迁

眉间皱痕 提交于 2020-02-05 03:15:58

大家好,我是来自SAP成都研究院Revenue Cloud 团队的质量工程师 , yoyo。很高兴可以和大家分享我个人的工作体会。每个团队都有QE(Quality Engineer), 相信大家对QE 的工作并不陌生,我也就不唠叨QE 的具体工作啦。作为从事软件质量保证工作十年的“老人”,我想就我个人的工作经历和大家探讨下软件质量保证工作的变迁。

当我们谈论软件产品的质量保证工作时,必然是基于某种软件开发模式上的。皮之不存,毛将焉附?脱离了软件开发模式,质量保证工作就是空中楼阁。相信大家都感受到,近十几年,软件开发模式不断涌现新的概念和词汇,Agile, Continuous Integration , Continuous Delivery, DevOps ,令人应接不暇。我们首先要理解软件开发模式的变迁,然后才能进行与开发模式匹配的质量保证活动。

1. 瀑布开发

传统的瀑布模式如下图:

在这种模式下,测试活动仅仅是线性开发活动的后期活动。质量保证严格依赖于各个文档(需求文档,设计文档,测试计划和测试报告)以及评审会议,自动化测试可有可无。

2.增量开发

团队把产品的需求,设计,实现以及测试放在若干迭代周期里完成,每个迭代结束的交付物视为产品的增量,不要求增量达到能交付的要求,但需要能够基本可以工作。产品的交付仍然发生在最后,如下图所示:

增量开发的核心就是持续测试和持续集成。对质量保证工作来说,分为了两类活动。 一是迭代中对增量的质量保证,二是发布前对整个产品的质量保证。由于增量和产品最终交付的要求是不一样的,所以通常在软件发布前团队要停止功能开发,进行全方位的回归测试和缺陷修复,从而保证产品质量达到交付要求。增量开发的优点很明显:

  • 测试的计划,执行,评估不仅仅是基于每一个发布版本,而是细化到每一个迭代中。产品的质量在开发过程中进行了频繁的校验,质量的可见性更高,反馈更及时。
  • 过程的质量更多的被考虑在了质量管理范畴中。质量管理人员深入到项目过程中,能观察到团队的整体运行情况,从一些实际质量现象和数据上反馈团队存在的问题,从而帮助团队识别风险,并相应调整开发和测试策略。

3.敏捷开发

实际上,运行的很好的增量开发已经具备了敏捷开发的雏形,它们都具有以下特点:

  • 强调短时间的迭代
  • 必须实现持续测试和持续集成
  • 能响应频繁的需求变化。

那什么是敏捷开发?它的核心又是什么呢? 如下图所示,相对于“非敏捷”,敏捷开发在Continues Integration(CI)的基础上强调Continuous Delivery(CD),每个迭代的产出物要达到可交付质量要求,它的核心就是把发布(到客户的生产环境)也纳入到短时间的迭代中。

成都Revenue Cloud团队从2016年项目一开始就明确定义了这个方向,我们要一步步地实现真正的Continuous Delivery。负责Infrastructure 的德国同事们做了很多工作,搭建了支持持续交付的完整框架,包括持续集成,构建管理,配置管理,发布管理,我们称之为DWC(Dev With Confidence), 有兴趣的同事可以咨询我们组的Andy Ma和Vicky Chen 同学。

那么在这样的开发模式下,我们要怎样进行质量保证工作呢?以下是我个人的粗浅见解:

第一,团队的目标是交付。

随时随地,各种形式,各种方式,无所不用其极地强调我们的目标是交付。 当我们说某一个功能是不是完成,那一定是指这个功能是不是良好运行在产品环境(而不是本地或测试环境),并满足定义好的质量要求(功能,性能,安全性等等)。

第二,全员对质量负责,质量保证活动是日常开发活动的一部分。

当产品只有长周期,大版本的交付时,在日常工作中我们容易会把某些任务,特别是质量保证任务放到后期进行,质量债务趁虚而入。而如果实现的增量要快速交付,我们就不得不把质量保证任务融入到日常开发活动中。开发人员, QE, 产品经理以及团队的所有人都要进行相应的质量保证活动,让缺陷无处遁形。

怎样落实呢? 那就是定义我们的Quality Strategy 了, 保障每个角色(who)都清楚知道自己应该在什么时候(when),什么环境(where)下如何进行(how)什么样(what)的质量保证活动。建议团队可以有一张图来指导大家。 这是Revenue Cloud 成都团队的质量保证活动的Overview Picture(出于安全考虑,landscape 被我打上马赛克啦)。

而Quality Strategy 绝对不是一成不变的,需求在变化,产品在变化,团队在变化,质量保证活动也应该随之变化。每运行一段时间,我们要收集反馈,无论是外部质量的反馈(比如来自产品团队的反馈,客户报告的缺陷或需求),还是内部质量的反馈,比如需求是否清晰,测试案例是否valuable, 代码质量是否足够好,自动化ROI(Return oInvestment)是否可接受,等等。根据这些反馈,我们再来改进质量策略。

第三,预防缺陷

测试是一种基于后验的质量保证方法。另一个更为重要的先验方法,就是缺陷预防。也就是说在开发人员提交测试前预防缺陷的产生,包括:

  1. 在开发人员实现代码前,尽量确保需求清晰,Accept Criteria 和自测点清晰。
  2. 在产品功能实现过程中,开发人员, 产品经理, QE,UX ,UA密切沟通,确保需求,实现和测试点的正确性和全面性。大家都坐在一个办公室里面,不管是Daily Meeting还是直接面对面, 沟通是很容易的,关键在于大家有没这个意识和习惯。
  3. 在开发人员代码提交(从自己的分支提交代码到主线)前,除了通过所有的自动化回归测试,还需要按自测点来验证实现的新功能。在这点上,我们需要思考怎样帮助里开发人员更好更有效的做自测。比如,自测点Scope是否合适?是不是有些重要场景没覆盖或者场景定义太多?开发人员是否需要培养测试思维或方法?Planning时候是否没有预估自测时间?开发人员自测是否得到了产品经理/QE及时和正确的反馈?

第四,实施策略性的自动化测试

当我们的发布周期很长时,可能觉得自动化测试可有可无,作用也不是那么明显,但随着发布周期越来越短,自动化测试的重要性越来越明显。在Revenue Cloud ,我们除了季度的大版本发布,还有更短周期的feature发布,以及每天的patch发布。可以说,自动化测试是不可动摇的根本。然而实现自动化测试,必然有很多因素要考虑。谁来做?选什么工具?哪些测试被自动化?各个层面的自动化怎么组合?这个策略需要团队自己决定,尝试和改进,毕竟适合的才是最好的。但我认为有几点原则是共性的:

  1. 自动化测试绝不是QE 一个人的事情。自动化测试和功能实现一样,应该是整个团队的任务,和功能backlog一样,包括QE和开发人员在内的所有团队人员都可以领取自动化测试的任务 。测试代码也应和功能代码一样对待,要进行代码审查,以及代码维护。不要舍不得让资深的人员参与自动化测试,良好可靠的自动化测试终会让团队受益。
  2. 自动化测试的有效性比完备性更重要。如果自动化测试的“假失效”和“假通过”太高,对团队来说不仅没有帮助,反而是一种干扰。要保证测试的有效性,除了保障测试脚本实现的质量外,还有很重要的一点,不要放过自动化测试的每一个fail, 要分析清楚fail的原因,是产品实现层面的缺陷就改实现,是测试脚本的问题就改脚本,是环境问题就优化环境。如果以自动化测试不稳定为理由,不去深入分析,那它永远都不稳定,自动化测试结果也永远得不到信赖。
  3. 我们团队在刚开始做E2E(End-to-End)自动化测试时,测试总是不够稳定,但经过一段时间的结果监控,我们逐步总结并优化了遇到的一些常见问题 :比如测试数据之间有依赖或冲突,identify UI 元素的ID不唯一,断言不准确,测试前置条件被其他自动或手动测试破坏,UI新的调整或实现导致测试失效等等。经过团队一段时间的努力,现在E2E测试的有效性大大提高了,团队所有成员都认可自动化测试的反馈。分析和优化的过程可能是痛苦的,甚至让你怀疑投入是否值得。但坚持下来,当自动化测试有效性得到保证时候,你会感受到它带给你的安全感。
  4. 多层面的自动化测试要综合考虑。自动化测试是多个层面的,在Revenue Cloud ,以功能测试为例,测试可以分为Unit Test, Integration Test, Contract Test, E2E Test。如下图所示:

我们既要避免某个层面测试薄弱,也要避免在多个层面进行重复的自动化测试。以成都团队为例,在开始的一两个release, 我们对Service Unit Test 的要求是覆盖率>80%, Service Integration Test 大致是覆盖60%的API测试用例, 然后E2E GUI Test覆盖核心业务场景, UI 的Integration Test并没有引入。后来随着项目的进行,我们发现API Integration Test 投入产出比最高。它比Unit Test 更接近service 真实行为,它比E2E GUI Test反馈更早更快,也更易实现。我们逐渐调整了策略,减少了Unit Test 的比重, 加大了Integration Test 的覆盖,目前我们API 的Integration Test 覆盖了>80%的测试用例。

再后来,随着产品功能的增加,我们发现E2E GUI 测试运行越来越慢,于是我们又再次调整了策略,一是引入是OPA5的UI Integration Test,把原来E2E GUI测试中纯UI 的逻辑完全挪到OPA5测试中,大大缩短了自动化测试的运行时间。二是减少了部分和Service Integration Test 的重复测试,使E2E GUI 测试更多的侧重于端到端完整的业务场景,而不仅仅是某个具体功能。 通过这两次调整,多层面的自动化测试能更高效的分工合作,为产品质量保驾护航。

以上三点是我认为定义自动化测试策略的重要原则。另外,我经常被问到一个问题: 你们项目采用什么自动化测试框架/工具呢? 在谈到多层面自动化测试的时候,我列出了Revenue Cloud 采用的自动化测试工具。对于Unit Test, Contract Test, Integration test 这些和技术平台/语言相关的测试,我们采用的测试工具并没有什么” 惊喜” 。Junit,Spring Contract Cloud, OPA5, Rest-Assured 都是大家耳熟能详的测试框架,在SAP 类似技术背景的项目中广泛应用着。我重点介绍下可能大家比较陌生的Nightwatch + SauceLabs 的E2E 测试方案吧。

SauceLabs 是一个云测试服务平台,在云上提供VMs运行多个测试,并提供了视频录制,截图和日志记录功能,很好地解决了多个自动化测试并行运行的设备问题。并且它支持不同浏览器,不同屏幕分辨率,可以应用到浏览器兼容性测试中。当然,这个是商业服务,申请的VM 越多,价格越贵。

Nightwatch(守夜人),这是一个使用Selenium 2 (webdriver)实现的开源E2E 测试框架,对Selenium API 做了些封装,能更容易和简洁的实现测试脚本,但它不支持UI 操作录制。其实本质上,它和Selenium, Ranorex, Start 等工具没什么实质不同。就像江湖高手会根据自己的喜好、功夫的特点选择武器,我们也可以根据团队的技术特点和偏好,当然还有预算来选择工具。然而工具只是工具,就像决定比武结果的决定因素并不是武器一样,决定自动化实施成功的关键因素,从来不是工具,而在于我们自己的功夫修为本身。

第五, QE的角色定位。Revenue Cloud 成都团队从2016年建立,也曾经回归缺陷 比比皆是,也曾经有提交测试的功能连Smoke Test(冒烟测试)都跑不过。那段时间,QE其实很忙碌的,有各种测试要做,各种缺陷要回归测试,而且产品发版前还紧张的不行。但到现在,团队越来越成熟,质量意识越来越好,开发人员提交测试的backlog 一次通过率基本维持在80%左右。在整个项目交叉测试时候,其他组给我们提的缺陷越来越稀少,团队的交付越来越顺畅,而我作为QE, 不再淹没在基础测试中,可以有更多的时间做更有价值的事情。我也在团队的需求和帮助下,学习了自动化测试框架, 研究了SAP产品标准的Performance, Accessibility, GDPR 以及Fiori Guideline 等等,拓展了自身的技术领域。

因此,我最后特别想和大家分享的一点是QE 的角色定位。QE 不是充当警察的角色,站在大家对立面挑刺。QE也不是最后的质量安全防线,站在大家身后填坑救火。QE是和大家一起并肩战斗的战友。一方面,QE充当着质量教练,引导和帮助团队提升质量,建立成熟的质量文化。另一方面,和Agile团队的每一位成员一样,QE也需要在团队中不断学习和成长,不仅仅是加强QE技能,还要加强对业务的理解,对用户行为的认知, 甚至对具体实现技术的认识。

最后感谢大家阅读。关于SAP Revenue Cloud产品本身的更多介绍,请参考SAP官网:https://cx.sap.com/en/products/billing/revenue-cloud

更多阅读

  • SAP成都研究院DevOps那些事
  • 金庸和古龙,Netweaver和微服务,以及SAP Hybris Revenue Cloud

要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!