前段时间与某互联网大厂质量负责人针对测试左移和测试右移进行了探讨，以下系列文章为整理其口述内容。测试左移和单纯的把测试减少有哪些区别？要理解测试左移，首先我们要一起聊一下，哪些行为属于测试左移？我们总结了测试左移的几个比较重要的行为：评审、技术对齐、自测赋能和多角色协作。上篇文章给大家介绍了自测赋能，本文介绍一下技术对齐。

举一个接口测试的例子，上面这张图是自动化接口测试比较常用的一个实现逻辑。左边是一个研发的模型定义，右边是一个测试的模型定义，一般来说，这两个模型定义是相同的。先解释一下这个模型定义或者也可以叫做模型类到底是什么。

我们写接口测试，一般来说是需要写请求的对象和响应的对象，把请求的对象发出去，然后再拿到响应这个对象，然后再去校验响应的对象。

请求的对象跟响应对象本身是都是基于这个模型类的，研发的模型定义里其实也有这个模型类，测试为了写接口测试也会有模型类，所以理论上来说，这两个模型类应该是对其的，不过有时候可能他们俩不是同一种语言。所以在接口测试的过程中，模型类是非常重要的。

如果研发的模型变动，比如说他的模型增加了一个字段，相当于他的接口请求里加了一个字段，或者是响应里多加了一个字段，或者删了一个字段，测试这边其实是非常难以同步的，尤其是现在，流水线触发比较常见的情况下，其实我们很难去处理这样一个同步。比如说研发这边就真的改了一个东西，马上就触发流水线，马上就跑测试了，测试几乎是没有时间去改变这个模型定义的。这就变成了技术上没有对齐的一个情况。

解决方案是这样的，首先我们需要去使用一些标准的模型定义，现在比较通用的模型定义有两套，一套是rpc请求上的thrift格式，还有一个是http请求上的swagger的模型定义格式。他们都是对标准模型的一个定义。

有了这个定义之后，哪怕研发和测试是使用不同的语言的，他们的模型定义也可以进行同步。再就是，研发代码改动的时候，可以通过一些自动化监控的措施来把模型定义同步到测试，同时生成测试的模型类代码。

最后就是标准模型可以生成可视化的接口文档，一方面测试可以提早介入，研发给出接口设计之后，测试可以马上写接口测试用例了，另一方面，前端也会比较轻松，因为后端已经给接口定义了，前端开发起来也会很快。

下面我们一起看一下前面提到的模型类和接口定义文档规范的实例。最左侧是swagger文档中定义的一个http的一个接口定义。

当它被生成可视化文档时，它是右上角图例这样的。

由这个文档也可以直接生成测试的模型类代码。有了这个东西之后，测试去写接口自动化测试的代码就很方便了。这就是一个由标准模型类定义→可视化的文档→测试脚本的一个过程。