质量体系建设 - 测试左移/右移

zhsttty

已于 2024-06-19 10:07:19 修改

阅读量1k

点赞数 22

分类专栏：软件测试基础文章标签：功能测试单元测试

于 2024-06-18 09:46:15 首次发布

本文链接：https://blog.csdn.net/weixin_43011308/article/details/139763102

版权

软件测试基础专栏收录该内容

2 篇文章 0 订阅

订阅专栏

前言

随着互联网技术的逐渐完善，软件测试领域已经不再局限于单纯的功能测试，而是开始从流程等方面下手去治理质量。

这几年有一个很火的概念叫作测试左移/右移。就是把整个测试的流程向左移动/向右移动，简单地来说就是尽可能早地介入测试，更晚地结束测试。那么为什么要把测试活动往前推，向后挪？这样做的意义在哪？有什么好处？又该怎么去做？下面详细地展开讲一讲

测试左移

先谈一谈测试左移。测试左移提倡测试人员尽可能早地介入测试，而不是等到需求转测后才开始介入。

最早互联网时代，采用的是【V模型】的流程，这种流程中，正式的介入测试其实是在需求转测后，这样的话开发和测试之间的工作是独立出来的，代码设计阶段，测试不知道开发是用什么方案设计的，也不知道开发有没有听懂需求，跟自己的理解有没有误差，一切都只有等到需求转测后才能知道答案。

V模型

V模型这种模式，不仅效率低下，而且由于很多其他的原因，比如说一些bug在耽误了这么长一段时间后，即使找到了也不好修改了。后来大多数的互联网公司就抛弃了【V模型】，选择使用【W模型】。这种模型，提倡开发和测试的工作同步进行，当开发在做技术选型时，测试也在了解需求准备测试用例，开发做技术评审，测试也做测试用例评审。大家都尽早地参与到了整个需求流程中，不仅提高了效率，对质量也有一定的提升，这便是一个测试左移的例子。

W模型

为什么要说这么多，其实是想让大家更直观地了解测试左移的概念以及测试左移的作用，测试左移的根本目的就是为了更早地发现问题。试想一下，如果开发做出来的东西，跟产品需要的完全不一样，而直到需求转测大家才发现这个问题，那么这时候修复起来是不是需要花相当多的时间与精力？而如果你能在技术评审或者用例评审的环节就发现这个问题，则可以节省下很多时间。

怎么做？

随着软件测试行业的发展，测试左移已经不再局限于简单的【W模型】，而是有了更多其他的方法

需求评审、技术评审、用例评审

1.1需求评审

当在进行需求评审时，希望大家不是只关心产品要实现什么样的功能，而是要在这个基础上，思考一下产品要的这个功能是否合理，能否实际地解决问题，会不会有什么隐患或者没考虑到的地方。举个例子，我曾经做过一个需求，是要在小程序中接入一个web页面。当时在需求评审时并没有想太多其他的东西，但是等开发转测后才发现，当流程进行到一个关键的步骤时，就因为域名限制的原因无法继续了，且这个问题无法解决，这是典型的前期调研工作没做好导致的错误，最后大家白白浪费了一周的工期，需求也只能搁置。

1.2技术评审/代码评审

跟需求评审不同的是，在技术评审/代码评审上，更多的是考虑开发的实现方案是否合理，是否会有隐患，性能方面会不会有压力。当然这个环节要求测试人员也有一定的开发基础。

1.3用例评审

用例评审这个环节相信大家已经很熟悉了，我认为一场好的用例评审，测试人员应该是将更多的精力投入在让大家的认知对齐，换句话说是确保所有人对需求的认识是一致的，如果出现了分歧，尽早地解决。并在这个基础上，说明自己的测试思路，这次需求的关联点，有哪些需要特别注意/容易出错的地方，而不是把用例从头到尾念一遍，这种用例评审毫无意义，还不如让开发自己看用例高效。需要注意的是，测试人员并不是全能的，测试人员也会有遗漏的地方，在用例评审上也需要开发、产品的帮助，他们有义务帮你思考哪些地方是有问题的，哪些地方是不是有遗漏，他们进行开发时会改动到哪些地方。用例评审不是你一个人的工作

自动化测试

自动化测试是很流行的一种测试方法，通过自动化测试，可以快速的完成冒烟测试，避免开发在写代码时不小心动到了别的模块的内容。如果改动到别的模块的内容，引发错误，可以更早地在转测阶段发现，降低修复的成本，而不是测试到一半时，甚至上线后才发现问题。

测试用例

3.1用例思路

在这里不讲什么等价类、边界值、场景法之类的用例设计方法，我认为更重要的还是跟上面提到的评审一样，需要思考这次需求的内容可能跟哪些地方有关联，改动会不会影响到其他模块，会不会有一些特殊的场景/数据出现，有没有更好的实现方法，而不是仅针对功能点本身来设计用例

举个例子，这个是一个判断用户购物车总金额的组件。只从这句话和图片就可以看出很多隐藏的测试点。例如：

①用户有多个店铺的购物车时，如何判断购物车金额？

②用户在B端中设置的是美金，但实际C端使用货币是人民币时，汇率怎么换算？

③在shopify后台中，有一个货币选项叫未知货币，当设置了这个选项时，怎么判断金额？

④是否有取不到汇率的币种？如果有的话该怎么处理汇率换算的问题？

⑤这个组件与原有的其他组件能不能串联起来？

⑥汇率换算时，会不会有精度丢失的问题？有的话怎么处理？

如果结合具体的需求内容，还可以挖出更多的测试点。可以看出设计用例的思路比用例设计方法要更重要，方法是死的，思路却是活的

3.2冒烟用例

质量建设不只是测试的工作，团队里的其他成员也应该共同对此负责。作为测试人员的你可以提供冒烟测试用例给开发，让他们进行自测，只有自测通过的需求才能转测。

虽然看起来开发干的事情变多了，但是试想一下，如果开发不进行自测，开发完了就把需求转测，到你手里连流程都跑不通，你还是得打回需求，让他们返工修改，甚至可能出现多次返工的情况。这样子一来一回，花在环境部署与沟通上的时间反而变得更多。与其这样不如让开发进行自测，提交一个不用返工的版本，反而能节约更多的时间。

除此之外，如果你提供了冒烟测试用例，开发人员在开发需求的过程中，也可以参照冒烟测试用例中的场景，一定程度也上减少了转测内容与需求不同的情况

code diff

code diff指的是进行代码比对，就是将开发的代码拉到本地跟上一个版本的代码对比，查看修改了哪些地方，判断测试范围。

通过code diff，可以更清晰地看到开发修改了什么内容，修改的内容是不是对的。有时候开发写代码只考虑了功能层面，但是在别的层面没有过多考虑。比如开发可能为了某个功能，对所有的数据进行遍历循环，这样虽然实现了功能，但是却对性能有很大的负担，仅从页面上可能是看不出来的。

除此之外，这样做可以预防开发夹带代码的问题，通过对比可以发现修改涉及哪些服务，针对这些修改的地方可以查出是否夹带了不是本次需求的代码。这是一张示例图，可以更直观地明白code diff是什么

当然，很多时候其实做code diff并不现实，可以让开发提供测试范围，以及代码的改动是否影响其他模块，通过这种方式得出一个大概的测试范围

测试数据

有时候测试数据不一定要到测试阶段才开始准备，在面对较为复杂，需要大量数据的需求时，可以在转测前提前准备数据，这样在转测后就能直接介入测试，不用再花费时间在造数据上了

code review

如果条件允许，可以让开发也进行code review，作为开发人员在代码方面肯定是比身为测试的你更加专业的，理论上也能够比你发现更多的问题。不过code review的实际效果不好评估。前公司在上线前，要求开发组长必须进行code review，实际效果确实有一些，但是并不多，它预防了一部分较为明显的代码设计上的问题，但是只要稍微隐蔽一点的问题还是没法发现。