炮轰“测试左移”，向软件测试领域的“歪理邪说”宣战 | IDCF

为什么会有这么一个话题呢？很长一段时间，在软件测试领域，一直弥漫着一种悲观的氛围！比如“测试无用论”，“我们需要全职的QA吗”，“人工智能将取代测试工程师”，“测试工程师并没有办法为企业创造利益”等等。

由于一些人或组织有心或无心地制造一些焦虑，让软件测试的从业者尤其是刚入行的软件测试工程师，对软件测试本身的意义，以及软件测试职业的发展、技术路径充满了疑虑！

在此，作为一个从业20年以上的软件测试工程师，一个ISTQB国际软件测试工程师认证的专家级证书获得者，我想谈谈自己的认识和看法，希望能给软件测试从业者一些我觉得正确的软件测试理念和观点。

一、什么是“测试左移”

第一炮我们先从“测试左移”入手，谈一谈我对“测试左移”的看法。

所谓的“测试左移”是什么？

通过百度搜索，国内查到“测试左移”最早的描述起始于2016年底到2017年初。换句话说，“测试左移”是一个新概念。

最初在谈到“测试左移”这个概念的时候，更多是指软件研发过程中的测试活动应尽早介入。

（图一 测试左移）

上面这张图描述了测试左移的基本原理，即软件研发生命周期中的缺陷大部分是在编码过程中引入的，但这些缺陷通常是在编码之后才逐步地发现出来。如果在编码过程中发现和修复缺陷的成本是1X，那发布给用户后，则发现缺陷和修复的成本会增长为640X。这就引出了：如果我们提早做测试工作即“测试左移”，则发现或修复缺陷的成本会显著地降低。这也就是“测试左移”的理论基础。

如果你足够细心，就会发现这张网络流传的图还有个问题，即它默认缺陷的注入是从编码开始的，而真实的情况是只要有人开始参与了研发工作（如需求分析、设计等），就势必会开始注入缺陷，在这里我们就不累述了。

需要注意的是，最早“测试左移”的概念是指测试工作要提前做，而不是特指测试工程师“左移”即全职测试工程师从编码阶段介入，这两者是有区别的！区别我们放到后面再阐述。
“测试左移”虽然提出时间不长，但这是个新概念吗？

软件工程领域最著名的模型毫无疑问是瀑布模型：

大家所熟悉的软件工程瀑布模型（waterfall model）概念，起源于 Winston Royce 发表于 1970 年的著名文章 "Managing the Developmentof Large Software Systems" (Proc. Westcon, IEEE CS Press, 1970, pp.328-339)。

（图二：瀑布模型）

在我看来，所谓的“测试左移”正是在弥补瀑布模型的不足，即不要让测试工作只成为交付前的最后且唯一的质量保障手段，应该往前提，需要贯穿于整个软件研发生命周期中。
但请注意，瀑布模型是1970年提出的，距今已经有50多年了，这么大的一个问题，怎么会几年前才给出个答案？

经典的V模型早把这件事情说完了！

V模型是由Paul Rook在1980年率先提出的，在1990年出现在英国国家计算中心的出版物中，它是对瀑布模型的一种改进。

（图三：V模型）

在这里我不想解释V模型，有兴趣的同学可以在网络上自行查询。

我想说的是，测试工作从需求开始，贯穿于整个软件研发周期是40年前就提出来的，这压根就不是啥新概念，如果你最近才知道那是你的问题！

那为什么近期换了个说法，又提出了“测试左移” ？

测试左移一词（shift-left testing）最早出现在Arthur Hicken的博客里，在他的博客中提到了对测试左移的看法。

(图四：最早谈到“测试左移”)

原文地址：https://www.stickyminds.com/a...

但这篇文章的发布时间是在2018年，比国内开始谈论“测试左移”的时间晚，有可能这个地址并不是首发地址，但并不影响我们的讨论。

从字面意义上看，“测试左移”更多的是强调开发工程师应该在软件研发生命周期内尽早地验证自己代码的正确性。注意是开发工程师自己测试自己的代码。

在敏捷和持续交付的场景下，这个说法一点问题都没有，任何一个工程化的软件研发模型都在强调尽早验证和确认（这就是著名的V&V模型），最早可以追溯到40年前的V模型。

那为什么又开始强调“测试左移”呢？很简单，一直没做呗！没做什么？比如：单元测试、持续集成、单功能点验证等。注意以上这些测试，最合适的执行人员是开发工程师本人。

为什么一直不按照要求做呢？除了怕麻烦、对交付质量要求低、后续还可以让测试工程师代劳以外，还能有什么原因？这也是在敏捷活动中，一直在推动开发人员自测、对自己代码质量负责、进行TDD实践等的核心原因！

综上所述，最开始提出“测试左移”的本意只是再次强调开发工程师应该自己做单元测试，对自己的代码负责，这是个老生常谈的话题。新名词的出现，只是为了让开发工程师再次重视起来！

二、炮轰“测试左移”，炮轰的是什么？

问题1：测试的测试与开发的测试有什么区别？

截止到现在，我们并没有发现“测试左移”的提法有什么问题，虽然“测试左移”本质上只不过重新发明了个名词，换汤不换药 。

可事实上并没有这么简单。

“测试左移”这个提法朗朗上口，随着时间的推移，“测试左移”被曲解成“测试工程师左移”，即测试工程师应该全部变为测试开发工程师，需要具备优异的开发技能，参与到单元测试、集成测试的环节中，或者说直接取代开发工程师来进行代码逻辑和接口的测试，通过编写代码测试代码。

更有甚者甚至鼓吹今后将不再需要不懂代码的测试工程师，不会编码的测试工程师将全部失业，不会有未来，手工测试终将被代码测试代码取代。媒体广告中充斥着测试开发工程师、全栈测试工程师的宣传，这一氛围让手工测试工程师感觉低人一等，逐步被边缘化，一夜之间仿佛软件测试工作不谈代码、不谈自动化就是政治不正确，就是被行业抛弃的角色。

在和领测老贺聊测试的QQ群中总能看到这样的言论，以上的提法在软件测试工程师圈子内持续蔓延，人云亦云的结果就是制造焦虑，对自己技能的不信任，对基于功能测试、基于手工测试工作的质疑！面对开发人员不够硬气，总觉得低人一等，由此进入恶性循环！

为了说明这个问题，我尝试从以下几个方面加以分析：

1）开发工程师和测试工程师的工作目标存在巨大差异

开发工程师的工作目标是实现功能，目标相对明确，判定成功的标准也明确，即目标功能实现正确。

但测试工程师的工作目标是高效地寻找软件缺陷，需要的是风险思维和概率思维，判定测试成功的标准也不算明确，发布后的评估才是终极审判。注意这里评价测试工作的两个维度：一个是高效；一个是缺陷。

2）同样的事情，从组织的角度考虑谁做更划算

做每件事情都有成本，标准的思考模型应该是两利相权取其大，两害相权取其轻。针对代码逻辑的单元测试谁做成本最低？收效最高？当然是编写代码的本尊了！企业必须用最有效率的方案去获取目标。

3）单功能点验证不是测试工程师眼中的软件测试

如果你细心观察，就会发现大多数具有开发背景的工程师口中的软件测试基本上都是单功能点验证，并且他们坚持认为这就是测试的全部。作为一个有20年软件测试经验的测试工程师，我可以很负责任地告诉你，单功能点验证通过只是系统化软件测试的入口条件，绝不是测试的全部，或者在严格意义上来说这根本就不是软件测试。专业的软件测试工作研究的是功能的组合，在无穷无尽的功能组合中寻找当前场景下的最优解才是你应该追寻的目标。什么是最优解？就是在平衡各方利益的情况下，如何最有效率地满足既定的质量目标！

理想情况下，我们拿到的软件就应该是一个单功能点验证通过的产品。换句话说，单功能点验证应该是开发工程师的职责！只有这样，专业的测试工程师才能发挥最大的效用。如果你的公司只做单功能点验证，或者说绝大多数工作都是单功能点验证，我可以明确地跟你说，你做的不是专业测试工作。你测试的产品质量一定很差！

综上所述，开发的测试和测试的测试根本就是两个概念，单元测试本就应该由开发工程师完成，单功能点的验证不能是测试的全部，专业的测试工程师要具备风险思维，要做基于风险的测试覆盖。

让功能测试工程师集体转型做单元测试，并称为“测试左移”，“不是傻就是坏”！

问题2：测试工程师不需要了解代码吗？

软件测试是一个行业，里面有若干工种，随着职位的不同，对掌握代码的技能要求是完全不一样的。例如：同样是厨师，但是面点、西餐厨师，对刀工的要求就远远弱于中餐厨师。

当然，当你掌握了代码后，对测试的效果肯定是有正向加分的，但是我要提醒你一句，你的价值来源于你与团队的技能互补，而不来源于你和团队的技能相同点。

也就是说，你的团队到底是需要一个专业测试工程师做基于风险的测试评估，还是需要一个懂开发的测试工程师，用代码测试代码，从而提高做单功能点验证的效率？这是你或者说你的团队需要考虑的问题！

以国内目前的氛围来讲，现在谈测试工程师需要掌握代码的论调不是太少，而是太多了。而讨论具体如何构建测试体系，让测试工程师掌握专业的基于风险、基于覆盖的测试思维不是太多了，而是太少了。

测试工程师掌握代码本身并没有错，相反还有很大的好处，这会极大地丰富你的测试手段，提高测试效率。但请注意，和整个测试体系的构建来比，这还只是停留在“术”的层面，作为测试管理者必须清醒地意识到软件测试本身到底解决什么问题，效率是锦上添花，科学的覆盖率策略才是根本！没有覆盖率保证前提下的效率带来的只有怀疑和混乱！

问题3：基于代码测试代码的自动化测试可以取代专业的功能组合测试吗？

很遗憾，至少目前不行。

目前的自动化测试技术是将手工测试用例中适合重复执行或数据驱动的用例抽取出来，并将其自动化执行。基于这个原理，自动化测试通常是手工测试的最小用例集，是用来做质量的最低防火墙的。

出于成本考虑，在很多场景下，手工测试的成本也会远远小于自动化的成本。所以也没有道理将所有的手工测试自动化。

再有，例如发现Bug能力超强的探索性测试技术，本身就不需要提前规划测试路径，从原理上说自动化测试是不可能替代探索性测试的。

MBT基于模型的测试技术，至少目前看还不可能建模后做全遍历覆盖，这样会造成用例爆炸。
基于AI进行自主学习的测试，现在并没有看到可以实用的解决方案。还处于探索、研究阶段，对此我也保持谨慎乐观的态度。

说了这么多，无非是想说明，依靠代码测试代码，测试开发工程师能解决的问题有限，不可能完全取代手工测试工程师。

如果你的企业真的是这么做的，我想请你思考一下，目前你的企业软件产品的质量高吗？是不是对发布质量要求比较低？后期主要依赖用户发现？如果是的话，这是个特例，并不是普遍情况，而且以互联网应用为主，客户对发布质量不敏感。

三、为什么说“测试左移”是个伪概念

• 首先，前面已经提及“测试左移”不是新概念，只是对几十年前原有理论的一个重新命名而已！
• 其次，“测试左移”与“测试工程师左移”是完全不同的。
• 第三，与其现在持续强调“测试左移”带来的误解，为什么不强调“开发右移”。让开发工程师意识到单元测试、单功能点测试是开发工作的一部分，不能，也不应该让测试工程师替你来完成。因为只有如此，测试工程师才能将精力集中在真正的测试工作上面来。当开发抱怨测试技术含量低，测试效果不好的时候，测试工程师没有将工作重点放到真正的测试工作上来才是症结所在！
• 第四，具体到应该“测试左移”还是“测试右移”，我想分歧无非是“单元测试”和“单功能点测试”谁来测？也可能很多企业还上升不到这个高度，因为压根就不测！我的观点是：当然测比不测强，但是如果现在是测试工程师进行的单功能点测试，我想请你意识到，这不是测试工作，或者说这不是测试工作的全部。如果你的企业想让软件质量上一个台阶，请你们有体系、有步骤地将这项工作转移到研发部门。也就是开始强调“开发右移”！
• 第五，请别跟我谈敏捷，就这件事情上来说没什么区别。开发人员必须完成自己的测试工作，请“开发右移”。
• 第六，所谓的测试工程师的“测试左移”是提高了质量还是降低了质量？短期看似提高（因为以前没人做的事情有人做了），但长期稳步下降（因为质量的第一责任人开发工程师放弃了这部分工作）。谁的职责就是谁的职责！可以协助、教，但是绝不能替代！（所谓的教就是敏捷中的测试教练的工作）。

贯穿于全生命周期的软件测试，不意味着全生命周期的软件测试工作均由全职测试工程师完成，不同角色应该完成各自意义上的测试工作。

请诸位测试工程师充分意识到：软件测试工程师是为质量服务，不是为软件开发工程师服务，具体的任何一项测试工作都是手段，你的目标是建立一个集合所有角色的质量保证或者说测试体系。所有角色分工协作，才能共同有效地保证质量。

醒醒吧：软件测试和软件开发处理的问题不一样，不要自怨自艾！到底是测试做得不好，水平太低，还是你理解的测试压根就不对？

用正确测试理念武装起来的，硬气的测试工程师对企业才有价值！

四、放弃能效比谈质量都是耍流氓

前面分析了大量开发工程师应该保证自己代码质量的原因。可能有人会问，你说开发人员自测自己的代码，保证单功能点的正确性姑且算你正确。但是“测试左移”说的是提早测试，这个提早测试并不唯一指单元测试、集成测试，还包括对需求的测试啊！“测试左移”泛指专业的测试工程师应该从需求阶段开始介入，这总不会有问题吧？如果没有问题，怎么能说“测试左移”或者说“测试工程师左移”是伪概念呢？

这个问题很好，所以我放到最后讨论这个话题。先说一下我的结论：全职测试工程师从需求开始介入，可以认为是测试工程师左移的一个好的实践，但未必是一个所有企业都普遍适用的最佳实践。

为了说清楚这个话题，我们从如下几点加以说明：

首先，我们要区分测试工作和全职测试工程师的工作，测试工作广义上指验证和确认工作，可能由专职的测试工程师完成，也可能由团队中更合适的角色来完成。具体由谁来完成，需要组织综合考虑：技能适配性、沟通成本、职业发展、效率最优、成本最低等制约要素。

下面我们来讨论“测试工程师从需求阶段介入”是不是一个好的实践？

如果测试工程师从需求阶段介入，对测试工程师的技能有没有特殊要求呢？答案是肯定的，当然有！

• 第一，在需求阶段介入的测试工程师要对业务非常熟悉，至少是个业务专家，对业务的理解不能弱于需求分析师，否则根本没有办法进行对等的交流。
• 第二，在需求阶段介入的测试工程师要对需求文档的书写技能和语言逻辑很清楚，这样才能参与到需求的获取和评审工作中来。
• 第三，在需求阶段介入的测试工程师要有很强的沟通技能，这个阶段的工作很多是从沟通交流中切入的。
• 第四，在需求阶段介入的测试工程师要有很强的测试分析和设计能力，因为这就是他此时介入的分内工作。

综上所述，在需求阶段介入的测试工程师是整个测试团队中核心中的核心！

那在需求阶段介入的测试工程师在这个阶段具体的产出物是什么？

如果在需求评审之前介入的话，老实说，没有什么硬性的产出物，更多的是提前对系统需求进行了解。提出后续测试工作要点和组织方式的规划，由于需求文档也没有完全定稿，所以当前所有的工作都存在被推翻的可能性。

如果在需求评审中或需求评审通过后介入的话，更多的是作为需求评审人员参与需求评审工作，综合需求和其它文档等，进行测试的分析和设计，这里是有明确产出物的。但是请一定注意，测试人员如果参与需求评审工作，你首先是个业务专家，可以为需求评审贡献一份绵薄之力，其次你才是测试工程师，从系统的可测试性思考需求的问题。千万不要搞反了！需求工作的第一责任人是需求分析师，切记！

综上所述，如果作为质量的负责人，你应该如何选择？让测试工程师从需求评审前、评审中、评审后那个阶段介入更合理呢？这里并没有唯一或者最佳实践，你要综合考虑成本、环境、技术、风险、投入产出比等制约条件。

我的建议是：最早评审完成后介入，或者推迟到系统测试开始之前介入，主要是从投入产出比的角度考虑。当然，每个组织对质量的期望是不同的，需要按照自己的实际质量目标进行综合考虑。

就这个话题来说，我们谈论的范围并没有超过几十年前V模型涵盖的内容，如果说这就是最“先进”的“测试左移”理念，我表示不服！

五、总结

放弃成本谈质量，就是耍流氓！合理的团队协作模型，让组织效率整体提升，过程质量、产品质量双提高才应该是追求的目标！

• 对在软件测试圈内“贩卖焦虑”说不！
• 软件测试领域是个专业的领域，作为这个行业的从业者，我们应该系统化我们的测试体系，用正确的测试理念武装自己。
• 我们构建的是一个基于风险、基于概率思维的质量评估体系，技术手段是为测试目标服务的。
• 专业的软件测试不能脱离整体的覆盖率谈测试技术。

内容来源：领测软件测试网
作者：领测老贺

每周四晚8点【冬哥有话说】线上直播，4月“DevOps之庖丁解牛”，拆解DevOps的工具及具体实战。公众号留言“回放”可查看往期直播视频

• 0401《数据库持续交付流水线分享与演示（Azure DevOps+Flyway）》
• 0408《持续交付中的版本管理与基于Azure DevOps扩展框架的插件开发》
• 时间待定《微服务，多团队协作中的API测试怎么做 - Pact契约测试》
• 时间待定《BoatHouse端到端流水线展示》