职业发展路线一般就是一直继续做自动化或尝试挑战巨头公司的高端岗位，更多的人会自动化之后去和黑盒测试人员竞争测试管理岗位，这时他们有技术上的先天优势。

　　自动化测试的陷阱和泥潭：

　　HP公司的QTP广告深入人心，录制回放的自动化现在仍有许多支持者。但这类岗位停留于工具的使用上，对个人来说，技术路线极短。因为这种工具就是为了让不怎么会技术的人使用而设计的。对公司来说，商业工具确实是成本最低的自动化测试解决方案。所以有不少公司仍然用他。但他很难招到愿意为公司牺牲自己的技术路线的人，一般他只能招到懂一点点技术的黑盒测试人员来做这种自动化测试。这里有一个很老的典故：某测试人员来到一家软件公司，技术负责人指着角落里一台积满灰尘的电脑说，这是我们的自动化测试专用机，不过录制的脚本老是跑不起来，现在我们已经不太搞自动化测试了。

　　开源工具单独无法使用，而懂一点技术的黑盒测试人员搭不好测试框架。以网站测试威力，最流行的开源工具selenium，必须和测试执行器（xunit系列）一起用。团队需要至少有一个人有搭建测试框架的能力。实际上很多团队没有这号人。搭出来的测试框架用四个字形容就是一塌糊涂。总之这对后面的人影响很大，如果搭框架的人已离职，你最好想清楚要不要去这种项目做自动化测试。一个蹩脚的框架会让你痛不欲生，产生还不如做手工测试的念头。

　　为什么懂一点技术的黑盒测试人员搭不好测试框架。为什么懂一点测试的开发人员也搭不好测试框架。因为，他们有一个共同特征：不懂自动化测试原理。 比如说，自动化测试要关注可维护性，要设计合理的代码重用机制，以网页测试最流行的开源工具selenium来说，官网就有介绍页面对象模型的使用方法。但一般人看不懂。再比如搭一个好的selenium框架需要很好的编程语言基础。假设你招了大部分转行做测试的初级开发人员或懂一点技术的黑盒测试人员用java和selenium来做网页自动化测试，你跟他说“多用组合少用继承”，他完全不懂你说什么，他反正写java就不管三七二十一继承继承再继承，他娘的他就会个继承，要么他干脆把所有东西塞一个类里面，然后你会看到他们在测试代码里写出几千行的上帝类、写出十几个类的继承链。你跟他说testNG的测试执行机制，他也一头雾水。我看到过某实际项目中使用了5年的自动化测试脚本，里面竟然是用自己的代码重新实现testNG自带功能的，并且除了增加测试代码复杂度以外毫无任何好处（难道是他们初代作者为了提高测试人员不可替代性的大智慧？），还有开发人员异想天开得用spring来封装测试类的（那他肯定没用过xunit系列测试执行器）。还有时候你会看到几千行测试数据和几千行测试预期结果放在同一个文本文件里，然后后来人找不到要找的数据，就胡乱地往这个巨大的文本文件里写一行自己要的数据，他也不管是不是跟前面的重复了。对这种，我只想说一句，那个已经离职掉了的原作者，你回来让我打一顿消消气好不好。

　　综上所述，基于这些原因，中小公司你想搞用户界面层的自动化测试，多半搞不好。但自动化测试不等于用户界面自动化测试。还可以搞接口，搞单元测试。接口测试是一个很适合做自动化的切入点，如果技术负责人问我怎么开始做自动化，我就会推荐他从接口测试的自动化开始。这一点对公司、对测试人员都有巨大好处，是少见的双赢。

　　我做接口测试工作时的体会：

　　这他娘的比黑盒测试简单无数倍，薪资竟然比黑盒测试高。

　　太容易了，好爽。

　　不要给我招懂一点技术的黑盒测试人员，也不要给我招转行做测试的初级开发。好吧，只能招到这样的。最后他们做的东西我都要返工一遍，还不如我自己做来着……算了慢慢教。如果不懂自动化测试原理，你烦我也烦。你烦做不好，我烦教不会。

　　做接口测试依赖于开发人员的配合，我们没时间通读代码（对更多的人来说，其实读也读不懂），开发愿意帮助你的话，在这个岗位上你的工作很容易取得成就。

　　接口功能测试是测试行业的一个黄金点。其后自然而然的你可以接触接口的压力测试，并接触正宗的性能测试。（待续）