在论坛混了多日，发现越来越多的性能测试工程师基本上都能够掌握利用测试工具来作负载压力测试，但多数人对怎样去分析工具收集到的测试结果感到无从下手，下面我就把个人工作中的体会和收集到的有关资料整理出来，希望能对大家分析测试结果有所帮助。

分析原则：

• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）

• 查找瓶颈时按以下顺序，由易到难。

    服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）

    注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。

• 分段排除法 很有效

分析的信息来源：

•1 根据场景运行过程中的错误提示信息

•2 根据测试结果收集到的监控指标数据

一．错误提示分析

分析实例：

1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection

•Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely

分析：

•A、应用服务死掉。

（小用户时：程序上的问题。程序上处理数据库的问题）

•B、应用服务没有死

（应用服务参数设置问题）

    例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％

•C、数据库的连接

(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)

2 Error: Page download timeout (120 seconds) has expired

分析：可能是以下原因造成

•A、应用服务参数设置太大导致服务器的瓶颈

•B、页面中图片太多

•C、在程序处理表的时候检查字段太大多

二．监控指标数据分析

1．最大并发用户数：

应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

    在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

    如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

2．业务操作响应时间：

    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。

• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？

• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题

3．服务器资源监控指标：

内存：

1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

内存资源成为系统性能的瓶颈的征兆:

很高的换页率(high pageout rate);

进程进入不活动状态;

交换区所有磁盘的活动次数可高;

可高的全局系统CPU利用率; 

内存不够出错(out of memory errors)

处理器：

1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 

合理使用的范围在60%至70%。

2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

CPU资源成为系统性能的瓶颈的征兆: 

很慢的响应时间(slow response time) 

CPU空闲时间为零(zero percent idle CPU) 

过高的用户占用CPU时间(high percent user CPU) 

过高的系统占用CPU时间(high percent system CPU) 

长时间的有很长的运行进程队列(large run queue size sustained over time)

磁盘I/O：

1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。

2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

I/O资源成为系统性能的瓶颈的征兆 :

过高的磁盘利用率(high disk utilization) 

太长的磁盘等待队列(large disk queue length) 

等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 

太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 

过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 

太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

4．数据库服务器：

SQL Server数据库：

1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。

2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。 

3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。

4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

Oracle数据库：

1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。

快存（共享SQL区）和数据字典快存的命中率： 

select(sum(pins-reloads))/sum(pins) from v$librarycache; 

select(sum(gets-getmisses))/sum(gets) from v$rowcache; 

自由内存： select * from v$sgastat where name=’free memory’; 

2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。

缓冲区高速缓存命中率：

select name,value from v$sysstat where name in (’db block gets’,

‘consistent gets’,'physical reads’) ;

Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。

日志缓冲区的申请情况 ：

select name,value from v$sysstat where name = ‘redo log space requests’ ;

4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。

内存排序命中率 ：

select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’

注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

本文出自51testing博客，转载请注明出处
原始链接：http://blog.51testing.com/?49159/action_viewspace_itemid_869.html

今天在整理电脑的时候发现这样一篇文章、已经想不起来是从哪里弄来的。仔细读来颇有一番收获、再次贡献给大家、愿大家在软件测试的道路上取得一席之地、实现自己的财务自由之路。

软件测试职业发展方向，大体上可以分为管理路线、技术路线、管理+技术路线。

软件测试，是技术主导的职业；不管选择哪条发展路线，都是需要一定的技术沉淀，只是相对来说，管理路线对技术方面要求不高而已。那么我们就先挑重头的技术路线展开讨论。一般来说，一个普通的测试工程师刚入行，3个月左右熟悉企业的工作流程和模式，那么今后的工作内容趋于平稳。

然而社会是残酷的！如果单单停留在测试工程师的阶段，若干年后，相信你再也竞争不过那个时候的应届毕业生，当你的工作技能和职业素质趋于与那些朝气蓬勃的年轻人相当时，企业会毫不留情的选择他们，而release你，因为你的成本消耗要比他们高，这是大实话！然而现实又是公平的！因为软件开发技术的不断日新月异，软件功能需求的不断丰富多样，决定软件开发这一系统工程的错综复杂，因此为了保证软件的质量，就要提高测试的水平，这也就为软件测试职业的细化起到先决因素，也是目前社会上出现招聘专项测试工程师的必然趋势！

因此，这个趋势给了我们这些常规测试工程师一个空前的好机会！所谓“以毒攻毒”，软件开发靠的是技术，为了测试软件，也必须用技术；那么我们就来看一下从技术路线，软件测试职业发展有哪些方向。

测试初级阶段：

测试工程师，属于软件测试职业生涯的初级域，其适用范围是入行软件测试3年内的常规测试从业者，其主要工作内容是按照测试组长、测试主管（即直接上司）分配的任务计划，编写测试用例、执行测试用例、提交软件缺陷，包括提交阶段性测试报告、参与阶段性评审等
管理+技术路线：
首先是常规路线，这条发展路线要求管理与技术并重，因为软件测试的行业特点决定了这个因素：测试工程师向上晋升到测试组长、测试主管、测试经理、测试总监，直至咨询域的更高方向！
测试组长是企业项目级主管，对于中小型软件公司也可以是企业级主管，属于中级发展域，适用范围是3到5年职业经验的测试从业者。其工作内容是根据项目经理或测试经理的计划安排，调配测试工程师执行模块级或项目级测试工作，并控制与监督软件缺陷的追踪，保证每个测试环节与阶段的顺利进行。严格来说，这个级别更多属于测试的设计者，因为企业的测试流程搭建是由更高级别的测试经理或相关管理者来做的，测试主管负责该流程的具体实施；而更多的工作，是思考如何对软件进行更加深入、全面的测试。测试主管比较有创造性的工作内容就是测试设计，而恰恰很多公司忽略了或没有精力来执行此工作内容！应该说，在一个企业里做了3年左右测试工作的人员，能够晋升到该职位，而之所以晋升，是与个人测试技术的过硬、测试方法的丰富，加上对测试流程的监控力与执行力的职业素质息息相关！
测试经理是更高级别的测试管理者，属于高级测试方向域。对于大中型软件公司，该职位尤为重要，并且对其职业要求也比较高，一般适合5到8年的测试从业者，在管理与技术能力双双比较成熟的情况下，可以结合具体环境晋升到该级别。测试经理负责企业级或大型项目级总体测试工作的策划与实施。测试经理除了需要统筹整个企业级或项目级测试流程外，还要对于不同软件架构、不同开发技术下的测试方法进行研究与探索，为企业的测试团队成员提供指导与解决思路，同时还要合理调配不同专项测试的人力资源（如业务测试工程师、自动化测试工程师、白盒测试工程师、性能测试工程师），对软件进行全面的测试；另外，一些企业里，测试经理还需要与客户交流与沟通，负责部分的销售性或技术支持性工作。
测试总监，属于常规发展路线的最高域，该职位一般在大型或跨国型软件企业，或者专向于测试服务型企业有所设立，一般设立测试总监的企业，该职位都相当于CTO或副总的级别，是企业级或集团级测试工作的最高领导者，驾驭着企业全部的测试与测试相关资源，管理着企业的全部测试及质量类工作。而其职业要求，也是技术与管理双结合。
技术路线：
技术路线中级域：
技术路线，划分为三个半方向，分别是自动化测试工程师、白盒测试工程师、性能测试工程师和认证测试工程师；前三者适用于通用软件测试领域，认证测试工程师乃嵌入式测试领域职位，至少目前仅出现在嵌入式领域。
自动化测试工程师，定义在功能测试范畴，指通常所说的依靠自动化测试工具进行软件黑盒测试的工程师。从大环境讲，自动化测试是软件测试执行阶段的必然趋势，社会对于软件测试的认可度以及对自动化测试人才的需求必将日益增加。
白盒测试工程师，定位于在软件测试周期的单元测试阶段对软件进行的代码级测试的人，包括代码走读、代码功能与逻辑测试、代码内存泄漏检查、代码运行效率检查、代码测试覆盖率分析等。如果说，自动化测试只是依靠脚本语言完成测试脚本编写与调试的过程（因为自动化测试工程师的工作重点不在编写脚本），对于自动化测试工程师的技术要求要相对偏低的话，那么白盒测试工程师就要对大型程序开发语言的完全掌握，因此其技术要求相对偏高！
性能测试工程师，即在系统测试阶段、功能测试后对软件系统性能指标进行采集分析和运行效率检测的人。在一个尽量压缩的测试流程里，功能测试可以手工进行，白盒测试可以不做，但是性能测试必须要做，除非该软件非网络类软件即单机版软件！软件测试，从宏观上可以划分为三个大方面：功能测试、性能测试、安全性测试，功能测试说明软件做对了，功能测试+性能测试说明软件做好了，三者结合起来说明软件做的非常好！安全测试暂且抛之不提，这是下一个发展域的内容，但是为了把软件做好，为了真正保证软件的质量，性能测试绝不容忽视；只因目前很多企业由于时间、成本、人力条件的限制，暂且不做性能测试。性能测试工程师相对来说，是三个技术路线里技术要求最高的，因为软件的性能瓶颈归根结底落实到代码的运行效率这个问题上，因此性能测试要做好，性能测试工程师起码要懂开发；而为了发现性能问题，要懂软件开发架构；为了定位性能问题，要懂操作系统、网络协议、应用服务器乃至数据库的原理与使用；为了最终解决性能问题，要根据定位的问题有针对性的对代码、操作系统、网络架构、服务器、数据库进行优化！当然性能测试是一个系统工程师，绝对不是一两个人的事情，对于常规性能测试工程师，具备定位性能问题的能力即可。
技术路线高级域：
进入技术路线的高级域，根据中级域的四个路线，可以细分成五个路线，分别是资深自动化测试工程师、资深白盒测试工程师、资深性能测试工程师、安全性测试工程师、标准化工程师，这些高级技术类人才完全与常规测试经理平齐，属于软件测试职业发展高级域。
资深自动化测试工程师由自动化测试工程师晋升而来。如果说常规自动化测试工程师只是负责自动化测试脚本本身的设计与开发，那么资深自动化测试工程师的工作内容就是自动化测试这项工作的实施！也就是说，录制脚本-添加验证点-回放脚本只是最初始的自动化阶段，要在企业实施自动化测试，要有资深自动化测试工程师来设计数据驱动，开发测试框架，甚至一些企业内部自主开发小型测试工具（而非商业工具）的先例，这些也都是建立在资深自动化测试工程师具有深厚的技术底蕴后，主导其他人员协调完成的事情。
资深白盒测试工程师，其工作内容包含常规白盒测试工程师的内容，除此之外，要协助测试经理或测试总监攻关测试方法与技术性难题，因此其技术水平更加雄厚。如果常规白盒测试工程师是停留在某种程序设计语言类型的代码级测试，那么资深白盒测试工程师就要脱离程序设计语言本身，结合不同架构、多种开发技术交互的情况下，寻找代码测试方法，并具有对代码优化的能力。
资深性能测试工程师，来源于常规性能测试工程师，按照常规性能测试工程师的技术要求，资深性能测试工程师应该具备性能测试整体方案的设计能力，以及软件系统性能问题定位和性能优化的能力！除此之外，也要对主流的软件开发模式下的应用系统具有敏锐的洞察意识和感知意识。
安全性测试工程师，其实从性能测试工程师衍生出来，因为只有具备性能测试经验的人，才对软件的开发模式、实现架构和技术本身充分了解，才会感知和预见软件系统存在的安全漏洞，加上其本人是测试出身，才知道如何通过系统漏洞尝试攻击软件系统，达到测试的目的。目前国内软件行业对于安全性测试的认识尚未清晰，该职业也更没有普及，一般只限于军事类、机密类、防病毒类或其他高安全性软件的测试工作中。
技术路线专家域：
在技术路线，向上继续提升的方向，我们称之为“技术专家”；如果说前面描述的技术职位的所涉范围都定位在企业内部，即企业级资深性能测试工程师，那么技术专家，我们可以看作是领域级专项人才！随着软件测试行业的职位不断细化，每个人在自己擅长的领域走向深入，都可以成为该领域的技术专家，技术专家在自已经营的领域里，具有个人独到的见解和深厚的技术实力，而这类人才可以不再从事具体的测试工作，而是提供行业性测试技术咨询、培训等，为软件测试整体行业的发展，起到了鲜明的带头作用。
管理方面：
管理方面中级域：
从事了1到3年左右的常规测试工程师，在经过对个人性格特点剖析后，如果认为自己是一个倾向于“高管理-低技能”的类型，那么想要实现自己的职业提升，可以向中级发展域的配置管理工程师、质量保证工程师、业务测试工程师转型。
配置管理(SCM)与质量保证(SQA)同是CMM中的关键过程域（KPA），也同是现代软件工程里的必要角色，与软件测试同属软件开发团队的重要组成部分。只因这两个角色在软件工程里的人员配比数量相对较少，还不如软件测试这样规模化乃至于形成行业，而最多是一个职业；另外一个社会现象是，企业很少直接从社会直接招聘配置管理工程师和质量保证工程师，而通常的做法是从企业内部的现有测试员工队伍里选拔，而转型后的测试工程师，就成为SCM或SQA。分析其原因，我们可以感知，SCM、SQA与软件测试工程师都是关注于软件质量的相似职位，社会对于配置管理、质量保证的定义和工作内容并未普及，与其直接从社会招聘“0”基础的人来培养，倒不如从软件测试人员里升华！一般来说，这两种职位的上报对象是项目经理或相同级别管理者。
转型后的配置管理与质量保证工程师，一定要转变一个意识，那就是常规测试工程师的工作范围很大一部分（不是全部）只限于测试流程，而配置管理和质量保证的工作范围是面向整个软件开发流程，二者的职业要求都非常重视软件工程知识体系的建立和软件开发总体流程的实施能力。由于配置管理工程师除了企业配置管理流程的搭建与实施外，一般会涉及配置管理工具的管理与维护，而质量保证工程师更多的工作是软件开发流程的控制与维护，故而配置管理对技术的要求稍高于质量保证。
业务测试工程师，定义为面向行业类软件业务逻辑与工作流测试的人员。当前软件开发类型，很大一部分是行业类软件的应用，如ERP、SCM、CRM、OA、电信、金融、财务、嵌入式、通信、手机、游戏……这就要求从事行业类软件测试的人员具备行业背景、业务知识，熟练该行业工作流程。从社会上出现的很多对此类经验要求的测试工程师招聘信息中，我们更加肯定这种趋势；所谓存在即是道理，既然社会上有了需求，那么就可以作为个人发展的方向。而另外一个特点是，业务测试工程师的工作内容主要是黑盒测试，属于功能范畴，因此对技术要求不大，设置一些大型行业类软件公司的业务测试工程师薪资丰厚，但是完全可以不懂技术，因为它的工作性质决定了不需要懂很多的技术！他们甚至连软件的界面测试都不做——交给常规测试工程师实施，而完全关注软件的业务性和易用性，由于其深厚的行业背景，可以为软件的在正式发布前提出很多建设性的意见，而这些建议正是软件开发商提高产品易用性、增加用户满意度、开拓市场、创造利润的关键因素之一！

管理方面高级域：
当管理路线的中级域方向继续上升至高级域，就分别到达配置管理经理、质量保证经理、产品经理、业务专家。
如果说配置管理工程师、质量保证工程师更加侧重于配置管理流程、质量保证流程的实施与日常管理维护，那么配置管理经理、质量保证经理就是更侧重于配置管理流程、质量保证流程的建立与改进。一般在中小软件企业，可能没有这两个角色，而全部的配置管理或质量保证工作都由工程师担当；但是大中型软件企业对资深配置管理经理、资深质保经理求贤若渴。软件系统越庞大，软件开发团队规模就越庞大，软件开发流程中出现问题的几率就越高，高效管理软件开发流程，不断改进软件质量，是每个软件公司在技术上没有顾虑后的下一个急需攻破的难关！
业务专家，属于行业内咨询、顾问的角色，已经几乎脱离了测试工作本身，而更多为企业的产品需求分析、设计、开发、测试等各个环节提供指导工作，其目的也是提高软件的易用性和稳定性，减少后期不必要的需求变更。该职位也同样在目前热点行业的大中型软件企业有所设立。
产品经理，这个职位在很多企业有所设立，可以说它是质保经理的派生，只是它更侧重于软件在产品化之前的质量监控工作，包括软件开发流程、软件测试等技术与管理的各个方面。
管理方面咨询域域：
管理路线的最高发展域是咨询域，与技术路线的专家域类似，在配置管理、质量保证、软件产品化、行业领域达到高深造诣的人才，他们有丰富的从业经验、深厚的管理底蕴，具有对软件工程高瞻远瞩的慧眼和胆识，往往供职在专业的咨询与培训公司，提供IT业管理类咨询与培训的服务，推动着软件行业的前进。国内外很多为软件企业进行CMM咨询和实施的公司里，就是这些人才的大本营之一！
由于国内软件测试行业目前的发展迅速、需求旺盛，在国内的软件测试职位晋升一般要比国外快，但因行业本身太年轻，大家对软件测试中软件测试职业的发展了解不够，从而导致许多有志在此发展的年轻人举步不前。所以下面介绍一下海外公司成熟的软件测试行业职位分布情况，我国一些在软件测试行业中处于前端的公司与之也相仿，这可以作为软件测试 职业规划 的参考，给新人一个导向。
各个职业阶段所需技能

第一阶段：(测试员)初级测试工程师
自身条件：初入行具备计算机专业学位或一些手工测试经验的个人。

具体工作：执行测试用例，记录bug，并回归测试，通过qtp等测试工具录制回归测试脚本，并执行回归测试脚本。

学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。

第二阶段：(测试工程师)程序分析员
自身条件：有1~3年工作经验的测试工程师或程序员。具有初步的自动化测试能力，完善自动化测试脚本。

具体工作：设计和编写测试用例，编写自动测试脚本程序且担任测试编程初期的领导工作。

学习方向：拓展编程语言、操作系统、网络与数据库方面的技能 。

第三阶段：(中级测试工程师)程序分析员
自身条件：有3~5年经验的测试工程师或程序员。负责管理1~3名测试工程师或程序员，具有一定的行业业务知识，储备系统分析员的能力。

具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审(软件需求，软件测试计划等)，并为其它初级的测试工程师或程序员充当顾问。

学习方向:继续拓展编程语言、操作系统、网络与数据库方面的技能。

第四阶段：（高级测试工程师）测试组负责人
自身条件：有5~8年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试等。

具体工作：负责管理5~8名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。

学习方向：性能测试，测试技能

第五阶段：(资深安全或性能测试工程师)测试/编程高级负责人
自身条件：有8~10年经验的测试工程师或程序员。

具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。 负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。

学习方向：开发一些特定领域的技术专长

第六阶段：测试/质量保证/开发(项目)、经理
自身条件：有10多年的工作经验。

具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工

第七阶段：(公司级质量总监)计划经理
自身条件：有15年以上开发与支持(测试/质量保证)活动方面的经验。

具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任

职业生涯规划是人生的大事，下面我结合亲身经历，谈谈自己的观点：

step1：校园阶段 (毕业前1年～1.5年)

很多人的 职业规划 是到了工作以后才开始进行的，其实，这样做，有很大的局限性。凡是工作过的人，都有一个体会，就是自己的第一份工作，会影响到5～10年的发展轨迹，甚至会对一生产生影响。因此，选择一份合适的工作作为起点，是必须要在校园内思考清楚的问题。

由于中国的教育基本是理论教育，大家在工作前的实践能力大多比较弱，固然有其不足，但也有好的一面，那就是可塑性比较好。可塑性好代表了选择的余地可以很大，因此，大家在选择第一份工的时候，要充分结合自己的教育背景、个人能力、兴趣爱好、长期目标等等，作出理性的决策。

软件测试，特别是黑盒软件测试是一种入门起点较低、上手迅速、且发展空间比较大的职业，因此，对于很多学生而言，作为进入IT就业的初级岗位，是非常合适的。

校园阶段的规划，主要是选择大的入门方向，当然，此时也可以给自己一个长期的目标，但是不必规划过细，因为，在没有入行前，一切都还未知，把握好路线即可。

下文假设大家选择的是软件测试～～

step2：入门阶段 (入行后3个月～1年)

对于刚刚入行的新人，这个时期是一个全面熟悉期，最能够学习到新的知识，也最有拼搏的热情和动力。建议大家可以借着这股冲劲，尽可能了解所在领域的全貌，了解各个主要分支的内容、特性、优势、局限性等等，并考察自己当前的工作环境，结合个人匹配程度和兴趣爱好，根据前述内容调整自己的规划。

对于测试行当而言，技术方面一般有几类：黑盒测试、白盒测试、自动化测试、测试工具、专用业务技能等;相关的管理方面一般有：测试管理、质量管理、项目管理等。

面对上述形形色色的方向，建议大家可以都稍稍了解下内涵，然后确定1～2个，作为中长期的主攻方向，达此标准，基本已经实现了入门，至于能否进得厅堂，就要看后期的努力了。

step3：提高阶段(入门后3年～5年)

对于入门后选择管理还是选择技术，其实这种问题，是无可无不可的，关键是看对自己的长期的定位了。不过，我个人建议当前阶段还是技术为重吧。毕竟，在一个技术环境中，要做好管理，没有扎实的基础，也难服众嘛。

本阶段是人最容易懈怠的阶段。毕竟，刚刚入行的热忱早已被日复一日的繁复工作给冷却，有了一定的工作经验，胜任本职，对于大多数人而言，绝不是问题。家庭、娱乐方面开始占据了业余生活的主流。可是，毕竟大家还很年轻，大多数人此时也不过20多岁，就此懈怠也是非常可怕的。因此，有规划的提高自身核心竞争力，在这个时候尤为关键。

提高是要提高的，但是对于大多数人而言，也没有必要很拼搏，此时处在一个比较稳定的职位上的你，可以考虑进行细化自己的中期规划了。根据选定的方向，制定一个自我提升的计划，并定义好自我检查的里程碑(譬如：每个季度或半年算一个阶段)，每天或者每周，有规律的学习一点即可。抱定一个目标——“每天进步一点点”，几年一大成不是问题。

我个人是反对急功近利的，倾向于稳打稳扎，这个阶段忌做“万金油”，而应努力成为有一技之长的“专家”。

对于选择做技术的人而言，这个阶段的达成标准，一般至少要能够熟悉你所选技术方向的大多数技术细节，“细节决定成败”嘛，虽然把握全局的能力是必要的，但是作技术而言，倘若不能钻的很细很深，恐怕也很难以高手自居吧。

对于选择做管理的人而言，我个人倾向是：此阶段接触管理的理念，并可以介入管理，但是此阶段不宜全面进入管理(除非你有更深层次的考虑，可以不去稳打稳扎)。学习管理的理念是非常重要的，其实管理更多一种思维和做事的方式，这门学问很深入，也不像技术，会不会是那么的显著，因此，建议多看多学，取长补短，并努力形成自己的做事风格。高级软件测试工程师，测试组长等，都是不错的含有技术特征的管理职位，此时的你应该能够胜任于此。

这个阶段的达成后，你也可以跻身老手行列，不必为求职犯愁，你应该可以很容易跳槽或时不时被猎头骚扰下，达成此阶段，你要做更深入的规划。

step4：升华阶段(老手后5年～10年)

此时的你，即将步入中年，不论是曾经专注技术还是偏爱管理的，都面临着家庭和社会的双重压力，你不可能像年轻人一样整天拼搏了，你需要稳定，因此，不能频繁的跳槽，建议考虑比较正规且有潜力的企业，要考虑给自己一个长远的发展规划。

  测试这行的客观规律总的来说是：入门容易，提升难。 有些人干测试8－9年了，其针对同一个产品的测试思路和方法，与干测试只有2－3年的人看不出有什么区别。于是行业中有了一种误区，认为测试技术的提升主要集中在对性能测试工具的使用及脚本开发，自动化测试开发，测试工具开发领域。仅个人愚见：测试工具开发和自动化测试开发 主要还是开发技术而不是测试技术，从没有做过测试分析，测试设计的开发人员也能胜任。如果仅狭义地认为测试技术的发展只在自动化测试框架开发或测试工具开发上，那么从逻辑上来说，任何一个开发人员都可以成为测试技术大拿。当然我想：没有人会真正这么认为。

  就其我的感受而言，开发工作有时反而会简单一些。为什么呢？开发工作的目标从一开始是非常明确的，要实现什么要做什么做到什么程度大多数情况下都是清晰的，最大的困难则是如何实现如何做到，总的来说是一个不断聚焦的过程。而测试工作的目标呢？其实很多时候，并不如开发那么明确，例如：同样一个性能指标，开发很清楚要通过实现XX算法来达到目标；而测试则需要对该性能指标先进行测试分析，再进行测试设计，可是测试分析做到什么程度却是一个发散的过程， 2小时也可以，2天也不够，这就导致了测试质量的浮动范围是非常大的，由于开发和项目经理通常对测试设计并不了解，也无法了解（测试其实是一个专业度非常高的领域），因此会导致测试部的工作质量很难在过程中真正去度量和监督。

   从哲学上来说：确定性的规律往往难度不大；不确定性的规律往往说明它是一个复杂系统。因此，我个人认为：测试技术领域最难的技术应该是测试分析和设计。从另一个角度来看，测试价值的体现最主要还是保障自己组织开发的软件在关键应用时不要出故障，给组织造成商业损失。所以，有效的测试覆盖率是最重要的测试工作目标（而不是自动化测试率），需要说明的是测试覆盖率不等于代码覆盖率。通过单元测试达到代码覆盖率100％了就能保障产品无bug其实是一个误区，因为很多组织会为了达到单元覆盖率而去开发单元测试代码，单元测试代码或单元测试设计的质量只能保障消除产品编码的问题，发现产品设计的问题则往往会很困难。而发现产品设计问题的最主要方法还得需要基于黑盒的测试分析和设计。
  如何做好测试分析和测试设计，根据我的经验和体会，建议测试分析和测试设计主要通过3个维度来做，则可以大致达到一个比较高的有效测试覆盖率：

  维度一：从用户实际使用的场景和习惯入手，开发一批测试用例；
  优点：  可以覆盖到主要基本场景；
  不足：  从事场景分析的人无法做到了解用户所有的场景，必定受参与测试分析资源限制会有场景遗漏；
 维度二：通过测试对象内部实现流程的路径及依赖关系分析入手，开发一批测试用例；
  优点：可填补维度一的部分遗漏场景，特别是异常处理和分支交互处理的场景；
  不足：分析阶段主要精力会被局限在内部流程的熟悉和分析中，从而也会遗漏真实环境中的一些偶然小概率事件；51Testing软件测试网

  维度三：依赖基于经验的测试分析和设计，例如：错误猜测法或探索性测试法；
  优点： 给维度二再做一次补充测试分析和设计；
  不足： 维度三效果的质量高低取决于组织内部经验的积累量及测试人员思维的发散能力和创造性；
  总得来说：无论是功能测试还是各种专项测试，依次使用以上3个维度的测试分析和设计，基本上能覆盖到被测对象的绝大部分应用场景，充分保障产品质量，减少问题遗漏。
    因此：测试的核心技术是测试分析和测试设计的能力，它决定了后续所有测试活动的质量及效果。同时，要做好一个测试任务，掌握广泛的测试类型也是必要的核心技术，如：如何给每个测试对象做细做深压力测试，长时间测试，健壮性测试也是决定项目测试质量的关键所在。我本人不相信随便做做的压力测试设计和健壮性测试设计能够保障产品实际应用表现良好。
  测试活动的质量或者一个测试工程师技术水平如何将主要取决于：测试分析和设计的深度及系统化，以及掌握广泛的专项测试类型。
转载http://www.51testing.com/?293557