博为峰IT培训学校是中国专业的IT培训机构之一，博为峰51Code在国内率先推出IT就业培训业务，即通过数月的强化培训，使缺乏职场竞争力的学员具备企业级项目执行能力，先后在10余个城市推出软件测试，软件开发线下培训，并推出在线职业教育平台博为峰网校Atstudy，面向全国/国际提供软件测试，软件开发等或进阶类，考证类等课程。

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

　　首先，较前面已经提及“测试左移”不是新概念，只是对几十年前原有理论的一个重新命名而已！

　　其次，“测试左移”与“测试工程师左移”是完全不同的。

　　第三点，与其现在持续强调“测试左移”带来的误解，为什么不强调“开发右移”。让开发工程师意识到单元测试，单功能点测试是开发工作的一部分，不能，也不应该让测试工程师替你来完成。因为只有如此，测试工程师才能将精力集中在真正的测试工作上面来。当开发抱怨测试技术含量低，测试效果不好的时候，测试工程师没有将工作重点放到真正的测试工作上来才是症结所在！

　　第四点，具体到应该“测试左移”还是“测试右移”，我想分歧无非是“单元测试”和“单功能点测试”谁来测？也可能很多企业还上升不到这个高度，因为压根就不测！我的观点是：当然测比不测强，但是如果现在是测试工程师进行的单功能点测试，我想请你意识到，这不是测试工作，或者说这不是测试工作的全部。如果你的企业想让软件质量上一个台阶，请你们有体系，有步骤的将这项工作转移到研发部门。也就是开始强调“开发右移”！

　　第五点，请别跟我谈敏捷，就这件事情上来说没什么区别。开发人员必须完成自己的测试工作，请“开发右移”。

　　第六点，所谓的测试工程师的“测试左移”是提高了质量还是降低了质量？

　　短期看似提高（因为以前没人做的事情有人做了），但长期稳步下降（因为质量的责任人开发工程师放弃了这部分工作）。

　　谁的职责就是谁的职责！可以协助、教，但是绝不能替代！（所谓的教就是敏捷中的测试教练的工作）。

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

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

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

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

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

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

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

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

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

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

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

　　，  在需求阶段介入的测试工程师要对业务非常熟悉，至少是个业务，对业务的理解不能弱于需求分析师，否则根本没有办法进行对等的交流。

　　第二，  在需求阶段介入的测试工程师要对需求文档的书写技能和语言逻辑很清楚，这样才能参与到需求的获取和评审工作中来。

　　第三，  在需求阶段介入的测试工程师要有很强的沟通技能，这个阶段的工作很多是从沟通交流中切入的。

　　第四，  在需求阶段介入的测试工程师要有很强的测试分析和设计能力，因为这就是他此时介入的分内工作。

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

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

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

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

　　综上所述，如果作为质量的负责人，你应该如何选择？让测试工程师从需求评审前，评审中，评审后那个阶段介入更合理那？

　　这里并没有或者较佳实践，你要综合考虑成本，环境，技术，风险，投入产出比等制约条件，综合考虑。

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

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

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

尊重原创文章，转载请注明出处与链接：http://www.soxsok.com/wnews584725.html 违者必究！ 以上就是关于“苏州软件测试培训学校推荐”的全部内容了，想了解更多相关知识请持续关注本站。