一不留神，毕业后在软件公司里已经工作七年多了。期间经历了民企、国企、美国硅谷小外企和大型外企，做过正规软件开发（团队规模10人以上，有产品经理、开发人员、测试人员、文档工程师，客户为Cisco，出过2个以上的版本，代码量在20万行以上），功能测试、性能测试、测试自动化、测试辅助工具开发、国际化测试、本地化测试、兼容性测试、第三方测试、测试团队管理，对软件测试的理解也逐渐深入。特写下以下文字与大家分享。

l、软件测试的前途

软件测试在整个软件生命周期中是必不可少的重要一环，但是其在研发体系中的重要性要弱于软件开发和基础技术研究（如搜索引擎的搜索算法，图像的识别算法，统计分析模型等），要高于大多数外围工作（如安装部署、环境搭建等），很难拿高薪，工作强度适中。

做软件测试的同学们看了这个结论可能会很不爽，难以接受，但确确实实是我在工作多年、经历了多家公司后总结出来的切身体会。重要性不是某个人或者公司领导决定的，而是尤其工作自身的特点决定的。为什么测试工程师则经常抱怨自己的工作不受重视，而很少有架构师抱怨呢？因为他们的工作内容门槛高，可替代性低，一般人把他放到那个位置上也干不了。

拿大多数软件公司来说，软件开发和软件测试是两个最常见的工种，拥有最庞大的工程师群体。一般来说，开发工程师比测试工程师可以拿到更高的薪水。核心开发工程师的工作内容技术门槛比较高，可替代性比较低。一个明星产品的原型，或者内核，往往也就是一两个人写出来的，Linux内核，JBoss，Struts，Spring，Hibernate...太多太多这样的例子。虽然说一个技术原型和成功商业化的产品之间还有很大的距离，还需要不同工种的人互相协作，但是谁在扮演更重要的角色不言而喻。毕竟，软件是开发出来的，不是测试出来的。核心开发工程师做的工作，初中级工程师根本无法染指。

大多数测试工程师拿到的都是行业平均薪水，差距不大。对一个产品进行测试，80%的工作量是功能测试，性能、可靠性、国际化、易用性等等加一起一般也就占20%。道理很简单，如果一个产品的主要功能跑不起来，其他东西都白搭。由于种种原因（如需求变化大导致界面变化大），功能测试又以手工测试为主。这部分是技术含量最低，替代性最强，个人知识积累最少的测试工作了。今天测试产品A，明天测试产品B，就好比今天当力工搬砖头，明天搬木头，只要力气在，搬就是了，管他搬的是什么。甲做也可以，乙做也可以，经验丰富、耐心细致的可以发现更多、隐藏更深的bug，但是不存在做不做的了的问题。3年下来，一名开发工程师可以掌握一门编程语言，懂点设计、架构、框架、UML，或者一个人前台后台持久层全部拿下。而一名手工功能测试工程师，只能成为某个被测试产品的使用专家，不用去懂J2EE或者.Net，Flex或者Html5，MVC或者SSH。被测产品一换，一切重头再来。

测试中比较有技术含量和门槛的是测试自动化开发、白盒测试和性能测试。

先说说测试自动化开发。测试自动化开发主要有两种，一种是用现成的工具如QTP、WinRunner编写测试脚本。还有一种是自己用Java或者C#编写辅助测试工具。现成的工具都基于某种语言，如QTP基于VBScript，WinRunner基于自己独有的类C语言，Selenium基于Java。自己编写的工具大多用于批量数据生成、导入、处理等。而这两者归根到底还是软件开发，而且大多数是比较简单的开发。

测试脚本很多不需要界面，是命令行程序，这样GUI开发中的很多难点就不会遇到了。

大多数是单线程运行，因为是脚本，即使是上千个脚本，只要按照顺序跑就可以了，这样多线程的麻烦就不用去处理了。

不需要访问数据库，因为测试结果一般记到文件中如html文件，并以表格或者简易报表的形式显示就可以了。这样，在软件开发中的一块重头戏-持久层开发和数据库设计就不用考虑了。

如此这般，对于一般的测试脚本或者工具开发，专业的软件开发人员即使没有什么测试经验，也可以轻松上手，做得游刃有余。

白盒测试是相对于黑盒测试而言的，是通过写程序来测试程序，比较常见的如测试Web Service API，测试类库提供的API。和测试脚本开发类似，属于相对简单的开发。这类活儿没有编程基础的人做不了，希望深入钻研技术的资深开发人员又不愿意做，比较适合初级开发人员来做。

再说性能测试。

性能测试的主要目的就是验证一个软件产品可以允许多少用户并发访问，性能指标如响应时间、CPU和内存占用率是多少。一般来说这种测试无法手工做，需要借助于工具，如LoadRunner， QALoad，JMeter等等。首先，在录制的脚本基础上做一些编程是必不可少的。其次，在获取到基本的性能指标值后，如何去分析并解决问题，比如调整操作系统、数据库、中间件的参数，做个集群啦啥的，或者对程序做代码级的优化，又远远超出了测试的范畴，是一般的性能测试工程师根本做不了的，需要架构、IT工程师、开发人员协同攻关。可以看出，一位性能测试工程师所作的脚本开发工作，对于专业开发人员来说，没有什么门槛。而复杂的测试环境搭建的工作，又需要网络工程师、数据库工程师的强有力支持，个人难以独自应付。

国际化测试的门槛一般。核心的东西，挤干了水分，也就两三个月，包括字符集、编码、字体、Bidirectional language、时间日期货币小数点排序布局等。换句话说，一位功能测试工程师，在经过好的导师三个月的专业培训和学习后，就可以基本胜任国际化测试的工作了。这里的门槛在于，市面上介绍国际化测试的书不多，很多东西需要在工作中去一个个知识点地学习，需要老员工来带。不像对java、数据库开发进行系统介绍的书那样满大街都是。

兼容性测试是典型的没什么技术含量的人力密集型工作。本人曾经做过一个月的打印机兼容性测试，上百台打印机，一个接一个放入打印纸打印，看看对被测试的国产Linux的支持程度。或者一个产品，测试对不同数据库的支持。让我想起在上大学的假期里给人发传单时，发一次挣30元钱，谁干都可以，卖卖苦力。后来改行写游戏外挂，一个月轻松挣3000多块，让室友们羡慕得不得了。

手机/平板电脑应用的测试。手机或者平板电脑上的应用要么是单机应用如雷电游戏，要么是客户端程序如新浪微博客户端，特点是输入少，以浏览为主。客户端程序的开发难度要低于服务器端程序，其测试难度也相应得低一些。

测试的另一大不利因素是缺乏成就感。设计人员、开发人员可以出去和人说，大家用的某某杀毒软件的小狮子是我的idea，某某输入法是我开发的，某某网站是我写的，里面存在只有我知道的某某漏洞。测试人员与之相比则会比较尴尬。

说了这么多，绝对没有轻视测试或者刻意抬高开发的意思。每一个工种都是不可或缺和重要的。但是，他们带给工程师本身的价值增值不一样，工作时间越长越明显。打个不太恰当的比方，开发与测试工程师，就好比医生与护士，会计和出纳。医生越老经验越丰富，价值越高，每个年代都名医辈出，受人敬仰。而护士，除了开创者南丁格尔外，没有几个能被大家所熟知和记住的。

工作内容杂、重复性高是低价值工作的一个共同特点。而这是想在职业上有所发展的同学必须要注意的一点。

说了这么多测试工作的局限性，下面接着说说从事软件测试这个行当的好处。毕竟，包括我在内的很大一个群体都在靠这个行当吃饭，全是缺点的话，谁还愿意干这行。而且，想干好测试的话，还是需要花费一番心思的。

劳动强度和工作压力适中。开发人员的一大压力是到了deadline能否做完分配的模块。技术难点是不可避免的，没有人能百分百地保证一个全新项目能按时开发完，能解决所有的技术难题。测试要好很多，测试工作主要是量的问题，大不了加加班，不存在完不成的问题。

技术更新周期长。不管是Flex、Html5还是Jsp写的软件界面，对功能测试人员来说区别不大。而对于开发人员来说，技术的切换则是一件比较痛苦的事情。就像被人从一个热被窝里面揪出来，再从新捂一个冷被窝。其中的辛苦，经历过的人都知道。

技术面、适用面比较广。开发人员讲究的是深度，测试人员讲究的是广度。测试人员在换工作时，从测试 .net 产品转向测试Java产品问题不大，而对开发人员来说则是个大问题。

开发人员比测试人员 ‘轴’的更多。很多牛人技术很好，但是沟通能力很差，朋友少，这和工作性质有很大关系。长期的编程造成了不少开发人员呆板的思维方式。生活是丰富多彩的，远不是只有技术。

2、测试团队管理

1）谁在做软件测试？

计算机专业毕业的女同学：软件测试的劳动强度和压力比软件开发小很多，还要求耐心和细致，很适合希望干本行的科班出身的女同学

非计算机专业毕业的同学：软件测试的入行门槛比开发要低一些，很多学与计算机相关的理工科专业（如信息系统、数学、物理、电子）毕业，甚至是当年因为几分之差与计算机专业失之交臂，同时又对此行业很感兴趣的同学转行过来

软件开发、售前、售后技术支持工程师转行做测试：部分软件开发工程师在工作若干年后，不太喜欢太大的工作压力和强度，希望能够保持工作和生活的平衡，多一些时间陪陪家人。他们强大的开发背景很快就能在测试组里显山漏水，鹤立鸡群，即便开发能力在开发组中只是一般般的；部分售前、售后工程师在结婚生子后不希望太多的时间在外地出差，希望能多照顾家庭，他们的行业知识和沟通能力对测试工作也大有裨益。

2）测试工程师的心里在想什么？

每个人的需求不一样，这就需要管理人员根据每个人的需求来做工作，因人而异，才能达到最好的效果。

有的人冲劲很足，渴望挑战技术难点，提升技术水平，就让他多做核心工作，获得成就感。

有的人求安稳，不求职业有多大发展，但求多照顾家庭，少加班；或者阶段性的，比如家里刚要了小孩儿，希望能多照顾家庭，就分配一些没难度的工作给他

有的在工作若干年后对测试逐渐失去兴趣，会转行做开发或者技术支持。只要有心的话，在日常工作中都可以觉察的到。

3）测试的技能要求

编程：编程能力是一切IT相关行业的基础，尤其对于软件测试来说，编程能力和功底越高越好。这样他就可以知道开发过程中哪些地方容易出问题，发现很多纯黑盒测试人员发现不到的深层次bug。

数据库、中间件、操作系统：被测试的系统千差万别，测试人员很多情况下需要自己搭建测试环境，在测试过程中发现问题后需要甄别是测试环境的问题还是被测系统存在bug，所以常见的数据库、中间件、操作系统都要会装会用，至少要熟练使用一种。

行业背景知识：如果被测试的软件是QQ，Office这类通用软件，那不需要什么行业知识。如果测试一个复杂的财务软件或者ERP软件，没有基本的背景知识的话，很多流程会走不到，或者根本就走不通，测试覆盖率会出现严重的问题。全指望产品使用说明文档或者客户现场支持是不现实的。

测试工具的使用：最常用的如QTP，LoadRunner。这个没有难度，就是个熟练度。

沟通：各个工种都需要

英语：IT的各个工种都需要

4）测试人员风险管理

和其他团队一样，测试团队也面临着人员流动的风险。不论是流动到公司内部的其他部门，还是跳槽到其他公司，对于小组来说，都是失去了一位熟练的工程师，需要重新花费成本去招聘、面试和培养。如果是一位核心测试工程师流失了，甚至会造成整个team的技术水平下降。现如今，人员的流动是不可避免的，为了把损失降到最低程度，需要在管理制度上有所考虑。

a、根据二八法则，重点关注核心工程师的思想动态和情绪变化，各种资源也要一定程度地倾斜。20%的工作是核心工作，80%的工作是外围的次要一些的工作。只要能抓住20%的核心工作，其余80%的外围工作风险就小多了

b、重要的工作一定要有至少2位工程师会做，否则人一走，工作就立刻瘫痪了。

5）FAQ

Q：在做测试的时候，发现并记录bug后，是否提倡由测试人员分析并修复呢？

A：我在做测试时，和我所在的团队成员曾经这样尝试过，最后发现费时费力，事倍功半。因为对于一个大型软件系统来说，代码结构比较复杂，即使是这个产品的开发人员，让他调试不是自己所编写的模块的代码，都需要花好大一番功夫。而对于某个模块的开发人员来说，对自己编写的模块了如指掌，调试并修复bug事半功倍。而且对于开发人员来说，写前台的不懂后台，或者写中间层的不懂持久层都很常见，在开发过程中都需要相互配合联合调试。如果测试人员真想提高技能的话，不如自己多动手写一些程序，或者精读一些代码更有益一些。当然，愿意多钻研是一件非常好的事情。

Q：如何尽量规避测试覆盖率不足的风险？

A：测试的最大风险在于测试覆盖率不够导致漏报，最终被漏掉的问题在产品发布后被客户在使用中发现。而实践又证明，没有开发人员的帮助，测试人员100%会漏掉一些重要的bug。所以，需要在制度设计上有所考虑。如有兴趣，具体方法可联系本人。当然，所有方法都只能尽量提高测试覆盖率，对于一个几十万行代码量的中大型系统，没有完美的方法能保证100%的覆盖率。

Q：测试组和开发组的关系就像猫和狗一样天生不和么？如何理顺？

A：在很多软件公司，测试组和开发组的关系都比较紧张，不好调和。开发组认为测试组发现不了多少重要的bug，就会在一些边角问题上吹毛求疵，鸡蛋里挑骨头，在领导面前说坏话，在开发进度已经很紧张的情况下还要来挤占宝贵的时间问这问那；测试组认为开发组做的东西太烂了，报的bug没有引起足够的重视，得不到足够的开发状态更新和支持配合。这些矛盾是由多方面的原因引起的。

1）评价体系

测试组没有有效发现bug，等产品上线后被客户发现了，导致投诉甚至经济上的损失，是测试组的责任；测试组发现的bug，开发组无法按时修复，是开发组的责任。测试人员心中大骂：因为开发人员做得东西烂，才导致自己没有发现全部的bug；如果开发做得好，自己怎么会漏掉bug进而影响了年终奖。开发人员也极其不爽：都怪测试人员临到最后才发现了一个致命的bug，导致自己没有时间修复，让产品带着问题发布了。

于是乎，为了各自的饭碗和声誉，悲剧开始了。

测试组会竭尽全力提高测试覆盖率，报bug，宁可有少量误报，也不敢遗漏；而要提高测试覆盖率，测试组需要开发组的大力支持和配合。实践证明，没有开发人员的帮助，比如介绍哪个模块有潜在问题和复杂的逻辑分支，测试组无法独自发现很多重要的bug。

而开发组在项目后期压力会比较大，一边拼命修复bug，一边看着新bug一个个先仆后继地冒出来，感觉bug就如同苍蝇般轰都轰不走。遇到比较严重又不好修复的bug，更是倍感压力，茶不思饭不香。突然间，开发人员自己发现了一个比较严重又不好修复的bug，第二天就要交付产品，时间来不及了，而测试组还没有发现。该如何抉择呢？

a、主动报告bug，自己承担全部责任；为了这个bug，可能需要专门给产品开发一个patch，在公司上下都造成了负面影响

b、隐瞒bug，测试组最终也没有发现，产品交付使用后被客户发现了，测试组承担全部责任

c、隐瞒bug，测试组最终也没有发现，产品交付使用后客户也没有发现，皆大欢喜，在下一个版本里自己悄悄修复

公司不同，企业文化不同，奖惩激励制度评价体系不同，最终会使开发人员在一番权衡之后做出截然不同的决定，进而影响这个产品甚至整个公司。

2）组织架构

在很多大公司里，部门会按照职能来划分。测试部下辖若干测试小组，每个小组负责测试一个或者一类产品；开发部下辖若干开发小组，每个小组负责开发一个或者一类产品。测试部经理和开发部经理都直接向研发中心的经理汇报。当测试部经理和开发部经理在一些工作上意见不一致时，没有人来直接做裁决，导致互相扯皮。一个中大型研发中心同时会有至少几十个项目在运作，研发中心的经理在宏观层面上掌控全局，根本无暇顾及每个项目的细节，很多时候就任由测试组和开发组的人来互相角力了。项目经理和产品经理在不同的公司里话语权差异很大，经常无法有效调和这些矛盾。

在有些公司里，部门会根据事业部/产品线来划分。部门甲负责一个或者一类产品，下辖开发组，测试组，项目经理，产品经理，UI设计人员等。当开发组和测试组意见不一致时，由部门经理最终拿主意，对项目的成败负全部责任。这种架构下情况会好很多。

Q：如何评价测试人员的工作？

A：需要bug数量和经理的主观感受相结合。单纯依赖bug数量，就如同单纯依赖代码行数来评价开发人员一样片面。其一，Bug的数量可以掺水；其二，做性能测试的人员所报bug数要远远小于做功能测试的人员，做测试开发的人员就根本没有bug可报。

Q：在从事若干年测试工作后，大家都向哪些方向发展了？

A：根据我和身边同事们所经历过的各类公司的经验，大致有如下几种出路。

1）测试管理。管理职位是稀缺的，不是想做管理的人都能有机会去做，即使各方面能力都具备了。

2）转开发。测试转开发 比 开发转测试 的难度要大得多，越早越好，转失败的不在少数。

3）转售前售后技术支持、顾问、培训。测试的好处在于对产品的整理理解和把握，同时研发的背景对于这几个工种非常有益。

4）在测试的道路上长期走下去，做技术专家。这是大部分人的选择，不管是主动的还是无奈被动的。