-有时候，资源有限未必是坏事，它是倒逼你创新的最好方式。“因为牌烂，所以能打得精彩”。但是从短期视角来看软件研发，这个观点似乎不好使。最常见的错误方式是采用Deadline

如果你是工作在传统软件企业的工程师的话,网站的架构设计知识对你来说可能没那么重要。因为,你的测试对象是传统软件,此时你需要对你的被测软件的架构有比较深入的理解。而现在如你所知,互联网企业已经占据软件产品的大半壁江山。如果你想跳出传统软件产品测试这个舒适区的话,那互联网企业将是一个最可能的去向。而在互联网企业进行软件测试的话,很多时候需要针对互联网的架构来设计有针对性的测试,另外对于互联网的压力测试以及结果分析也需要对架构知识有比较清楚的认识。这时,不懂得网站架构设计知识,在开展测试时,就真的会有处处被掣肘的感觉了。更别提,这还会直接影响到你的能力提升和职业发展了。在测试过程中,你可能会经常遇到诸如负载均衡器、缓存集群、数据库读写分离、消息队列、CDN、反向代理服务器和分布式数据库等概念,在测试执行中也经常会和这些系统打交道。但是你可能并不清楚这些组件真正的作用。还有些时候,特别是性能测试,如果你不清楚详细的架构设计以及其中的技术细节,你可能根本无去解读和分析性能测试的报告。我来举两个实际的例子吧。基于消息队列的分布式系统测试设计的例子在分布式系统的架构中,为了减少各个应用系统之间的直接耦合,往往会引入消息队列来实现解耦。也就是说原本的功能实现是由系统A调用系统B来完成业务功能的,而引入了消息队列后,系统A不会再直接去调用系统B,而是将调用B所需要的数据放到了消息队列中,此时我们将系统A称为消息的生产者,然后系统B通过监听该消息队列,主动从消息队列中依次抓取数据进行系统B的处理,系统B在这种情况下称为消息的消费者。通过这种方式,就完成了系统A和系统B之间的调用解耦。那么,我们再来看测试的设计。测试用例的设计可以站在黑盒测试的视⻆,完全不需要知道消息队列的存在,而直接从业务功能的层面去设计用例。但如果只这么做的话,你会发现虽然你的测试全部通过了,但是产品一旦到了线上,还可能会出现很多问题。比如说,消息的生产者产生消息的速度远远大于消息消费者处理消息的速度时,很可能会造成消息队列满的情况,此时系统的行为是怎么样的?

核心观点：单体架构,具有灵活性差、可扩展性差、可维护性差等局限性,所以有了微服务架构。微服务架构的本身的特点,比如微服务数量多,各个微服务之间的相互调用,决定了不能继续采用传统API测试的策略。为了既能保证API质量,又能减少测试用例数量,于是有了基于消费者契约的API测试。基于消费者契约的API测试的核心思想是:只测试那些真正被实际使用到的API调用,如果没有被使用到的,就不去测试。基于消费者契约的测试方法,由于收集到了完整的契约,所以基于契约的Mock

在生产环境中实际运行大型分布式系统，难免会有各种不可预料的突发和异常事件发生。一方面，随着云原生技术微服务架构的发展应用，后端系统的复杂性不断提升，另一方面，随着业务侧系统的广泛使用，用户规模和数据规模都在经历爆发式的增长，这些都给软件系统以及基础设施带来了巨大的挑战。庞大的分布式系统天生有着各种复杂依赖，可能出错的地方不仅数不胜数，更是防不胜防，我们已经很难评估某个单点故障对整个系统的影响。同时业务和技术的迭代速度快，在这种背景下，如何持续地，有信心地保障系统的稳定性和高可用性受到了有史以来最大的挑战，如果处理不好就会导致业务受损，或者是其他各种无法预期的异常行为。在复杂的分布式系统中，我们已经无法阻止这些故障的发生，所以我们应该致力于在这些异常行为被触发之前，尽可能多地识别它们。然后，针对性地进行加固，防范，从而避免故障发生时所带来的严重后果。我们知道发生故障的那一刻不是由你来选择的，而是那一刻来选择你，你能做的就是为之做好准备。为此，我们需要化被动为主动，不是等到故障发生了再去处理，而是先下手为强，通过人为的故障注入，主动来发现问题并解决问题，这就是混沌工程(

要想彻底搞垮一个测试团队并非易事，需要多角色通力配合、多方联动、综合施策，才能达到目的。本文从“实践经验”出发，为大家总结了搞垮测试团队的18项措施，或许可以给大家带来一些启发。—

的实施过程是对齐和支撑，人人都要思考，做什么样的工作才能帮助团队实现目标，这是一种向上的支撑力。不单单是垂直方向要目标对齐，水平方向上也要对齐。兄弟部门或协作部门的

近几年，业界对研发效能的关注度与日俱增，众多工程人员和学者进行了大量的思辩悟，我们对这一“盛世”喜闻乐见，虽然百家争鸣的背后也可能伴随着偏见和纠葛，但恰恰是这些不同的声音，造就了软件研发效能的进步和反思，也启发着我们进行多元化的思考。我们从工程角度思考研发效能提升，建设了众多易用的工具平台；我们从组织优化的角度出发，践行了DevOps等实践；我们从项目管理的角度出发，推崇敏捷开发，并丰富了度量等手段。从工具到组织，再到管理，我们做了那么多提升研发效能的事，你也许不禁要问：这些工作究竟是如何作用到研发效能的提升上的？软件研发效能的本质到底是“人性”的，还是“物性”的？毫无疑问，软件研发是一项人类的活动，然而，在对软件研发这一过程进行考察时，这个几乎毋庸置疑的论断，却是许多人共同的思维盲点，这也许是因为，计算机在这一过程中的作用被过分夸大了。我们总是不自觉的认为我们可以依靠计算机解决所有问题，当然，也包括解决我们自己。这样的例子很多，管理者喜爱推销自动化测试，认为自动化测试能够替代测试人员的工作，继而降低人员的工作强度，但遗憾的是，我从未见过一位管理者能够真正兑现这一承诺，测试人员或是将精力大量投入在维护因业务迭代而无法执行的自动化脚本上，或是投入在分析自动化执行结果上，从全局视角看，测试人员还是那么忙碌、疲倦和无精打采。事实上，所有企图单方面用技术手段去消除软件研发过程中人的因素的努力，基本都是以失败告终的。管理者的美梦也许无法成真，但也并不是完全没有益处，它促进了我们的思考。让我们放下手头的键盘和鼠标，从人性和物性的角度，辩证思考一下我们正在从事的这项工作。1软件研发效能的“人性”软件研发是人类的智力产物，我想没有人会质疑这一点，而这恰恰也是软件研发最令人感到困惑的地方，它难以度量产出、难以管理、难以控制。那是不是软件研发效能提升工作就成了一门“玄学”呢？这也未必。解铃还须系铃人，既然软件研发工作是人类的活动，那么在此之上的所有效能提升工作，都要顾及人的基本感受和合理需要。毕竟，人类的所有活动也都是为了自身能更好的存在和发展而进行的，这正是对研发效能提升最人性的解读。如果我们无视人性，那么不要说研发效能提升，恐怕连其中的某些环节都无法做好。最近关于度量的话题比较热门，我们就一起来看一个关于度量的案例吧。先介绍一个社会心理学名词——霍桑效应（Hawthorne

微信公众号的江湖里有个说法，叫「三千字断头台」，也就是一篇文章不太会写超出了3000字，因为大部分人对一篇文章的阅读极限就是3000字（甚至更少），超了字之后大家读不完，今后也不太会去读了，最后导致看的人越来越少。我自己也比较纠结，后来意识到一个问题，我写文章主要对内容负责，大家看不看根本就不是我所关心的问题，我的核心目标是把内容写好，所以也就释怀了，我只关注内容是否能够表述清楚、逻辑是否合理。提前告知大家，今天的篇幅略长，主要是敏捷这个话题，涉及的面太广了。我眼中的敏捷掐指一算，自己从2000年左右第一次接触敏捷，至今已有10多年了。还记得那时第一次参加了一场为期2天的敏捷的培训，老师是个老外，中文讲得不错、很健谈，课上有概念、有游戏、也有很多学员之间的互动，整个体验还是不错的。在2天的培训最后结束时，老师让每位学员谈一下自己对敏捷的感受。我当时也是年轻（年少无知），我直接大声说出了自己的感受：「敏捷更适合存在于乌托邦的团队或公司里，不适合大规模推广」（现在看来肯定是啪啪打脸，因为当时我的认知水平，只能到此程度）。那时，我觉得敏捷中很多价值观、宣言、规则流程设立的太理想化了，曾经在瀑布式模式开发过的小伙伴应该清楚，现实世界是很复杂的、人性也是非常复杂的，各种奇奇怪怪的事情、人和人之间的矛盾、组织与流程之间的不协调、领导风格的多种多样，想找一个全部都认同敏捷文化、且不折不扣去执行的团队真的太难了！（现在行业中也依旧很难，但不代表没有）培训结束回到公司，领导问我培训参加过后，感觉如何。我不遗余力的给老板和团队讲，敏捷有多好，敏捷有多么高大上。原因不为别的，是因为他们不懂敏捷，我这么说更显得自己2天的培训时间没有白白花掉、酒店的自助餐没有白吃。说实话，当时的我其实只是想告诉自己的领导，选择让我去参加培训是一个多么明智的决定，而并非我对敏捷的理解有多么深刻。10多年过去了，随着时间的流逝，对人阅历、对事情的判断、对敏捷的认识，和当初有了不一样的理解和感悟。现在，我的看待态度是：敏捷只是一个开发模式的工具而已，既不是长生不老药，也不是解决一切问题的办法，不用盲从，也不用鄙夷，如果你觉得合适，你就拿来用就好了。之前薛兆丰老师有一个说法，如何让一只鹦鹉成为经济学家呢？答案是：只需要让鹦鹉学会「需求」和「供给」两个关键词，这只鹦鹉也能成为经济学家。这个调楷一方面说明了「需求」和「供给」是经济学最核心的概念和逻辑；另一方面又说明了，看似简单的「需求」和「供给」概念，想要搞清楚并不是很容易。同样，对于敏捷，如果让我给出最核心的两个词让鹦鹉成为敏捷教练，我会选择「产品」和「团队」这两个词。产品这个关键词，可以衍生出敏捷中很多概念：产品思维、产品需求、产品迭代、产品价值等。面对产品需求不明确、能为用户创造哪些价值不知道、用户体验又要超过同行的产品，这已经超出了普通程序员在学校里面学习的计算机知识了。团队这个关键字，可以衍生出敏捷中很多概念：人性、角色、团队能力、团队沟通、团队承诺等。面对不同背景、学历、来自五湖四海、脾气秉性差异极大的同事们，能不能把这个团队服务好，已经远远超出了Scrum

说到规章制度，我首先映入眼帘的是各个公司的各种规章制度、各种繁文缛节，这样不能做、那样也不合规、这么又不规范，总之，一言难尽。虽然现在互联网大厂更重视「业务交付」，但是在整个软件行业里，既存在着「野蛮式生长」的团队，也存在着被制度处处掣肘的团队，下面让我们跟着漫画走进今天的话题。作坊式搬砖小队

作为技术团队的带头人，如何帮助老板打造一支看起来强大，实际上却非常拉胯的技术团队呢？今天我们来聊聊，一个新的团队成立时，你作为技术团队的带头人，老板给予你充分的授权，你该如何飘飘亮亮地「搞垮」一个团队呢？这一篇是「搬砖启示录」系列的第二篇，我们争取坑出技术、坑水平，变着方法的帮老板烧钱？招聘唯才是举吃瓜度

不懂变异测试，你好意思说自己是测试工程师，今天让我（一个即将秃头的工程师）带你深入浅出理解变异测试的方方面面。从测试覆盖率的局限性谈起很多时候我们会用单元测试执行后的代码覆盖率来衡量测试的充分性和完整性，问题是有了很多测试用例，同时又有很高的白盒覆盖率，是否代码质量真的就高枕无忧了吗？答案显然不是。来看个《软件研发效能提升之美》书里的例子就懂了。比如下面的代码，测试执行后的代码覆盖率可以达到100%，但是代码中的问题并没有能暴露出来，这样的测试用例缺乏对于缺陷的发现能力，会导致测试用例数量不少，同时测试覆盖率也很高，但是缺陷依旧不能被发现的尴尬处境。图1：覆盖率不等于有效性的例子这里暴露出的本质问题是测试覆盖率不等于测试的有效性，那么测试的有效性又应该如何来衡量呢？这就是变异测试（Mutation

核心观点软件可测试性是实现高质量、高效率交付的基础，关注可测试性可以提升软件质量。可测试性差，会直接增加测试成本，让测试的结果验证变得困难，让测试活动延迟发生。可测试性是设计出来的，提升可测试性可以节省研发成本。可测试性包括可控制性、可观测性、可追踪性与可理解性四个维度。随着云原生技术的加速普及与快速发展，软件系统的规模和复杂性不断水涨船高。与此相对应，在软件研发过程中，为测试而设计（Design

大概在五六年前，有一次我在Google美国总部参加一次技术交流，有一个演讲让我印象深刻，让我至今一直记忆犹新的不是其演讲内容，而是演讲开始的第一页PPT：“别人眼中的Google

谈到研发效能，我们有着自己的独到见解。我们看到的现象是：只要努力搞，没有折腾不垮的团队。虽然有很多大厂研发效能做的还不错，成为了大家膜拜的对象，但是我们也看到很多“内卷”现象的发生。经历了很多故事，我们更能谈谈自己的理解和感悟。研发效能是目前互联网企业和传统软件企业都高度关注的领域，互联网大厂希望通过“研发效能”实现持续的研发能力提升以应对日趋复杂的产品开发；腰部厂商则希望通过“研发效能”实现弯道超车，充分发挥后来者居上的优势；更多中小企业看到国内互联网大厂不约而同地在这个领域重点投入，纷纷也是摩拳擦掌准备在效能领域发力。一夜之间，似乎只有推进了研发效能，才能提升研发团队的效率，才能让自己在和友商的比拼中不至于输在起跑线上。那么现在企业的研发效能实践到底为企业带来了多大的优势，又帮企业解决了哪些问题呢？那些推行研发效能的企业现在的状态怎么样？研效问题到底解决了吗？别急，这些问题其实大多都还没有解决，而且有些问题可能还变得更糟糕了。毕竟研发效能的实施没有捷径，需要摸着石头过河，肯定不会能像电影里面演的那样注定会有皆大欢喜的结局。经历了风雨，不一定能看见彩虹，更有可能会得重感冒。研发效能问题今天解决不了，不要着急，因为明天同样也解决不了。所以就让我们“放心大胆“地看看研发效能到底是如何搞垮一个团队的。要看懂研发效能如何搞垮一个团队，我们首先需要对研发效能有一个全局的认识，需要先从正向的角度来理解研发效能。到底什么是研发效能和敏捷的概念类似，到底什么是研发效能很难精确定义。其实很多复杂概念也不是定义出来的，而是逐步演化出来的，是先有现象再找到合适的表述。其实，效率和效能也从来都不是软件工程的专有名词，纵观人类发展史，就是生产力和生产效率不断提升的发展篇章，到了数字化时代，软件研发效能的重要性被凸显了出来。如果要用一句话来总结研发效能的话，我们会用“更高效、更高质量、更可靠、可持续地交付更优的业务价值”来总结。图1：研发效能的“第一性原理”解释一下其中几个关键概念：更高效：价值的流动过程必须高效顺畅，阻力越小越好。更高质量：如果质量不行，流动越快，死的也会越快。更可靠：安全性和合规性要保障好。可持续：输出不能时断时续，小步快跑才是正道，不要憋大招。更优的业务价值：这是从需求层面来说的，你的交付物是不是真正解决了用户的本质问题。比如：“女生减肥不是本质问题，女生爱美才是”。可以体会一下。在这个概念的引导下，我们引出持续开发，持续集成，持续测试，持续交付和持续运维的理念，它们是研发效能落地的必要实践。与此同时，我们还需要从流动速度，长期质量，客户价值以及数据驱动四个维度来对研发效能进行有效的度量。为什么大厂都开始搞研发效能你有没有想过，为什么最近几年各大行业龙头企业都纷纷开始在研发效能领域发力，而且步调如此一致，我们认为背后的原因有以下这么三点：图2：组织层面的“谷仓困局”01很多企业存在大量重复造轮子就像“中台“概念一样，现在很多大企业的产品线非常广，其中存在大量重复的轮子，如果我们关注业务上的重复轮子，那么就是业务中台；如果我们关注数据建设上的重复轮子，那么就是数据中台；如果我们关注研发效能建设上的重复轮子，那就是研效平台，其实研效平台在某种程度上也可以称之为”研发效能中台“，其目标是实现企业级跨产品跨项目的研发能力复用，避免原来每条产品线都在做研发效能所必须的”0到1“，没人有精力去关注更有价值的”1到n“。现代化的研效平台会统一来打造组织级别通用研发能力的最佳实践平台。02toC产品已经趋向饱和从商业视角来看，现在toC产品已经趋向饱和，过去大量闲置时间等待被APP填满的红利时代已经一去不复返了，以前业务发展极快，那么用烧钱的方式（粗放式研发，人海战术）换取更快的市场占有率达到赢家通吃是最佳选择，那个时代关心的是软件产品输出，研发的效率都可以用钱填上。而现在toC已经逐渐走向红海，同时研发的规模也比以往任何时候都要大，是时候要勒紧裤腰带过日子了，当开源（开源节流中的开源）遇到瓶颈了，节流就应该发挥作用。这个节流就是研发效能的提升，同样的资源，同样的时间来获得更多的产出。03部分企业存在“谷仓困局”从组织架构层面看，很多企业都存在“谷仓困局”（图2），研发各个环节内部可能已经做了优化，但是跨环节的协作可能就会有大量的流转与沟通成本，从而影响全局效率。基于流程优化，打破各个环节看不见的墙，去除不必要的等待，提升价值流动速度正是研发效能在流程优化层面试图解决的一大类问题。研发效能真的能够提高吗既然如此重要，那接下来的问题是研发效能是否真的能提高？很不幸，我们的观点比较悲观。我们认为研发效能的绝对值随着以下因素的增长必然会变得越来越差，就像我（声明一下，这里没有张乐老师）的头发一样，随着时间的推移必然会越来越少一样。软件架构本身的复杂度提升（微服务，服务网格等）软件规模的不断增长（集群规模，数据规模等）研发团队人员规模不断扩大引发沟通协作难度增长所以，我们能做的不是提升研发效能的绝对值，而是尽可能减缓研发效能恶化的程度，使其下降的不至于太快，努力保持现状就是成功。图3：研发效能的鸿沟减缓研发效能恶化我们能干啥看清了本质后，关于如何减缓研发效能的恶化，我们能做点什么呢？可以说研发效能的涉猎面是很广的，软件研发的每个阶段都有研发效能需要关注的问题，腾讯提出的“研发效能双流模型”可以说很好的诠释了这一概念。双流模型从软件研发的各个阶段提出了研发效能提升的各种工程实践，并且倡导需求价值流和研发工程流的自动联动。图4

本文核心观点：团队的复盘能力有多强，决定了团队的进步空间有多大复杂系统的高网络密度和强耦合性是造成故障无法完全避免的罪魁祸首故障是表象，背后技术和管理上的问题才是根因可以包容失败，但是不允许犯错不“浪费（忽视）”任何一个失误不能以唯一根因为导向来复盘避免将故障归因于外部客观原因在企业业务价值的交付过程中，故障是很难避免的，所以对企业来讲故障复盘是一项关键核心能力，今天我就从研发效能的视角来系统性地聊一聊。1.