测试工程师的职业规划

不同类型的软件公司，对测试工作的重视程度也有很大不同。建议测试人员选择一些业务持续发展的公司。做项目东一榔头西一棒的公司，是不需要高质量的测试的，他们需要的是尽快把软件交出去，却无法静下心来思考，怎么把质量做好。选择这样的公司，要冒相当大的风险。

接下来说一下大家关心的话题，如果选择了测试，怎么能从测试团队中脱颖而出呢？经常被提出的概念有“管理和技术两条路线”，这个概念太抽象，还是无法帮我们理清思路。有的观点认为，测试要学习开发技术，这个也没有说到关键点上。我认为测试人员的职业发展有下面两个，换句话说，软件企业最需要拥有这两种能力的测试人员。注意，这两种能力并不互相冲突。

第一、不断改进测试策略，提高测试效率和质量

目前很多公司的测试还是以手工的黑盒测试为主，测试策略比较单一，可能很多同学都遇到在写测试计划的时候，测试策略那一章不知该写什么的问题。如果只做黑盒测试，会在提高测试质量的路途上出现一道难以逾越的鸿沟。

改进测试策略需要掌握开发技术，但是技术仅仅是必要条件，更重要的能力，是能够系统的规划一件事情，分析工作中的问题，选择最有效的解决方法，最终和大家一起实现一个共同的改进目标。

改进测试策略一般会考虑以下几个方向：单元测试（白盒和灰盒）、自动化测试、性能测试、安全性测试、易用性测试等等。当然，具体的改进目标，要根据业务的不同，选择合适的方向。

不过，很多测试团队的人力资源都比较紧张，无法投入太多的人手去改进测试策略，能够很好的解决这一矛盾就显得非常重要。公司需要的是，能够根据测试团队的当前状况，制定出有效的改进计划，并带领大家提高测试效率的人。

第二、能够“吃”业务，控制业务的测试质量

这里需要说明，“吃”业务并不等同于熟悉业务。对于测试工作来说，熟悉业务是非常重要的，大部分测试人员上岗以后，都会从了解业务开始，逐渐的掌握产品线的业务规则。但是，当一个测试人员熟悉了某个业务以后（成为业务专家），问题出现了：他/她可能会一直陷在这个业务的测试执行中，无法解脱，几年如一日的做着类似的工作。

即使增加了新的测试人手，业务专家也没有感到多少轻松。一方面，业务专家要周而复始的对新人进行培训，解答他们工作中的问题，培训成本极高；另一方面，业务专家不放心把重要功能交给新人测，必须自己来测试，业务专家的职业发展出现了比较尴尬的局面。

由此我们提出了“吃”业务的概念，它与熟悉业务最大的区别就在于，测试人员吃掉一个业务以后，可以把测试工作完全交给另一个测试人员来做，同时，也能保证测试的质量。而要达成这个目标，关键就在于文档。我们需要以业务为单位，完善测试用例、业务沉淀、测试设计、测试脚本等文档，并且，更重要的是，要把这些零散的文档组织成一个系统的文档体系。

注意，吃业务并不等于为这个业务单元编写一套非常完整的文档，而是建立起一个基本的，可持续维护的文档体系即可。业务专家吃完一个业务以后，可以把这个业务交给其他人，然后开始吃第二个，同时，关注原先的业务的文档完善过程。这样，有吃业务能力的测试人员，能管理更多的业务需求和测试人员，而且由于他/她接触的业务越来越多，工作的视角也会逐渐提高，成为系统级的测试工程师和团队leader。

要设计这一文档体系，也需要较好的系统设计能力，当然，最主要的是持之以恒的毅力。另外，每个业务单元的文档体系，也可以在一批批的测试人员中传承，每个人都会来维护、完善它，并从中学到很多经验。