前段时间与某互联网大厂质量负责人针对测试左移和测试右移进行了探讨，以下系列文章为整理其口述内容。测试左移和单纯的把测试减少有哪些区别？要理解测试左移，首先我们要一起聊一下，哪些行为属于测试左移？我们总结了测试左移的几个比较重要的行为：评审、技术对齐、自测赋能和多角色协作。上篇文章给大家介绍了评审，接下来讲一下自测赋能。
所谓自测就是让研发自己来做测试。让研发来做测试，其实他缺乏两部分的能力。第一部分的能力是我们大部分的研发缺乏测试的意识和测试的规范。
比如说，研发在做测试的时候，是需要做交叉测试的。为什么呢，比如说你自己写了你自己功能模块的代码，如果你考虑到这个地方可能会出bug，你一定不会写出这个bug，因为你已经从思想上把它避免了，所以你写的时候一定会避开这个bug。
所以说你自己去测你自己的代码的时候，实际上是不能发现自己的问题的，必须得其他的研发来发现自己的问题。这也是为什么测试去测研发能测出问题。
第二个，自测需要一些准入准出的一些标准。比如说你自己写的测试，肯定是有一个单元测试的覆盖率，或者是一些报告，把它提出来当作准出的一个标准。准出的标准有了之后，才算自测阶段的结束。通过这个可以规范研发自测的行为，来提高他们自测的意识。
第二个方面是说，我们可以为研发搭建一些自测的技术骨架。下图是一般测试脚本会有的一个分层和骨架。最右侧是它的一个测试框架，底层是它的模型层代码，中间是一些自定义的抽象，抽象的上面就可以写实际测试的脚本了。
这样脚本写起来相对来说比较简单，像积木一样进行组装就可以了。实际上，研发所需要做的自测工作在你给他搭建了技术骨架之后，其实是比较简单的。
我们这边也是这样，我们会写一些测试的骨架，骨架写完之后，告诉研发可以写这些东西来做自测。他也可以跟我们在同一个测试代码仓库里进行一个协作，来写测试脚本的代码。