职业经验 傲野:如果测试没有梦想,那跟咸鱼有什么区别?

Mars · May 18, 2020 · Last by Mars replied at May 21, 2020 · 2467 hits

前言

从社会发展上来说,各领域的分工越来越细。但从技术部门的发展上来看,测试和开发的角色却是在不断融合,背后的原因是什么?是互联网迭代的速度越来越快促成的多角色融合,还是因为技术(特别是质量技术)先进生产力在逐渐取代落后的生产力?

在回答这些问题之前,我们先来回顾“测试工程师”作为一个职能或者个体在过去的发展历程:

  • 10年前,最初级的测试产出工件是比较一次性的,比如项目中写的文本型测试用例,基本在项目发布后就废弃了。

  • 那个时期测试工作的进阶是方法论,比如能够把测试用例的设计方法,项目流程管理讲得头头是道已经是高阶了。

  • 有一些技术能力的测试同学,投身于自动化脚本的编写。自动化在“软件”测试时代和互联网初期,是真正的硬核能力。

但这样的测试模式和效率都是非常低的,显然无法支撑互联网无快不破的浪潮。2010年以后,在头部企业的测试团队发生了一系列的变革,快速地从上述的这些初级能力,扩大到以 CI/CD 为驱动的技术体系,并最终推动了测试技术产品化进程,形成一个较为清晰的测试平台发展脉络。

在这个将近十年的周期中,由于测试工具、平台的不断创新,测试团队得到了一个突破性的发展。但工具作为传统测试模式的辅助手段,仍然会遇到突破的瓶颈。比如,从全球来看质量也发生了一定的分支:

  • 一种是不断坚持平台化的发展路径:项目质量是基础,不断孵化出各类的效能平台,解决的问题也从传统的质量领域本身,往研发各环节拓展。有些大型的企业也开始沉淀了通用的研发协同平台(研发流水线)。

  • 一种是从内往外突破:比如 Google 的 SRE 团队,以纯技术的手段,打造一个内建且自洽的质量体系(传统以证伪为理论依据的是一个外建的质量体系)。[1]

这两者的方向和目标,是有一定的重合的,比如有些公司以测试负责线下,SRE 负责线上进行区分。但如果从质量这个大的目标来看,未来的成功画面应该是:“质量和效率的结合”和“外建与自洽的结合”。因为只有这样,才能打造一个真正完整的技术质量生态。

实时质量

也是基于上述的一些思考和实践,我们在2017年底提出了“实时质量”的概念。“它不是一个具体的测试技术产品,而是一种面向未来解决质量问题的方法和手段。”

它的主要特性是:运行含测试,实时可反馈。

为什么要往这个方向发展?

随着技术的不断创新和交付模式的不断改变,对于测试团队来说,需要尽快地从交付型质量往实时质量方向进行转移。传统的交付型质量,把测试作为一道道关卡,以任务的方式布防在开发提测、项目发布时。这种方式存在不同角色之间的过多交互,只能起到单点的质量保障。而实时质量的目标是:将质量手段以模块、组件乃至系统化的方式嵌入到业务型应用中,形成实时保障质量的能力。 未来开发和测试人员之间的合作(或者就不区分开发测试了),不仅仅是人与人之间的协同,更多是双方分别为完成“业务特性服务的代码”和为完成”业务质量服务的代码“而相互配合,并形成系统级的依赖关系。在提供的这些质量系统上,我们希望公司内部的各种角色都能成为质量的操作者。只在做到这些,我们才可能将测试工作真正从面向过程到面向对象。

图示:理想的测试工作方式

实时质量的架构

要做到质量的实时反馈和面向对象测试,这意味着我们的测试方法和协同方式发生了较为根本性的变化。我们需要以一个合适的方式参与到业务应用中,与此同时我们还需要把测试的各种能力封装成一个个服务,而不是现在的工具。工具终究是需要人来操作的,而我们希望未来测试任务的主体是机器、算法。测试人员只构建测试服务,而不参与测试过程,这也是最符合测试开发 Test Development Engineer 的 job design 。

图示:实时质量架构

那测试到底还需不需要做功能测试?可能在很长一段时间内仍然是需要的,但那一定只是日常工作中很小一部分。

实时质量是基于现有测试能力改造

我们在推进一个新的方向时,尽量不要去推翻重来。如果要面向未来,实时质量必须是可以向下兼容的,因为只是这样才能继承现有的测试沉淀,也才能被团队中的测试人员所接受和支持。只有自己不断进化才符合自然规律。所以我们需要更多强调对现有测试能力的改造,而避免另起炉灶。以下用运营页面测试的实时质量改造作为一个案例。

★ 案例:运营页面的实时质量改造

作为电商域的同学对于运营页面应该非常熟悉,在之前也非常痛恨。比如:

“CBU的一次大促,运营人员至少需要配置千级以上的活动页面,而每一个页面上又包含几百上千个商品等活动元素,平均一个页面需要5到10分钟的人肉检测,同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来,我们至少需要十几人/日的测试资源才能保证会场的正确性。”

这个过程很痛苦,运营人员需要不断去找对应的测试同学协同,幸福感很差。而测试人员来说,这些页面的测试更多是一个重复劳动,一个黑盒。能力也得不到什么成长。我们如何对它来进行实时质量的改造呢?

总共分两步:

  1. 我们对传统的测试体系进行了改造。把以往通过人工测试的各个测试点,通过自动化的方式来实现。比如基于 DOM 树制定一系列规则,例如403这些的错误都可以被很好地扫描出来。同时,针对于一些无法通过规则排查的问题,我们运用了算法能力。例如空坑检测,一致性检测等。

  2. 把以上测试组件,通过消息的方式跟运营页面发布系统对接。

它的系统依赖关系是如下的:

图示:运营页面检测系统依赖图【示意】

同时针对于不同的业务场景,我们开发了不同的页面检测能力,比如针对于 DOM 树的页面检查:

还有基于算法能力的识别能力:

通过上述的改造后,对于运营人员发布页面以及页面的测试就极简化为三步一站式的能力。从以往运营、测试、开发之间的来回交接,变成了运营跟系统之间的交互。不仅提升了运营人员的页面搭建体验,也极大地提升了测试的效率。

在某次运行中活动中实际的执行结果【示意图】:

以上的过程和结果数据,也充分体现了“运行含测试,实时可反馈”的价值。

数据和算法是实时质量的核心

测试出现以来,我们一直习惯于代码逻辑类的测试,但数据一直都是测试很重要的生产材料。因为人肉执行任务的局限性,我们发明了等价类和边界值等测试理论和方法来用尽可能少的成本来尽可能多的验证问题。但一方面算法的不断应用,每一个数据都可能存在个性化的业务表达,我们可能无法找到一个通用的预期结果较验(还是会有一些通用的预期结果的,比如非空判断和区间等,但这类的预期不能很好地做业务判断)。因此,我们也需要用数据和算法能力来武装自己。

在以数据驱动的业务发展进程中,我们的测试主体已经从简单的代码转变为数据+算法。或者说,业务对质量的核心述求,已经从简单的页面错误、代码 BUG 到数据的准确性、算法的有效性(我老板在每次大促前,都要再三叮嘱我数据不能错)。如何来感知质量风险,以及捕获各类的异常?那必须先把数据、流量、监控来做收口,同时提升测试工具在大数据分析上的能力。

基于这些思考,我们构建了全域实时数据校验能力,是一款通过实时获取线上 DB 中的海量业务数据,完成业务数据校验、质量风险感知的产品。

★ 案例:Captain 全域实时数据校验

图示:数据对比框架【示意】

它具备的一些能力:

  1. 严格的安全策略。

  2. 实时获取线上数据:通过强大的数据支持能力,平台可以在无损线上数据库表的前提下,通过 SQL 查询获取线上 DB 中的真实业务数据,且做到了实时获取,通过数据可以进行完善健壮的数据校验,从根本上提高对于业务的把控。

  3. 多样的数据获取方式:目前平台支持多种数据获取方式:单库单表查询、单库多表联表查询、分库分表查询、跨库的多表的联表查询。

  4. 多种比对方式支持,比如跨库查询和联表查询等等。

最主要,它可以用一套脚本无损地支持测试环境、灰度、生产环境等。让线下测试的所有经验可以得到复用和沉淀。(我们内部调侃说,这才是带着测试的灵魂的,而其他的很多产品都只是一个面向开发的工具)

在前期解决数据一致性,对账等常用的基本需求上,我们可以依赖于这些数据和测试的服务,展开更多的业务形态。

实时质量需要不断突破测试的边界

★ 测试的边界在哪里?

过去有人告诉我,不能去修改业务应用的代码,只能让在盒子外面或者调用的方式来测试。还有人说,我们只开发工具,不能接触任何的业务。现在这些都在逐渐模糊,大家努力一起,让测试的很多活动,从简单的功能测试,往研发工具和业务质量等或前或后地迁移。

在过去的一两年,我们团队也已经慢慢承接了更多的职责,有些甚至于是直接服务于客服、运营和产品人员的。我认为,一支强的团队一定是不断走在突破原来工作边界的道路上。没有什么是一成不变的。

但每个职能团队都是有自己的核心价值的,而至于哪些应该由测试来做,哪些由开发做。我们的标准是:判断这件事情是更为了“让技术更有品质”还是“让技术创造新商业”?(“让技术更有品质”是我们团队的使命,“让技术拓展业务边界”是开发团队的目标)

以下虽然是几年前的例子,但也很好的体现了我们在边界的突破,以及如何用实时质量的思想来开装自己,创造提交 BUG 以外更多的价值。

★ 案例:Offer 360提升客服端实时质量能力

商品链路复杂,线上问题排查难度大,之前开发每天平均投入2-3个小时处理线上问题,但实际上大部分的问题都是正常业务逻辑,并且可以让客满或者技术支持自助查询的。因此,我们通过提供实时查询错误日志以及 debug 信息的服务,把用户反馈问题的排查,开放给客服。帮助他们第一时间解决用户的问题。

实时质量未来规划

实时质量是一种思想,我觉得它未来是可以跨越在当前两种不同的发展分支上的。

测试这么多年来一直被弱化,我也看到集团很多优秀的测试 leader 转型开发、产品。如果我们还不多些思考,多些探索。如果做测试都还没有梦想,那跟咸鱼有什么区别?

图示:测试未来的发展

后记

上周在内部的论坛上看到一个开发专家的留言,还是挺有感触的。我们一直以来都在强调测试能力不断演进,强调开发能力,但测试的初心不能丢。我们在工具、测试能力上不断改进,但是从人和组织的角度上来看,在追求最高效的同时,我们是需要一定的组织设计来形成岗位间的相互监督。这也是在测试1.0阶段开始,测试被赋予的一种职责。

“在阿里这几年的感受是,开发做的事越来越多,设计、测试、运维、交付等工作都由开发来做。导致岗位间的互相监督制约不够;一个萝卜一个坑,一个坑一般只有一个萝卜,导致同应用同岗位之间的交流、协作不多。岗位中传帮带,互相 review 机制不够;开发压力重,为了拿业务目标,在没有监督制约的环境下,很多基础事情的优先级被放低。因此,建议不要迷信系统的监督,系统有覆盖不到的地方,有过时的地方,有能绕过去的地方。不要放弃岗位间的监督,几十年的软件工程发展出各个岗位,有其自身的价值和门槛,一味的赋能开放,最后会变成什么都不精。至少测试、开发两个岗位要分离。”
阿里内部论坛

做测试总还是要有点梦想的,如果对我们做的事情有兴趣。

欢迎加入我们: batu.hjj@alibaba-inc.com
微信:http_home

共收到 25 条回复 时间 点赞
1Floor has been deleted

前排坐下研读。

比较好奇运行含测试,实时可反馈,啥时能解决?比如金融口

可能跟咸鱼没区别吧,但是咸鱼也是一种生活方式啊,你这说的咸鱼是一种不好的东西一样

有两个问题想问一下:
运营页面的实时质量改造这个例子,是会把测试服务和业务服务部署在一起, 当运营配置了页面的时候, 自动触发测试服务进行检测吗?
如果是这样的话, 如何保证不对原有的业务造成影响?

在阿里这几年的感受是,开发做的事越来越多,设计、测试、运维、交付等工作都由开发来做。导致岗位间的互相监督制约不够;一个萝卜一个坑,一个坑一般只有一个萝卜,导致同应用同岗位之间的交流、协作不多。岗位中传帮带,互相 review 机制不够;开发压力重,为了拿业务目标,在没有监督制约的环境下,很多基础事情的优先级被放低。因此,建议不要迷信系统的监督,系统有覆盖不到的地方,有过时的地方,有能绕过去的地方。不要放弃岗位间的监督,几十年的软件工程发展出各个岗位,有其自身的价值和门槛,一味的赋能开放,最后会变成什么都不精。至少测试、开发两个岗位要分离。

恒温 回复

是你在内网发的?

先留言,稍后再看,高大上的东西!!

simple 回复

不是啊,这个是傲野的文章呀

开源就是程序员内卷的开始.
越开源用的越多,越稳定,架构越成熟,程序员就越是工具人.
当开发成本降低,发现质量问题效益降低,岗位融合很难避免,
其实大厂还好了,毕竟质量要求高,有一定的门槛.
不知道如何破局,现在我这是内卷最重的技术方向,应该没有之一...

magicyang 回复

很多所谓破局或者创新,就是内卷玩法

Mars #12 · May 19, 2020 作者
Ouroboros 回复

现在已经实现了一部分。

Mars #13 · May 19, 2020 作者
Linus Ling 回复

不需要部署在一起,可以通过MQ来做变更关联。

Mars #14 · May 19, 2020 作者
恒温 回复

存在即合理。

Mars #15 · May 19, 2020 作者
magicyang 回复

万事总有两面性,商业系统对质量的要求不会降低,质量问题会带来故障、资损、舆情,都不是商业公司能接受的。

恒温 回复

看你们的聊天,我还需要查字典,第一次知道内卷,读书少还是不行啊

那测试到底还需不需要做功能测试?可能在很长一段时间内仍然是需要的,但那一定只是日常工作中很小一部分。
不评论了,学习了。

Mars #18 · May 19, 2020 作者
zyanycall 回复

功能测试还是需要的,但方向是无人值守,更多的通过技术手段解决问题,对于测新也是有技术的探索,比如智能化、组件化的测试。

Mars 回复

感谢分享,我主要是对实时质量的有效性理解有点疑惑。
假设一种极端情况,我们就用实时质量来评估是否具备上线条件,不做任何其他测试。
如果运行一段时间没有问题,那么我们什么时候能得到可以上线的结论呢?
感觉实时质量是测试的补充,采集到一些正向的常见的用户行为,并能把海量的业务数据当用例库积累,但是还得解决如何反馈更深层次或者更恶意的行为带来的问题

这东西写的都很好,但是可能一看代码就把人吓死。就像alimama前面开源的一个什么智能引擎。这东西有点不明白的就是运营上传一个文件不能预览一下吗?这么费劲搞了一大堆,都不知道面对的具体问题到底什么

CBU的一次大促,运营人员至少需要配置千级以上的活动页面,而每一个页面上又包含几百上千个商品等活动元素,平均一个页面需要510分钟的人肉检测,同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来,我们至少需要十几人/日的测试资源才能保证会场的正确性。”

这种东西到底是产品问题还是测试问题?实在是很难说。

另外这个架构要是追查什么实时质量数据能扛住,那是见鬼了。阿里一天的数据量要这个结构能扛住,我觉得有点不可思议。

CBU的一次大促,运营人员至少需要配置千级以上的活动页面,而每一个页面上又包含几百上千个商品等活动元素,平均一个页面需要510分钟的人肉检测,同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来,我们至少需要十几人/日的测试资源才能保证会场的正确性。”

说实话不太明白为什么运营人员要和测试人员不断测试标准和Bug来回讨论,测试要是花10多天检查会场页面的显示的正确性,其实测试人员也很贵的。如果运营人员不够,没有办法支撑大型活动,那么要么产品还有很大改善空间(或者确实有很大难点不好突破,或者其实就是短期就是没办法突破了),要么就是通过流程,在短时间内增加外包人员。 但是和测试有多大关系?不过本人呆过的大部分公司其实也都是这样,缺人的时候就找测试帮忙。

大致看完了,感谢分享。实时质量这个概念是挺不错的,把质量手段嵌入到业务应用中。但有个比较重要的点,这些质量手段谁来应用,谁来负责?

文中提了不少例子,基本上是属于“赋能”,即原来其他方做不了或者不想做,给测试同学做的重复性的活,经过赋能让他们也能做,由他们直接判定结果是否符合预期,释放测试资源和负担。但这也会带来一个问题,那就是如果他们没做好(毕竟他们的核心职责不是质量),就没人能兜底了。

个人觉得,对于证实类的工作(确认一个功能是否和需要的一致),确实可以交给其他人做,毕竟这个应该是一个项目所有角色的共识,并不复杂,出问题也非常明显,只要有责任心,一般不至于遗漏到生产上。但对于证伪性的工作(探索这个功能在各种特殊情况异常情况下的表现,是否合理),或者证实特别困难的工作(比如场景组合特别多,比较难考虑周全),个人认为这是测试最核心的领域(测试设计),也是测试的价值。

只是互联网的节奏,对非核心故障容忍度比较高,所以基本上大部分证伪性工作都会放到线上灰度来做,小流量时发现了修复就好,所以好像逐渐也就变成测试最能产出的事情是赋能了,赋能开发进行自测,赋能产品进行验收,赋能业务和运维进行各种数据统计监控,发现问题。

只是一点感慨,目前也没想到特别好的方式破局,只能一步一个脚印,把证伪变为证实(吸取教训,把意外情况变为意料之中,成为需求的一部分纳入考虑和验证),把质量变为大家都认可并愿意花精力去保障的事。

Mars #23 · May 21, 2020 作者
Ouroboros 回复

实时质量的方向是通过无人值守来进行测试,至于可上线的结论,需要根据覆盖率来进行判定,覆盖率又分为很多种,比如代码覆盖率、故障覆盖率、业务覆盖率,实时质量对用例执行的实时性也是有要求的,需要快速+可反馈。

Mars #24 · May 21, 2020 作者
simonpatrick 回复

几乎没有工具可以解决全阿里的问题,这里的描述也是解决CBU大促的问题,是一种提效的质量保证方案。

Mars #25 · May 21, 2020 作者
simonpatrick 回复

产品的全方位质量是测试来保障的,比如出现了会场页面的空坑、空楼层、链接不可跳转等,测试都是需要负责的,测试开发就是要通过技术手段解决各种质量问题。

Mars #26 · May 21, 2020 作者
陈恒捷 回复

测试追求的好结果是没有故障、没有资损,测试开发就是要通过技术手段解决质量问题,好的工具可以自动测试,让开发自测,让运营自测,目前我们这边的测试开发比例是1:8,赋能是一种好的方式,即解决了业务质量问题,对测试人员的技术又能有一定的提升,何乐而不为呢。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up