为什么会有这么一个话题呢？很长一段时间，在软件测试畛域，始终弥漫着一种乐观的气氛！比方“测试无用论”，“咱们须要全职的 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 端到端流水线展现》