从社会发展上来说，各领域的分工越来越细。但从技术部门的发展上来看，测试和开发的角色却是在不断融合，背后的原因是什么？是互联网迭代的速度越来越快促成的多角色融合，还是因为技术（特别是质量技术）先进生产力在逐渐取代落后的生产力？
在回答这些问题之前，我们先来回顾 “测试工程师” 作为一个职能或者个体在过去的发展历程：
10 年前，最初级的测试产出工件是比较一次性的，比如项目中写的文本型测试用例，基本在项目发布后就废弃了。
那个时期测试工作的进阶是方法论，比如能够把测试用例的设计方法，项目流程管理讲得头头是道已经是高阶了。
有一些技术能力的测试同学，投身于自动化脚本的编写。自动化在 “软件” 测试时代和互联网初期，是真正的硬核能力。
但这样的测试模式和效率都是非常低的，显然无法支撑互联网无快不破的浪潮。2010 年以后，在头部企业的测试团队发生了一系列的变革，快速地从上述的这些初级能力，扩大到以 CI/CD 为驱动的技术体系，并最终推动了测试技术产品化进程，形成一个较为清晰的测试平台发展脉络。
在这个将近十年的周期中，由于测试工具、平台的不断创新，测试团队得到了一个突破性的发展。但工具作为传统测试模式的辅助手段，仍然会遇到突破的瓶颈。比如，从全球来看质量也发生了一定的分支：
一种是不断坚持平台化的发展路径：项目质量是基础，不断孵化出各类的效能平台，解决的问题也从传统的质量领域本身，往研发各环节拓展。有些大型的企业也开始沉淀了通用的研发协同平台（研发流水线）。
一种是从内往外突破：比如 Google 的 SRE 团队，以纯技术的手段，打造一个内建且自洽的质量体系（传统以证伪为理论依据的是一个外建的质量体系）。[1]
这两者的方向和目标，是有一定的重合的，比如有些公司以测试负责线下，SRE 负责线上进行区分。但如果从质量这个大的目标来看，未来的成功画面应该是：“质量和效率的结合” 和 “外建与自洽的结合”。因为只有这样，才能打造一个真正完整的技术质量生态。
也是基于上述的一些思考和实践，我们在 2017 年底提出了 “实时质量” 的概念。“它不是一个具体的测试技术产品，而是一种面向未来解决质量问题的方法和手段。”
它的主要特性是：运行含测试，实时可反馈。
为什么要往这个方向发展？
随着技术的不断创新和交付模式的不断改变，对于测试团队来说，需要尽快地从交付型质量往实时质量方向进行转移。传统的交付型质量，把测试作为一道道关卡，以任务的方式布防在开发提测、项目发布时。这种方式存在不同角色之间的过多交互，只能起到单点的质量保障。而实时质量的目标是：将质量手段以模块、组件乃至系统化的方式嵌入到业务型应用中，形成实时保障质量的能力。 未来开发和测试人员之间的合作（或者就不区分开发测试了），不仅仅是人与人之间的协同，更多是双方分别为完成 “业务特性服务的代码” 和为完成” 业务质量服务的代码 “而相互配合，并形成系统级的依赖关系。在提供的这些质量系统上，我们希望公司内部的各种角色都能成为质量的操作者。只在做到这些，我们才可能将测试工作真正从面向过程到面向对象。
图示：理想的测试工作方式
要做到质量的实时反馈和面向对象测试，这意味着我们的测试方法和协同方式发生了较为根本性的变化。我们需要以一个合适的方式参与到业务应用中，与此同时我们还需要把测试的各种能力封装成一个个服务，而不是现在的工具。工具终究是需要人来操作的，而我们希望未来测试任务的主体是机器、算法。测试人员只构建测试服务，而不参与测试过程，这也是最符合测试开发 Test Development Engineer 的 job design 。
图示：实时质量架构
那测试到底还需不需要做功能测试？可能在很长一段时间内仍然是需要的，但那一定只是日常工作中很小一部分。
我们在推进一个新的方向时，尽量不要去推翻重来。如果要面向未来，实时质量必须是可以向下兼容的，因为只是这样才能继承现有的测试沉淀，也才能被团队中的测试人员所接受和支持。只有自己不断进化才符合自然规律。所以我们需要更多强调对现有测试能力的改造，而避免另起炉灶。以下用运营页面测试的实时质量改造作为一个案例。
★ 案例：运营页面的实时质量改造
作为电商域的同学对于运营页面应该非常熟悉，在之前也非常痛恨。比如：
“CBU 的一次大促，运营人员至少需要配置千级以上的活动页面，而每一个页面上又包含几百上千个商品等活动元素，平均一个页面需要 5 到 10 分钟的人肉检测，同时运营和测试人员需要不断就测试标准和 Bug 来回讨论、提交。一次大促下来，我们至少需要十几人/日的测试资源才能保证会场的正确性。”
这个过程很痛苦，运营人员需要不断去找对应的测试同学协同，幸福感很差。而测试人员来说，这些页面的测试更多是一个重复劳动，一个黑盒。能力也得不到什么成长。我们如何对它来进行实时质量的改造呢？
总共分两步：
我们对传统的测试体系进行了改造。把以往通过人工测试的各个测试点，通过自动化的方式来实现。比如基于 DOM 树制定一系列规则，例如 403 这些的错误都可以被很好地扫描出来。同时，针对于一些无法通过规则排查的问题，我们运用了算法能力。例如空坑检测，一致性检测等。
把以上测试组件，通过消息的方式跟运营页面发布系统对接。
它的系统依赖关系是如下的：
图示：运营页面检测系统依赖图【示意】
同时针对于不同的业务场景，我们开发了不同的页面检测能力，比如针对于 DOM 树的页面检查：
还有基于算法能力的识别能力：
通过上述的改造后，对于运营人员发布页面以及页面的测试就极简化为三步一站式的能力。从以往运营、测试、开发之间的来回交接，变成了运营跟系统之间的交互。不仅提升了运营人员的页面搭建体验，也极大地提升了测试的效率。
在某次运行中活动中实际的执行结果【示意图】：
以上的过程和结果数据，也充分体现了 “运行含测试，实时可反馈” 的价值。
测试出现以来，我们一直习惯于代码逻辑类的测试，但数据一直都是测试很重要的生产材料。因为人肉执行任务的局限性，我们发明了等价类和边界值等测试理论和方法来用尽可能少的成本来尽可能多的验证问题。但一方面算法的不断应用，每一个数据都可能存在个性化的业务表达，我们可能无法找到一个通用的预期结果较验（还是会有一些通用的预期结果的，比如非空判断和区间等，但这类的预期不能很好地做业务判断）。因此，我们也需要用数据和算法能力来武装自己。
在以数据驱动的业务发展进程中，我们的测试主体已经从简单的代码转变为数据 + 算法。或者说，业务对质量的核心述求，已经从简单的页面错误、代码 BUG 到数据的准确性、算法的有效性（我老板在每次大促前，都要再三叮嘱我数据不能错）。如何来感知质量风险，以及捕获各类的异常？那必须先把数据、流量、监控来做收口，同时提升测试工具在大数据分析上的能力。
基于这些思考，我们构建了全域实时数据校验能力，是一款通过实时获取线上 DB 中的海量业务数据，完成业务数据校验、质量风险感知的产品。
★ 案例：Captain 全域实时数据校验
图示：数据对比框架【示意】
它具备的一些能力：
严格的安全策略。
实时获取线上数据：通过强大的数据支持能力，平台可以在无损线上数据库表的前提下，通过 SQL 查询获取线上 DB 中的真实业务数据，且做到了实时获取，通过数据可以进行完善健壮的数据校验，从根本上提高对于业务的把控。
多样的数据获取方式：目前平台支持多种数据获取方式：单库单表查询、单库多表联表查询、分库分表查询、跨库的多表的联表查询。
多种比对方式支持，比如跨库查询和联表查询等等。
最主要，它可以用一套脚本无损地支持测试环境、灰度、生产环境等。让线下测试的所有经验可以得到复用和沉淀。（我们内部调侃说，这才是带着测试的灵魂的，而其他的很多产品都只是一个面向开发的工具）
在前期解决数据一致性，对账等常用的基本需求上，我们可以依赖于这些数据和测试的服务，展开更多的业务形态。
★ 测试的边界在哪里？
过去有人告诉我，不能去修改业务应用的代码，只能让在盒子外面或者调用的方式来测试。还有人说，我们只开发工具，不能接触任何的业务。现在这些都在逐渐模糊，大家努力一起，让测试的很多活动，从简单的功能测试，往研发工具和业务质量等或前或后地迁移。
在过去的一两年，我们团队也已经慢慢承接了更多的职责，有些甚至于是直接服务于客服、运营和产品人员的。我认为，一支强的团队一定是不断走在突破原来工作边界的道路上。没有什么是一成不变的。
但每个职能团队都是有自己的核心价值的，而至于哪些应该由测试来做，哪些由开发做。我们的标准是：判断这件事情是更为了 “让技术更有品质” 还是 “让技术创造新商业”？（“让技术更有品质” 是我们团队的使命，“让技术拓展业务边界” 是开发团队的目标）
以下虽然是几年前的例子，但也很好的体现了我们在边界的突破，以及如何用实时质量的思想来开装自己，创造提交 BUG 以外更多的价值。
★ 案例：Offer 360 提升客服端实时质量能力
商品链路复杂，线上问题排查难度大，之前开发每天平均投入 2-3 个小时处理线上问题，但实际上大部分的问题都是正常业务逻辑，并且可以让客满或者技术支持自助查询的。因此，我们通过提供实时查询错误日志以及 debug 信息的服务，把用户反馈问题的排查，开放给客服。帮助他们第一时间解决用户的问题。
实时质量是一种思想，我觉得它未来是可以跨越在当前两种不同的发展分支上的。
测试这么多年来一直被弱化，我也看到集团很多优秀的测试 leader 转型开发、产品。如果我们还不多些思考，多些探索。如果做测试都还没有梦想，那跟咸鱼有什么区别？
图示：测试未来的发展
后记
上周在内部的论坛上看到一个开发专家的留言，还是挺有感触的。我们一直以来都在强调测试能力不断演进，强调开发能力，但测试的初心不能丢。我们在工具、测试能力上不断改进，但是从人和组织的角度上来看，在追求最高效的同时，我们是需要一定的组织设计来形成岗位间的相互监督。这也是在测试 1.0 阶段开始，测试被赋予的一种职责。
“在阿里这几年的感受是，开发做的事越来越多，设计、测试、运维、交付等工作都由开发来做。导致岗位间的互相监督制约不够；一个萝卜一个坑，一个坑一般只有一个萝卜，导致同应用同岗位之间的交流、协作不多。岗位中传帮带，互相 review 机制不够；开发压力重，为了拿业务目标，在没有监督制约的环境下，很多基础事情的优先级被放低。因此，建议不要迷信系统的监督，系统有覆盖不到的地方，有过时的地方，有能绕过去的地方。不要放弃岗位间的监督，几十年的软件工程发展出各个岗位，有其自身的价值和门槛，一味的赋能开放，最后会变成什么都不精。至少测试、开发两个岗位要分离。”
阿里内部论坛
做测试总还是要有点梦想的，如果对我们做的事情有兴趣。
欢迎加入我们： batu.hjj@alibaba-inc.com
微信：http_home
