在我的微信公众号:领测软件测试网 后台，和领测老贺聊测试的QQ群中总能看到这样的言论，以上的提法在软件测试工程师圈子内持续的蔓延，人云亦云的结果就是制造焦虑，对自己技能的不信任，对基于功能测试，基于手工测试工作的质疑！面对开发人员不够硬气，总觉得低人一等，由此进入恶性循环！
为了说明这个问题，我尝试从以下几个方面加以分析
1、开发工程师和测试工程师的工作目标存在巨大差异
开发工程师的工作目标是实现功能，目标相对明确，判定成功的标准也明确即目标功能实现正确。
但测试工程师的工作目标是高效的寻找软件缺陷，需要的是风险思维和概率思维，判定测试成功的标准也不算明确，发布后的评估才是终极审判。注意这里评价测试工作的两个维度，一个是高效，一个是缺陷。
2、同样的事情，从组织的角度考虑谁做更划算
做每件事情都有成本，标准的思考模型应该是两利相权取其大，两害相权取其轻。针对代码逻辑的单元测试谁做成本最低？收效最高？当然是编写代码的本尊了！企业必须用最有效率的方案去获取目标。
3、单功能点验证不是测试工程师眼中的软件测试
如果你细心观察，你会发现大多数具有开发背景的工程师口中的软件测试基本上都是单功能点验证，并且他们坚持认为这就是测试的全部。作为一个有20年软件测试经验的测试工程师，我可以很负责任的告诉你，单功能点验证通过只是系统化软件测试的入口条件，绝不是测试的全部，或者在严格意义上来说这根本就不是软件测试。专业的软件测试工作研究的是功能的组合，在无穷无尽的功能组合中寻找当前场景下的最优解才是你应该追寻的目标。那什么是最优解？就是在平衡各方利益的情况下，如何最有效率的满足既定的质量目标！
理想情况下，我们拿到的软件就应该是一个单功能点验证通过的产品。换句话说，单功能点验证应该是开发工程师的职责！只有这样，专业的测试工程师才能发挥最大的效用。
如果你的公司只做单功能点验证，或者说绝大多数工作都是单功能点验证，我可以明确地跟你说，你做的不是专业测试工作。你测试的产品质量一定很差！你需要系统的学习一下软件测试到底怎么做，你可以找领测国际了解一下ISTQB国际软件测试工程师认证培训（请允许我做一下硬广）。
综上所述，开发的测试和测试的测试根本就是两个概念，单元测试本就应该由开发工程师完成，单功能点的验证不能是测试的全部，专业的测试工程师要具备风险思维，要做基于风险的测试覆盖。
让功能测试工程师集体转型做单元测试，并称为“测试左移”：“不是傻就是坏”！
测试工程师不需要了解代码吗？
软件测试是一个行业，里面有若干工种，随着职位的不同，对掌握代码的技能要求是完全不一样的。例如：同样是厨师，但是面点，西餐厨师，对刀工的要求就远远弱于中餐厨师。
当然，当你掌握了代码后，对测试的效果肯定是有正向加分的，但是我要提醒你一句，你的价值来源于你与团队的技能互补，而不来源于你和团队的技能相同点。
也就是说，你的团队到底是需要一个专业测试工程师做基于风险的测试评估，还是需要一个懂开发的测试工程师，用代码测试代码，从而提高做单功能点验证的效率？这是你或者说你的团队需要考虑的问题！
以国内目前的氛围来讲，现在谈测试工程师需要掌握代码的论调不是太少，而是太多了。而讨论具体如何构建测试体系，让测试工程师掌握专业的基于风险，基于覆盖的测试思维不是太多了，而是太少了。
测试工程师掌握代码本身并没有错，相反还有很大的好处，这会极大的丰富你的测试手段，提高测试效率。但是请注意，和整个测试体系的构建来比较，这还只是停留在“术”的层面，作为测试管理者必须清醒的意识到软件测试本身到底解决什么问题，效率是锦上添花，科学的覆盖率策略才是根本！没有覆盖率保证前提下的效率带来的只有怀疑和混乱！
基于代码测试代码的自动化测试可以取代专业的功能组合测试吗？
很遗憾，至少目前不行。
目前的自动化测试技术是将手工测试用例中，适合重复执行或数据驱动的用例抽取出来，并将其自动化执行。基于这个原理，所以自动化测试通常是手工测试的最小用例集，是用来做质量的最低防火墙的。
出于成本考虑，在很多场景下，手工测试的成本也会远远小于自动化的成本。所以也没有道理将所有的手工测试自动化。
再有，例如发现Bug能力超强的探索性测试技术，本身就不需要提前规划测试路径，从原理上说自动化测试是不可能替代探索性测试的。
MBT基于模型的测试技术，至少目前看还不可能建模后做全遍历覆盖，这样会造成用例爆炸。
基于AI进行自主学习的测试，现在并没有看到可以实用的解决方案。还处于探索，研究阶段，对此我也保持谨慎乐观。
说了这么多，无非是想说明，依靠代码测试代码，测试开发工程师能解决的问题有限，不可能完全取代手工测试工程师。
如果你的企业真的是这么做的，我想请你思考一下，目前你的企业软件产品的质量高吗？是不是对发布质量要求比较低？后期主要依赖用户发现？如果是的话，这是个特例，并不是普遍情况，而且以互联网应用为主，客户对发布质量不敏感。
为什么说“测试左移”是个伪概念
首先，最前面已经提及“测试左移”不是新概念，只是对几十年前原有理论的一个重新命名而已！
其次，“测试左移”与“测试工程师左移”是完全不同的
第三点，与其现在持续强调“测试左移”带来的误解，为什么不强调“开发右移”。让开发工程师意识到单元测试，单功能点测试是开发工作的一部分，不能，也不应该让测试工程师替你来完成。因为只有如此，测试工程师才能将精力集中在真正的测试工作上面来。当开发抱怨测试技术含量低，测试效果不好的时候，测试工程师没有将工作重点放到真正的测试工作上来才是症结所在！
第四点，具体到应该“测试左移”还是“测试右移”，我想分歧无非是“单元测试”和“单功能点测试”谁来测？也可能很多企业还上升不到这个高度，因为压根就不测！我的观点是：当然测比不测强，但是如果现在是测试工程师进行的单功能点测试，我想请你意识到，这不是测试工作，或者说这不是测试工作的全部。如果你的企业想让软件质量上一个台阶，请你们有体系，有步骤的将这项工作转移到研发部门。也就是开始强调“开发右移”！