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

评审大家都比较熟悉，一般分为三种，一种是产品经理主导的需求评审、一种是研发主导的设计评审，再就是测试的设计评审。首先跟大家一起看一个真实的案例，这也是我们线上曾经出现过的问题。

系统版本升级，新的配置项需要进行一些数据的升级。在做数据升级的时候，在配置项里有一个字段是userID，指的是这个配置对哪个用户生效。旧系统里存在一些数据，在升级迁移的过程中会导致userID这个字段为空。这也是比较常见的一种情况，当字段为空的情况出现时，空的逻辑在新的版本升级之后，这一条配置会对所有的用户生效。就造成了在这个版本升级了之后，脏的数据会变成一条错误的数据应用在了所有用户上面。

如果我们去加强测试设计来模拟，我们就一定要做系统升级时的数据测试，同时也需要去做脏场景，脏场景必须要脏到配置项的userID为空这种场景。这也是非常难以考虑到的一种情况，需要细致到每一个字段，并且这个字段还要为空，才能浮现这个问题。

这个问题其实是研发设计评审阶段应该被发现的一个问题。因为研发设计的逻辑允许userID为空，但是为空的时候是对所有用户都生效的。脏数据产生的时候，空是一个默认值，也就是默认在迁移之后，这条数据对所有用户生效，这显然不符合最基础的逻辑。也就是说研发的脆弱设计才会导致这样一个bug的形成。

所以在研发设计评审的过程中，去多方参与评审，就能发现这个问题，而不是把这个问题尝试通过测试阶段来拦截。

在评审阶段，做测试左移的时候为什么要强调评审？

首先，在代码的实现阶段以前，在需求的环节，在研发的环，都可能产生bug。并不是所有的bug是从代码本身或者实现代码本身的过程中产生。实际上在设计的阶段引入的bug是非常多的。第二点，越早发现bug，解决这个bug的代价就越低。最后一点是，评审是多角色对齐的一件事情。无论大家是做需求的评审还是做研发设计的评审，还是做测试设计评审，是这三方进行认知对齐的一件事情。做过认知对齐之后，是可以平摊风险和责任的，后期也就不会出现扯皮的情况。