第一篇：软件测试人员结构组成分析（大全）
软件测试人员结构组成分析
软件测试工程师是软件行业中一种即年轻又古老的职业，进入二十一世纪以来，随着中国加入WTO以后，从事这项职业的人也越来越多。一个公司在组建一个测试队伍的时候如何分配人员结构，从而使公司软件测试工作水平得到提高，是大家比较关注的问题。本人依照自己的经验提出自己的观点：
我们首先来看一下测试人员的纵向结构
1，测试经理
测试经理主要负责测试队伍的内部管理以及与其他外部人员，客户的交流，详细说来主要包括进度管理，风险管理，资金管理，人力资源管理，交流管理等等，测试经理需要具有项目经理的知识和技能。同时测试工作开始前项目经理需要书写《测试计划书》，测试结束需要书写《测试总结报告》
2，测试文档审核师
测试文档审核师主要负责前置测试，包括在需求期与设计期间产生的文档进行审核，比如《业务建模书》，《需求规格说明书》，《概要设计书》，《详细设计书》等等。审核需要进行书写审核报告。当文档确定后，需要整理文档报告，并且反映介绍给测试设计师。3，测试设计师
测试设计师主要根据需求期与设计期间产生的文档设计各个测试阶段的测试用例。（往往测试文档审核师，测试设计师可以有相同的一组人来完成）
4，测试工程师
测试工程师按照测试用例，来完成测试工作。
但是测试人员应该有哪些人来组成呢？也就是测试人员的横向组成，让我们再来讨论讨论：
1，需要具有一定开发经验的计算机专业人员
由于具有一定开发经验的计算机专业人员即懂得计算机的基本理论，又有一定的开发经验。所以对于软件中哪里容易出错，哪里不容易出错他们了如指掌；他们可以分析程序的性能，软件性能差是否是占有内存空间太多，或者是占有CPU时间太多引起的，还是其他原因，他们往往是专家。尤其是进行非功能测试的时候，他们可以更好的搭建系统测试平台。这种人员应该占测试队伍中一半以上。
2，需要具有本软件业务经验的人员
测试队伍中需要有这样的人员的目的在于，这些人员由于对业务非常熟悉，软件质量的前提又是满足用户的需求。专业业务知识是计算机专业人员达不到的，所以这方面人才可以利用它们的业务知识和专业水平，参与系统需求期间的文当审核，可以发现软件中存在的业务性错误。比如专业用语不准确，业务流程不规范等等，这种人才对于专业性比较强的软件测试工作尤为重要，比如税务，法律，艺术，CAD,CAM…
3，只需要会操作计算机的人员
由于软件一旦卖出去之后，使用软件的人各种各样，各种各样的人带来各种各样的操作情况，请一大部分人员在软件测试工作后期进行测试工作是十分重要的，他们往往会发现专业测试人员测试不出的东西和一些希奇古怪的错误。这就是软件测试学中所谓的猴子测试法。对于一个软件公司来说，并不是说所有的测试队伍都需要这三种人员，实际中可以一组人代替多个角色，但是要遵循以下原则：
1，对于业务不是很专业的软件，具有一定开发经验的计算机专业人员与具有本软件业务经验的人员可以合并；
2，只需要会操作计算机的人员，可以由公司行政人员来充当。
第二篇：CS结构软件测试小结
安装卸载类：
1、在已经安装软件的情况下，再次进行安装，表现是否正常（比如提示是否升级、检测到已安装），需要考虑已安装和现安装版本差异问题
2、各种杀毒软件（卡巴、瑞星、360）对安装程序的影响
3、是否能在控制面板里面卸载
4、安装后快速启动、桌面、开始程序里面的快捷方式情况
5、卸载时是否退出客户端（退出和不退出都要考虑），卸载后的表现
6、安装的程序是否带有插件
带有微软的framewor，而影响用户的安装和使用
7、安装目录的考虑（中英字符、长度、空目录、根目录、修改目录、默认目录）
8、是否需要考虑在虚拟机中的安装使用？
9、各个版本的安装包大小，客户端产品是需要下载的，所以包的大小对用户来说比较重要 字符（串）类（可输入编辑框或者文本框等也会涉及到）
1、需要考虑字符串长度、字符类型（中文、英文、数字等）、编码类型、如果是英文，还会涉及到大小写的区别。
2、全空格的考虑情况，字符中间含有空格，最导和最后包含空格情况考虑
3、涉及到编码的，要看各个编码下的显示是否正确，以及各个编码之间
4、当有限制长度类的输入时，需要考虑长度刚好达到限制和超过限制后仍然进行输入的情况，也就是需要考虑边界值。
5、对于只能输入字符的地方，尝试输入其他字符比如 汉字，看看操作表现是什么样子。界面类
1、应用程序所有可点击地方是否可以进行操作，菜单、按钮、超链接（文字颜色以及是否能正常超链）、文字等。
2、各种操作对应的正确、错误类提示信息是否正确
3、窗口的缩放（双击的最大最小，点击按钮的最大最小，关闭）、拖动（开多个窗口拖动）、任务栏（左键单击和右键单击的操作）、托盘区、任务管理器操作
一般客户端软件，开着窗口在桌面上移动的时候，cpu占用都比较高，这个性能需要控制在某个合适的范围内。
4、需要考虑窗口的模态性问题，比如有模态窗口的时候，进行其他的操作，以及模态窗口的重绘等。
5、需要考虑软件对键盘上各个键的响应情况，最多用的是enter、shift、crtl、上下左右箭头，home，vendors，pgup，pgdn，del，对tab键的支持等。还要考虑各种热键（全局热键和软件自身的热键）是否能正确响应。
6、各种控件的表现和操作是否正常，下拉列表、日历控件等
7、如果有托盘图标，需要考虑托盘图标的显示状态，是否能显示，操作是否正常等
8、软件的tooltip是否正确合理齐全
9、如果有排序类功能，排序是否正确，如果不正确，和windows系统本身的排序进行比对，看是否一致（例如中文在英文之后，英文是否区分大小写）
10、操作界面的即使动态刷新
11、如果设计到焦点切换的，需要看鼠标的焦点切换是否正常，适合用户使用习惯。
12、涉及到列表类显示的，要看是否显示翻页，翻页是否正常
13、涉及到编辑框的，要看输入内容过多之后，是否有滚轮
14、窗口在屏幕上的位置是否需要具有记忆能力，比如某个窗口操作一次后，下次打开的位置定位在哪里？
15、有的客户端软件要求有飘窗类的提示，需要测试再不同情况下是否能出来，比如最小化到托盘、任务栏以及用ctrl+D显示桌面，是否能正常出来飘窗
16、需要考虑再不同显示器上的显示，各种比例和分辨率下的现实情况。
17、对换行符的处理，有的显示、输入区，如果有换行符的话可能会出现问题
测试遇到过含有换行符的话，后面的内容无法显示出来。
18、一些操作状态的延续变化，很难发现啊。
邮件列表中，在某个分组上点击右键，不放鼠标，将鼠标拖动到分组下的列表上，出现右键菜单不一致的bug。
19、对任务栏的考虑，要考虑任务栏在下方以及在屏幕上下左右侧的情况 兼容性
1、在中英文系统上使用的区别，在控制面板的区域和语言选项里面进行设置，管理选项卡里更改系统区域设置。
2、在不同操作系统上使用的区别（XP,VISTA,WIN 7,2000,2003）
3、在远程操作电脑的时候使用情况，测试的时候遇到过远程操作的时候会可能崩溃的错误。
4、浏览器：不同IE浏览器、带标签页和没有标签页，同一个IE浏览器不同版本的
5、同一个系统的不同系统用户操作（管理员和非管理员）
6、需要考虑不同分辨率，屏幕大小下是否能合适的显示。
7、需要考虑各种浏览器的缓存情况，会不会因为缓存而对测试产生影响
8、对于需要输入文字的地方需要考虑多种输入法切换是否能正常输入。输入达到限制后，再继续输入，是否有问题
9、在32位和64位系统上都需要进行测试。特别是对新的64位系统的支持度。
10、需要操作系统，比如sp1 sp2 sp3等，其他很多操作，可能会有影响的地方都需要考虑一下。
11、需要考虑计算机休眠、待机后再启动软件的表现情况，（还有待机）
各种杀毒软件对软件的影响。瑞星、卡巴、360等
杀毒软件对一些文件类型、端口等有监控，需要考虑。可能由于软件使用某些端口而被杀毒软件阻止而导致不能正常使用
12、jpeg格式图片有灰度图和RGB格式图片，都需要测试到。
13、考虑文件系统格式fat32 /ntfs下区别，比如fat32下有单个文件4G大小的限制等 5 用户体验类
1、界面文字提示是否友好、易懂、简练（因为用户都是懒惰的，不愿意看复杂的东西）
2、操作流程是否清晰，用户知道自己每步都是在做什么
3、有错误类信息，不要使用代码类文字，考虑到用户群体的情况，还要区分中英文（用哪个更好）上传下载传输类
1、上传是否超过最大容量、流量限制
2、上传格式
3、需要考虑不传输文件、传输文件内容为空（大小为0KB，边界值考虑）、文件内容包含特殊字符、文件名字符
4、涉及到网络传输，和端口有关系的，要考虑模拟一下端口错误，封端口的操作（需要补充具体如何封端口）
5、和网络有关系的要考虑使用代理的情况下，软件的运行状况，在传输中设置错误的代理，本地传输并没有受影响（自动收信过程中，设置了代理，但是自动收信还能继续），不受影响应该是正确的。
6、上传下载文件，考虑本地文件，还要考虑ftp，http上的文件。I/O读取类
1、需要考虑磁盘空间不足的情况
2、考虑同不同目录下相同文件的操作情况（比如邮件附件，两次添加同目录下的一个文件和分别添加不同目录下的相同文件的表现）和同目录下同名文件的重复操作
3、正在使用的文件是否是独占状态
4、涉及到文件操作时要考虑文件的类型（例如：txt、doc、gif、png、jpg。。。）、大小（0KB，正常、极大，其实也就是临界值考虑）
5、涉及到导入导出类操作的，需要查看导入导出过程中各种表现是否需要同步变化
6、涉及到文件保存时，需要考虑文件保存的类型、名称的默认给出。
7、文件拖动类的考虑
有的应用程序可以上传、下载、保存文件，那么拖动这些文件试试，看是否会有问题。
例如:对于foxmail邮箱这个软件，可以携带附件，那么试图拖动文件到附件区，或者从附件区拖动附件到文件夹，任务栏，或者拖动到程序中其他地方。另外，发现附件可以直接拖动到正文区进行显示的（新发现的功能，应该是编辑区的控件本身就支持吧，呵呵，惊讶了一把，居然还有这个功能，似乎很方便）。
8、系统对单个文件夹大小做限制，ntfs和fat格式的系统对单个文件大小有限制
9、图片文件原本为jpg格式的，但是修改后缀为gif后添加到表情 或者插入到其他地方。出现不能识别的问题。因为其他控件按照后缀先判断为gif格式，再走gif格式流程处理，但是实际上图片本身是jpg格式的
10、涉及到文件写入读取的，需要考虑移动设备，比如U盘、硬盘、ftp等 8 性能类
1、单核、双核的区别
2、内存大小的区别
3、同一个操作涉及不同的文件大小的时候，PC的反应（例如传输大文件和小文件）
4、涉及到网络操作时，超时是否及时、提示是否合理
5、是否有GDI泄漏（界面？）
6、使用过程中cpu、内存的占用情况 检索、过滤、搜索类
1、对分词的检索是否准确，比如如果检索ab，那么a b是否 会被检索出来？要视要求而定。
2、搜索的时候，对不同格式的文件内容，是否能够正常搜索，比如HTML格式和txt格式之间的区别，因为HTML格式本身含有标签以及其他一些内容，但是这些内容并不显示出来，所以搜索的时候是否需要搜索这些内容，需要进行考虑
3、搜索匹配时，对中英文的支持度（比如输入英文能否匹配中文，输入中文，能否匹配英文等。）
其他
1、客户端类软件，需要注意到开启的各个窗口之间数据同步一致性问题，各个窗口之
间事件触发是否会马上在其他窗口或者界面响应。
2、考虑界面上文字、各个窗口之间需要保持一致的文字说明。（诸如相同属性名称 文字提示信息等）
3、同一个操作涉及到的不同状态变化是否正常。（例如，点击某个链接，文字颜色是 否变化，点击某个按钮，按钮颜色或者属性是否变化等）
4、使用软件的过程中，多关注cpu、内存、句柄占用等方面的情况。
5、要能多考虑各种异常情况（磁盘空间不足、文件占用、网络断掉、断电、手动切进程模拟异常退出）
6、涉及到对文件目录的操作，需要考虑是否能记住/清除原来使用过的文件目录。如果是新建，要考虑是否可以新建成功（windows对新建文件的字符限制）
7、同一类的界面表现、操作应该尽量保持保持一致。（？没有描述好）
8、要多考虑进行了一个操作/设置后，可能会影响的其他方面，同步表现是否正常，设置是否有效等。
9、和服务器有相关的一些操作，都要考虑一些操作是在客户端处理，还是在服务器端处理的。服务器和客户端之间的一些交互返回信息，比如错误码等。
11、个人想法总结类
1、写总结、bug类语言描述一定要慎重，多读几遍，以便让其他人更能看明白，避免 求快而写错别字，用错术语。总结类需要写的更专业一些，避免通俗的、麽凌两可的的语言描述。宁可多花时间少写内容，少报bug，也不要报上去的bug，给别人看的总结出现过多纰漏，没有发现的bug可能是工作失误，但是发现了，但是却有不描述好，或者自己描述的不确定后事后自己都解释不清楚的话，那就更糟糕了，更上级看的总结也是如此，及时发现的bug再多，总结却是评价你这次测试的一个方面，如果总结写的很差，必然给领导留下很差的印象，或者总是在受到领导的批评。总之，三思而后行，是没错的，也许某些时候会降低工作效率，但是有时候，出现错误带来的负面影响比工作效率低下带来的负面影响更大。
2、开发对于一个软件安装和使用中生成的各种文件，最好有一份比较好的说明文档，当然开发可能没有时间去写，而且公司里面如果没有强行要求的话，他们也是不会写的，所以测试人员就只能自己多去钻研了，对于这些文件的了解对于测试也是很有必要的。遇到不懂的要及时跟开发沟通询问。有时候可能需要花费比较多的时间来了解开发的一些处理流程和文件具体含义（比如一些XML文件具体保存的是什么内容），这就需要协调和测试时间的冲突，因为要花时间了解，所以测试必然会耽误时间，但是了解之后却有利于进行某些功能的测试。慢慢改进吧。
3、不属于自己的任务，还是不要多去做的好
4、有时候自己提出来的产品问题，不一定会被领导、策划或者其他相关开发人员接受，除非等到产品发展部提出来。
5、测试中，只要有一点问题，就应该及时提出来，如果自己用的不顺手，或者觉得不合理的，自己多记录和总结，虽然不一定会被公司采纳，但是可以作为自己的总结类内容，整理出来。
12、可用性用户体验
1、跟网络有关系的，对网络错误的提示，有的需要及时，有的不需要频繁提示网络错误，应该多提供几次重连，比如三次，如果重连三次都发现网络错误连接失败，就提示用户，否则太频繁会有骚扰和降低用户对产品的信赖
2、给用户提供的操作，用户可以用，也可以选择不用，所以界面上需要提供取消类的入口，否则强制性的使用体验上不是很好，比如提供上一步类的入口也类似。
3、需要判断重复性的操作（已经安装、已经导入、已经。。）是否能提示用户
4、涉及到告诉用户文件类型的操作，应该尽可能明确的给予显示类型，因为不是很多用户对文件类型有概念。比如如果某个功能需要导入txt格式文件，尽量做到能自动检测显示出来，而不是让用户自己去找
5、像日历这种控件，不仅仅需要提供月更改入口，还要提供便利的年更改的入口
6、对于一些快捷键，能给予tip或者附带在文字后面的，尽量让用户可见，否则让用户揣测，那太不人性化了点吧。
7、发现***和其他圆角的窗口有同样的情况，最大化时鼠标移到屏幕的最右上角点击，如果没点中按钮而是正好点在圆角的地方，则关掉的不是闪电邮而是它后面的窗口，比如浏览器……因为我经常把鼠标往右上角一推就按，不会去找按钮，所以好几次了。不过这倒也不太算是毛病..
第三篇：软件测试人员的职业生涯发展规划
软件测试人员的职业生涯发展规划
第一阶段：（测试员）初级软件测试工程师
自身条件：初入行具备计算机专业学位或者一些手工测试经验的个人
具体工作：执行测试用例，记录bug，并回归测试，通过QTP等测试工具录制回归测试脚本，并执行回归测试脚本。
学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。
第二阶段：（测试工程师）程序分析员
自身条件：有1-2年的工作经验的测试工程师或者程序员。具有初步的自动化测试能力，完善自动化测试脚本。
具体工作：设计和编写测试用例，编写自动测试脚本程序且单人测试编程初期的领导工作。学习方向：拓展编程语言、操作系统、网络与数据库方面的技能。
第三阶段：（高级测试工程师）程序分析员
自身条件：有3-4年经验的测试工程师或程序员。具有一定的行业业务知识，储备系统分析员的能力。
具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审（软件需求，软件测试计划等），并为其它初级的测试工程师或程序员充当顾问。
学习方向：继续拓展编程语言、操作系统、网络与数据库方面的技能。
第四阶段：测试组负责人
自身条件：有4-6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。
具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。
学习方向：性能测试，测试技能
第五阶段：(资深安全或性能测试工程师)测试/编程高级负责人
自身条件：有6~10年经验的测试工程师或程序员。
具体工作：负责管理8~10名技术人员。性能测试整体方案设计，软件系统性能问题定位和性能优化，内存优化及分析数据溢出等，分析系统的安全漏洞等。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品。负责开发项目的技术方法。为一些用户提供支持与演示。
学习方向：开发一些特定领域的技术专长
第六阶段：测试/质量保证/开发(项目)、经理
自身条件：有10多年的工作经验。
具体工作：管理8名或更多的人员参加的1个或多个项目。负责这一领域(测试/质量保证/开发)内的整个开发生存周期业务。为一些用户提供交互和大量演示。负责项目成本、进度安排、计划和人员分工
第七阶段：(公司级质量总监)计划经理
自身条件：有15年以上开发与支持(测试/质量保证)活动方面的经验。
具体工作：管理从事若干项目的人员以及整个开发生存周期。负责把握项目方向与盈亏责任
第四篇：软件测试人员的自我修养
软件测试人员的基本修养
见到题目，你或许会想起电影《喜剧之王》中尹天仇所看的《演员的自我修养》，会对影片中周星驰所扮演角色对梦想成为一名出色的演员而孜孜以求的情节记忆犹新。人们说行行相通，我们这里就说说测试人员的基本修养。
见到题目，你或许会想起电影《喜剧之王》中尹天仇所看的《演员的自我修养》一书，还有那句经典的台词：我是一个演员，跑龙套的也是演员！更会对影片中周星驰所扮演角色对梦想成为一名出色的演员而孜孜以求的情节记忆犹新。人们说行行相通，一通百通。我们这里就说说测试人员的基本修养。
1、代码编写，不可或缺
乔布斯说：Design is not just what it looks like and feels like, design is how it works（设计不仅是外形和感觉，设计关乎如何运作）。那么可以说测试亦是如此，测试不是简单地拿过来用一用。当开发人员将开发完成的软件提交到测试人员那里以后，测试人员首先需要做的是迅速透彻地理解软件的功能。你会说这是需求讨论阶段已经介入的工作，没错，但除了理想状况，很多时候是赶鸭子上架，容不得按常理出牌。或者你会说要先做版本验证测试（BVT）查看其可测性，但这都是理想状况。
而无论如何，你首先要搞明白提交过来的东西具备哪些功能以及是如何工作的？事先准备好满足测试需要的软硬件环境自然不必多说。开发经验的作用不光局限于对编码及相关技术的理解，还会使你更加了解开发人员的心理感受，从编码心理和工作习惯的角度，更好地弄懂软件是如何工作的。这一点多多少少有点儿只可意会不易言传的感觉。我在工作中切身体会到，有些朋友搞定编码的思路，可以使人强烈感受到一股强大的、严密的逻辑气息。那思路和风格从头到尾自成一体——气派、美妙，令人赞叹不已。
世界著名计算机科学家，1984年图灵奖获得者Niklaus Wirth提出“算法+数据结构=程序”。清代人薛雪所撰《一瓢诗话》中有：如此体会，则诗神诗旨，跃然纸上。那么我要说：如此
体会，则码神码旨，亦跃然纸上。
2、全面深入，T型路线
T字型知识架构是指在细分领域细致专精，相关技术领域也要有所了解。测试人员真的需要了解相关技术吗？答案是肯定的。这里说的相关技术并非指测试相关，而是指开发所用的相关技术。说得再直白些，最好是懂得相关技术，甚至是该领域的技术专家。
我曾亲身经历过这样一件事情：在一个有着广泛市场影响的项目中，新版本发布增加了新的功能，在HTML页面中使用JavaScript来控制控件的显现。而发布时间紧迫，不允许有更多的时间使用正向用例来验证功能的正确性。尽管如此，我们也针对这小小的控件设计了将近百条用例。涉及的方面包括从页面的正反向跳转来验证控件的版本升级，到控件的跨域调用、浏览器的兼容、服务设置及干扰，如此种种，无一不需要通过了解相关技术，才能设计出有价值的用例。当然，有些有价值的用例来自于使用习惯，这可以说是很难有章可循的，需要靠经验的积累。最后，还要检查JavaScript文件内容是否正确。这样一来，最大限度地保证了产品上线后该功能点万无一失。
3、理清思路，有的放矢
很多人会认为，在测试工作中引入巧妙的编程技巧或者使用酷炫无比的技术手段，就代表测试水平高超。这种做法显然舍本求末，没有明白测试行为本身的目的。对于专业测试人员，这点误区可以理解，但不可接受。软件测试的目的，一方面是为了尽可能发现软件存在的缺陷，追踪直至解决这些缺陷；另一方面是为了度量被测试对象质量的优劣程度，对可能出现的问题从技术和其他方面采取相应的措施。两者都是为了降低潜在的商业风险。
一般来说，我们首先会根据软件系统本身的特点，其应用场景及开发人员等相关资源，去制订相应的测试策略，其中包括制订测试计划、分配测试资源、设计测试用例等。测试工作前期的大部分内容，不仅需要相关的技术知识，还包括更多的相关应用领域的知识和经验，以及分析能力。而这一切行为皆为降低产品潜在的商业风险所服务。诚然，使用优美的代码和酷炫的技术完成测试任务无可厚非，而无论如何，主旨不可偏离。
4、积基树本，夯实基础
好比说，找来一些帮手来垒墙，这自然不需要什么高深的建筑理论，但要做对整体工程进行把控的建筑工程师则需要读过建筑理论，掌握相关的基础知识。计算机科学领域中的基础知识，包括数据结构、操作系统、编译原理、数据库原理等。基础知识越是夯实饱满，也才越容易被融会贯通、结合实践从而得到宝贵的升华。数据库产品种类繁多，各类软件开发框架也层出不穷，而不变的永远是基础知识和基本原理。假如你明白高级语言应用开发学习的内容无外乎语法、框架和类库这三部分，学习起来自然不会眉毛胡子一把抓。
在计算机科学领域，如果涉及性能优化（时间复杂度、空间复杂度、数据库、操作系统、网络、并行计算、向量计算等）、复杂的数据结构、协议模型等特殊的问题，那么基础知识也就成了解决问题的必要条件。不用多说，作为专业技术人员，牢牢掌握这些知识是走向一流水平的不二法门。顺便说句题外话，这些基础知识同时也被看做试金石，可以帮助你进入一流水平的研发团队。
5、与人分享，谈吐有致
与人打交道，就难免涉及人际方面的事宜。沟通的技巧和方式自然是举不胜举，说上三天三夜也未必穷尽。所以在这里对此高谈阔论多少会显得有些捉襟见肘。但很重要且有效的一点沟通技巧可能会被忽略，那就是“不抱怨，找方法”。当团队之间、成员之间需要就某个问题进行交涉，甚至可能会发生争论乃至争吵时，最好少说多做，提出解决办法并且付诸行动。这里向大家推荐阅读卡耐基的《人性的弱点》以及费希尔的《沟通力》。希望能汲取其中的营养，完善性格的弱点，潜移默化地在无形之中大显神威。
6、一丝不苟，持之以恒
在软件测试的整个周期中，可能会出现一些不是总能重现的问题，这类问题的处理方式可大有讲究。从工程学的角度说，遇到这样的问题，不能及时找到原因而修复的话，需要降低该问题的优先级，等待再次重现，保留现场抓取的相关记录。这样既不会影响当前版本的发布，又毫无疏漏地追踪了曾经偶然出现的问题。某个问题一旦出现，是不能轻易放过的。既然不是总能重现，那如何证明此问题是否已经解决呢？当然，反复验证是重要的一方面。经过反复验证，其实还不能有把握地说这类问题已经修复。是不是心里还是没底呢？那就去看一看
源码。
每天反复做一件事，坚持10年，任何人都会有所成就。当企业和项目负责人，等待你那封Test Signoff邮件发出的时候，你是否可以满怀信心地点击Send按钮呢？是否可以对发布前提交的版本做到胸有成竹，锦囊之中自有乾坤呢？百年三万六千日，朝着自己的人生目标，努力过好每一天。修养的形成不在于猛攻，而在于点滴的积累和润物无声地打磨。
第五篇：软件测试人员的职业生涯规划
软件测试人员的职业生涯规划 第一阶段：（测试员）初级软件测试工程师
自身条件：初入行具备计算机专业学位或者一些手工测试经验的个人
具体工作：执行测试用例，记录bug，并回归测试，通过QTP等测试工具录制回归测试脚本，并执行回归测试脚本。
学习方向：开发测试脚本并且开始熟悉测试生存周期和测试技术。第二阶段：（测试工程师）程序分析员
自身条件：有1-2年的工作经验的测试工程师或者程序员。具有初步的自动化测试能力，完善自动化测试脚本。
具体工作：设计和编写测试用例，编写自动测试脚本程序且单人测试编程初期的领导工作。学习方向：拓展编程语言、操作系统、网络与数据库方面的技能。第三阶段：（高级测试工程师）程序分析员
自身条件：有3-4年经验的测试工程师或程序员。具有一定的行业业务知识，储备系统分析员的能力。
具体工作：帮助开发或维护测试或编程标准与过程，分析软件需求，获得测试需求。确定测试需求相应的测试方法，获得测试策略方案。参与同行的评审（软件需求，软件测试计划等），并为其它初级的测试工程师或程序员充当顾问。
学习方向：继续拓展编程语言、操作系统、网络与数据库方面的技能。第四阶段：测试组负责人
自身条件：有4-6年经验的测试工程师或程序员。具有丰富的行业业务知识，具有系统分析员的能力，专长性能测试。
具体工作：负责管理1~3名测试工程师或程序员。集中于技能方面，担负一些进度安排和工作规模/成本估算职责。分析性能瓶颈的原因，为开发团队提供bug解决策略。
学习方向：性能测试，测试技能
第五阶段：(资深安全或性能测试工程师)测试/编程高级负责人
自身条件：有6~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年)
此时的你，即将步入中年，不论是曾经专注技术还是偏爱管理的，都面临着家庭和社会的双重压力，你不可能像年轻人一样整天拼搏了，你需要稳定，因此，不能频繁的跳槽，建议考虑比较正规且有潜力的企业，要考虑给自己一个长远的发展规划。
正因为有前期的细节的背景的支撑，此时，你需要努力提升自己的宏观把握能力。哪怕做技术的，也要考虑适当的转型管理(中国特色是：工程师很难超过35岁的，一般人到了30岁不是转管理就是转商务了)。当然，一般人是技术做得越好，管理的时候，越容易切中项目要害。但是，对于从技术上来的人，关键是要开始培养和人打交道的能力。此阶段的关键是，需要逐步形成自己的管理风格，具备协调并行事务的能力。
当然，纯管理和技术型管理还是有所区别的。对于纯管理的人，熟练应用管理的科学理念，形成自己的风格尤为重要。纯管理的测试经理人，不仅仅可以做好测试方面的管理，其实也可以做好项目甚至其他的管理。其实，不管管理的对象是什么，它们的管理理念还是相通的。从测试管理中摸索出来的很多经验，可以很好的推广于其他的管理领域。而对于技术型管理的人，主要是带好技术团队，同时，不断补充新的技术知识，跟紧技术潮流。此时的你，有强大的技术背景支撑，不需要过分钻研细节，只需洞察核心，合理安排好你的团队成员即可。
这个阶段，也可能少数的人会选择离开具体的企业，而开始从事测试咨询，那是一个充满挑战的崭新开始，也必须有前期的积累方能胜任。
对于大多数人而言，此阶段中一个需要重点考虑的问题是，是否将测试作为自己的终生职位，如果是，基本上达到上述的目标，保持状态，基本可以做到退休的。如果不是，那就比较可怕了。其实我不建议此阶段的人转型，除非有充分的理由和很好的机遇。毕竟，达到此阶段，你已经付出了至少5年的努力，而且还是人生的黄金时段，时光一去不复返啊。当前状态下转行，请务必慎重。
点击咨询 