前面的文章我们为大家介绍了中通科技质量控制中心的产生背景、整体的技术架构以及质量控制中心的质量看板部分，本文将为大家详细介绍精准自动化测试部分。

下一个就是我们精准自动化测试的系统架构图，精准自动化主要是我们自动化运行的一个平台。用户的请求进来会先进入到ngnix，做一些负载均衡的处理，下面这一行绿色的部分是一些即插即用的服务插件。

最右边就是我们会用到的一些任务调度、任务状态相关的一些技，这个架构图上也都有体现。

接下来就是自动化测试的这一块。我们目前支持http接口、dubbo接口、测试脚本、移动专项测试。

团队成员可以在这上面编写自己的自动化脚板，去配置一些脚本执行的策略，然后对自动化的脚本做一些规范性的检查，这些脚本运行完，结果都会推送到测试人员的邮箱里，会收到一些及时的推送。

前面的文章中我们也提过，我们测试环境的稳定性是通过心跳检测来保障。我们所有的应用都是需要对接到心跳检测，必须要有一个心跳检测的用例，然后配置到自动化平台。

心跳检测从很大的程度上保障了我们测试环境的稳定性。因为现在业务的交互是非常非常多的，可能几十个应用之间都有相互的依赖。如果你中间某个环节有问题的话，那整个测试环境都要崩溃了。

所以我们需要一个比较方便的一种方式，那这个地方就是，我们每个运用都需要配置一个心跳检测。之前我们的网关大约有几十个心跳检测。上百个这种网关都需要借这样一个心跳检测，去快速、准确、及时地通知到我们的测试伙伴，去维护测试环境的稳定。

精准自动化还有一个批次运行结果。刚刚我们也讲了，我们的自动化可以配置自己运行的策略。有一些是准出自动化，也就是说我们的应用在准出的时候必须要运行的一些自动化，有一些是定时的。

我们的团队成员可以根据自己的需要去配置测试策略，运行结果都会展示在我们的批次运行结果里面。可以去查看错误日志等，去进行一些分析。

还有最重要的一块，是我们对运行结果的一个分析。

这个视图是站在部门领导的角度去看的，他可以去看一下我们整个部门、项目组最近这一段时间的自动化测试运行到底是一个什么样的情况，失败是多少？从各个部门、各个角度、各个维度去分析。

另外一部分是我们dubbo的mock。其实我觉得http或者dubbo这些东西问题都不大，主要是实现的原理和思路。现在的一些测试团队中，大家所做的一些项目，一些大团队的应用都是中间穿插了十几个应用，这样的情况下，我们的测试人员测试起来就非常的麻烦。

如果说我们的一个应用中间穿插了十个环节，中间有一个应用，它现在要发版，那它怎么测呢？它依赖于上面，又依赖于下面，是不是就没法测了？不是的，我们有mock这种方式，做一个挡板。

我们只需要在我们的平台上去配置这样一个挡板，然后打一个标签，告诉我们的平台，中间这块服务我要做一个挡板，做一个标记。把你的预期值、mock值、期望的值配置到系统中。

在运行的时候，如果你是打了标签的，那它就会去读你的期望值。这样对于中间环节应用的测试就非常方便了，他不需要去管上下游。当然这个知识在我们自己测试的阶段，如果你要做回归测试的话，还是需要串起来的。

这个是在快速迭代的过程中，给我们的测试成员提供一种简便的方式，能够快速把自己的部分的测试完成，可以很快再去做回归，可以大大提高测试效率。

上图就是我们上面提到的，mock信息的配置。