上面我们已经为大家介绍了测试工具体系模型图以及具体实践落地的那些部分。我们把这其中的数据链路图也来给大家分享一下。

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

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

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

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

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

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

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

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

但其实在质控中心，在发报告的时候，是需要你做一个自动化的准出，你的准出报告会被同步到质控中心，发报告的时候就会体现在里面。
同样的还有一些代码覆盖率的一些相关报告会同步。在你发送测试报告的时候，也会去把它拉出来。如果你的覆盖率这个标准不达标的话，可能你这个上线就没法上，然后这个标准我们都是用统一规范了。
压测的话也是一样的，我们会去在这个质控上提交一些压测的场景、压测申请、脚本结管理等等。

我们在质控上去建一个压测的计划。这个压测计划跟这个压测平台之间可以交互，需要你把压测的数据进行一个同步，最后发出去这个测试报告。

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

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

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