[本文出自天外归云的博客园]
业界通病
现在中国的测试行业普遍存在一个问题，那就是测试与开发所占有的比重问题。这个问题的模糊界定直接导致了对于测试人员与测试开发人员应该具备的素质不能产生一个很好的标准。
之前业界普遍存在的问题：
1）工龄长没技术的老员工没贡献，居高不下；
2）对黑盒功能测试的误解，认为作一名纯手工测试人员是低级的；
3）对于开发能力的向往，很多大公司拿这个作为kpi要求测试人员应该具备某些开发能力导致测试人员开始不把重心放在业务测试上，潜心研究造轮子。
以上三点直接导致：
1）有能力的员工得不到发展，思考离职与跳槽；
2）排斥纯手工测试，认为那是没技术的，会让人瞧不起，从而测试热情降低，开始浮躁，想要跟大潮一起学习写代码当开发；
3）不再好好做测试，造了一堆轮子。这里我想说：姑且不说轮子是否有用，测试用例总归是一个测试人员的魂，要把心思多放在对于测试用例设计的反思上，多结合实际业务测试中出现的问题由表及里的反思问题出现的原因，从而推出测试用例的设计疏忽所在，增加测试用例设计的经验。你发明一套大家一看就懂的测试用例设计框架我认为是一件更加有意义的事情。
正是针对第一点，所以有了kpi，减少了混吃等死的概念。
但是对于第二点，我想说：纯手工测试也是测试，他并不低级，测试做的好坏跟是手工还是自动化没有半毛钱关系，而是直接跟你设计的测试用例好坏挂钩；
对于第三点，我说一句：想要造轮子？可以！多结合实际测试业务线造点儿对测试过程有用的、可复用的、能提高工作效率的轮子，切忌脱离业务造轮子，那和纸上谈兵如出一辙。轮子重复造没有意义，不要为了kpi换汤不换药，已有框架重复造。
现在业界普遍看好一些持续集成的东西，对此而生成的解决方案可谓百花齐放。我觉得研究是有必要的，但是应该在实际的测试工作中应运而生。
持续集成有他的好，所谓的自动化测试正好可以在持续集成上体现出来。持续集成确实可以发现一些由于代码变动因素而引起的bug，但是在现如今敏捷开发的过程当中、朝令夕改的需求下、不断缩短的软件生命里，“要花多大的心思搞这件事、怎么搞？”这个问题值得仔细思考。
职责分工
我觉得分工有必要明确，职责解耦是必要的！高耦合很多时候并不是一件好事。只有分工明确，大家才会避免浮躁，整个业界才会稳步前进！
测试工程师的技术体现在：
1）能够熟练操作测试工具、测试环境；
2）能够熟练掌握各种测试数据的mock方法；
3）能够对有必要自动化的测试过程进行编程（脚本或工具开发）；
4）能够系统、全面的设计测试用例；
5）能够对测试平台、工具的开发提出详细建议，能够细化需求与交互细节；
6）能够对测试过程与测试心得进行总结与分享，具备优秀的文档编写能力。
测试开发工程师的技术体现在：
1）能够按要求完成对测试平台的开发（后台+前端+项目部署+bug修复+需求优化+项目维护）；
2）能够按要求完成对测试工具的开发。