有没有发现现在招聘测试工程师的JD，基本都涉及开发内容了？比如：
是不是感觉不会写代码？就干不了测试了？
事实上，“面试要求造火箭，日常工作拧螺丝”之类的事情比比皆是。
即使日常工作只是“点点点”的验证工作，面试时候也得笔试，在纸上写个排序算法什么的。
软件测试已经走入一个误区——“非代码不可”！
换言之，软件测试目前一个趋势，测试工程师什么角色都必须写代码。
写代码，增强自动化程度，让计算机完成重复动作，本身无可厚非。但是一旦过了，变成“必须写代码”，就是当前软件行业的一个误区。
“非代码不可”的误区形成，有几个原因：
测试不受重视
这个话题相信会引起众多测试人的共鸣。
请回答几个问题：
“公司里研发和测试人员的配比是多少？”
“软件研发周期是多久？多少时间留给测试？”
“软件上线后出现问题，第一个被责问的是哪个团队？”
几个问题，基本就可以男默女泪了。
测试团队必须体现出自己的技术性、专业性？还要量化地表现出来。
全面学习研发，跟着写代码，就是一个很直接的想法。
于是，很多测试人放下业务研究，拿起了IDE开始写代码…
测试团队负责人不懂测试
这也是一个现实问题，不少的测试团队实际负责人是R&D的领导，或者测试经理向R&D负责人汇报。
R&D的领导，99%是纯研发出身，也是不争的事实。
IT技术发展，分工越来越细化，研发和测试，本来就是两个不同的方向。
这就难免出现外行管内行的问题。
如果从纯研发人员眼光来看，代码量是衡量工作的一个标准，但是用这个标准要求、衡量测试的工作，则以偏概全了。
多数人，只能理解自己懂得东西，否则就套用到自己理解的范围内。
过分强调自动化
自动化测试，是一个好的方向，替代了很多人工劳动，尤其在回归测试方面，尤为重要！
但是，如果觉得“自动化测试”能解决一切问题，那么就言过其实了。
全面推广自动化测试，意味着相关的测试人员必须写代码。
- 怎么判断测试的业务覆盖率？
- 怎么判断异常用例的范围足够？
- 多少缺陷是自动化测试用例发现的？多少是人工测试发现的？
几个问题的答案，不言自明。
如果没有好的软件架构，自动化测试，尤其是UI自动化测试，绝对是疲于应付各种修改。
铺开自动化测试前提是，有个好的测试架构师规划。
综上所述
走出“非代码不可”的误区，软件测试应该回归本质：保证质量。
在测试这个角度，软件测试的本质是质量保证，一切能够提高质量的工作都是测试人员应该涉猎的，代码仅仅是其中一部分。
误区的存在，导致很多测试人员在为了代码而学习代码，并没有解决质量问题，甚至不懂业务。
更可怕的是不少测试人员既不关心业务，也不关心技术，而是整天琢磨着下一步转型成什么角色的工作。
就软件测试领域而言，接口测试、安全测试、性能分析……，很多工作真的不需要具体写代码。
人的精力是有限的，全面开花，往往意味着“十八般武艺样样稀松”。最终会面临35岁问题。
随着敏捷跟DevTestOps体系的流行，测试行业也开始慢慢发展，各种概念开始流行，测试人员对于未来的发展可能会迷茫，这个是可以理解的，但还是要有独立思考的能力，不要总是人云亦云，相信什么名人效应。
迷惘的时候，不妨思考一下事情的本质是什么，找到本质，也就有了方向。
