【IT168 技术文章】

　　公司开发的产品专业性较强，软件测试人员需要有很强的专业知识，现在软件测试人员发展出现了一种测试管理者不愿意看到的景象：

　　1、开发技术较强的软件测试人员转向了软件开发(非测试工具开发)；

　　2、业务能力较强的测试人员转向了软件需求；

　　3、沟通能力较强专业能力较强的人员转向了软件实施；

　　为什么不愿意看到呢，自己培养起来的优秀人员都为别的部门、别的公司干活去了，而测试这边永远都是新人，永远都是刚入门的软件测试工程师：开发水平一般、业务能力一般、沟通能力一般。而那些转行的测试同仁们，薪水并没有质的飞跃，到了‘那边’成绩平平，很快就被埋没了。这里当然要排除那些实在对开发、对业务、对实施非常感兴趣想在这些领域有所建树的狂热者们。问题就来了，那些人为什么要‘转业’呢?原因无外乎以下几点：

　　1、公司的软件测试没有技术含量，没有挑战性；

　　2、认为在公司能做到测试经理就已经是测试发展的最高境界了；

　　3、测试人员薪水较其他低；

　　4、想了解一下测试之外的其他岗位，丰富自己的阅历，为以后更好的做管理做准备。

　　那么，公司的软件测试真的技术含量很低吗?工作效率已经达到最高了吗?真的不需要挑战吗?测试经理就没有高级和低级之分了吗?测试人员的薪水就不可以比开发人员高了吗?测试人员真的需要那么多吗?当然不是，也许很多年的‘旧路’不能靠自己改变，也许有人埋怨领导者们因循守旧、顽固不化，但没有人会阻挡我们去创新，去阻止我们探索新的模式、新的思路、新的工作方法去改变这种现状，没有公司是傻子，一个人的薪水和他体现出来的价值是成正比的。所以应该打破常规，去探索新的东西，这种创新不仅包括技术创新也包括管理创新。关于职业发展，仅根据公司的实际情况，和从大家那里得来的想法，谈一谈：

　　1、开发技能较强的软件测试人员可以转向自动化测试工具、测试管理工具的开发，这里不仅要求开发能力较强，还需要多了解第三方测试工具，挖掘测试组内测试人员的需求，了解业务；

　　2、业务能力较强的可以做测试(用例、计划)设计工程师，由于公司产品业务较强，需求人员仅能为测试人员提供需求文档，而究竟哪些是最重要的测试点，测试过程中采取什么样的测试方法能使得测试路径最短、覆盖率最全，这些都需要抓住软件业务的精髓；

　　3、做到了测试经理，完全可以把管理再出神入化，每个人身上有什么特点，怎样能让每个组员的能力发挥到极致，怎么更好的争取测试人员的利益，怎样做到最好的资源调配，怎样让大家不再迷茫，另外，怎样提升自己的威信，提升执行力，领导力，怎样把管理做到让人啧啧，到了这种程度，通过横向和纵向对比，优势自然就出来了。

　　另外，转做开发、需求、实施，然后又转回测试做管理，这种我是比较赞同的，但度不好掌握，而且如果自己的水平实在太高，很可能会让这类人产生英雄无用武之地的想法，公司的平台太低，而自己感觉自己的水平偏高，所以很可能导致这类人的离职，所以个人的发展和公司测试部的发展一定得保持同步，谁都不能过快，步伐不一致的的两个人怎么能走在一条道上呢?所以在个人发展的情况下，关注公司总体测试发展，先认清两者的发展方向再去‘转业’未尝不可。

　　4、做到测试设计人员、自动化工具、管理工具开发人员就是极致了吗?当然不是，测试行业照样有咨询、有顾问、专家，测试管理做好了也可以去做项目经理、去做部门经理，实在不行，完全可以去创业嘛。

　　总之，发展无极限，路是自己走出来的，不要只走别人踩出来的路。

软件工业是自动化工业的一部分。而且是最活跃发展最迅速的一个方面。到底有多迅速？任何人的想像力都不够！正如我们不会把我们的事务托付给不可靠的经纪，任何有分量的公司都不会采用没有质量保障的软件。软件测试人员，我是说有水平有经验的软件测试人员永远是供不应求的。软件测试经理不得不花很多的时间去面试有潜力的应聘者。一些应聘者在软件方面或者软件测试方面毫无实际经验，明知道软件测试工作是一个高回报的和最合适的软件工业入门，就是无法抓住一个又一个机会。这些人真正需要的是一个指南能告诉他们如何成为一个软件测试工程师。

首先，进入软件测试需要哪些技能？

1、软件工程技能你必须了解软件软件工程(设计、开发和简单测试)，应用，系统，自动测试编程，及操作系统，数据库，网络系统和协议的设计和使用。

2、交流技巧如果想确定软件缺陷，你应当能够指出什么时候的缺陷算是缺陷。

3、组织技能如果你在别人都头脑发昏的时候保持清醒，你就可能是一个好的软件测试工程师。在网络时代软件测试是一项有压力的复杂性工作，但如果你能从这些纷繁中找到一种途径，它就是一项回报丰厚的事业。

4、实践技能当一个工作需要经验，而你又需要一个工作去丰富你的经验时该怎么办？这并不完全是一个两难的问题，你可能采用几种方式去获得实际经验。

5、态度除了技术水平，你需要理解和采取适当的态度去做软件测试。

1、软件工程技能(Software Engineering Skills)

软件工程技能可以分成三大块：理解软件工程的规则，了解计算机编程和操作系统知识。

理解软件工程“规则”。有一种过时的眼光认为软件工程只是由一些在工作期限之前疯狂编程、靠着非凡的协调能力和超人般的咖啡消耗整夜不睡，不停地设计和测试程序的“专家”们组成的。这种现象确实存在，但你只有了解了软件开发的真正过程，才会是一个专业人员。

从哪开始呢？先到图书馆去走一走。你需要建立软件测试知识的软件工程基础。我的建议是阅读Roger Pressman的软件工程：A Practitioner's Approach, fifth edition (职业入门，第五版，McGraw Hill, 2000年版)和 Glenford Myers的The Art of Software Testing(软件测试艺术，John Wiley & Sons, 1979年版)。Pressman的书是一个对软件工程原理的全面介绍。有很多关于软件技巧、项目管理、要求分析和软件设计等软件工程方面的好书，但Pressman对这些方面在一本书里作了介绍。Glenford Myers不到二百页，1979年发行，却是软件测试方面的圣经。Myers定义及诠释的测试方法论已成为软件测试的基本模块。

Myers还考查了软件测试中的经济(缺陷的代价)和心理学方面(测试的目标就是发现失误及不成功之处)，以及主导软件开发和测试的基本原则。

对参考书进行基本研究是一个好的开端，但这只是单方对话。如果你能和上千个直接具有软件工程和测试经验的人以及想进入这一领域的人对话是不是再好不过了呢？感谢那些网络电子部落，你已经可以做到了。Comp.software-eng覆盖了设计、编程、项目管理等软件工程的各个方面。Comp.software.testing涵盖了软件测试的自动化、培训、技巧等方面。

等等，别只停留在这里！你是不是应当经常访问这些网址呢？Bug-Net(http://65.54.244.250/cgi-bin/linkrd...%2ebugnet%2ecom)是有关软件缺陷的在线杂志。阅读有关缺陷的文章是学习如何工作及失败的极好方式。你也应当查阅软件测试及质量工程杂志(http://65.54.244.250/cgi-bin/linkrd...ww%2estqe%2ecom)。STQE 是确定网络软件测试资源很好的始发站。

计算机编程。不能想像有的人喜欢测试产品却从不阅读、检查和理解组成产品的软件一样。

不要误解我的意思。你不必花所有的时间去读源代码，但任何你做过的有关自己程序的设计、编写和纠错都能大大地有助于测试别人编写的程序。

你怎样学习编程？通过编程。可以严肃地说，开始学习写计算机程序是最简单的事。记住我说的是“开始学习”。软件编程环境，例如 Microsoft Windows Foundation Classes (MFC) or Sun's Java Foundation Classes (JFC, also called "Swing")不断变得越来越复杂，越来越难跟得上。

但我在努力超越自己。你应当怎样学习编程呢？

首先，买Microsoft Visual Basic。不要让名字骗了你。你能用这套组件建立相当复杂的程序。而且它只要一百元左右。下一步呢？等等，是visual编程警告的时候了！

现在你为你的PC买一个程序语言的时候，你其实是买了一个集成开发系统或称为IDE。这些IDE通过对编程的简化把开发过程流水线化。这些IDE其实会帮你写很多编码。这非常有利于尽早开发出一个产品，却不利于你学习编程。如果你用Windows产生程序，你别无选择，因为环境介入太多使你无法从头编程。如果你从Unix系统产生程序，你能自己写所有的编码。

一旦你习惯了与参量、控制结构、对象、输入输出及更重要的Visual Basic纠错打交道的时候，你就可以开始学习C语言了。学习C能使你熟悉十六进制系统，通过指针分配和参考内存，存取个体位码及建立程序模块。

我总是认为在学Java之前最好先学会C，因为C强迫你自己去完成许多任务而Java会自动处理(例如，释放未用的空间)。用C工作比Java难，但你能学到编程更多的基本方面。你其实能用Visual C++ IDE从头写C程序，但最好还是在Unix系统中学C。

操作系统知识。你已经把它交给了在Redmond, Washington的那些人了。在短短的几年内，Windows NT已经成为世界上大部分计算机的标准操作系统。如果你要用NT工作，你需要了解它的寄存地址。(它是一种用于存储你的系统结构的各个方面的数据库。)我发现Peter Norton写的Inside Windows NT 4.0 (SAMS, 1998)是一本很好的介绍书。但是，如果你的应用或系统要求高的保密度、产出、可靠性及灵活性，Unix依然是最好的选择。

如果你想成为一个成功的软件工程师，你必须能在Unix的世界里工作，如果你想从头学习编程，也要在Unix下进行。

你的选择是什么？你可以到当地的学校或大学学习课程，或者在家建立一个Unix系统。别昏过去了，你所需要的只是一台PC和一份能让你从网络免费下载的Linux拷贝。(你大约花二十九元能买一份在一个CD-ROM中带了所有文件的拷贝。)Linux不是Unix的“玩具”版，它是真实的。它已经发行了七百万份拷贝，一些主要的PC生产商甚至先替你装载了它。

好了，你已经到了Unix或Linux系统了。你应当学些什么？文件和目录结构，标准输入输出和错误流，背景(background，也称为"daemon")处理，从C调用系统功能，好，我可以接下去了。一个好的开端是读Arnold Robbins的Unix in a Nutshell (O'Reilly & Associates, 1999)或者是Ellen Siever的Linux in a Nutshell (O'Reilly & Associates,1999)。

2、交流技能(Communications Skills)

能写出计算机程序却写不出一个完整句子的软件工程师现在还有。但不幸的是，要成为一个成功的软件测试工程师，你需要清楚的交流。

你怎么去学习写？通过写。如果文字水平太粗糙，上一门创造性写作的课。每天写工程流水记录或发email。关键是学习(或重新学习)怎样用清晰可懂的语言表达你的思想。一个好的写作参谋是William Strunk Jr.和E.B. White写的The Elements of Style(Allyn & Bacon, 2000)，它一点也不象初中教科书。

测试工程师必须把产品测试的技术写成文件。测试计划提供指导并把测试设计转化为设置、实现测试和评估结果的步骤指导。具有一般软件和产品特性不同层次经验的工程师都能使用这样一个详细的测试计划。如此测试设计者或测试方案作者之外的工程师也能能进行测试。

测试计划也帮着佐证测试策略的正确性。项目中的每个人都应当参与审查(即市场、开发、支持、技术写作及测试人)。计划的审查是必不可少的，因为尽管测试工程师尽最大努力来达成一个对产品的全面定义，这一测试设计者所基于的定义不一定是完整或准确的。此外，就象开发者很难测试他们自己的编码一样，测试工程师也很难明确评估他们自己的测试计划。每一个计划审查者都可能根据其经验及专长建议修改，有时候审查者还能提供测试工程师在组织产品定义时不具备的信息。例如，一个市场人员可能了解到了新的客户要求，一个软件支持专家可能从有关的产品领域了解到了一个新的缺陷报告。

测试计划强调测试计划和执行的原则。在测试计划中描述进行测试所需的测试设计和步骤是另一层关于测试设计和计划的原则。在测试设计和计划中的错误与欠缺在设计转化成测试计划中特定的结构和测试步骤后就经常是再已无法弥补。

测试计划可作为其它项目，例如为不同的产品准备测试时的参考资料。当被测试软件找到缺陷解决并证实后，测试计划所述的测试可以用于证实缺陷的解决方案。同时，一个主要的测试设计信息来源，特别对于旧产品的新版本而言，是相关产品或前版本的测试计划。在建立新版本时，旧版本的软件测试计划都应当被重新审查。

与功能与设计说明不同，测试计划将从测试的角度来描述产品的功能操作。从这方面说，测试计划构成了公司公共档案的一部分。随着时间的流逝人们会离开公司，带走他们的知识。以前产品的测试计划就能帮助你定义新产品的测试。

软件测试工程师还要写测试结果报告。测试结果必须写成文档，这样就能确定被测软件的状态，提供关于必须要解决的缺陷的记录。产品测试中发现的所有缺陷的记录是测试部门最显眼、保存时间最长的文档。测试计划和测试报告在项目的最后常被遗忘，但现存缺陷的清单(或数据库)代表项目未完成的议程。这一议程没完成是因为一些缺陷必须在对原来产品的一个patch或maintenance release的时候纠正，或者它们在这个产品作为后续产品的基础之前被修复。

在与软件产品打交道的过程中，测试工程师比其他部门的人参与项目的更多方面。测试部门应当记录项目过程中重大事件(例如设计决定)的信息。这个信息应能帮助测试部门和其他部门避免在后续项目中犯同样的错误。错误是不可避免，在一个项目中可能出问题。从这些经验中学习就可能避免问题，避免今后的同样错误。从错误中学习的第一步就是记住它们，记忆的第一步就是把它们写下来。

　 我们都知道微软的测试人员叫SDET(Software Development Engineer in Test)，其人员的能力都是非常强的，其实微软以前也是有STE(Software Test Engineer),但后来由于种种原因在微软抛弃了这种职位(一个是名称，还有就是自动化，这种职位的人员debugging能力有限，还有工作内容变化等)。但是不管怎样，在微软内部对SDET的能力培养总是不可缺少的，这一方面给测试人员有一种压力，另一方面也给测试人员对未来的一种渴望。现大概了解下微软是怎么来培养一个新的测试人员的：

　　这是从个人贡献度(在微软叫IC, individual contributor, 也就是我们经常说的技术专家)来考虑：

　　0-2年内：

　　1.       作为一个新的Tester，学习测试设计方法

　　2.       实现测试自动化

　　3.       具备Debugging能力

　　4.       学会 Model Based Testing

　　5.       选择性的学习一些course

　　2-5年内：

　　学习一些自己感兴趣的一些技术(设计模式，SQL Server，C#，C++, 协议，其他)

　　5-10年内：

　　成为Senior Tester

　　如果从测试管理角度来看，其实前面几年2-3年都是一样的，后面如果可以的话，可以作为new test lead, 然后学习一些管理课程，再后面就是new test manager。

　　可以看到，在微软也是一样，都会提供两条路，一个是管理路线，一个是专业技术路线。这里要说的是在微软测试人员和开发人员在职业发展上拥有同样的机会。

　　相信大家都听说过测试架构师，在微软也有测试架构师，但不同的是测试架构师是个角色，不是个职位。目前为止微软共有10000名Tester，只有40位测试架构师。

　 　大概说下测试架构师一般在干啥，有开发testing infrastructure, testing authoring frameworks, 有评估一些能创造复杂测试的一些特性，有些是在大部门内负责一些特定的技术，有些是专门提供咨询怎样提高测试效率。当然一些共同和主要的责任就是为他们部 门提供技术的领导力和测试策略的方向性。这也要求测试架构师不仅在测试领域，而且在开发和管理方面都要有提高效率的能力。

　　下面主要说下IC Tester 的职业发展路径，最开始就是SDET 1 也可说是 IC 1。到最高是 Partner SDET (IC 6), 这些级别之间的不同主要在技术深度，技术广度，影响力范围。

　　SDET的职业发展阶段

阶段职位名称	SDET	SDET 2	Senior SDET	Principal SDET	Partner SDET
对客户的影响力	收集用户反馈和阐明特性需求，还有写测试用例	在一些特性上与用户直接交互并提供关键的反馈，开发测试用例	定位用户的期望，考虑产品集成，还有设计特定的场景和UC	实施与用户进行技术的交流，并提高用户与部门之间的交互性	负责让高级用户理解整个产品线并提高产品设计
对测试的影响力	搞清楚一些模糊的需求和特性	在提高测试文档和技术设计上提供关键性的建议	确定一个能在未来发现多bug的设计模式	在一个产品领域，领导在测试方法和技术上的创新	在整个产品线领域，领导在测试方法和技术上的创新

　　解释下在微软产品和产品线的概念，比如 office 里面的word是个产品，那整个office就是个产品线。

　　IC的职业发展并不是在Partner SDET上就停止了，但在测试领域的确是这样，不过Partner SDET却是VP的候选人之一。所以大家应该有信心进入高层的。

　　如上都是从技术方向分析了测试人员在微软的发展道路，已经决定了职业发展方向的同学，你还在哪些方面有差距呢？后面会介绍从测试管理方向来看微软是怎样看测试管理的发展的。

作者: jige    来源: Taobao QA Team