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

大家好,我是来自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的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏新智元

微软开源图数据查询语言LIKQ,海量图数据实时检索和集成触手可得

【新智元导读】 微软开源图数据查询语言 LIKQ,这是基于分布式大规模图数据处理引擎 Graph Engine 的一种可用于子图和路径查询的数据查询语言,强强联...

446100
来自专栏IT大咖说

天天写业务代码,如何成为技术大牛!

不管是开发、测试、运维,每个技术人员心理多多少少都有一个成为技术大牛的梦,毕竟“梦想总是要有的,万一实现了呢”!正是对技术梦的追求,促使我们不断地努力和提升自己...

14930
来自专栏微信公众号:Java团长

如何在面试中介绍自己的项目经验?

在面试时,经过寒暄后,一般面试官会让介绍项目经验 。常见的问法是,说下你最近的(或最拿得出手的)一个项目。

12930
来自专栏java一日一条

阿里面试回来,想和Java程序员谈一谈

其实本来真的没打算写这篇文章,主要是LZ得记忆力不是很好,不像一些记忆力强的人,面试完以后,几乎能把自己和面试官的对话都给记下来。LZ自己当初面试完以后,除了记...

21630
来自专栏全栈工程师成长之路

浅谈iOS进阶路线

560120
来自专栏Java架构

微服务是传统企业电商解决方案的银弹吗?成功实施微服务的先决条件挑战和风险业务方面的思考演进路线结论

18630
来自专栏CSDN技术头条

Get 技术领域最新趋势!

ThoughtWorks 每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由 ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以...

12930
来自专栏Java技术栈

面试时如何介绍自己的项目经验?

在面试时,经过寒暄后,一般面试官会让介绍项目经验 。常见的问法是,说下你最近的(或最拿得出手的)一个项目。

40130
来自专栏WeTest质量开放平台团队的专栏

鲜科技!内部云游戏沙龙分享

云游戏,也叫订制游戏,是在线游戏的一种不只是网页游戏或者是微端游戏,是一种游戏输入,运算,和画面显示分离的技术。目前有2种主要的云游戏形式:基于视频串流的云游戏...

75570
来自专栏PPV课数据科学社区

大数据可视化、实时性分析的工具——Datawatch

编者注:互联网后时代,我们谈的最多的不是电脑,而是基于互联网产生的伟大的互联网公司,比如谷歌、微软、百度、阿里巴巴等;移动互联网后时代,我们谈的更多的不是手机,...

697100

扫码关注云+社区

领取腾讯云代金券