👉目录
1 软件测试发展史
2 测试左移（Testing shift left）
3 测试右移（Testing shift right）
4 自动化测试 VS 测试自动化
5 来自 EX 测试的寄语
最近两年，互联网大厂的招聘中，测试工程师岗位似乎显著减少。在腾讯内部，随着一些 BG 的研效改革逐渐深入，测试工程师这个岗位开始逐渐减少。似乎正在印证一个现象：测试岗位的未来已经不那么乐观？
但软件测试伴随着软件行业的出现经过了几十年的进化，花了很多时间和汗水才走到今天，测试这个领域是不会消失的。不少人都议论过岗位和角色的消失是否合理，一般都分成两派，一派认为测试工程师是独立且专业的岗位应该保留，合理缩减比例；另外一派认为软件测试领域并不复杂，觉得自己对于测试和自动化测试已经非常熟悉，完全可以胜任。
不管你属于哪一派，首先要熟悉软件测试才能更有发言权。熟悉是个模糊的说法，我们可以思考一个简单的问题，测试自动化和自动化测试这两个名词有什么区别？如果区分不出来或者没有概念的话，这篇文章非常适合你，这是专门写给开发的测试漫谈。
关注腾讯云开发者，一手技术干货提前解锁👇
01
软件测试发展史
软件测试这件事本身就伴随着计算机的出现而出现，并且持续保持着演进，但在我的身边特别是一些改革较为激进的 BG，这种演进成为了噩梦的开始。逐渐发量化的测试工程师投入导致产品质量逐渐下滑，为了规避政治不正确的测试兜底而自裁系统测试导致缺陷满天飞。有意思的是，结果数据也从事实上证明了这一点，测试开发比越低的项目，质量和口碑就越不堪，故障越来越频繁，质量差到让用户逐渐麻木。
有些乐于尝试的开发，积极拥抱变化，实践 TDD，关注覆盖率，但结果工作越来越累，任务越来越 delay，产品今天说老板中午吃饭提了个甚好的建议你赶紧改改，项目经理明天说我们重新调整了一下优先级你先做另外一个需求，你想哭但哭不出来，甚至觉得 TDD 是 Tech Driven Dead 的缩写。更离谱的是某天连一位在平行世界早已被你捅了100刀的产品都忍不住站出来振臂高呼，别再瞎xx搞啦，再搞项目就要黄啦。所以软件测试的演进到底是怎么回事，是不符合国情，比如硅谷工时短收入高，还是文化所限，比如硅谷技术至上产品靠边站，且让我们往下聊。
1.1 面向调试期（Debugging period）
参考软件测试大师Hetzel 和 Dave Gelprin 可以将测试划分为五个重要的时代。
第一次出现术语“Bug”和“Debugging”的故事大家应该都在课本里学过，1947年，哈佛大学科学家 Grace Murray 在Mark II 计算机中检测到一只飞蛾卡在了继电器中，导致继电器接触不良。她描述这起事件时将飞蛾称为导致缺陷的“Bug”，并将消除缺陷的行为称“Debugging”。
当时，因为计算机的发展主要还集中在硬件设备的发展商，所以测试也相应的集中在硬件上，而且硬件的可靠性对于软件的正常运行至关重要，稍有不慎便是灾难（可能跟当时的存储条件有关，还没有持久性存储技术）。这个阶段的测试其实就是调试，没有任何区别，也没有所谓的测试人员之分，所执行的测试仅具有纠正性质，通过采取某些措施以使程序能正常工作。
1949年，艾伦·图灵 (Alan Turing) 写了他的第一篇关于对程序进行调试的文章，紧接着在1950年，他在“图灵测试“一文中解释了软件必须如何适应项目要求以及机器或参考系统（人类逻辑）的行为必须无法区分的情况。简而言之就是软件必须经过人类逻辑的验证，让机器执行结果和人类预期相符。
1.2 演示期（Demonstration period）
1957年，Charles Baker 进一步且系统性的解释了开发测试的必要性，他对 Dan McCracken 所著的 Digital Computer Programming 一书的评论中将程序测试与调试区分开来，认为两者的区别在于确保软件满足预先设计的要求（测试）以及程序的功能（调试）。
在这个时期，测试开始作为一项单独的活动进行，软件测试的主要目标是确保满足软件需求。例如，需求是“QQ 的登录状态有7种”。测试人员会确保只展示 7种状态。
随着计算机软件的蓬勃发展，应用程序的开发变得越来越复杂，越来越昂贵，成本也越来越高，解决软件缺陷的成本明显影响了项目的盈利能力，因此测试开始变得极为重要。随之而来的是，软件测试这个新领域正在被逐渐重视，更多的从业人员开始关注并投入进来。这个阶段对于软件测试的关注，主要体现在测试的数量和质量，软件产品的质量第一次开始与测试结果关联。逐渐的，软件开发领域，细分出了软件测试领域。
1.3 破坏导向期（Destruction period）
“软件测试是为了发现错误而运行程序的过程”，1979年，Glenford J. Myers 从根本上改变了软件测试这个行为的定义。
Myers 担心的是，如果软件测试用来追求证明程序是合格的这个目标时，人们可能会下意识地选择导致程序失败的可能性较低的测试数据，因为这样更容易接近和达成目标。而如果目标是证明程序有缺陷，我们的测试数据将更有可能检测到它们，我们将在测试中获得更多的收获，从而推动软件质量的提升。
“成功的测试用例是检测到尚未发现的错误的测试用例”，从此，软件测试被重新定义，测试主要为了尝试证明程序无法正常工作，从而帮助发现软件质量的问题，并推动质量提升。这与之前的定义和工作方式相反，当这个定义被广泛认同后，软件开发领域逐渐产生了新的测试和分析技术，软件测试领域真正的开始崭露头角。
1.4 面向评估期（Evaluation period）
从1983年到1987年，软件测试的重点是评估和衡量软件的质量。测试提高了对软件工作方式的信心指数，大中型软件没有得到充分测试的情况下是不允许发布的，Winston Royce 提出的“瀑布模型”在这个时期几乎是唯一被广泛采用的软件开发模型，模型中要求测试人员在下游进行测试，直到达到可接受的点，检测到的错误数量减少，否则将无法进入到下一个环节。
自此测试阶段被认为是软件产品研发过程中不可或缺的阶段，如工业领域一般，QA 开始进入到软件开发团队，测试结果决定了产品是否达到发布标准。相应的为了提高这个阶段的研发效率，一些自动化测试的工具逐渐出现。当年的软件开发领域不像工业领域可以靠堆积大量的人力去降低耗时，人才是十分稀缺的，所以提效工具自然而然的就被酝酿了出来。
1.5 预防期（Prevention period）
1988年 William Hetzel 出版了“软件测试的成长”一书，他将测试按规划、设计、构建、维护和执行这几个研发环节做了区分，不同的环节测试的行为和目的不同。显著的变化是从产品规划阶段就涉及到了测试行为，这个阶段的测试更多的是针对产品方案进行测试，起到提前预防的作用，有点类似我们的需求和用例评审。
测试所起到的作用更加广泛，不仅需要证明软件符合预期，还要尝试发现更多的故障，并且还要尝试预防缺陷。在这个时代，识别测试技术是关键。20 世纪的最后十年也出现了探索性测试，测试人员探索并深入了解软件以试图发现更多错误。再往后测试驱动开发 (TDD) 和行为驱动开发 (BDD) 等新测试概念兴起，也是试图更早的起到预防的作用。啰嗦一句，可能不少年轻人对于软件测试的这个时间线会觉得跟我们的认知有些脱节，主要是因为我们国家软件行业起步较晚，如果把这个时间线加上10-20年，并且把每个时期压缩，基本上就能对齐我们国内的软件业发展节奏了。
历史告诉我们软件测试是基于对软件质量要求越来越高而形成的特定领域，又因为某个时期的大型软件对质量有极高的重视度，催生了专职且专业的软件测试工程师这个角色和岗位，但一些中小型特别是start up公司，他们并不会设立专职的软件测试工程师，但别搞混淆了，没有测试工程师不代表他们不做软件测试。所以我们可以尝试达成概念上的一致，软件测试这个环节和行为是不可或缺的，软件测试工程师的角色则根据公司和产品定位会有不同的设定。
纵观软件测试发展史，如果我们把整个开发阶段想象成一条有限的线，从需求规划（requirement）到产品上线，我们会看到测试阶段是如何向左移动的：它最初是在产品完成阶段的活动，后来开始在开发中后期活动，再后来更是提前到了需求规划阶段，这种现象被称之为测试左移。所以你会发现，我们近两年大力提倡测试左移非常符合软件发展历史规律。所以接下来我们直接聊「测试左移」，一个张口就来，却没有背普遍深入理解的概念。
02
测试左移（Testing shift left）
众所周知，缺陷越晚在生命周期中被发现，修复起来就越困难，成本也越高。整个项目的风险和压力时常在瀑布模型下层层传递最后压在了测试人员的头上，因此软件测试社区中近些年最重要和最广泛讨论的趋势之一便是左移测试，试图打破这种局面，寻找更平衡更有效的方法保障质量。
2.1 怎么理解左移
测试左移本质上意味着“经常测试，并尽早开始”。但是为什么它被称为“左”呢？听上去容易令人困扰但很好理解，我们通常习惯从左到右阅读（除了阿拉伯、希伯来和意第绪语等少数语言），所以如果我们要表示一个连续的阶段，描述方式会从最左边开始向右，瀑布模型中的阶段可以表示如下：
Requirement → Design → Implementation → Verification → Maintenance验证阶段（通常就是测试活动）是倒数第二个阶段，如果我们想把测试活动提前到研发阶段更早期开始介入，则需要把 Verification 阶段向左侧移动，于是社区将这样的趋势称之为左移。
然而，不要误解测试左移提倡的测试是一个离散的阶段，只放在开始阶段，而非结束阶段。因为在真正的软件敏捷开发中，不应该有阶段，而是更早的开始关注质量和介入测试，是在短的迭代周期中发生的连续活动。
2.2 为什么要左移
几十年来，无数大型项目证明了瀑布模型会导致缺陷通常在生命周期后期被发现，这种工作模式下，时间久了就会对这个软件项目造成巨大的伤害：
许多需求、架构和设计缺陷直到在它们的实现上浪费了大量的时间后才被发现和修复。
代码和功能越堆越多，调试（包括识别、定位、修复和回归测试缺陷）变得更加困难。
封装使得执行白盒测试和在测试期间实现高水平代码覆盖率变得更加困难。
修复缺陷的时间比开发新功能的时间更多，项目可能会尝试牺牲质量，这会加剧技术债的产生，如果不加以管控，可能会使项目沉没。
如果为了提升质量而放慢项目节奏，项目进度将会成为灾难，因为开发们将会面临着改不完的bug，做不完的需求变更。
造成这上面一系列问题的原因在于软件开发项目中，项目成员总是对质量保证有不同的对待，他们承担着不同的角色、拥有不同的职责、定义了不同的工作描述和以及不同的领导。
我们在工作中，特别是在腾讯的传统项目管理风格下，经常会碰到以下场景：
测试人员时常处于高压状态，一方面要为项目进度承担风险，一方面要为项目质量承担主要责任，这样很容易导致测试环节的执行效果变形。
开发人员、产品人员和测试人员长期保持对立状态，测试本着工作职责要保证最终产品的质量，会严格把控产品和开发的输出，但开发有时会将问题归咎到产品，而产品又会将矛头指向开发，当开发和产品达成一致时又会将矛头指向测试。
测试环节的完成度和效果，几乎完全依赖当前这个测试执行者的个人能力和经验，如果遇到能力不足，或工作状态不佳的情况，最终输出的产品质量可能会造成灾难。
但是，如果我们将质量保证和开发人员以及团队其他所有角色挂钩，quality assurance is everyone’s responsibility，作为一个项目团队每个人都要为质量负责，共同的目的是生产最终适合客户的产品，我们很大几率会得到以下效果：
在软件开发生命周期的早期发现错误，并且能有效降低解决错误的成本。
获得更高质量的产品，意味着打更少的 patch，改更少的 bug，更少的加班。
产品发布预期会更加可控，降低每个人发版本的焦虑。
极少技术债，代码库一直保持高质量维护状态。
因为质量保障人人有责，所以我们提倡质量左移。又因为我们希望推动质量左移，所以人人都应该参与质量保障。
2.3 如何开展左移
如上面所说，测试左移是要让开发参与到质量保障中来，将测试行为推向编码阶段。一个很好的采用方法是测试驱动开发 ( TDD )， 它首先根据程序应有的逻辑来实现单元测试，然后编写使测试正常工作的代码。这种做法的目的是在开始写代码之前有一个清晰的结构，一个更健壮和高效的代码（包括测试代码），对于后续的迭代更具有持续性（持续集成，持续测试）。
还有一种工具化的测试左移的方法是使用静态分析工具。静态分析工具有助于识别参数类型或接口使用不当的问题，将这类工具集成在 IDE 里可以更早更快的发现问题，比如大家熟知的 ESLint 便一个非常著名的静态代码检查工具。
此外，行为驱动开发 (BDD) 也可以加速测试左移的开展。BDD 定义了一种所有利益相关者都可以理解的通用设计语言，例如产品经理、开发人员和其他角色。因此，它使所有相关利益相关者能够同时处理相同的产品功能，从而加快团队的敏捷性。特别要注意的是，这种模式较好地卷入了产品人员提前关注质量，将左移进一步前置，以将需求结构化的形式来验证需求质量。试想一下，如果一个 scenario 写出来就觉得不对劲，是不是应该先看看需求哪里有问题，而不是急于去实现它。所以换句话说，BDD 可以促进跨团队协作，同时缩短了功能交付时间。
不过我们应该要理解的是测试左移的顶层思想，目标上希望尽可能早的发现甚至规避问题，角色上需要全员为质量负责，执行上是要将软件测试主流的冰淇凌模式转变为金字塔模式，基于这个思想之下具体到团队该怎么做，完全可以因地制宜，比如 BDD 和 TDD 本身并无冲突，甚至还可以尝试 BDD+TDD 的模式，另外 TDD 更适合无用户交互的项目比如纯后台，BDD 则更适合重交互的项目如客户端和前端，还有 TDD 的进化版本 ATDD 是一个更重用户体验的模式。
2.4 测试左移的局限性
推行测试左移，通过 TDD、BDD 和 ATDD 框架，研发团队可以利用清晰的流程来捕获需求并在低级别（单元测试）和高级别（验收测试）进行测试，以确保应用程序的质量，并且可以持续的享受稳定可靠的测试代码带来的收益。然而，在现实世界中，我们面临着许多压力——竞争、时间、技能短缺——这使得这一切都难以成为现实，或者在执行过程中产生各种各样的技术变形，最终实现效果并没有达到预期。
举个充分具有腾讯特色的例子：开发A 在很好的践行 TDD 开发，但某天产品说今天上午开会老板对一个特性表示了不同意见，产品们中午饭都没吃开会讨论出了调整方案，希望明天就能上线，时间紧迫来不及废话，就拿着这张照片开发吧（会议室白板拍下来的方案），这时开发A 该如何保障质量？可能有人说这太特色了，场景反而没那么多，那再举个常见的例子：Android 50/iOS 80要发布了，开发B 提前拿到了开发者版本要针对新系统对 APP 做一次全面体验和质量排查，发现了不少严重影响用户使用的问题，大部分是兼容性问题可以直接优化，也有一些是新功能产生的体验问题需要产品给方案，但临新系统发布不到一周时间了，这时开发B该如何保障这波更新的质量？
受时间和资源所限，我们只能将质量放在需求交付之后再进行把控，以希望快速发现和修复，避免产生更大范围和更严重的影响，这就涉及到了下一个话题，测试右移。
03
测试右移（Testing shift right）
3.1 怎么理解右移
如果在产品开发周期的早期进行测试意味着向左移动，那么稍后进行就必须向右移动。这就是测试右移的意义所在——在产品发布后进行测试。按照测试左移的概念，我们将在生产环境进行的测试行为和质量保障称之为测试右移。
在去年的一项由 Capgemini 和 Broadcom 联合进行的问卷调查中，生产中的测试被列为目前实施或计划中的首要实践。此外，39% 的受访者提到使用运营分析来确定或优化测试覆盖率。简单来说就是越来越多的软件企业开始重视生产环境的测试验证，而非一味的追求前置的保障。
当被问及客户如何衡量持续测试流程的有效性时，利用生产数据和利用用户反馈分别排名第一和第二。
有些专业人士将测试右移划到SRE领域，也有一些DevOps概念将之称之为TestOps，强调测试与运维之间的紧密结合，甚至还有一种说法叫运维左移，叫什么不重要，重要的是这说明测试右移引起了足够的重视，值得关注和尝试。
3.2 为什么要右移
先说第一个理由，创建质量门（Quality Gate）是开始左移运动的一个行之有效且简单的方法。大多数公司都有某种类型的生产质量门，最简单的形式是“所有测试用例的 X% 必须通过，并且关键优先级缺陷少于 Y。” ，相信各位都经历过或正在经历这个阶段。更DevOps的玩法则是流水线质量红线，通过持续测试以及红线来拦截潜在的质量问题。
但是如测试左移局限性章节所述，有些时候我们会收到来自各方的影响甚至干扰，导致技术动作变形，质量门也好流水线红线也好，时常会被打破和践踏，前几年作为测试工程师我最大的噩梦便是来自项目经理的一句「我们再来review下bug单」......下图是一张常见的影响和可能性对缺陷优先级的视觉描述。低影响 + 低可能性 = 低优先级（P2）；低影响 + 中等可能性 = 低优先级（P2）；低影响 + 高可能性 = 中优先级（P1）；中等影响 + 中等可能性 = 中优先级（P1）；中等影响 + 高可能性 = 高优先级（P0）；高影响 + 高可能性 = 关键优先级（P00）。善于发明创造的鹅厂项目经理可能还会发明P000，甚至P0000来让更多缺陷看上去优先级没有那么高，从而放过问题尽快发布。
于是在缺乏适当的质量心态的团队或者场景下，第一道门被打破后，必须建立起第二道门来对质量进行把控，否则千里之堤将毁于蚁穴，每一次的缺陷漏出（不论是有意还是无意）都会对项目的未来造成不同程度的影响甚至伤害。
这第二道门便是测试右移（也可以叫做质量右移），当缺陷在并非我们预期的阶段漏出了，我们应该具备足够的能力和手段（工具）发现并修复，并且确保未来不会再次漏出。
再说第二个理由，研发团队提高速度的最有效方法之一是将质量目标左移，也就是测试左移。实际情况，我们也正在推动早期测试的各种基础设施和管道，以最终减少新增代码发布到生产并且质量稳定的时间。前面我们也探讨了有多种测试可以轻松地将测试行为向左移动，例如单元测试。但有时候有些事情超出了传统测试工程师的覆盖范畴， 例如服务器可能会停机，又如一些热点事件导致访问激增，性能和可用性问题随时可能爆发。虽然部署到测试环境可以模拟与生产相当的环境，但事实证明模拟毕竟是模拟，不是完全替代品。
生产环境的全面广度和多样性很难在测试环境中复制，用户流量的真实场景也很难模拟。即使我们根据以往的案例构建并优化了测试手段，随着生产需求的不断发展，维护这些配置文件和行为也成为一项重大责任。此外，生产环境也在不断变化。它从来都不是一成不变的，即使我们的业务没有变化，它下面的一切也在不断变化，比如它所依赖的基础设施。因此，经过一段时间后，团队发现某些类型的测试只能也必须要在生产环境中进行。
两个理由其实只是从不同角度说了同一件事，百分百的可靠性/质量通常是一个不切实际的目标。我们从 Google 的 SRE 哲学中学到的一个关键原则是，100% 的可靠性/完美质量的产品不仅不切实际，而且通常成本太高而无法实现。SRE 建立了服务水平目标(SLO) 和风险预算的概念，以量化生产系统中可接受的风险容忍度，同样的原则也适用于测试和整体质量。Netflix 在这方面我个人觉得已经做到了业界极致，他们在2019年O'Reilly SACon 上名为《Anatomy of Testing in Production》的分享介绍了 Netflix 如何演进到在生产环境做测试的全历程，内容非常清晰明了，我就不在本文越俎代庖凑字数了。
3.3 如何开展右移
关于测试右移，我的经验并不多，还在边学习边实践，很多事物都超出了我以前的经验范畴，涉及到很多新名词、新角色和新技术，我用我有限的知识帮大家捋一捋，开阔下思路。
数据分析能力：由于大多数生产数据都是大量、多样且通常是临时的，因此我们必须进行数据分析，以便快速从这些数据中获得洞察力，并与其他数据集进行关联以识别操作。高级分析技能（例如预测分析或机器学习）对于预测事件（例如发布质量）也是必不可少的。虽然这些分析技能在运营领域都是稀松平常的事物，不过对于开发人员和测试人员来说相对较新。
CX 测试能力(Customer Experience)：CX 现在被认为是衡量生产质量的关键指标。如今常见的 CX 测试包括 A/B test、金丝雀测试以及众测。与其他运营数据一样，CX 数据通常也非常庞大且通常是非结构化的。虽然理论上来说 CX 应该是运营团队关注的事情，但如果要在生产环境做质量保障，则需要获得足够的技能来从 CX 流程和数据中收集数据并提升洞察力。举个例子，现在腾讯文档的很多生产缺陷反馈都来自于用户反馈，然后其中参杂着体验问题和功能缺陷，开发人员不得不对这些反馈做一道手工过滤，以便将有效的质量问题转入研发计划，这显然是一种低效的做法。
监控和操作能力(Ops)：了解监控原理（例如创建、测试和部署监控器以及使用监控器中的数据）是测试右移的一项关键技能。同样，熟悉 oncall 流程，运营手册（事件、故障、警报、MTBF、MMTR、配置定义等）也是非常必要的。
可靠性技能：越来越多的项目开始组建 SRE 团队，说明可靠性已经被意识到是一个非常关键的质量属性。SRE 涉及到测试的包括混沌/弹性测试、部署和回滚测试以及配置测试。
新工具的支持：对于测试右移来说，工具的支持是不可或缺的，没有合适的工具就无法执行测试右移，这其中包括监控、数据分析（针对生产和 CX 数据）、CX 测试（例如 A/B 和金丝雀测试）和可靠性测试等很多领域的工具。
复盘能力：当问题无法避免的在生产环境被放大，我们除了第一时间修复问题外，还需要对问题进行复盘，找出根因，想办法从源头或者更早的环节发现和拦截问题，甚至从最早的设计阶段就可以避免它，不要浪费每一个被漏出去的问题，「Now, what did we learn today?」。
04
自动化测试 VS 测试自动化
如果你有耐心认真看到了这里，恭喜你已经开始对测试领域产生了兴趣，那么我们接着聊点更「测试」的东西，也就是开头提到的自动化测试和测试自动化的区别。
不管是前面说到的测试左移还是测试右移，都绕不过自动化测试这个词，那么「测试自动化」又到底是个什么概念？作为开发我需要理解这个东西吗？是不是测试领域的故弄玄虚？它们是相关的概念，但每一个都有非常具体的含义和目的。在简单聊过测试左移和右移的重要性之后，是时候定义这两个概念，阐明它们之间的不同和相似之处，因为他们的区别真的很重要。
先说自动化测试，“自动化测试”只是自动运行一组特定的测试并验证其结果的过程，而不是手动进行。当我在机器上跑运行单元测试时，我正在做的是自动化测试。当有人MR新代码时，CI 流水线自动执行单元和集成测试，它也在做自动化测试。接着说测试自动化，“测试自动化”解释起来可能有点棘手，虽然自动化测试=将测试验证通过自动化执行，但“测试自动化”是一个更广泛的概念。它是指将管理组织内部不同测试需求以及行为的整个过程完全自动化。
如果把自动化测试比作流水线（Pipeline），那测试自动化则是工作流（Workflow）。现实情况自动化测试确实更多的是以 pipeline 的形式运用在 CI/CD 中，而测试自动化则是通过 worklfow 的形式对研发流程中涉及到测试行为进行编排，使这些环节可以自动串联和执行，而每个环节是用自动化测试还是其他测试工具来实现，都是测试自动化需要考虑的范围。
4.1 自动化测试
贯彻自动化测试团队中收益最大的角色是谁？在我看来，答案很明确：开发人员，but why？为了方便开发同学们聚焦，让我们暂时专注于单元测试。其实“单元测试”并不是一个很好的名字，对于初学者来说，他们可能会被带偏认为覆盖了某个函数就叫单元测试或者代码覆盖率达到 X%就叫好的单元测试。真正意义上的单元测试要考虑的东西很多，或者说单元测试要承载的功能很多：
提升代码质量，它可以帮助开发人员在进行集成测试之前识别单元中可能存在的最小缺陷。
提升调试性，可测试性一定程度上等于调试性（capability of being (easily) debugged）。
功能文档，想要了解代码逻辑的开发人员可以通过阅读每个单独模块的单测轻松了解系统。
开发效率，因为单元测试天然是自动化测试的缘故，可以快速变更快速验证快速迭代。
提升信心，重构代码和更新引用库变得更加容易，不论是担心改动对他人的影响，还是他人的改动对自己的影响，在进入下一阶段之前，优秀的单元测试意味着该单元在与其他模块集成之前已被证明处于正常工作状态。
单元测试是由程序员编写的，对于程序员来说，是为了“证明”，至少在一定程度上有信心，一段给定的代码确实做了它应该做的事情。截至目前，自己验证自己产生的代码，听上去很合理，收益最大的人自然也是自己或其他协同开发的人，即开发人员。
我们再将“可执行规范”的定义扩展到集成测试。集成测试简单来说就是将测试范围扩大到系统级别的功能验证，并且使用真实的数据库/文件系统/账号等而非模拟/存根。集成测试要考虑的东西是什么，或者说集成测试要承载的功能有哪些？我就不再展开细说了，聪明的你一定已经结合上面单元测试的结论有了自己的答案。
最后我们将“可执行规范”的定义扩展到端到端测试，已无需多言，答案似乎很清楚：项目中“自动化测试”的主要受益者是开发人员。或者，换句话说：自动化测试是实现开发人员理性的工具（曾经的你「一把梭」过吗，DDDD），测试代码和业务代码相辅相成，它允许开发人员无所畏惧地重构，因为他们知道有一个可靠的安全网，分别在不同层面以测试套件的形式出现，如果他们破坏了什么，都会被发现并被拦截。
看到这里如果你还认为自动化测试是为了节约测试工程师人力，那......是在下认输了。
4.2 测试自动化
贯彻测试自动化，团队中谁会从中受益最大？这个答案可能有争议，但在我看来最大受益人依然是开发人员。
在传统的瀑布模式的组织中，测试只不过是整个周期中的另一个阶段。测试阶段往往发生在周期结束或接近结束时。我们在前面的测试左移中已经讨论的足够清晰，这样做实在太晚了，反馈周期变慢会降低整个测试策略的实用性和效率。如今，推行 DevOps 的公司正朝着全面 CI/CD 的世界迈进，他们不能永远等待测试的反馈，测试本身必须是连续的（continuous testing），这样才能在开发的所有阶段确保质量，不然 CI/CD 很难完整。
在这种情况下，自动化测试是可以派上用场，但这只解决了单点的测试行为被自动化执行的问题。如果要将测试完全且彻底的融入到 CI/CD 中，这必须依赖更完整的测试工具链，比如测试环境、测试数据（账号、素材等）的自动生成和管理；又比如通过 IDE 实现本地开发远程执行自动化测试；再比如针对一些核心业务或模块需要设置定时任务以及风险告警；最后再提一个对自动化测试本身的运营思路，使用自动化测试本身已经比较成熟没有难度，但在哪个阶段/环节执行，执行哪种类型的测试任务，执行结果是否可以作为有效的拦截依据，这些是需要花些心思的。如果前面说的这些测试域的事情不能自动化，就很难提升自动化测试的速度和一致性，也无法连续的启动和运行测试。更恶劣的情况甚至会让自动化测试本身变得非常困难且容易出错，而且还很耗时，最终失去了做这件事的全部意义。这并非危言耸听，腾讯文档项目就正在经历着折磨......
通过自动化管理上述测试需求，测试自动化可帮助组织在整个开发周期中将质量保持在最高标准。此外，测试自动化我认为属于测试域，属于研效部的事儿，而非业务自己做，他们要考虑工具的持续迭代，考虑解决通用、抽象的问题，这意味着业务的开发们可以专注于创建更有针对性的 testcase 并更有效的通过测试代码来覆盖（对，我说的就是你，刷覆盖率的，出来挨打）。这点文档后台团队做的就不错，在我跟他们短暂的合作过程中能感受到他们在踏踏实实的写能让自己放心的 UT，并将工具交给更专业和专注的团队去负责，这里要点名感谢 Testone 后台测试工具链的开发同学非常接地气的合作。
说到这里我埋个小坑，今年的 DORA state of DevOps 2021 report 又重点强调了持续测试，他们指出正在进行 DevOps 转型的公司的持续测试能力对能否真正实现持续交付有着重大影响，未来我应该会输出一些关于持续测试的内容。
4.3 我该怎么做
我在这里澄清“自动化测试”和“测试自动化”之间的混淆，并不是想争论命名的歧义，而是概念本身确实不同。我希望给开发同学们普及更广泛的测试概念，如果你希望你的团队能持续以最高质量标准交付软件，就要懂得更多。自动化测试很重要，尤其是让开发人员有信心无畏地重构他们的代码，毫无疑问，这有助于提高代码质量，你已经感受到我很克制的在传递「自动化测试完全应该由开发人员自行完成」这个思想。但是，当你的团队或项目开始转向持续集成/持续部署（CI/CD）场景时，测试自动化变得至关重要，因为测试不仅要左移也要右移。除此以外还要将测试行为流程化并且尽可能自动化，质量不是一道门就可以完全把关好，而是需要层层把关，守护好自己创造出来的东西。当你了解了测试自动化这个更高维度的概念，你便走进了如何通向高质量产品的大门，你会发现质量这东西除了测试工程师，还要跟 Infra/SRE，DevOps 工程师和数据工程师等各种角色打交道和密切配合才能追求卓越，精益求精。
05
来自 EX 测试的寄语
笔者在腾讯做了近十年的测试工程师，很多开发人员因各种理由习惯性的将隐患甚至显而易见的问题直接丢给下一个环节也就是测试，真正发自内心对质量和品质有意识的开发屈指可数，不过有个很有意思的现象是，这些凤毛菱角的开发们现在都逐渐担做起了管理工作，有的做完需求敢跟我对赌，一个 bug 一顿饭，利用我来鞭策他提升自己的开发质量；有的当 bug 辗转多人几个月仍未解决的时候，我就会想到把 bug 单转给他，即便不是他负责的模块他也会抽时间根治，并且很讨厌的拉着你说一堆你一点也不想听的分析过程；当年合作时还没升技术高 P 的某位，质量意识之高从现在腾讯会议这款产品完全能体会得到。腾讯文档的开发们我就不夸了，一来做的确实还不够好，二来怕大家骄傲～
我在想，可能没有天生就对质量有追求或测试能力强的开发，但一定有 owner 意识、责任心以及合作精神都很强的开发，他们重视自己所做的项目，重视自己的每一个产出，重视跟自己合作的伙伴，所以他们愿意花时间，甚至牺牲时间去保障质量。拥有这样品质的同事，已不仅仅被局限在是一位优秀的开发，一定会被领导认可，被放在更高的位置去影响更多人。
“在计算机存在的整个过程中，如何设计软件以及如何开发软件一直是一直讨论的中心。没有哪篇文章像 Frederick P. Brooks 的“No Silver Bullet”那样成为讨论的核心。然而，在他写下这篇对知识的贡献将近 35 年后，布鲁克斯的观察仍然正确。软件工程是一个复杂且要求很高的领域，它给从业者带来了许多问题，并且没有单一的解决方案，即没有灵丹妙药，可以提供一种简单的方法来减少创建软件产品所需的工作。”
很多开发者觉得让开发为质量负责，对开发们造成了很大的伤害，甚至是一种变相的压榨。但现在政策和市场暗流涌动，互联网行业风云变化，快速抓住机遇和有效保障质量之间如何平衡很难抉择，去测试化不是银弹，但不可否认是符合趋势的一种为未来做人才储备的手段。至少我们要先学会自动化测试，并接受测试左移和右移的思想，这是软件测试发展的趋势，再远一些几十年后会怎么样我不知道，当下我们只是在尝试走别人走过的路，仅此而已。
-End-
原创作者｜顾况
感谢你读到这里，不如关注一下？👇
📢📢去测试化意味着测试失业？点击下方图片得到答案！👇
让开发去做测试是好事还是坏事？欢迎评论留言。我们将选取1则优质的评论，送出腾讯云定制文件袋套装1个（见下图）。4月10日中午12点开奖。
