日历
| |||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | 31 | ||||||
搜索标题
统计信息
- 访问量: 395
- 日志数: 6
- 建立时间: 2007-03-11
- 更新时间: 2007-06-14
RSS订阅
我的最新日志
-
JMeter 分布式性能测试
2007-6-14
-
zz [性能测试] 大批量测试数据的产生
2007-5-21
-
[转帖]Web下的整体测试
2007-5-21
-
JMeter 改善JMeter脚本质量
2007-5-21
解读改善Jmeter 脚本质量 [ 2006-10-27 9:47:00 | By: 黄峰 ]摘要
使用Jmeter开发一个负载测试脚本并不困难， 因为JMeter 提供了丰富的元件和拖拽风格的操作界面，但是，建立一个接近实际负载的测试脚本还是是有一定难度的。其中的一个原因就是鉴定测试质量的一些参数是令人费解的，本文可以为你解答部分这方面的疑惑，并就如何满足响应时间等测试需求等提供了一些指导原则。JMeter 是一个流行的用于负载测试的开源工具， 具有许多有用的功能元件，如线程组（thread group）， 定时器（timer）， 和HTTP 取样 (sampler) 元件。 本文是对JMeter 用户手册的补充，而且提供了关于使用Jmeter的一些模拟元件开发质量测试脚本的指导。
本文同时也讨论了一项重要的内容：在指定了精确的响应时间要求后，如何来校验测试结果，特别是在采用了置信区间分析这种严格的统计方式的情况下应如何操作。请注意，我假定本文的读者们了解关于Jmeter的基础知识，本文的例子基于Jmeter2。0。3版。确定一个线程组的ramp-up period （Determine）
Jmeter脚本的第一个要素是线程组（Thread Group），因此首先让我们来回顾一下。 正如图一所示，线程组需要设置以下参数：
·线程数量。
·ramp-up period。
·运行测试的次数。
·启动时间:立即或者预定的时间，如果是后者，线程组所包含的元素也要指定这个起止时间。
图 1。 JMeter 线程组（JMeter Thread Group）
每个线程均独立运行测试计划。因此， 线程组常用来模拟并发用户访问。如果客户机没有足够的能力来模拟较重的负载，可以使用Jmeter的分布式测试功能来通过一个Jmeter控制台来远程控制多个Jmeter引擎完成测试。
参数 ramp-up period 用于告知JMeter 要在多长时间内建立全部的线程。默认值是0。如果未指定ramp-up period ，也就是说ramp-up period 为零， JMeter 将立即建立所有线程，假设ramp-up period 设置成T 秒， 全部线程数设置成N个， JMeter 将每隔T/N秒建立一个线程。 (正确理解这个参数设置，是非常重要的。)
线程组的大部分参数是不言自明的，只有ramp-up period有些难以理解， 因为如何设置适当的值并不容易。 首先，如果要使用大量线程的话，ramp-up period 一般不要设置成零。 因为如果设置成零，Jmeter将会在测试的开始就建立全部线程并立即发送访问请求， 这样一来就很容易使服务器饱和，更重要的是会隐性地增加了负载，这就意味着服务器将可能过载，不是因为平均访问率高而是因为所有线程的第一次并发访问而引起的不正常的初始访问峰值，可以通过Jmeter的聚合报告监听器看到这种现象。 （当然如果想测试服务器的负载峰值则需要设置为零）
这种异常不是我们需要的，因此，确定一个合理的ramp-up period 的规则就是让初始点击率接近平均点击率。当然，也许需要运行一些测试来确定合理访问量。
基于同样的原因，过大的ramp-up period 也是不恰当的，因为将会降低访问峰值的负载，换句话说，在一些线程还未启动时，初期启动的部分线程可能已经结束了。
那么，如何检验ramp-up period I太小了或者太大了呢？首先，推测一下平均点击率并用总线程除点击率来计算初始的ramp-up period。 例如，假设线程数为100， 估计的点击率为每秒10次， 那么估计的理想ramp-up period 就是 100/10 = 10 秒。 那么，应怎样来提出一个合理的估算点击率呢？没有什么好办法，必须通过运行一次测试脚本来获得。
其次， 在测试计划（test plan）中增加一个聚合报告监听器，如图2所示，其中包含了所有独立的访问请求（一个samplers）的平均点击率。 第一次取样的点击率（如http请求）与ramp-up period 和线程数量密切相关。通过调整ramp-up period 可以使首次取样的奠基率接近平均取样的点击率。
图2 JMeter 聚合报告
第三， 查验一下Jmeter日志(文件位置：JMeter_Home_Directory/bin) 的最后一个线程开始时第一个线程是否真正结束了，二者的时间差是否正常。
总之，是否能确定一个适当的ramp-up time 取决于以下两条规则:
·第一个取样器的点击率（hit rate）是否接近其他取样器的平均值，从而能否避免ramp-up period 过小。
·在最后一个线程启动时，第一个线程是否在真正结束了，最好二者的时间要尽可能的长，以避免ramp-up period过大。
有时，这两条规则的结论会互相冲突。 这就意味着无法找到同时满足两条规则的合适的ramp-up period。 糟糕的测试计划通常会导致这些问题，这是因为在这样的测试计划里，取样器将不能充分地采集数据，可能因为测试计划执行时间太短并且线程会很快的运行结束。
用户思考时间（User think time），定时器，和代 理服务器（proxy server）
在负载测试中需要考虑的的一个重要要素是思考时间（think time）， 也就是在两次成功的访问请求之间的暂停时间。 有多种情形挥发导致延迟的发生： 用户需要时间阅读文字内容，或者填表， 或者查找正确的链接等。未认真考虑思考时间经常会导致测试结果的失真。例如，估计数值不恰当，也就是被测系统可以支持的最多用户量（并发用户）看起来好像要少一些等。
Jmeter提供了一整套的计时器（timer）来模拟思考时间（think time）， 但是仍旧存在一个问题：: 如何确定适当的思考时间呢？幸运的是， JMeter 提供了一个不错的答案：使用 JMeter HTTP 代 理服务器（Proxy Server）元件。
代 理服务器会记录在使用一个普通的浏览器（如FireFox 或 Internet Explorer）浏览一个web应用时的操作。 另外， JMeter 在记录操作的同时会建立一个测试计划（test plan）。 这个功能能提供以下便利：
·不必手工建立HTTP 访问请求， 尤其是当要设置一些令人乏味的参数时（然而，非英文的参数也许不能正常工作) 。JMeter 将会录制包括隐含字段（hidden fields）在内的所有内容。
·在生成的测试计划中，Jmeter会包含浏览器生成的所有的 HTTP 报头，如User-Agent (e。g。， Mozilla/4。0)， 或AcceptLanguage (e。g。， zh-tw，en-us;q=0。7，zh-cn;q=0。3)等。
·JMeter 会根据设置在录制操作的同时建立一些定时器，其延迟时间是完全根据真实的操作来设置的
现在让我们来看一下如何配置Jmeter的录制功能。 在JMeter 的控制台上， 在工作台（WorkBench）元件上单击右键，然后选择”add the HTTP Proxy Server “。 注意是在WorkBench 上单击右键而不是在Test Plan上， 因为现在是要为记录操作进行配置而不是要运行测试计划。 HTTP Proxy Server 的实现原理就是通过配置浏览器的代 理服务器而使所有的访问请求通过JMeter发送（，因而被Jmeter把访问过程录制下来）。
如图3所示， HTTP代 理服务器（HTTP Proxy Server）元件的一些参数必须被配置:
·端口(port): 代 理服务器的监听端口
·目标控制器（Target Controller）: 是代 理用于存储生成的数据的控制器，默认情况下，， JMeter 将会在当前的测试计划中找一个记录用的控制器用于存储，此外也可以在下拉菜单中选择任意控制起来存储，通常默认值就可以了。
·分组(Grouping): 确定在测试计划中如何来为生成的元件分组。 有多个选项， 一般可以选择“只存储每个组的第一个样本”，否则，将会原样录制URLs，包括包含图像和Javascrīpts脚本的页面。当然 也可以尝试一下默认值“不对样本分组”（"Do not group samples"），来看一下JMeter 建立的原版的测试计划。
·包含模式(Patterns to Include) 和 排除模式(Patterns to Exclude) :帮助过滤一些不需要的访问请求。
图 3。 JMeter 代 理服务器(Proxy Server)。
当你点击开始（Start）按钮时，代 理服务器就会开始记录所接受的HTTP 访问请求。 当然，在开始记录前，要首先设置好浏览器的代 理服务器设置。在代 理服务器元件中可以增加一个定时器子元件（配置元件），用于告知Jmeter来在其生成的HTTP请求中自动的增加一个定时器。Jmeter会自动把实际的延迟时间存储为一个被命名为T的Jmeter变量，因此，如果在代 理服务器元件里使用了高斯随机定时器，就应该在其中的固定延迟偏移（Constant Delay Offset）设置项里添上${T}（用于自动引用纪录的延迟时间），如图4所示。这是另一个节省时间的便利特性。
图 4。 在代 理服务器组建中增加一个高斯随机定时器
定时器将会使相应的的取样器被延迟。 延时的规则是，在上一个访问请求被响应并延时了指定的时间后，下一个被定时器影响的取样访问请求才会被发送出去。 因此， 你必须手工删除第一个取样器中自动生成的定时器，因为第一个取样器不需要定时器。
在启动HTTP代 理服务器以前，要在测试计划中增加一个线程组（thread group），在线程组中增加一个录制控制器（recording controller）用于存储生成的结果。 否则， 生成的元件将会被直接添加到工作台里。另外， 在录制控制器里增加一个HTTP请求默认值元件HTTP Request Defaults 元件 (是一个配置元件) 也很重要，这样Jmeter就不填写使用了默认值的字段。
录制完成后， 停止HTTP 代 理服务器; 在录制控制器元件上单击右键将记录的元件保存为一个文件用于以后重用，另外，不要忘了恢复浏览器的代 理服务器设置。
指定响应时间需求并校验结果
尽管本节内容与Jmeter不是直接相关，但是Jmeter仍旧是指定响应时间需求和校验测试结果这两个负载测试评价任务互相联系的纽带。
在web应用的环境里，响应时间指的是从提交访问请求到等到HTML结果所耗费的时间。从技术的角度看，响应时间也应包括浏览器重绘HTML页面的时间，但是浏览器一般是一块接着一块地显示而不是直接显示完整的整个页面，让人感觉响应时间要少一些。 另外，典型的情况是，负载测试工具不会考虑浏览器的重绘时间。 因此， 在实际的性能测试中，我们将考虑以上描述的情形， 如果不能确信，可以在正常的响应时间上加一个固定值，如0.5秒。
以下是一套众所周知的确定相应时间的标准:
·用户将不会注意到少于0.1秒的延迟
·少于1秒的延迟不会中断用户的正常思维， 但是一些延迟会被用户注意到
·延迟时间少于10秒，用户会继续等待响应
·延迟时间超过10秒后，用户将会放弃并开始其他操作
这些阀值很有名并且一般不会改变，因为是关乎人类的感知特性的。 所以要根据这些规则来设置响应时间需求， 也需要适当调整以适应实际应用。例如，亚马逊公司(Amazon.com) 的主页也遵循了以上规则，但是由于更偏重于风格上的一致，所以在响应时间上有一点损失。
乍一看，好像有两种不同的方式来确定相应时间需求：
·平均响应时间(Average response time )
·绝对响应时间（Absolute response time）;即， 所有的响应时间必须低于某一阀值
指定平均响应时间比较简单一些（straightforward），但是由于数据变化的干扰，这个需求往往难以实现。为什么取样中的20%的响应时间要比平均值高3倍以上呢？请注意，JMeter 计算平均响应时间与图形结果监视器中的标准偏差是一致的。
另一方面， 对绝对响应时间需求过于苛求是不实际的。 如果只有0。5%的取样不能通过测试该怎么办？如果再测一次，又会有很大的变化。 幸运的是， 使用置信区间（confidence interva）分析这种正规的统计方法可以顾及到取样变化的影响。
在继续进行前，让我们首先回顾一些基本的统计学知识。
中心极限定理（The central limit theorem）
中心极限定理表明如果总体的分布有一个平均值μ和标准偏差σ，那么对于一个十分大的n(>30)，其取样平均值的分布将接近于正态分布，其平均值μmean = μ ，标准偏差σmean = σ/√n。
注意取样平均值的分布是正态的，而取样自身的分布不必是正态的。也就是说如果多次运行测试脚本则测试结果的平均响应时间将会是正态的。
图 5 和图 6 分别展示了两个正态分布。 在这里横坐标是采样响应时间的均值， 总体的均值被调整到坐标的原点（shifted so the population mean is at the origin）。 图5 表明90%的时间里，采样均值位于±Zσ的区间里（percent of the time， the sampling means are within the interval ±Zσ，），这里的Z=1.645 和 σ 是标准偏差。 图 6 表明了99%的情况下的情形这时的Z=2.576。 在给定的概率下，如90%， 我们可以看到相应的Z呈现正态曲线，反之亦然。
Figure 6。 Z value for 99 percent
在相关资料中所列的是可提供正态曲线计算的一些网站。在这些网站，我们可以计算随意的相对区间内的概率(如，-1.5 < X < 1.5)或者在一个聚集的区域（cumulated area）内 ，(如， X < 1.5)。 也可以从下面的表中得到近似值。
表 1。 对应于给定的置信区间（confidence interval）的标准偏差范围（Standard deviation range）
表 2。 对应于给定的标准偏差范围（Standard deviation）的置信区间（confidence interval）
置信区间（Confidence interval）
置信区间（confidence interval）的定义是[取样平均值- Z*σ/√n， 取样平均值+ Z*σ/√n]。 例如， 如果置信区间（概率）是90%， 经查找可知Z 值是1。645， 于是置信区间就是 [取样平均值- 1。645*σ/√n， 取样平均值+ 1。645*σ/√n]， 这意味着在90%的时间里， 总体平均值（population mean）(是未知的) 会落入这个置信区间内。 也就是说， 我们的测试结果是十分接近的。 如果 σ（标准偏差） 更大一些， 置信区间也会更大，这就意味着置信区间的上限就会更可能会越过可以接受的范围，即σ 越大，结果越不可信。
响应时间需求（Response-time requirements ）
现在我们把所有的信息都归结到响应时间需求上来。首先。必须要定义性能需求，如: %95概率的置信区间的平均响应时间的上限必须小于5秒。 当然，最好有相应的需求或场景。
在性能测试结束后，假设进分析得出结论是平均响应时间是4.5秒，标准偏差时4.9秒，样本数量是120个，然后就可以计算%95概率的置信区间了。 通过查表1，找到Z值是 1。95996。 于是置信区间就是 [4.5 – 1.95996*4.9/√120， 4.5 + 1.95996*4.9/√120]， 也就是 [3.62， 5.38]。 尽管看起来这个响应时间看起来很不错，但这个结果（因为超出了需求的要求，因而）是不可接受的。 实际上， 可以检验的是即使是对于80%概率的可信区间，这个测试结果也是不能接受的。正如你所看到的，使用了置信区间分析后，会得到一个十分精确的方法来估算测试质量。
在web应用中，为了测定某一场景的响应时间，我们一般要通过测试工具来发送多个访问请求，例如：
4. 登陆
5. 显示表单
6. 提交表单
假设我们对请求3更感兴趣。为进行置信区间分析，我们需要的仅是请求3的所有样本的响应时间均值和标准偏差，而不是全部被统计的样本的。
在Jmeter的图表结果监听器中计算的却是全部请求的响应时间均值和标准偏差。 而Jmeter的聚合报告监听器计算的是独立的采样器的响应时间均值，可惜没有计算标准偏差。
总之， 仅仅指定响应时间均值是危险的， 因为不能反映出数据的变化。 即使响应时间均值是可以接受的，但是置信区间仅有75％，这个结果也不能令人信服。但是，使用置信区间分析还是会带来更多的确定性。
结论
本文讨论了以下内容:
·详细讲解了Jmeter 线程组在加载负载时的特别设置
·使用Jmeter代 理服务器(Proxy Server)元件自动建立测试脚本的指导方针，其重点在于模拟用户思考时间（user think time ）。
·置信区间分析（Confidence interval analysis）， 一种我们可以用来更好地满足响应时间需求的统计分析方法
通过使用本文提及的技术可以改善测试脚本的质量，更广泛地说，本文所讨论的内容属于是性能测试的一个工作流程的一部分， 是其中的一个较困难的部分。性能测试包括并不仅限于以下内容：
·编写性能测试需求
·选择测试情景
·准备测试环境
·编写测试脚本
·执行测试
·回顾测试脚本和测试结果
·指出性能瓶颈
·书写测试报告
此外， 性能测试结果，包括确定下来的瓶颈， 都需要反馈给开发团队或者架构师进行优化设计。 在这个过程中，并写测试脚本和回顾测试脚本是其中很重要的部分，要精心筹划和管理实施。凭借测试脚本指导和一个好的性能测试流程，你将会有更多的机会来在较重负载下优化软件性能。
关于作者
Chi-Chang Kung 是台湾Sun 公司的java系统架构师，也是IEEE 和ACM的成员。
相关资源
·JMeter: http://jakarta.apache.org/jmeter/index.html
·《中心极限理论以及经典推论》（"Central Limit Theorem and Classical Inference" ）Scott M。 Lynch (2005年2月):
http://www.princeton.edu/~slynch/clt_inference.pdf
·置信区间（Confidence intervals）:
http://people.hofstra.edu/faculty/Stefan_Waner/RealWorld/finitetopic1/confint.html
·《java网站的性能分析》（Performance Analysis for Java Websites）， Stacy Joines et al. (Addison-Wesley， 2002年9月; ISBN: 0201844540):
http://www.amazon.com/exec/obidos/ASIN/0201844540/javaworld
·《响应时间：三个重要的限制条件》("Response Times: The Three Important Limits") 引自《实用工程学》( Usability Engineering)， Jakob Nielsen (Morgan Kaufmann， 1994; ISBN 0125184069):
http://www.useit.com/papers/responsetime.html
·一些提供了正态曲线计算功能的网站(Websites for normal curve calculation):
o http://www.psychstat.smsu.edu/introbook/normal.htm
o http://www.ecositebr.bio.br/curva_normal.htm
o http://statistik.wu-wien.ac.at/mathstat/hatz/vo/applets/probCalc/normal_z_p.html
·更多关于测试的文章，请参照JavaWorld's 标题索引的Testing 部分:
http://www.javaworld.com/channel_content/jw-testing-index.shtml
·关于JAVA开发工具，参见JavaWorld's 标题索引的Development Tools 部分:
http://www.javaworld.com/channel_content/jw-tools-index.shtml原文地址：http://www.matrix.org.cn/resource/article/44/44226_JMeter+tips.html
-
zz 软件测试职业发展
2007-3-11
软件测试职业发展三步曲之一
http://hr.51testing.com/testcareer.asp
软件测试职业发展三步曲之一
——软件测试职业发展方向
作者：叶赫华
天地玄黄，宇宙洪荒；所谓光阴似箭，因为一转眼滚滚的历史车轮就将人类文明推进了二十一世纪的信息时代！葛大爷有对白曰：“二十一世纪最宝贵的是什么？”对曰：“人才！”何为人才？sincky曰：“适应时代潮流，把握社会需求，并为我中华老大帝国创造社会价值的人！”哎哟，不诹了，其实今天笔者在这里要和大家探讨的，是软件测试的职业发展问题，重点要阐述的是软件测试从业者的职业发展方向，欢迎大家按enter键换行，继续浏览！
一个人从大学毕业，即开始发生从学生时代向职业人士的过渡，这种过渡走的好，可以实现毕生宿愿，体现个人价值，不管你是否喜欢，功名、利禄尽收眼底；如果走的不好，则会误入歧途，纵有凌云壮志、万丈豪情，难免一生郁郁不得志，终归化作片片飞尘，无语对穹苍！那么如何才能顺利的完成这种过渡、踏上我们豪迈的职业旅程呢？答曰：认清自己，选择适途！战国的魏人荆轲具有“十步杀一人，千里不留行”的本领，曾向魏王献策曰：“国君，我是职业杀手，我杀人的技术很强！”魏王问：“那么你想杀谁呢？”对曰：“杀他个国君如何？”魏王大惊，慌然离去！后来荆轲离开魏国，与燕太子丹密谋，留下了“图穷匕首见”、“荆轲刺秦王”的千古佳话。荆轲，良禽也，择木而栖和太子丹合作，是他的高明之处；不过笔者认为他是一个典型的“低管理、高技能”的人才，当他紧握嬴政的脖领、持剑相逼时，他太得意忘性了，可见他没有领导的“统御力”和“决断力”，所以落了个刺杀失败、拔剑自刎的下场，虽然他的侠义与胆识流畅千古，但是终究是个“杀手”而已；当今社会下，如果“低管理、高技能”的人干工作干到丢了性命，那也真是一个笑谈了！
目前我们国家高等学历大幅度扩招，造成社会的低端人才严重过剩，大学生毕业找不到工作、或者找不到合适的工作例子鳞次栉比；但是社会各行各业对高端人才的需求又求贤若渴；那么如何解决这种矛盾呢？从大环境来说，国家应该改革教育体制、提高教学质量、重视高端人才的培养，但是，一个问题一旦上升到国家的层次，就要等它个十年八年！我们没有办法改变世界，但是我们有能力改变自己；所以我们从个人的角度来讲，讲讲我们这些软件测试的从业者们，如何“认清自己、选择适途！”
纵观当今社会各行各业，对于个人的职业发展方向，从宏观上都可以划分为四个群体，即：
“低管理、低技能”
“高管理、低技能”
“低管理、高技能”
“高管理、高技能”
而在IT 行业这种划分方法更为合理，sincky为其命名为“一起点-三方向示意图”：
告别了象牙塔，带着对校园生活里那段风花雪月的追忆，年轻的毕业生们走上了社会；这时候的年轻人，大多数是属于“低管理、低技能”的群体，我们没有工作经验，不知道企业的工作流程，不清楚各个职业的工作技能，更不具备任何行业的管理能力；然而值得庆幸的是，人类问明发展到现在所出现的众多行业，都已经有了众多可以参考的群体，这些群体就理所当然的成了我们可以借鉴的发展方向！虽然我们的起点都是一个，但是可以选择的发展方向却是丰富多样！
高管理-低技能，即是我们通常所说的管理路线！在IT业，这个方向的成功者不乏项目经理、项目总监直至企业的最高管理层；但是走这个方向也要有技术方面的积累，因为管理者的影响力中，除了职位赋予的权力以外，还包括个人人格方面的能力和专业领域的专业能力，而后者就是技术水平！而计算机行业本身，也决定了技术底蕴对职业发展的重要影响，所以年轻的IT朋友们，如果想为自己的职业人生设计成这个路线，除了适当的技术积累外，更要有意识的锻炼自己的管理素质，下图可做参考：
低管理-高技能，即通常所说的技术路线！IT业以技术为主导，对于喜欢钻研技术、探讨技术的人，可以选择该条路线，走的深入、走的彻底！只因中国对于技术与管理的认识不同，造成很多人认为做技术不赚钱、不被重视，自身误以为不过是个工程师而已，所做事情只是辅助企业的运作。实际上，在欧美发达国家，资深技术人员的薪资非常高，从业时间的周期也相当长，在Microsoft、IBM等巨头企业，不乏年龄在50岁以上的资深程序员或系统架构师，而其薪资也和高级管理者一样高！而另外一个不争的事实是，企业对于管理的职位是有限的，并且一些优秀的技术人员不愿做管理，或者不适合做管理，因此社会上出现的资深技术专家（或者类似职位），为喜好技术的从业人员提供向上的通道。
高管理-高技能，即咨询方向是较为均衡、全面的路线，也是众多企业希望员工努力的方向。然而有调查结果显示，由于现实种种因素的制约，大约90％的个人是分别沿着管理方向或者专家方向发展的，真正实现在咨询方向达到一定的高度的人少之又少，而且在这为数不多的咨询方向达到又一定高度的人才，往往又会由于企业资源的限制无法将个人价值完全发挥而最终离开所在企业，成为专业培训师、咨询师；一些国际知名的咨询公司如麦肯锡、安达信乃至毕博或其他，可谓大家在个人职业生涯到达一定阶段，作为自己继续突破职业瓶颈的发展路线。
那么，对于软件测试的从业者，我们的出路在哪里？我们的职业发展该如何设计？我们的发展方向又有哪些呢？这里笔者和大多数测试同行意识相同，笔者也曾在多篇文章里标明，中国的软件测试行业尚属起步阶段，其发展的步履上布满了荆棘与泥泞；然而其发展速度可谓惊人的，从笔者刚毕业时候对软件测试的“0”概念、从业同行者寥寥无几，到最近2年的各大媒体纷纷报道的中国软件测试人才缺口20万、软件测试工程师将成为未来10年最紧缺的人才之一、包括笔者所接触的众多国内外优秀企业对高端测试人才年薪10万、15万、20万的招聘需求……可见，选择软件测试这个朝阳行业的朋友，做了一个比较正确的选择！然而，如何任何事物总有它的两面性和矛盾性：2006年初在北京、上海、深圳举办的几次春季大型招聘会上，多家企业纷纷打出各类高薪招聘软件测试人员的海报，出人意料的是，收到的简历尚不足招聘岗位数的50％，而合格的竟不足30％……引起我们思考的是，我们的软件测试从业人员还有很大一部分不满足当今社会的需求；而另一层含义是，我们还有很大的提升空间！因此解决该矛盾的突破点是：每个人在这个行业里找到自己的发展方向，规划自己的职业蓝图，从而有针对性的锻炼自己的职业技能，增加个人的职业砝码！
软件测试职业发展方向，大体上与上述的通用职业发展路线图相吻合，也可以分为管理路线、技术路线、管理+技术路线；只是针对该行业本身，有其特殊性和细致性。其图示如同两个重叠的”V”字样，我们为其命名为“双V模型”；该模型适用于大多数行业性软件测试从业人员，一些特殊领域如游戏测试、嵌入式测试、硬件测试，也可作为参考。本文是三部曲之一，只介绍职业发展方向定义，在下一曲会介绍各个职业方向应该具备的知识与技能体系！
双V的底点是测试工程师，属于软件测试职业生涯的初级域，其适用范围是入行软件测试3年内的常规测试从业者，其主要工作内容是按照测试主管（即直接上司）分配的任务计划，编写测试用例、执行测试用例、提交软件缺陷，包括提交阶段性测试报告、参与阶段性评审等。初入测试行业，进入企业从事测试工作的人员，都要从该层次做起，虽然有时感觉乏味无趣，甚至迷茫困惑，但是我们可以根据个人的兴趣与特长，向上选择适合自己的路线，因为谁都不会甘心一辈子只做一个普通的测试工程师，那么大家看到这里，就可以摩拳擦掌，看看向上发展的通道中，哪一个适合自己，然后立刻从现在开始，确定自己未来5年、10年甚至一生的发展目标迈进，用笔者经常跟学员说的一句话来形容：把握现在，即刻做起，相信自己是最强的！
首先是常规路线，即双V模型的重叠线，这条发展路线要求管理与技术并重，因为软件测试的行业特点决定了这个因素：测试工程师向上晋升到测试主管、测试经理、测试总监，直至咨询域的更高方向！
测试主管是企业项目级主管，对于中小型软件公司也可以是企业级主管，属于中级发展域，适用范围是2到5年职业经验的测试从业者。其工作内容是根据项目经理或测试经理的计划安排，调配测试工程师执行模块级或项目级测试工作，并控制与监督软件缺陷的追踪，保证每个测试环节与阶段的顺利进行。严格来说，这个级别更多属于测试的设计者，因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的，测试主管负责该流程的具体实施；而更多的工作，是思考如何对软件进行更加深入、全面的测试。因此笔者认为测试主管比较有创造性的工作内容就是测试设计，而恰恰很多公司忽略了或没有精力来执行此工作内容！应该说，在一个企业里做了3年左右测试工作的人员，很容易晋升到该职位，而之所以晋升，是与个人测试技术的过硬、测试方法的丰富，加上对测试流程的监控力与执行力的职业素质息息相关！
测试经理是更高级别的测试管理者，属于高级测试方向域。对于大中型软件公司，该职位尤为重要，并且对其职业要求也比较高，一般适合4到8年的测试从业者，在管理与技术能力双双比较成熟的情况下，可以结合具体环境晋升到该级别。测试经理负责企业级或大型项目级总体测试工作的策划与实施。随着软件行业的发展，企业对软件工程里各个角色的定位逐渐明显，测试经理完全与开发经理（一些公司也成为项目经理）平齐，除了需要统筹整个企业级或项目级测试流程外，还要对于不同软件架构、不同开发技术下的测试方法进行研究与探索，为企业的测试团队成员提供指导与解决思路，同时还要合理调配不同专项测试的人力资源（如业务测试工程师、自动化测试工程师、白盒测试工程师、性能测试工程师），对软件进行全面的测试；另外，一些企业里，测试经理还需要与客户交流与沟通，负责部分的销售性或技术支持性工作。嘿嘿，看看那些高薪招聘测试经理的企业对该职位的要求里外语口语的描述，就可见一斑！
测试总监，属于常规发展路线的最高域，如果再往上发展，那只能是咨询域了；不过笔者并没有将其在图中标记出来，因为该职位对于国内目前的大多数软件公司根本没有设立，也就没必要再在图中体现了。该职位一般在大型或跨国型软件企业，或者专向于测试服务型企业有所设立，由于其企业自身的职位定位不同，以及软件测试整体行情所处的阶段，这里不好归纳陈述；但是一般设立测试总监的企业，该职位都相当于CTO或副总的级别，是企业级或集团级测试工作的最高领导者，驾驭着企业全部的测试与测试相关资源，管理着企业的全部测试及质量类工作。而其职业要求，也是技术与管理双结合；基于目前软件测试行情看，这种高管理-高技能的发展目标，不会适合大多数人的选择，社会也不会提供如此众多的测试总监职位让我们去应征！
应该说，大多数测试从业者都不是技术与管理双优的人，而如今一些到达测试经理或测试总监级别的优秀测试人才，已经领先一步开辟了这条发展路线的先河，希望这些朋友和大家多多分享经验，让更多的朋友弥补自己管理或技术上的不足，在这条路线上有所建树，共同提高，在实现个人人生价值的同时，也自然而然的推动了软件测试行业的发展；行业发展了，测试人员不再被忽视了，待遇自然也提高了，也就不会有很多朋友迷茫的跟我说“我的日常工作只是点击按钮和按键盘”了，因为我们相信行业的不断成熟，会逐渐将软件测试职业细化，我们的从业者就可以真正的在如下的管理路线和技术路线找到自己的位置，并潜心走向深入的！
软件测试，是技术主导的职业；不管选择哪条发展路线，都是需要一定的技术沉淀，只是相对来说，管理路线对技术方面要求不高而已。那么我们就先挑重头的技术路线展开讨论。一般来说，一个普通的测试工程师刚入行，3个月左右熟悉企业的工作流程和模式，那么今后的工作内容趋于平稳。然而社会是残酷的！如果单单停留在测试工程师的阶段，若干年后，相信你再也竞争不过那个时候的应届毕业生，当你的工作技能和职业素质趋于与那些朝气蓬勃的年轻人相当时，企业会毫不留情的选择他们，而release你，因为你的成本消耗要比他们高，这是大实话！然而现实又是公平的！因为软件开发技术的不断日新月异，软件功能需求的不断丰富多样，决定软件开发这一系统工程的错综复杂，因此为了保证软件的质量，就要提高测试的水平，这也就为软件测试职业的细化起到先决因素，也是目前社会上出现招聘专项测试工程师的必然趋势！因此，这个趋势给了我们这些常规测试工程师一个空前的好机会！所谓“以毒攻毒”，软件开发靠的是技术，为了测试软件，也必须用技术；那么我们就来看一下从技术路线，软件测试职业发展有哪些方向。
技术路线，笔者结合国内外软件测试行业现状，划分为三个半方向，分别是自动化测试工程师、白盒测试工程师、性能测试工程师和认证测试工程师，在“双V模型”中右侧体现；前三者适用于通用软件测试领域，认证测试工程师乃嵌入式测试领域职位，至少目前仅出现在嵌入式领域，因此以虚线标记，即“三个半”的“半”。前三条路线对技术的要求程度逐渐增加，三条曲线的斜率也依次递增（认证工程师不参与比较）。
自动化测试工程师，笔者为其定义在功能测试范畴，指通常所说的依靠自动化测试工具进行软件黑盒测试的工程师。笔者接触的很多测试界朋友，尤其年轻的刚入行者，对测试工具充满了无限的兴趣，他们喜欢那种编写脚本、调试成功后的快感，喜欢看到自定义的日志里记录了本来手工测试烦琐的无聊头顶的工作、而采用自动化方式实现后如此清晰丰富的内容后的兴奋！可以理解，因为笔者也是从那段时光走过来的，现在也负责于我们学员的自动化测试教学工作。从大环境讲，自动化测试是软件测试执行阶段的必然趋势，社会对于软件测试的认可度以及对自动化测试人才的需求必将日益增加，从目前国内做自动化测试的从业者薪资情况看，也普遍高于常规测试工程师，最浅显的道理是“自动化测试比手工测试有了技术含量，^--^”虽然自动化测试在整个行业的普及不是一朝一夕，但是从个人角度讲，自动化测试可以作为个人的发展方向之一，因为如果你率先掌握了这种技术，等到社会需要时，你已成为这个职位的成熟操作者！而国内的51testing把握了时代前沿，与自动化测试工具巨头厂商Mercury（美科利）合作，在中国唯一推出Mercury自动化测试全套技能认证（CPE/SP/CPC），相比其它初等认证，它的实效性和价值性更具意义，也为测试从业者提供了一个进入自动化测试领域的快捷方式！
白盒测试工程师，笔者定位于在软件测试周期的单元测试阶段对软件进行的代码级测试的人，包括代码走读、代码功能与逻辑测试、代码内存泄漏检查、代码运行效率检查、代码测试覆盖率分析等。如果说，自动化测试只是依靠脚本语言完成测试脚本编写与调试的过程（因为自动化测试工程师的工作重点不在编写脚本），对于自动化测试工程师的技术要求要相对偏低的话，那么白盒测试工程师就要对大型程序开发语言的完全掌握，因此其技术要求相对偏高！而另一方面，白盒测试在目前国内软件行情下，一些公司根本不做，其成本高、代价大的特点决定了这个现状，而一些对软件质量要求非常高（如军事类、电信类、财务金融类等）的企业，也会调动开发工程师来实施此事。但是，还是那句话，测试行业在发展，测试人员能力在提升，软件的开发技术在复杂化，要对软件进行尽可能全面的测试，白盒测试不可忽视！当下专门高薪招聘白盒测试工程师的企业也比比皆是，从中我们可以感知，白盒测试工程师会是很多有开发背景、意欲进入测试行业的良好突破口，白盒测试人员的需求也会逐渐增加。
性能测试工程师，即在系统测试阶段、功能测试后对软件系统性能指标进行采集分析和运行效率检测的人。笔者认为，在一个尽量压缩的测试流程里，功能测试可以手工进行，白盒测试可以不做，但是性能测试必须要做，除非该软件非网络类软件即单机版软件！这里笔者再提一个观点供大家参考：软件测试，从宏观上可以划分为三个大方面：功能测试、性能测试、安全性测试，功能测试说明软件做对了，功能测试+性能测试说明软件做好了，三者结合起来说明软件做的非常好！安全测试暂且抛之不提，这是下一个发展域的内容，但是为了把软件做好，为了真正保证软件的质量，性能测试绝不容忽视；只因目前很多企业由于时间、成本、人力条件的限制，暂且不做性能测试。性能测试工程师相对来说，是三个技术路线里技术要求最高的，因为软件的性能瓶颈归根结底落实到代码的运行效率这个问题上，因此性能测试要做好，性能测试工程师起码要懂开发；而为了发现性能问题，要懂软件开发架构；为了定位性能问题，要懂操作系统、网络协议、应用服务器乃至数据库的原理与使用；为了最终解决性能问题，要根据定位的问题有针对性的对代码、操作系统、网络架构、服务器、数据库进行优化！当然性能测试是一个系统工程师，绝对不是一两个人的事情，对于常规性能测试工程师，具备定位性能问题的能力即可。正因为性能测试工程师技术要求的高超，该职位的待遇也是目前测试技术路线最高薪的一个，实为综合技术能力较强的测试人员的明智选择！
上述四职业路线由于其技术程度的突出，一般在企业里由测试经理直接所属，与测试主管级别具有相同的待遇，并处于相同发展域。
进入技术路线的高级域，根据中级域的四个路线，可以细分成五个路线，分别是资深自动化测试工程师、资深白盒测试工程师、资深性能测试工程师、安全性测试工程师、标准化工程师，这些高级技术类人才完全与常规测试经理平齐，属于软件测试职业发展高级域。
资深自动化测试工程师由自动化测试工程师晋升而来。如果说常规自动化测试工程师只是负责自动化测试脚本本身的设计与开发，那么资深自动化测试工程师的工作内容就是自动化测试这项工作的实施！笔者早年在IBM公开讲座时候，讲过一篇《以RUP原则实施自动化测试》的主题，RUP里提倡自动化测试是一个庞大的系统工程，绝对不是有了技术、有了工具、有了掌握技术和使用工具的人就可以实施的，而是应该把自动化测试当成一个针对企业自身的项目来看待，需要经过引入、计划、设计、测试、执行、配置管理等环节（参加sincky的blog“天行健-君子以自强不息”），而这些自动化测试的流程搭建，就是资深自动化测试工程师的份内之事。另外，笔者要强调，按照国内外自动化测试领域的发展趋势，我们把自动化测试划分为四个发展阶段（我的blog里也有阐述）；也就是说，录制脚本-添加验证点-回放脚本只是最初始的自动化阶段，要在企业实施自动化测试，要有资深自动化测试工程师来设计数据驱动，开发测试框架，甚至一些企业内部自主开发小型测试工具（而非商业工具）的先例，这些也都是建立在资深自动化测试工程师具有深厚的技术底蕴后，主导其他人员协调完成的事情。
资深白盒测试工程师，其工作内容包含常规白盒测试工程师的内容，除此之外，要协助测试经理或测试总监攻关测试方法与技术性难题，因此其技术水平更加雄厚。如果常规白盒测试工程师是停留在某种程序设计语言类型的代码级测试，那么资深白盒测试工程师就要脱离程序设计语言本身，结合不同架构、多种开发技术交互的情况下，寻找代码测试方法，并具有对代码优化的能力。由于该路线在国内很少有实例参考，这里不再赘述。
资深性能测试工程师，来源于常规性能测试工程师，按照常规性能测试工程师的技术要求，资深性能测试工程师应该具备性能测试整体方案的设计能力，以及软件系统性能问题定位和性能优化的能力！初此之外，也要对主流的软件开发模式下的应用系统具有敏锐的洞察意识和感知意识。软件开发的架构会日益复杂化，软件应用的各种软硬件平台、数据库类型、服务器类型、网络协议层出不穷，不得不说，都为性能测试的从业者们提出了严峻的考验！值得庆幸的是，各种同类产品的厂商在开发产品时都遵从业内统一标准，性能测试人员结合自身的丰富经验，加上对软件性能测试技术的研究，这样的考验我们欣然面对，这样的人才则会日益增多，在软件测试行业里充当佼佼者地位。
安全性测试工程师，笔者将其从性能测试工程师衍生出来，因为只有具备性能测试经验的人，才对软件的开发模式、实现架构和技术本身充分了解，才会感知和预见软件系统存在的安全漏洞，加上其本人是测试出身，才知道如何通过系统漏洞尝试攻击软件系统，达到测试的目的。目前国内软件行业对于安全性测试的认识尚未清晰，该职业也更没有普及，一般只限于军事类、机密类、防病毒类或其他高安全性软件的测试工作中。
再次强调，人类进入文明社会后，任何社会活动都不是独立的个体能够实现的；在高度讲究团队合作、协同办公的今天，软件测试工作更不是测试工程师几个人就能做完所有的事情的；上述各发展路线的技能要求，只是为了增强个人职业突破的砝码，你的砝码越多，“被利用”价值越大，为企业创造利润的程度越高，企业自然给予你更丰厚的回馈！达尔文伯伯的“优胜劣汰”自然规律不会变，“多劳多得、少劳少得”的市场规律也不会变！
曾经有如此众多的测试职业发展路线放在我面前，结果我没有珍惜；等到软件测试行业发展到成熟阶段，我想入行却入不了行的时候，我才后悔莫及；尘世间干测试最大的不幸莫过于此；如果非要问sincky：再往上的发展通道是什么，那么sincky一定要告诉你，技术专家域！
在技术路线，向上继续提升的方向，我们称之为“技术专家”；如果说前面描述的技术职位的所涉范围都定位在企业内部，即企业级资深性能测试工程师，那么技术专家，我们可以看作是领域级专项人才！随着软件测试行业的职位不断细化，每个人在自己擅长的领域走向深入，都可以成为该领域的技术专家，技术专家在自已经营的领域里，具有个人独到的见解和深厚的技术实力，而这类人才可以不再从事具体的测试工作，而是提供行业性测试技术咨询、培训等，为软件测试整体行业的发展，起到了鲜明的带头作用。在一些专业的咨询、培训公司，或者IBM、Microsoft等巨型公司，不乏这样的人才；然而目前在我国，这样的人才较少，但是却可以为我们大家提供努力方向，只要我们每个在技术路线供职的测试从业者，规划好自己的职业人生，并以坚韧的毅力和顽强的斗志，若干年后，你我皆可笑谈测试人生，把酒临风，其喜洋洋者矣！而目前在国内几个IT行业发达的省市，专项于软件测试服务或一些大型软件企业，也有这样的职位暂露头角，我们深信，社会对高端人才的需求趋势是越来越大的，更多的优秀企业也会为员工提供更多、更广的发展空间，值此大好形势，就看我们个人如何充分利用这些上升通道了。
在我们的软件测试从业人员里，有这样一部分群体：他们非计算机相关专业毕业，不懂软件开发，由于国内种种对软件测试人才的偏激认识，认为测试人员不需要懂开发，只要会编写文档、执行用例即可；因此很多测试工程师并不具备开发背景，并且对软件技术掌握肤浅，而对于没有技术底蕴的人强迫其走技术路线，不能不说是一种折磨！因此，这个群体里的朋友，是不是认为自己只能做一辈子常规测试工程师呢？答案是否定的，因为在“双V模型”的左侧，是软件测试职业发展的管理路线。软件测试的管理路线，与通用职业发展示意图的“高管理-低技能”并不完全相同，只因软件测试独具的行业特点，我们认为软件测试行业的非技术路线发展方向，更多的是从软件测试行业衍生出来的职位，如质量保证、配置管理。如果说软件测试职业发展的技术路线更侧重于职业技能的提升，那么这条管理路线则更侧重于职业素质的积累（笔者强调是“侧重”，并不表示不需要）；换句话说，技术路线更侧重人的智力因素，而管理路线更侧重人的非智力因素。
从事了1到3年左右的常规测试工程师，在经过对个人性格特点剖析后，如果认为自己是一个倾向于“高管理-低技能”的类型，那么想要实现自己的职业提升，可以向中级发展域的配置管理工程师、质量保证工程师、业务测试工程师转型。
配置管理(SCM)与质量保证(SQA)同是CMM中的关键过程域（KPA），也同是现代软件工程里的必要角色，与软件测试同属软件开发团队的重要组成部分。只因这两个角色在软件工程里的人员配比数量相对较少，还不如软件测试这样规模化乃至于形成行业，而最多是一个职业；另外一个社会现象是，企业很少直接从社会直接招聘配置管理工程师和质量保证工程师，而通常的做法是从企业内部的现有测试员工队伍里选拔，而转型后的测试工程师，就成为SCM或SQA。分析其原因，我们可以感知，SCM、SQA与软件测试工程师都是关注于软件质量的相似职位，社会对于配置管理、质量保证的定义和工作内容并未普及，与其直接从社会招聘“0”基础的人来培养，倒不如从软件测试人员里升华！一般来说，这两种职位的上报对象是项目经理或相同级别管理者。
转型后的配置管理与质量保证工程师，一定要转变一个意识，那就是常规测试工程师的工作范围很大一部分（不是全部）只限于测试流程，而配置管理和质量保证的工作范围是面向整个软件开发流程，二者的职业要求都非常重视软件工程知识体系的建立和软件开发总体流程的实施能力。由于配置管理工程师除了企业配置管理流程的搭建与实施外，一般会涉及配置管理工具的管理与维护，而质量保证工程师更多的工作是软件开发流程的控制与维护，故而配置管理对技术的要求稍高于质量保证。随着我国软件行业水平的不断发展，众多软件公司纷纷通过CMM/CMMI，企业对于软件开发团队的角色配比制度也将逐渐健全，当前社会对配置管理与质量保证工程师的职位需求日益增加，种种现象表明，对于软件测试工程师出身的从业者，转型至SCM/SQA不失为突破个人职业生涯瓶颈的又一通道！
业务测试工程师，笔者定义为面向行业类软件业务逻辑与工作流测试的人员。当前软件开发类型，很大一部分是行业类软件的应用，如ERP、SCM、CRM、OA、电信、金融、财务、嵌入式、通信、手机、游戏……这就要求从事行业类软件测试的人员具备行业背景、业务知识，熟练该行业工作流程。从社会上出现的很多对此类经验要求的测试工程师招聘信息中，我们更加肯定这种趋势；所谓存在即是道理，既然社会上有了需求，那么就可以作为个人发展的方向。而另外一个特点是，业务测试工程师的工作内容主要是黑盒测试，属于功能范畴，因此对技术要求不大，设置一些大型行业类软件公司的业务测试工程师薪资丰厚，但是完全可以不懂技术，因为它的工作性质决定了不需要懂很多的技术！他们甚至连软件的界面测试都不做——交给常规测试工程师实施，而完全关注软件的业务性和易用性，由于其深厚的行业背景，可以为软件的在正式发布前提出很多建设性的意见，而这些建议正是软件开发商提高产品易用性、增加用户满意度、开拓市场、创造利润的关键因素之一！
当管理路线的中级域方向继续上升至高级域，就分别到达配置管理经理、质量保证经理、产品经理、业务专家，这类人才地位高、待遇厚，一般资深的软件工程领域专家都聚集于此。
如果说配置管理工程师、质量保证工程师更加侧重于配置管理流程、质量保证流程的实施与日常管理维护，那么配置管理经理、质量保证经理就是更侧重于配置管理流程、质量保证流程的建立与改进。一般在中小软件企业，可能没有这两个角色，而全部的配置管理或质量保证工作都由工程师担当；但是大中型软件企业对资深配置管理经理、资深质保经理求贤若渴。软件系统越庞大，软件开发团队规模就越庞大，软件开发流程中出现问题的几率就越高，高效管理软件开发流程，不断改进软件质量，是每个软件公司在技术上没有顾虑后的下一个急需攻破的难关！
业务专家，属于行业内咨询、顾问的角色，已经几乎脱离了测试工作本身，而更多为企业的产品需求分析、设计、开发、测试等各个环节提供指导工作，其目的也是提高软件的易用性和稳定性，减少后期不必要的需求变更。该职位也同样在目前热点行业的大中型软件企业有所设立。
产品经理，这个职位在很多企业有所设立，笔者认为它是质保经理的派生，只是它更侧重于软件在产品化之前的质量监控工作，包括软件开发流程、软件测试等技术与管理的各个方面。由于该职位在业内没有明显定义，而根据不同企业的职位定位不同，这里无法统一陈述。
管理路线的最高发展域是咨询域，与技术路线的专家域类似，在配置管理、质量保证、软件产品化、行业领域达到高深造诣的人才，他们有丰富的从业经验、深厚的管理底蕴，具有对软件工程高瞻远瞩的慧眼和胆识，往往供职在专业的咨询与培训公司，提供IT业管理类咨询与培训的服务，推动着软件行业的前进。国内外很多为软件企业进行CMM咨询和实施的公司里，就是这些人才的大本营之一！
笔者认为，在“双V模型”的管理路线里，中低级发展域的人才对技术与管理的区分较为明显，而到了高级与更高级发展域，更多的是复合型人才，软件业以技术为主导，没有一定技术积累，还是很难达到高级境界；要在管理路线练出“上乘武功”，还是希望大家在主攻管理与流程类课题的同时，多丰富下自身的技术层面，嘿嘿！
另外，笔者提倡管理与技术两条路线的平齐，而并非目前社会上认为的技术要比管理低一等，技术是靠吃青春饭，在这些人才到达最高发展域的“咨询”与“专家”层面，二者应该完全具有相同的地位和待遇，只是“称谓”不同罢了！
“双V模型”是sincky结合当前国内外软件测试行业现状提出的职业发展流程图，仅供测试从业者参考，并非一个“死”的框架，大家不要拘泥于流程图本身；其实目前国内很多上升到高级域或最高域的资深人才，很多都是跳跃式、甚至跨越式的职业发展，因为命运掌握在自己手里，任何人都剥夺不了设计自身人生蓝图的权利；而另外一个角度是，任何人都不该不珍惜为自己规划职业生涯的机会！
软件测试，一个日出东方的国际型行业，虽然偶尔会弥漫晨雾，甚或有暴雨来袭，但是我们都该坚持！有人说：“什么叫失败？”答曰：“放弃就是失败！”每一次当我们身处逆境时，决不能用软弱的眼泪作为走向明天的见证，更不能用脆弱的感情去拴住生命的航线；是雄鹰就该搏击长空，是蛟龙就该挽起狂澜；沧海横流，方显英雄本色，疆场搏斗，可露壮士肝胆！人生没有豁免权，每位从业者只有怀着不息的斗志，乘千里长风，破万里巨浪，才能支配命运走向辉煌的明天！
后记：sincky，网名叶赫华；在我从事软件测试培训业的1年多里，接触了国内很多除了我们学员以外的软件测试界朋友，其中新手居多。在我们的网站、论坛、我个人的blog、我的qq群乃至其他朋友以我名义建的qq群里，最让大家感冒的话题就是测试人员的职业发展！大家都在做测试工作，可以不知道明天做什么，明年做什么，或者若干年后做什么！“行有行规”，除非不在软件测试这个行业，否则就要遵守这个行业的规律！我觉得，我们的学员有职业发展培训课程，可是面对外界这些热心朋友的提问，长久以来，我一直想集中的写点东西，起码让刚入行的新手对这一行业的职业发展方向有一个直观的感性认知，我也心满意足！但是这个行业还太嫩，并没有章据可循，我搜索了几天的国外网站，可是没有成文的观点可以参考！后来决定自己来写，参照的对象就是国内现状下的测试从业者，于是在和国内各个领域的测试高手朋友们的交流后，我在2006春节前夕用了一白天的时间画出了“双V模型”图，而这篇文章的撰稿，用了我一天一夜的满满时间。在经历几次修改后，这篇文章在今天终于正式发布了，没有别的，只是希望给国内测试界朋友一个参考，欢迎大家批评、讨论，发表自己的观点！（我的msn地址：sinckyzhang@gmail.com）“双V模型”里很多职位名词在国内叫法不一，比如有人把初级测试工程师叫做测试员，我不赞同这种叫法，毕竟不是主流；而我的目的，只是通过这些职位的工作内容来告诉大家在职业定位上需要达到的高度，名字嘛，只是个代号而已！ -
纪念开张
2007-3-11