大家看到测试中台的时候，可能会想到研发中台、账户中台、或者其他的一些跟中台相关的内容。我个人觉得测试中台不是每一个团队都适合做的，当你的团队达到一定规模的时候，有能力，有成本，去维护这个中台的时候，大家就可以去考虑去实现这样一个测试中台。

我们这边主要是把我们公共的一些测试服务插件、可独立的服务都归接到测试中台里，再给外部提供一些服务。我们的测试人员通过平台的辅助去高效地完成测试工作。下面是我们测试中台的一个宗旨。

我们的测试中台有三大目标：

1、提供即插即用的测试服务能力
大家也知道，现在我们研发技术团队的技术更新迭代是非常快的，比如说我们现在有ES集群、有MQ消息队列、kafka、还有数据库相关的oracle、mysql等等，在我们的业务线、业务流程非常多的时候，如果我们一个业务线上穿插了十多个这样的应用的话，我们测试人员要把里面的东西全部摸透的话其实是不太可能的。

中间一些底层的，比如说数据库的交互、链接kafka去查询数据等等，像这些我们可以给测试人员提供标准化的服务。比如说我们把这些服务打成一个包，测试人员只需要去找到这个服务进来，就能很方便地使用这一块的功能。

他不需要去了解到底怎样去用，也不需要了解里面到底是一种怎样复杂的使用方式。我们只需要告诉他使用的规范，他就可以去使用了。他不需要考虑我现在这个数据库连的是kafka的消费，我的日志写在哪里呢？是redis呢还是数据库呢？他只需要用这个插件就可以了。

2、提供自动化/性能/移动专项测试等的统一输出能力
因为我们现在有上百位的测试人员，负责的应用也是各种各样的，研发的技术栈也是非常多的。如果我们每一个测试小伙伴大家都去写自己的一套东西，维护起来有上百套，那这个成本是非常大的。

那我们就需要一个团队专门去提供一个自动化、性能、移动专项等等的统一的平台，统一输出，统一管理。我们的测试小伙伴只需要去上面去用就可以了，他们不需要再去花时间自己搭建一个东西。连上我们这个平台会统一管理，实现了统一输出的能力。

3、辅助测试规范化、标准化的统一能力输出
第三部分呢，其实也是基于第二部分的。如果我们把这些工具、插件等统一管理起来的话，我们测试规范的标准化，向外输出的是一个统一的能力输出。

以上就是我们测试中台的三大目标。围绕这这三大目标我们有一个测试工具能力的模型图。接下来的文章，我们将围绕测试工具能力模型图为大家展开介绍我们的测试体系的落地以及实践情况。