该帖子同步发自：(飞眉的博客  访问该博客)

　　最近论坛里很多新人询问“软件测试可以不编写代码是真的吗?做一个不会编程的测试人员可以吗?软件测试比开发简单是真的吗?....等等”。看到这些问题，让我有了一个疑问，不会编码的测试人员到底能走多远?

　　可以肯定一点，软件测试入门相对开发要求是低了一点，但也只局限入门，想要做好测试并不容易，甚至要比开发人员掌握更多的知识。

　　首先要明确软件测试工作的技术究竟体现在哪里，个人认为测试用例设计技术代表了测试技术，而自动化测试技术多数只是提升测试工作执行效率的手段。测试技术终究要转化为测试案例，我是这样理解测试用例设计技术的，它包含了产品需求细化+业务和实现逻辑+产品实现技术(概要设计、详细设计、算法)+测试手段(工具应用及反推)+测试角度+用户场景+功能关联/依赖法+测试点反推法+bug反推法等，可以说测试用例设计的好坏影响了被测系统的质量，很多新人认为测试用例没有用，写了一堆废话又很浪费时间等等，希望看到这里能对你有所触动，要想写出高质量复用率高的测试用例需要我们平时的学习和积累。

　　既然测试用例设计是测试人员能力的体现，那编程我就不学了?只要你是个有追求的人，那就不要太乐观了，看看大企业的招聘信息不难发现，很多企业都要求测试人员掌握一定的测试工具，或是相应的脚本语言、开发语言等。那我只掌握测试工具不会编程不也行了吗?这是个错误的想法，每个工具都有其相应的编程语言，无论是QTP、selenium还是Watir，单靠录制功能是无法做自动化测试的，最后还得靠编程。如果我直接做管理，不走技术方向是不是可以不掌握编程了，在一个不需要白盒测试、自动化测试、性能测试的团队中是可以的，测试在不断的发展，谁又敢保证你所在的公司日后不会开展相应的测试工作呢?尤其在一个拥有自动化测试组、性能测试组的团队中，老大不懂代码就无法掌控相应的测试工作，甚至不能让人信服，这样的老大又能做多久。所以我认为，测试人员的第一个分水岭在测试用例的设计上，第二个分水岭在于编程能力的掌握和应用上，第三个分水岭在管理和工作协调上。

　　写这些无非是想让踏入测试的新人明白，对于IT行业来说，软件的主要构成是代码，对于测试软件的我们来说，掌握代码就变成了理所当然的事。所以说想要彻底摆脱编程而选择测试的朋友，你们要珍重了。