转载

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

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

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

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、微服务、运维自动化等。