写点什么

软件测试行业悲观走冷,“让天下没有难做的工程效能”是否一支强心剂

  • 2016-07-14
  • 本文字数:4044 字

    阅读完需:约 13 分钟

随着互联网的电商、金融等公司蓬勃发展,这些公司的技术团队的规模也快速增长到了数百人,应用规模快速扩大,测试环境日益复杂,测试力量依然薄弱,应用验证成本不断提升。与此同时,由于充分的市场化竞争,产品的开发速度依然要求像过去十几人的小团队那样快速迭代,同时还要保证更高的质量要求。传统的项目集成及交付软件已经不能满足需求,工程的效能提升和质量保证上迫切需要平台来支撑技术和业务的快速发展。

针对目前现状,我们邀请章屹老师、阿里巴巴高级技术专家、测试架构师,发表了他自己的独到见解,希望读者朋友可以从中受益。

InfoQ:能否讲讲国内软件测试行业的现状如何?有什么独到见解?

章屹:我接触软件测试行业通常通过两个途径。一个是软件测试行业会议或论坛。二是云效上云后在各个企业用户落地中遇到的同行。这些朋友来自互联网企业或者传统行业。

软件测试行业在微软时代有过一个顶峰。顶峰到什么程度呢?那个时候甚至听到过硕士做开发、博士做测试的说法。微软时代,测试讲的是测试分析、测试的思维逻辑严谨性。往后发展,前几年在 Google 的带领下测试行业又出现了一个新的高峰,测试技术和测试工具成为了这个时期的主要热点。

但据我观察,近两三年,软件测试行业再次由热转冷。你会看到近几年的主流测试行业会议分享的测试工具和技术渐渐少了,更多的是探讨一些具体到点的测试新方法的尝试,很少出现具备普适性的测试工具和技术。甚至在很多公开场合听到了对测试未来的悲观言论。这是一个很有意思的现象。你会发现从事测试工具开发的同事也比过去少了,各个软件企业从事自动化测试的热情也比过去要少。

为什么会出现这种现象,在我看来有两点原因。

第一,业界只看到了自动化测试减少了回归测试中的部分成本,但没有体会到(除了我们之外)自动化测试对持续集成持续交付中的重大作用。自动化测试的价值受到质疑,使得从事研发测试工具开发的团队受到普遍的挑战。连带着各项测试技术受到挑战,使得业内流向这个领域的人才越来越少。

第二,过去在电信或硬件行业做测试,你需要丰富的通信理论或硬件理论和经验。测试的技术门槛较高,测试的手工操作背后包含了足够的技术背景,不会有人质疑这些行业的测试的价值。但在互联网快速发展后,技术的入门门槛越来越低,似乎只需要了解贴近自身生活的的互联网业务场景就可以进行业务测试。

在这样的背景下,我们更为迫切地需要把成功的、普遍适用的研发测试工具,持续集成持续交付平台及相关理念经验,更快地在业内传播,希望成功的星星之火可以燎原。

InfoQ:国内有经验的、专业的测试工程师就不多,更何况是技术精湛的测试架构师。目前国内的测试架构师的定位是否清晰?还是仅仅只是一个 title?与国外的测试架构师的距离还有多远?

章屹:对测试架构师的定位在阿里巴巴 B2B 来说还是很清晰的,用技术的手段解决领域级别的研发效能和质量问题,并沉淀出通用的方案或工具,是对测试架构师的要求。

但这也对测试架构师提出了很高的要求。很多质量和效能的问题往往需要跨技术域才能找到最佳的技术解决方案,所以好的测试架构师首先要有一个广阔的知识域

同时他在解决问题时需要快速深入技术问题细节并很好的处理,这对技术深度和学习能力也提出了很高的要求。

不仅如此,和开发架构师一样面临业务及产品挑战的同时,测试架构师还面临着质量和效率,质量和效率离不开人,所以我们看到好的测试架构师往往有很好的沟通协调能力

以这些要求看,对国内的测试架构师的要求并不亚于国外的测试架构师。此外,测试架构师的职责也在延伸,除测试和研发的质量效能外,我们可以看到在容灾、容量评估、安全等领域都有不错的测试架构师成长出来。

InfoQ:对于任何一个软件开发人员来说,架构师都是一个令人向往的角色。就连比尔盖茨在 2000 年卸任公司 CEO 的同时,也担任了微软公司的荣誉角色“首席软件架构师”。测试架构师与架构师有什么异同点?测试架构师的成长之路有什么特别之处?测试架构师需要哪些特别的能力?

章屹:测试架构师和开发架构师有共性,都具备业务架构能力的理解和规划,但两者的差异也不小。简单而言,开发架构师专注于支持业务的技术,比如大容量、大并发带来的技术挑战。而测试架构师更专注于工程效能和质量。

从 B2B 的测试架构师的成长来看,测试架构师往往分为两类,业务测试架构师和技术测试架构师。业务测试架构师更注重可测性,并且会在自己域内使用现有研发测试工具或少量二次开发来解决质量和效率问题。技术测试架构师一方面负责研发测试工具平台的建设,另一方面会找到各个域共性的质量和效率的难点问题,用工具化平台化的方式去解决。

InfoQ:阿里云效平台在改名之前支撑着 Alibaba.com 和 Aliexpress.com 网站内部,真正实现持续集成持续交付。是基于什么原因和目的将云效对外开放?

章屹:云效平台和阿里的其他上云的产品一样,都是长期服务阿里自身的业务发展而产生出来的,经历了阿里的业务本身的各种考验。也因为如此,一些使用云效的阿里同事离开阿里来到一些新公司之后,他们会发现随着技术团队的扩大,在工程的效能提升和质量保证上迫切需要类似云效这样的平台来支撑技术和业务的快速发展。于是他们找到了我们,云效就这样对外开放了。

在服务了这些最初的公司之后,我们也有了自己的思考。阿里的特长在于为 B 类企业服务,B2B 如此,天猫淘宝、钉钉也是如此,“让天下没有难做的生意”这句话(阿里巴巴集团执行主席马云,曾经作过《让天下没有难做的生意》的主题演讲)很好诠释了这一点。

为 B 类企业服务的基因也深深扎根于云效这个团队。我们在想我们能不能做“让天下没有难做的工程效能”。我们都知道,一个技术团队随着规模的扩大,研发测试全流程的各个节点的工作效能和质量提升都是难言之隐。说难言之隐是因为,它呈现的各种问题的严重性不一定能明确显性化出来,但的的确确让技术团队的每个人都痛苦不堪,却又难以忽视。

各个企业也都在尝试做研发测试的效能提升,但成功的不多。一方面研发测试效能领域庞杂,好的跨领域专业化的人才稀缺,具备技术能力同时有很好的沟通协作能力的人才更少,因为这个领域不仅涉及技术,还涉及研发、测试、SQA 等团队协作。

在过去的几年,我们有了种种经历,积累了较为丰富的经验。所以在云效的对外开放中,我们倡导的不仅是平台的输出,还有理念的分享、团队的打造以及各种问题的对应策略的传播。

InfoQ:目前云效已经在多家互联网公司的软件技术团队落地,并开始逐步深入到传统软件行业。那么,是如何落地到企业中?落地到互联网公司和传统软件行业有什么不同的挑战?

章屹:传统行业之前的软件更新迭代的速度是远低于互联网行业的,但可喜的是,近年来的互联网化使很多软件行业的软件更新迭代速度不断加快,于是对实现研发测试效能提升和持续集成持续交付有了更迫切的愿望。

但每个行业的软件企业的痛点都不一样,细分行业内的软件企业工程理念、历史包袱、技术基础、团队规模各不相同,都对云效平台的落地提出了挑战。目前我们遇到的相对较大的挑战还是对方的理念差异问题。技术可以快速引入,但理念的转变需要时间。

我们在和潜在用户交流的时候会充分了解对方的实际情况,比如技术团队规模及组织结构、技术栈、工程效能理念、代码工程规范度、现有的工程技术资产、产品迭代周期、业务发展状况,等等。从中挑选出真正需要的用户,根据对方的实际情况制定出不同的实施方案,方案包括不同的研发测试工具及相关理念、技能的培训和分享。只有如此,才能真正落地到需要的软件企业中去,为他们带来价值和能力。实现我们“让天下没有难做的工程效能”的愿望。

InfoQ:可否深入讲解什么是持续集成持续交付,并分享几个特别的案例?

章屹:持续集成和持续交付业内都有明确的定义。

持续集成的定义更明确,Martin Fowler 是这么定义的:持续集成是一种软件开发实践,即团队开发成员经常集成它们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译、发布、自动化测试)来验证,从而尽快地发现集成错误。前几周在 GIT 训练营我对开发工程师及架构师读完这段定义,我问大家根据这个定义,大家觉得最难实现的环节在哪里,大家一致认为是自动化测试。

回到持续交付的定义,大家也一致认为最难实现的环节是自动化验证。这是一个有趣的例子,很多持续集成和持续交付的分享大都谈了如何自动化的构建、编译以及发布,但很少提到自动化测试或验证。也许它确实是如此的难以实现,而使得人们很少谈论它的实践。

在 ArchSummit 深圳大会上,我会重点介绍自动化验证的实践环节,希望能给到一些新的思路。

InfoQ:平时关注行业哪些技术的发展,有什么不同的见解和看法?从事十多年从事软件的测试、开发、系统设计工作,有什么感悟和经验与大家分享?

章屹:技术需要专注,专业度也需要一定时间的堆砌。

我本人是喜欢长期专注在一件事情上的。但命运让我在十几年间从事了硬件开发、大系统设计、软件测试、软件开发等工作,也经历了军工行业、通信行业、互联网行业。好在每项工作或行业,我最少也待了 2 年以上,虽然不敢说专业,但也得到了一些沉淀和体会。这些经历使我习惯性地会用一些跨领域的技术观点去看待手头的所负责的技术工作,便于更快找到解决方案。

中途也尝试过创业,推销过软件,失败的经历让我意识到纯靠技术是不行的,必须业务和技术高度结合。我每上手一个新的工作内容,会习惯性先去了解这个内容涉及的横向和纵向的业务目标,据此思考自身工作带来的业务价值,再去研究对业务有促进的相关技术。

目前我的工作涉及工程效能、运维和稳定性,也包括了云效的技术工作,所以我会关注对这方面有促进作用的相关技术,比如 Docker、微服务、运维自动化等。

受访嘉宾介绍

章屹,阿里巴巴高级技术专家、测试架构师,清华大学电子工程系硕士毕业,十多年从事软件的测试、开发、系统设计工作。现为阿里巴巴 B2B 技术部 - 质量保证部 - 工程效能部技术负责人,负责提升研发测试效能的持续集成持续交付平台——宙斯盾(云效)的技术规划和建设工作。

2016-07-14 19:005473

评论

发布
暂无评论
发现更多内容

实现-最佳实践-个人复盘V3

南山

个人成长

社区来稿丨一个真正意义上的实时多模态智能体框架,TEN Framework 为构建下一代 AI Agent 而生

声网

天润融通发布微藤智能体平台,中国客户联络正式进入“智能体时代”

天润融通

如何在 Rust 中通过 Rumqttc 实现 MQTT 通信

EMQ映云科技

rust mqtt emqx

【首席战略官分享】流程管理和流程数字化 | 活动成本法

望繁信科技

数字化转型 业务流程管理 流程挖掘

2024-09-25:用go语言,给定一个长度为 n 的整数数组 nums 和一个正整数 k, 定义数组的“能量“为所有和为 k 的子序列的数量之和。 请计算 nums 数组中所有子序列的能量和,并对

福大大架构师每日一题

福大大架构师每日一题

RTE 大会报名丨AI 时代新基建:云边端架构和 AI Infra ,RTE2024 技术专场第二弹!

声网

实现-最佳实践-沉淀与践行V3

南山

个人成长

华为openMind分论坛:赋能AI社区生态汇聚,推动AI创新发展智慧未来

Geek_2d6073

实现-最佳实践-剁椒鱼头V3

南山

个人成长

实现-最佳实践-分享演讲V3

南山

个人成长

深入探索 RUM 与全链路追踪:优化数字体验的利器

阿里巴巴云原生

阿里云 云原生 全链路追踪 RUM

开发者的利器:Rainbond 赋能你的产品创新

北京好雨科技有限公司

云原生 k8s rainbond 企业号9月PK榜

华为四大创新助力运营商打造万兆智能接入网,加快50G PON商用部署,加速智能应用创新

Geek_2d6073

实现-最佳实践-创造心流体验V3

南山

个人成长

专业期刊《Java aktuell》:使用Apache TsFile和Apache IoTDB对时序数据进行分布式数据采集

Apache IoTDB

新场景、新能力,AI-native 时代的可观测革新

阿里巴巴云原生

阿里云 云原生 可观测

.net core集成Minio,构建一个文件存储的基础设施

为自己带盐

.net core Minio

实现-最佳实践-大模型提效V3

南山

个人成长

实现-最佳实践-个人介绍V3

南山

个人成长

PhysicsAI 与 Inspire Cast 的结合:实现铸件缺陷的快速预测

Altair RapidMiner

人工智能 AI 仿真 智能制造 altair

“万亿级”低空经济,谁在风口上“飞”?

趣解商业

科技 出行 低空经济

实践-最佳实践-时间管理V3

南山

个人成长

中国移动研究院与华为举行"数联网(DSSN)合作备忘录"签约仪式

Geek_2d6073

如何选择工作任务跟踪软件?8大工具比较

爱吃小舅的鱼

任务管理 任务管理软件

实现-最佳实践-感恩日记V3

南山

个人成长

inBuilder零代码新版表单设计器特性一览

inBuilder低代码平台

低代码 零代码

被动元数据的不足和主动元数据的先进性

Aloudata

大数据 数据治理 元数据 数据管理 数据血缘

AI媒体工作流“出道” | 闪迪助力探索AI的实践与创新

Geek_2d6073

从自动化到智能化:AI如何推动业务流程自动化

天津汇柏科技有限公司

自动化 智能化 AI 人工智能

观测云全面支持 OaC,通过 Terraform 管理您的可观测性

观测云

Terraform

软件测试行业悲观走冷,“让天下没有难做的工程效能”是否一支强心剂_阿里巴巴_陈兴璐_InfoQ精选文章