大厂的测试数据链路图是如何设计的？

前面的文章中我们为大家介绍了互联网大厂中通科技测试工具体系模型图以及具体实践落地的那些部分。本文我们把其中的测试数据链路图也跟大家分享一下。

最上面一行是我们最外面的一个系统，是暴露给用户的，最外层的一些交互系统。有项目管理系统、发布系统、代码仓库、缺陷管理和OA，这些平台和我们的测试平台之间都会有一些交互。

比如说质控中心，质量控制这一块主要是对测试流程、报告、一些过程当中的问题，做一些管控管理。还有一些专项测试的流程，评审报告等等。质控中心很大一部分是做在做一些管理的工作。

那左边这一块，其实是一个覆盖率的度量、缺陷度量、版本、项目、产品线、中心，都是围绕着各个不同的维度，去做一些度量，这个后面会再跟大家详细看。

上面项目管理系统我们建了版本都会跟质控中心有一个交互，这样大家把所有的版本全部统一起来，只需要数据的同步流向就可以了。

发布的话，需要走一些准出的自动化。发布的时候，如果这个应用没有走准出的话，在发布系统，它会去提醒去做一个准出的自动化的运行。

运行后有结果了它就会允许你继续往下走。后面就是缺陷管理等，在发一些测试报告的时候，需要去跟缺陷系统进行一个交互。这时候就会告诉你，你在发布的时候，有哪些bug是还没有进行验证的，这个时候就不能发报告。

OA这块体现了一些数据同步，包括一些报告、数据流向的一些相关信息。

在中间这块，在质量控制中心下面就是精准自动化平台、压测平台、压测分析平台、测试工具平台。

但其实在质控中心，在发报告的时候，需要你做一个自动化的准出，你的准出报告会被同步到质控中心，发报告的时候就会体现在里面。

同样的还有一些代码覆盖率的一些相关报告会同步。在你发送测试报告的时候，也会去把它拉出来。如果你的覆盖率这个标准不达标的话，可能你这个上线就没法上，然后这个标准我们都是用统一规范了。

压测的话也是一样的，会去在这个质控上提交一些压测的场景、压测申请、脚本结管理等等。在质控上建一个压测的计划，这个压测计划跟这个压测平台之间可以交互，需要你把压测的数据进行一个同步，最后发出去这个测试报告。

最底层的是什么呢？其实我们前面也提到了，这个测试中台的第一个目标就提供一些即插即用的服务。也就是我们的一些基础服务，这些服务都是都是可以单独拿出去用的。

资料中心、消息服务、代码覆盖率等等这些都是一些单独的服务。需要相关的服务与其交互时，你就可以选择不同的部分，去引用它，就可以达到你想要的一些效果。

以上这些就是测试中台的数据链路图。前面是我们的模型图，前后我们讲了根据这个目标模型图我们实现落地了哪些？实践落地的这些之间的一些交互、数据流向、模型是什么样的。接下来的文章我们会把每一块带大家详细讲解一下，欢迎大家继续关注。