优品软件培育计划【第四期】② —— 追求高投入产出比的测试左移与测试右移（测试左移）
2020/11/26
优品软件培育计划百场前沿技术系列讲座直播的第四场为大家请到的是字节跳动网络架构质量保障负责人赵悦，他同时还承担质量保障团队的测试平台搭建和测试方案设计等工作，在业务测试、测试平台设计、测试流程管理等方面拥有丰富经验。直播结束后，不少朋友都在点赞其深厚的专业积淀和给大家带来的精彩内容，也在期待视频的回放，现在就将整场讲座的内容整理如下，供大家继续学习使用。
我们都知道最近“测试左移”跟“测试右移”这两个概念被炒的比较火，今天我们也来探讨一下“追求高投入产出比的测试左移与测试右移”这个话题。首先我们先来思考三个问题：“凭借测试动作可以保障质量吗？”、“测试左移和测试右移指的是什么？”、“左移和右移过程中需要掌握什么概念、工具以及思想？”今天的讲座会从【软件工程生命周期】、【测试左移】、【测试右移】、【数据度量】这四个部分去展开。
首先我们去了解一下哪些行为属于测试左移？测试左移和单纯的把测试减少有哪些区别？我总结了测试左移的几个比较重要的行为：评审、技术对齐、自测赋能和多角色协作。我们先来看一下评审。评审大家都比较熟悉，一般分为三种，一种是产品经理主导的需求评审、一种是研发主导的设计评审，再就是测试的设计评审。首先跟大家一起看一个真实的案例，这也是我们线上曾经出现过的问题。
系统版本升级，新的配置项需要进行一些数据的升级。在做数据升级的时候，在配置项里有一个字段是userID，指的是这个配置对哪个用户生效。旧系统里存在一些数据，在升级迁移的过程中会导致userID这个字段为空。这也是比较常见的一种情况，当字段为空的情况出现时，空的逻辑在新的版本升级之后，这一条配置会对所有的用户生效。就造成了在这个版本升级了之后，脏的数据会变成一条错误的数据应用在了所有用户上面。
如果我们去加强测试设计来模拟，我们就一定要做系统升级时的数据测试，同时也需要去做脏场景，脏场景必须要脏到配置项的userID为空这种场景。这也是非常难以考虑到的一种情况，需要细致到每一个字段，并且这个字段还要为空，才能浮现这个问题。
这个问题其实是研发设计评审阶段应该被发现的一个问题。因为研发设计的逻辑允许userID为空，但是为空的时候是对所有用户都生效的。脏数据产生的时候，空是一个默认值，也就是默认在迁移之后，这条数据对所有用户生效，这显然不符合最基础的逻辑。也就是说研发的脆弱设计才会导致这样一个bug的形成。所以在研发设计评审的过程中，去多方参与评审，就能发现这个问题，而不是把这个问题尝试通过测试阶段来拦截。总结一下，在评审阶段，做测试左移的时候为什么要强调评审？第一个是说，在代码的实现阶段以前，在需求的环节，在研发的环，都可能产生bug。并不是所有的bug是从代码本身或者实现代码本身的过程中产生。实际上在设计的阶段引入的bug是非常多的。第二个是，越早发现bug，解决这个bug的代价就越低。最后一点是，评审是多角色对齐的一件事情。无论大家是做需求的评审还是做研发设计的评审，还是做测试设计评审，是这三方进行认知对齐的一件事情。做过认知对齐之后，是可以平摊风险和责任的，后期也就不会出现扯皮的情况。举一个接口测试的例子，上面这张图是自动化接口测试比较常用的一个实现逻辑。左边是一个研发的模型定义，右边是一个测试的模型定义，一般来说，这两个模型定义是相同的。先解释一下这个模型定义或者也可以叫做模型类到底是什么。我们写接口测试，一般来说是需要写请求的对象和响应的对象，把请求的对象发出去，然后再拿到响应这个对象，然后再去校验响应的对象。请求的对象跟响应对象本身是都是基于这个模型类的，研发的模型定义里其实也有这个模型类，测试为了写接口测试也会有模型类，所以理论上来说，这两个模型类应该是对其的，不过有时候可能他们俩不是同一种语言。所以在接口测试的过程中，模型类是非常重要的。
如果研发的模型变动，比如说他的模型增加了一个字段，相当于他的接口请求里加了一个字段，或者是响应里多加了一个字段，或者删了一个字段，测试这边其实是非常难以同步的，尤其是现在，流水线触发比较常见的情况下，其实我们很难去处理这样一个同步。比如说研发这边就真的改了一个东西，马上就触发流水线，马上就跑测试了，测试几乎是没有时间去改变这个模型定义的。这就变成了技术上没有对齐的一个情况。
解决方案是这样的，首先我们需要去使用一些标准的模型定义，现在比较通用的模型定义有两套，一套是rpc请求上的thrift格式，还有一个是http请求上的swagger的模型定义格式。他们都是对标准模型的一个定义。有了这个定义之后，哪怕研发和测试是使用不同的语言的，他们的模型定义也可以进行同步。再就是，研发代码改动的时候，可以通过一些自动化监控的措施来把模型定义同步到测试，同时生成测试的模型类代码。最后就是标准模型可以生成可视化的接口文档，一方面测试可以提早介入，研发给出接口设计之后，测试可以马上写接口测试用例了，另一方面，前端也会比较轻松，因为后端已经给接口定义了，前端开发起来也会很快。下面我们一起看一下前面提到的模型类和接口定义文档规范的实例。最左侧是swagger文档中定义的一个http的一个接口定义。由这个文档也可以直接生成测试的模型类代码。有了这个东西之后，测试去写接口自动化测试的代码就很方便了。这就是一个由标准模型类定义→可视化的文档→测试脚本的一个过程。接下来我们讲一下自测的赋能，所谓自测就是让研发自己来做测试。让研发来做测试，其实他缺乏两部分的能力。第一部分的能力是我们大部分的研发缺乏测试的意识和测试的规范。比如说，研发在做测试的时候，是需要做交叉测试的。为什么呢，比如说你自己写了你自己功能模块的代码，如果你考虑到这个地方可能会出bug，你一定不会写出这个bug，因为你已经从思想上把它避免了，所以你写的时候一定会避开这个bug。所以说你自己去测你自己的代码的时候，实际上是不能发现自己的问题的，必须得其他的研发来发现自己的问题。这也是为什么测试去测研发能测出问题。第二个，自测需要一些准入准出的一些标准。比如说你自己写的测试，肯定是有一个单元测试的覆盖率，或者是一些报告，把它提出来当作准出的一个标准。准出的标准有了之后，才算自测阶段的结束。通过这个可以规范研发自测的行为，来提高他们自测的意识。第二个方面是说，我们可以为研发搭建一些自测的技术骨架。下图是一般测试脚本会有的一个分层和骨架。最右侧是它的一个测试框架，底层是它的模型层代码，中间是一些自定义的抽象，抽象的上面就可以写实际测试的脚本了。这样脚本写起来相对来说比较简单，像积木一样进行组装就可以了。实际上，研发所需要做的自测工作在你给他搭建了技术骨架之后，其实是比较简单的。我们这边（字节跳动）也是这样，我们会写一些测试的骨架，骨架写完之后，告诉研发可以写这些东西来做自测。他也可以跟我们在同一个测试代码仓库里进行一个协作，来写测试脚本的代码。最基础的一个软件团队，他的三个角色是产品经理、研发、测试，有可能会带运维、技术支持这样的岗位。多角色协作一般会用到两个平台，一个是需求管理平台，或者说是缺陷管理平台，需求和缺陷一般来说是管理在同一个平台上。另一个是自动化流水线平台，这个是偏技术项的一个平台。在使用这些平台的过程中，要求各个角色之间话术的对齐。这个话术的对齐指的是，比如说我作为产品经理，我说的一个东西，跟你是一个研发你说的东西到底怎样是一致的？
对产品经理来说是一个需求，对于研发来说可能是一个新功能的代码分支。这个新功能的代码分支进行提测之后，对于测试是一个新功能的测试，他其实是需要在新功能的测试环境上去做测试的。如果说这是一个可稳定发布的版本，也就是说刚才说的新功能做完了，这个新功能已经合并到主分支了。对于研发来说，就变成了发布代码分支，对于测试来说就变成了回归测试。这些话术要对齐，对齐了之后，才能在平台上进行多步骤的拆分，进行流转。
最后一点是说，多个角色之间是可以相互帮助来解决问题的，大家的关系不需要闹得那么僵，可以相互帮助来解决问题。比如说研发可以通过暴漏一些后门来提供高可测性，这个例子可以这么理解，有些功能很难测，也很难测到，测试没有办法进行操作，对于测试来说这叫做“没有可测性”。那么研发可以开一个后门，比如说开一个接口，开了这个后门之后，测试就可以得到原本没有办法测到的一些信息，可以校验更多的东西。第二个是产品经理可以通过一些提示文案，来避免误操作，规避易用性问题。这个相对来说比较常见，比如说，我们经常可以看到一个版本升级了之后，如果一些功能改变了，或者说一些按钮的位置变化了，产品经理可以做一些小提示，让用户能够看到。用户看到这样的小提示之后，他就不会去认为这是一个应用性的问题。第三个是说，测试可以将内场的测试脚本放到外场去做，在线下写的测试脚本如果写得够通用，或者说屏蔽了数据的干扰，那你也可以把测试本身放到线上去跑，来给我们的交付和运维来使用。所以说多角色之间是可以来相互帮助来解决这些问题的。然后让我们来看一下测试左移的要点和误区，我总结的测试左移的要点是降低成本、提升效率。我们在测试阶段最重要的成本其实是时间，如果我们把这部分的测试动作左移到了跟开发或者设计的阶段是平行的，那明显是可以提升效率的。预防bug要比拦截bug的成本要低，我们尽量要在设计和评审的阶段来拦截bug提升测试效率，多角色对齐和约定是提高速度的关键，我们前面也举了很多例子，通过多角色的对齐或者平台的约束，可以提高测试的效率，或者说交付的效率。误区1：测试左移就是把测试交给研发；质量不是测出来的，所以就不需要测试了。这句话是非常错误的，虽然质量不是测出来的，但是如果不测，那就连质量是多少都不知道。所以测试本身是衡量质量的一个方法。不要care测试是在测试阶段发生的还是测试人员去做的，就算这个测试本身是自动化的，或者这个测试本身是研发帮你测的，这都无所谓，这都叫测试。并不代表测试左移了之后就是不要测试了。这个思想是因为，测试左移了之后，测试时间段也会左移，左移了之后会跟研发单测的时间点比较近，但是问题是，其实大部分的bug其实是发生在集成阶段，就是人和人之间沟通、系统和系统之间沟通的这样一个阶段。单元测试本身并不能拦截系统绝大多数的bug。误区3：测试左移的主要是，在测试阶段之前发现bug这样说其实也没有错，但是从我们刚才讲的来看，在测试阶段之前，是需要去做一些临时的铺垫，比如说一些评审、对齐，这些其实是会降低后续测试的成本，提高测试的速度。所以说广义上来说，测试左移并不是说我一定要在测试的左移过程中发现足量的bug。而是说，我也可以为测试打通各个环节，提高效率、让自己的测试阶段发现更多的问题，让自己的测试速度进行得更快。
