若是测试没有梦想，那跟咸鱼有什么区别？

软件质量不是测出来的，但为何又有这么多测试工程师为了质量而工做？测试是一个成本部门，测试创造的价值是什么？研发的模式在不断地变化，测试的定位如何不断去定义，将来的测试又会是什么形态？今天，阿里巴巴高级测试开发专家傲野总结了对将来测试形态的一些思考，但愿对正在作测试的同窗有所启发。

前言

从社会发展上来讲，各领域的分工愈来愈细。但从技术部门的发展上来看，测试和开发的角色倒是在不断融合，背后的缘由是什么？是互联网迭代的速度愈来愈快促成的多角色融合，仍是由于技术（特别是质量技术）先进生产力在逐渐取代落后的生产力？

在回答这些问题以前，咱们先来回顾“测试工程师”做为一个职能或者个体在过去的发展历程：

• 10年前，最初级的测试产出工件是比较一次性的，好比项目中写的文本型测试用例，基本在项目发布后就废弃了。
• 那个时期测试工做的进阶是方法论，好比可以把测试用例的设计方法，项目流程管理讲得头头是道已是高阶了。
• 有一些技术能力的测试同窗，投身于自动化脚本的编写。自动化在“软件”测试时代和互联网初期，是真正的硬核能力。

但这样的测试模式和效率都是很是低的，显然没法支撑互联网无快不破的浪潮。2010年之后，在头部企业的测试团队发生了一系列的变革，快速地从上述的这些初级能力，扩大到以 CI/CD 为驱动的技术体系，并最终推进了测试技术产品化进程，造成一个较为清晰的测试平台发展脉络。

在这个将近十年的周期中，因为测试工具、平台的不断创新，测试团队获得了一个突破性的发展。但工具做为传统测试模式的辅助手段，仍然会遇到突破的瓶颈。好比，从全球来看质量也发生了必定的分支：

• 一种是不断坚持平台化的发展路径：项目质量是基础，不断孵化出各种的效能平台，解决的问题也从传统的质量领域自己，往研发各环节拓展。有些大型的企业也开始沉淀了通用的研发协同平台（研发流水线）。
• 一种是从内往外突破：好比 Google 的 SRE 团队，以纯技术的手段，打造一个内建且自洽的质量体系（传统以证伪为理论依据的是一个外建的质量体系）。[1]

这二者的方向和目标，是有必定的重合的，好比有些公司以测试负责线下，SRE 负责线上进行区分。但若是从质量这个大的目标来看，将来的成功画面应该是：“质量和效率的结合”和“外建与自洽的结合”。由于只有这样，才能打造一个真正完整的技术质量生态。

实时质量

也是基于上述的一些思考和实践，咱们在2017年末提出了“实时质量”的概念。“它不是一个具体的测试技术产品，而是一种面向将来解决质量问题的方法和手段。”

它的主要特性是：运行含测试，实时可反馈。

为何要往这个方向发展？

随着技术的不断创新和交付模式的不断改变，对于测试团队来讲，须要尽快地从交付型质量往实时质量方向进行转移。传统的交付型质量，把测试做为一道道关卡，以任务的方式布防在开发提测、项目发布时。这种方式存在不一样角色之间的过多交互，只能起到单点的质量保障。而实时质量的目标是：将质量手段以模块、组件乃至系统化的方式嵌入到业务型应用中，造成实时保障质量的能力。将来开发和测试人员之间的合做（或者就不区分开发测试了），不只仅是人与人之间的协同，更可能是双方分别为完成“业务特性服务的代码”和为完成”业务质量服务的代码“而相互配合，并造成系统级的依赖关系。在提供的这些质量系统上，咱们但愿公司内部的各类角色都能成为质量的操做者。只在作到这些，咱们才可能将测试工做真正从面向过程到面向对象。

图示：理想的测试工做方式

实时质量的架构

要作到质量的实时反馈和面向对象测试，这意味着咱们的测试方法和协同方式发生了较为根本性的变化。咱们须要以一个合适的方式参与到业务应用中，与此同时咱们还须要把测试的各类能力封装成一个个服务，而不是如今的工具。工具终究是须要人来操做的，而咱们但愿将来测试任务的主体是机器、算法。测试人员只构建测试服务，而不参与测试过程，这也是最符合测试开发 Test Development Engineer 的 job design 。

图示：实时质量架构

那测试到底还需不须要作功能测试？可能在很长一段时间内仍然是须要的，但那必定只是平常工做中很小一部分。

实时质量是基于现有测试能力改造

咱们在推动一个新的方向时，尽可能不要去推翻重来。若是要面向将来，实时质量必须是能够向下兼容的，由于只是这样才能继承现有的测试沉淀，也才能被团队中的测试人员所接受和支持。只有本身不断进化才符合天然规律。因此咱们须要更多强调对现有测试能力的改造，而避免另起炉灶。如下用运营页面测试的实时质量改造做为一个案例。

案例：运营页面的实时质量改造

做为电商域的同窗对于运营页面应该很是熟悉，在以前也很是痛恨。好比：

“CBU的一次大促，运营人员至少须要配置千级以上的活动页面，而每个页面上又包含几百上千个商品等活动元素，平均一个页面须要5到10分钟的人肉检测，同时运营和测试人员须要不断就测试标准和 Bug 来回讨论、提交。一次大促下来，咱们至少须要十几人/日的测试资源才能保证会场的正确性。”

这个过程很痛苦，运营人员须要不断去找对应的测试同窗协同，幸福感不好。而测试人员来讲，这些页面的测试更可能是一个重复劳动，一个黑盒。能力也得不到什么成长。咱们如何对它来进行实时质量的改造呢？

总共分两步：

1. 咱们对传统的测试体系进行了改造。把以往经过人工测试的各个测试点，经过自动化的方式来实现。好比基于 DOM 树制定一系列规则，例如403这些的错误均可以被很好地扫描出来。同时，针对于一些没法经过规则排查的问题，咱们运用了算法能力。例如空坑检测，一致性检测等。
2. 把以上测试组件，经过消息的方式跟运营页面发布系统对接。

它的系统依赖关系是以下的：

图示：运营页面检测系统依赖图【示意】

同时针对于不一样的业务场景，咱们开发了不一样的页面检测能力，好比针对于 DOM 树的页面检查：

还有基于算法能力的识别能力：

经过上述的改造后，对于运营人员发布页面以及页面的测试就极简化为三步一站式的能力。从以往运营、测试、开发之间的来回交接，变成了运营跟系统之间的交互。不只提高了运营人员的页面搭建体验，也极大地提高了测试的效率。

在某次运行中活动中实际的执行结果【示意图】：

以上的过程和结果数据，也充分体现了“运行含测试，实时可反馈”的价值。

数据和算法是实时质量的核心

测试出现以来，咱们一直习惯于代码逻辑类的测试，但数据一直都是测试很重要的生产材料。由于人肉执行任务的局限性，咱们发明了等价类和边界值等测试理论和方法来用尽量少的成原本尽量多的验证问题。但一方面算法的不断应用，每个数据均可能存在个性化的业务表达，咱们可能没法找到一个通用的预期结果较验（仍是会有一些通用的预期结果的，好比非空判断和区间等，但这类的预期不能很好地作业务判断）。所以，咱们也须要用数据和算法能力来武装本身。

在以数据驱动的业务发展进程中，咱们的测试主体已经从简单的代码转变为数据+算法。或者说，业务对质量的核心述求，已经从简单的页面错误、代码 BUG 到数据的准确性、算法的有效性（我老板在每次大促前，都要再三叮嘱我数据不能错）。如何来感知质量风险，以及捕获各种的异常？那必须先把数据、流量、监控来作收口，同时提高测试工具在大数据分析上的能力。

基于这些思考，咱们构建了全域实时数据校验能力，是一款经过实时获取线上 DB 中的海量业务数据，完成业务数据校验、质量风险感知的产品。

案例：Captain 全域实时数据校验

图示：数据对比框架【示意】

它具有的一些能力：

1. 严格的安全策略。
2. 实时获取线上数据：经过强大的数据支持能力，平台能够在无损线上数据库表的前提下，经过 SQL 查询获取线上 DB 中的真实业务数据，且作到了实时获取，经过数据能够进行完善健壮的数据校验，从根本上提升对于业务的把控。
3. 多样的数据获取方式：目前平台支持多种数据获取方式：单库单表查询、单库多表联表查询、分库分表查询、跨库的多表的联表查询。
4. 多种比对方式支持，好比跨库查询和联表查询等等。

最主要，它能够用一套脚本无损地支持测试环境、灰度、生产环境等。让线下测试的全部经验能够获得复用和沉淀。（咱们内部调侃说，这才是带着测试的灵魂的，而其余的不少产品都只是一个面向开发的工具）

在前期解决数据一致性，对帐等经常使用的基本需求上，咱们能够依赖于这些数据和测试的服务，展开更多的业务形态。

实时质量须要不断突破测试的边界

测试的边界在哪里？

过去有人告诉我，不能去修改业务应用的代码，只能让在盒子外面或者调用的方式来测试。还有人说，咱们只开发工具，不能接触任何的业务。如今这些都在逐渐模糊，你们努力一块儿，让测试的不少活动，从简单的功能测试，往研发工具和业务质量等或前或后地迁移。

在过去的一两年，咱们团队也已经慢慢承接了更多的职责，有些甚至因而直接服务于客服、运营和产品人员的。我认为，一支强的团队必定是不断走在突破原来工做边界的道路上。没有什么是一成不变的。

但每一个职能团队都是有本身的核心价值的，而至于哪些应该由测试来作，哪些由开发作。咱们的标准是：判断这件事情是更为了“让技术更有品质”仍是“让技术创造新商业”？（“让技术更有品质”是咱们团队的使命，“让技术拓展业务边界”是开发团队的目标）

如下虽然是几年前的例子，但也很好的体现了咱们在边界的突破，以及如何用实时质量的思想来开装本身，创造提交 BUG 之外更多的价值。

案例：Offer 360提高客服端实时质量能力

商品链路复杂，线上问题排查难度大，以前开发天天平均投入2-3个小时处理线上问题，但实际上大部分的问题都是正常业务逻辑，而且可让客满或者技术支持自助查询的。所以，咱们经过提供实时查询错误日志以及 debug 信息的服务，把用户反馈问题的排查，开放给客服。帮助他们第一时间解决用户的问题。

实时质量将来规划

实时质量是一种思想，我以为它将来是能够跨越在当前两种不一样的发展分支上的。

测试这么多年来一直被弱化，我也看到集团不少优秀的测试 leader 转型开发、产品。若是咱们还很少些思考，多些探索。若是作测试都尚未梦想，那跟咸鱼有什么区别？

图示：测试将来的发展

后记

上周在内部的论坛上看到一个开发专家的留言，仍是挺有感触的。咱们一直以来都在强调测试能力不断演进，强调开发能力，但测试的初心不能丢。咱们在工具、测试能力上不断改进，可是从人和组织的角度上来看，在追求最高效的同时，咱们是须要必定的组织设计来造成岗位间的相互监督。这也是在测试1.0阶段开始，测试被赋予的一种职责。

原文连接 本文为云栖社区原创内容，未经容许不得转载。