DevOpsDays大咖说（第4弹）：质量与效能，相爱又相杀

DevOpsDays·大咖说

2020 China DevOpsDays大咖说的栏目是敏捷和DevOps领域的一款访谈类的直播节目——邀请在业界领域里面最专业、最有想法、最有深度且最有态度的资深的实践者老师，一起来聊一聊在敏捷和DevOps领域里的一些观点和思路，他们自己的职业练级旅程，以及在各自产品和项目上的经验教训。希望对大家的DevOps之旅有一些启发。

主持人：

张乐，DevOpsDays中国区组织者，京东DevOps与研发效能技术总监，负责DevOps工具链产品体系化建设工作。

许峰，DevOpsDays中国区组织者，数字化转型方面的独立咨询顾问，也是DevOps，敏捷精益，VeriSM数字化服务管理的讲师。

本期嘉宾：

朱少民

国内知名测试专家，QECon全球软件质量效能大会发起人。近30年一直从事软件测试质量管理相关工作，曾在思科中国担任QA高级总监。先后获得多项的科技进步奖，出版了10多部著作，代表作有《全程软件测试》、《软件测试方法和技术》等等。朱老师的个人的公众号叫“软件质量报道”。

质量和效能，是相爱又相杀的矛盾统一体。

如果过于关注效率而忽视质量，有可能会出比较大的问题，大家之前也从各种渠道上了解到一些比较大的系统宕机、系统崩溃这样的事件。所以抓效率不要忘记质量。在高质量的情况下，实际是带来高效率的。

技术驱动质量，技术驱动效率，通过一个技术的手段来解决问题，甚至有时通过一个流程来解决问题，这些都是更好地从质量效率两个方面同时来考量或平衡。我们把质量和效能看成是一个矛盾的统一体，看到这种矛盾的存在，但更重要是怎么更好地把它们结合起来，更有效的去解决我们软件过程当中的问题。

张乐：

今年9月份，QECon大会成功举办，请朱老师来谈一谈，您怎么看待质量和效能？怎么会想去办这么一场大会？

朱少民：

首先谢谢两位老师的邀请，有机会在这里和大家交流。

过去大家是比较关注质量的，但至少最近几年，大家开始更多的关注效能。也能理解，因为现在节奏特别快，竞争也特别激烈，大家都想怎么能提升效能、更快地交付产品。

质量和效能，是相爱又相杀的矛盾统一体。如果过于关注效率而忽视质量，有可能会出比较大的问题，大家之前也从各种渠道上了解到一些比较大的系统宕机、系统崩溃这样的事件。所以抓效率不要忘记质量。在高质量的情况下，实际是带来高效率的。比如质量差，不断的返工、从头再来，实际产出比较低。比如说代码重构，这本身是一件好事，但过于依赖重构，随意写代码，导致过度重构而形成了极大的浪费。在这样的背景下，我们发起了QECon大会，特别强调质量和效能的结合。今年9月4号的大会主场，我做了一个演讲，特别强调这个质效合一，不能把质量和效能隔离开来，而是将质量和效率融合起来。

要提高质量，先把需求做好。需求是源头，我们一定要重视需求。但是大家对需求就是不重视，在整个的软件行业里面，大家抱怨最多的也是需求，需求文档随便写，或者根本没想清楚就开始做。如果需求不对，影响设计、编程，质量做得再好，很大的投入也没有价值。这个道理大家都懂，只是一忙起来，就把需求的质量忘了。

构建一个好的需求，尽量不去返工，这样的效率实际是很高的。美国质量管理之父菲利普•克劳斯比 (Philip Crosby)说的：“质量是免费的”。第一次把事情做对，效率是最高的。所以做好质量并不一定付出很大的代价，许多人觉得我要把质量做好，一定有很大的投入，所以就不愿意把质量搞上去，因为觉得这个投入太大，或者不愿意进行这样的投入，但实际看你把时间怎么分配，假如前面你多花点时间在需求上面，后面你在设计、编程、测试可以少花很多时间，整体来看你还是合算的。大家可以先从一个小项目去做一个实验，做一些探索和实践，看看效果。

张乐：

我们谈 "质效合一"，是希望能够通过一些方法让质量和效率兼得，而不是二选一的过程。很多做质量出身的同学，在往工程效率、研发效能去转型，这是不是也是一种趋势？质量本身是我们交付过程的一部分，但光有质量是不够的，在保证质量的前提下，我们要去提升效率，所以是不是有很多相通的地方在这里面？

朱少民：

没错，就像自动化测试是提高效率的，比如做回归测试，人来做的话不会天天去跑，天天跑也不可能跑完这些测试用例。但有了自动化测试，你就可以不断地Run，反正是让机器在跑，所以可以持续地Run，这样也提高了质量。另外像代码的静态扫描静态分析，一方面效率高了，另一方面质量也提高了，因为它比人分析得更深、更全，相对于人，工具可以把代码全部扫描，检查有没有性能、安全或者代码规范等问题。

技术驱动质量，技术驱动效率，通过一个技术的手段来解决问题，甚至有时通过一个流程来解决问题，这些都是更好地从质量、效率两个方面同时来考量和平衡。我们把质量和效能看成是一个矛盾的统一体，看到这种矛盾的存在，但更重要是怎么更好地把它们结合起来，更有效地去解决我们软件过程当中的问题。

张乐：

去年DevOpsDays大会上海站，我们请来了Toda先生，他是日本TPS认证学院的院长。当时的演讲有一句我印象特别深刻：最大的浪费是返工。我们这里说的质效合一其实也表达了这个观点。

在这个VUCA时代，我们的系统越来越复杂，变更越来越快，数据量越来越大，还有很多AI技术的广泛应用，所以现在我们做质量保证和以前不一样，是不是质量保证的手段也在与时俱进呢？

朱少民：

VUCA时代给我们带来更大的挑战。一方面我们要想办法简化，现在流行serverless和微服务架构，就是我们在想办法解耦，面向接口设计和编程。如果业务关系复杂，要想办法把业务理顺，一是做合并同类项的工作，另外就是要一层层的分解。软件工程的提出是在1968年，那时讲结构化和模块化，到今天不管是面向对象或是面向构件还是微服务，本质并没变，我们采用松耦合架构，做抽象，隐藏信息或封装。越复杂的问题，越需要去建模型。比如UML的应用场景，对简单的问题，我们画一个用例图、类图也很简单，但其实越简单是越不需要画，越复杂越需要画。构建模型的目的是避免犯错误，看清楚问题的本质或者抓住它的主要矛盾和特征。这个是从复杂性方面来讲。另外从不确定性方面来讲，要认识到这种不确定性，想办法去降低不确定性。DevOps和敏捷，强调持续交付，以前的开发周期比较长，半年一年，那这种不确定性是严重的，因为在今天来看，你没没办法知道半年以后是什么样子，或一年后彻底变了。今天我们迭代越来越快，两个礼拜或一个月交付一个版本，时间越短，事情越确定（即尽可能消除不确定性）。还有我们在不确定里面，还是有确定性的东西。我们有概率论和随机理论，我们可以从杂乱无章中找出规律，就像今天人工智能、大数据，我们用神经网络计算方法和大数据的分析挖掘算法。原来看似不确定的、随机的、没有一点头绪的问题，最终还是能找出规律。从今天来看，我们大家是在不断地前进。

张乐：

对，是在持续的演进，很多的测试手段比以前更强了，包括一些工具一些实践方法模型上，都会比原来有更好的手段去支持更多类型的测试。

测试右移

在生产环境跑测试，还是要看情况，看上下文。假如出现的问题带来的影响比较小的话，你可以在生产上去跑测试。另一方面，我们要做得快，省去一些环节，把测试的环节右移；还有一种是不能做的测试，右移。这三种原因驱动我们做测试右移——在线测试。如果这个三个动机成立的话，那（测试右移）是可以去做的。所以现在总体来讲，我们讲的易用性测试、性能测试，以及安全性监控等，做线上的会多一些。

张乐：

在生产环境上做一些测试，说的好听点是测试右移，但有时候控制不好，反而会在生产环境上暴露一些问题出来。对于在生产环境上去跑测试或者说测试右移这个事情，您有没有什么一些建议呢？

朱少民：

在生产环境跑测试，还是要看情况，看上下文。

假如出现的问题带来的影响比较小的话，你可以在生产上去跑测试。测试总是有风险，靠测试也不能真正保证质量。除了讲质量是构建出来的，我们也要做评审，、做分析，就像过程评审，有时候比测试更有价值。要把风险控制好，像混沌工程里面讲的，故障半径也是要控制的。你做实验会出问题，那灰度发布也是这样的，要精准流量控制，千分之一的流量和1%的流量。我觉得你能承受得起的也可以用灰度发布。就像银行一样，如果你觉得你做的快，测试比较少，可以灰度发布，只是1%的流量。如果万一钱错了，你要赔人家的钱，那赔的钱比你在测试上投入的钱如果少的话，还是可以去做，是合算的。如果你损失的钱不是一笔小钱，如大银行，即使是千分之一的流量，也会有比较大的损失，那你承受不了，就不能去做了。

现在许多测试右移还是用在其他方面，就像易用性测试、人工智能的推荐算法或者是大数据的一些项目，究竟你的方案好不好是不知道的。包括UI设计师提出的新UI设计，也是要做AB测试。像腾讯、阿里一些大公司，流量很大。上线一个新产品，可能马上就有几百万几千万的用户上去了，那就必须要在研发环境下去做性能测试。但对于一些小公司，其实不需要在研发环节上去做性能测试，因为它的流量是从几百个用户，慢慢涨到几千个用户、几万个用户的，所以可以在线上做性能监控，发现性能问题就及时去调整，会更早地发现性能的瓶颈和问题，也就不需要做线下的性能测试。这里讲的线下性能测试是指完全模拟生产环境的、系统级的性能测试。开发还是应该做自己所开发的接口、组件、模块或者算法的性能测试。这样也要求我们从架构设计开始就要认真考虑性能问题。如果在架构设计上，把性能问题考虑好了，然后开发再把单元的性能测试做好，那整体的性能测试的代价也会比较小，所以，我们测试右移是为了减少这个（模拟生产环境的）成本。

另一方面，我们要做得快，那省去一些环节，然后把测试的环节右移；还有一种是不能做的测试，右移。这三种原因驱动我们做测试右移——在线测试。如果这个三个动机都成立的话，那（测试右移）是可以去做的。所以现在总体来讲，我们讲的易用性测试、性能测试、以及安全性监控等，做线上的会多一些。

许峰：

我想接着问一下与测试趋势相关的，朱老师发起的QECon（Quality & Efficiency Conference）大会举办得很成功，大家对质量效能的演讲反响热烈。所以，能否结合您近两年观察国际/国内在测试方面的新实践、新方法或思想给大家讲讲未来的趋势？

朱少民：

我们一般还是要谈谈趋势和未来的。

从QECon大会可看出，大家想到人工智能技术既然可用在产品、开发上，那自然也会用在测试上，如：图像识别，或自然语言处理，即人工智能测试是一个方向。用服务的概念，即SOA架构，亦即软件是一种服务、平台是一种服务、基础设施是一种服务，所以，测试也是向服务方向发展的，即测试云化（测试也构建在云上）也是一个方向。所以，我认为有两大趋势，分别是通过测试云化来实现质效合一，以及通过DevOps工具链集成的智能化来实现人工智能测试，即AI测试。

首先，我多年前去华为沟通，他们已用桌面云来工作，但发现测试云化还不显著，虽然这类大公司测试环境复杂，测试基础设施真正云化难度较大，但共享需求较多，还是值得云化——借助云化不仅可以节约成本，而且可以提高测试效能。刚才讲到既然开发、测试要融合，那基础设施就不能只谈测试的，而是整个研发的；若还涉及运维，就应该提倡DevOps，那如何才能更好地实现运维研发的基础设施贯通呢？这里我给大家推荐一本书，叫《基础设施即代码》，英文版是2016年出版的。此书核心观点是借助代码（包括脚本化的命令、配置文件）才能实现彻底服务化（即研发整体功能或测试都作为一种服务的话），因为只有代码具有可复用、可配置、可调用的特性。

其次，自动化测试使用的人工智能技术较多，但几乎都出自国外。2018年，我在“软件质量报道”公众号发布“未来已来，人工智能测试势不可挡：介绍9款AI测试工具”的文章，阅读量1.7万，介绍国外的9款AI测试工具，虽然工具成熟度良莠不齐，但至少有；而国内软件技术创新方面却要少很多，但这并非我崇洋媚外。对于常见的敏捷、DevOps、TDD、微服务、基础设施及代码等技术都是国外的，国内创新大概就只有中台。当然，这也与我国倡导加班文化的企业较多有关，如：996工作制，使得思考时间被严重压缩，创新能力减弱。

不过，国内也并非没有高水平技术。其一，阿里、腾讯、京东等，在微服务架构、Serverless架构或者运维等做得比较好；其二，特别是流量大，如：全链路压测，估计国外没我们水平高。因为像我国这般涉及大流量和庞大用户群使用环境的国家较少，也可以说，是国内环境逼着我们做好的。就像之前听说“最初的12306是法国人做的，但因法国总人口就几千万，使得第一次上线，系统就遭遇崩溃”，但若是国内的京东、阿里去做，可能就没问题。所以，有时候，差环境反而造就高能力！

总之，一方面是技术驱动质量。这方面亚马逊做得也比较好，但他们觉得技术只是一方面，或者技术的东西我们都能做得到；最重要也是最难的还是人或文化，因它很难改变、短时间内改变就难上加难，故，另一方面是好的文化。站在文化角度讲，刚才讲的有态度、有温度、有深度，特别是好的态度包括对待质量的态度、对待整个软件研发的态度就非常重要，如可以问一下自己：是不是真的热爱写代码？真的热爱做测试？ 

许峰：

关于AI测试前景您怎么看？它会较短时间内成为一些主流公司采用的测试手段吗？还是，有很长的路要走？

朱少民：

一方面，AI目前还是依赖于数据。因为“人工智能”说法出现在1950年，演进到现在，算是第三次高峰（或浪潮），它依赖于大数据，虽然存储能力、计算能力的提升也有助于推动AI的发展。因为算法的创新较少，主要还是靠计算能力，故在大数据的基础上，AI会有更好的发展。

目前国内业务数据的量级，还远达不到AI对大数据的要求。如：京东、BAT企业已积累20年或10+年的研发数据，但这量级的数据若从业务上来看的话，是不够的，因为业务变化快、需求文档质量差。若以开发为例：像做代码分析、代码推荐，若只算代码量不算少，可AI需要业务数据，就算在大学做研究，更多只是基于GitHub/Gitlab开源代码，很少考虑业务；测试也不例外，生成测试数据、测试用例相对容易，但很难生成验证、断言。假如，用AI做性能测试、压力测试、安全测试，慢慢取代人，比较容易；但业务验证取代人还是非常有挑战性的，如输入自然语言风格的API文档或需求文档，就能生成测试用例，实现真正的全自动化，很难，前期还是需要大量人力的投入（BDD、需求实体化，让需求可执行也不例外）。

所以，AI测试最好实现人机协同，即人机交互智能，如代码推荐。你要让机器人完整地实现代码，仅仅是理论上可实现（梦想），现实中还需要很长的路要走，但人机交互智能是可以的。如：一个程序员配几个小机器人，帮程序员做代码扫描分析、代码推荐、甚至缺陷定位，实现人机结对编程；若机器人做的好，可实现机器间博弈，这在人工智能技术应用和游戏等方面有验证。从人机博弈到机器间博弈，每个开发人员的效率可提高40%~50%，甚至提升十倍效能（之前访谈嘉宾的观点）。虽说十倍效能觉得不可想象，但对于像BAT、京东这样的大企业，研发人员好几万，不要说提高10%~40%的效能，即使提高1%~5%的效能就已令企业非常满意。通过AI技术提高10%~20%的效能可能性较大，故对于大企业来讲，开发基于AI的人机交互智能价值非常大。

许峰：

好的，朱老师讲的人机协同，给开发、测试人员配小机器人，做智能的代码推荐、缺陷定位，这些可能还是会实现的。

朱少民：

对，这不是幻想，像北京大学李戈老师aixcoder，就可做代码推荐。人机交互智能未来会做得更好的，可以最先得到普遍应用。

张乐：

有同学在提问，中小型企业也适合做自动化测试吗？它到底可帮项目提高多少效能？自动化测试作用有多大？

朱少民：

自动化测试跟企业规模没有太大关系。虽然我们讲上下文，但它与团队能力、是否是产品线有关系。若是做一次性项目的话，不能形成产品线，那做自动化测试一般是没有什么价值；但若公司虽小，但做有生命力的产品线和回归测试，那自动化是有价值的。

投入/产出多大？其一，取决于方法。若类似于BDD，需求就可执行；若是WEB用Selenium+Webdriver、移动的用Appium或其它工具，都会有差异。之前公众号发表过一篇文章，还可以用无脚本化的自动化测试（也会带来差异）。相比以前的录制回放，今天无脚本化的TA有人工智能支撑，已经产生了几个较好的工具。所以，采用无脚本化的TA，效率会更高一些。其二，背景不一样，投入产出也不一样。背景包括产品、代码、设计的可测试性、测试人员的能力、选用的工具和工具的使用方法等，原因非单方面的，不可一概而论。

张乐：

相信小伙伴应该听清楚了，没有一个简单的回答，从个人、组织、团队、工具技术的协同都有关。写自动化用例是有代价的，执行的次数越多，投入产出比可能就越高。

2020 China DevOpsDays大咖说系列

第四弹：朱少民（上篇）完。

（识别下面二维码 或点击 原文链接

输入专属优惠码ZSM2020 直降200元）