-
[转帖] QC 权限分配详解
2010-10-19 16:51:29
QCbug状态更改权限分配
1.首先用admin用户登陆QC指定项目，在状态栏选择【工具】→点击【自定义】
2.打开“Quality Center – 项目自定义”页面
设置“错误状态”
点击【自定义项目列表】→在“自定义项目列表”的“列表”属性框中选择【错误状态】
可以添加项目中需要的错误状态。
3.自定义组：点击【设置组】→在“设置组”页面→点击【新建】按钮→弹出的对话框中新建自定义组，并添加相关人员进去。
4.紧接着步骤3，点击【更改】按钮，弹出的权限设置 XXXX 组 （这里‘XXXX’是你刚才新建组的名称）→点击【缺陷】→在“修改状态”项中选择状态→在转换规则中，设置字段和状态。
5.这里还可以修改其他的权限，就简单的介绍这一个，举一反三，其他的如法炮制 -
mysql update：数据库字段值修改的方法
2009-08-14 08:27:57
-
英语论坛
2009-07-14 17:31:02
非常喜欢的英语论坛，下面是我的空间
谢谢大家光临哦希望大家也喜欢啊。。。
http://bbs.hxen.com/?fromuid=82465
http://bbs.hxen.com/?fromuser=LoveBeijing
-
C++ Test
2008-10-20 15:41:43
C++ Test是什么？
C++ Test是Parasoft公司出品的一个针对C/C++源代码进行代码风格测试，自动化单元测试的工具。
C++ Test能给我们带来什么？
1. 可以帮助我们检查程序的编码情况，判断是否严格按编码规范进行开发。
2. 对C/C++源代码进行分析，自动生成相应的测试用例，对函数进行初步的测试。
C++ Test的使用比较简单。可以自己新建一个工程，也可以根据一个VC工程生成一个工程。可以对整个工程进行全面的测试，也可以一次只对一个C/C++源文件进行测试。
图1
1. Command1：静态分析当前的文件。主要是对代码的风格进行检查。
2. Command2：动态分析当前的文件。主要是自动生成测试用例，对函数进行测试。
3. Command3：静态分析和动态分析。
4. Tab1： 显示源代码。
5. Tab2： 显示静态分析结果。
6. Tab3： 显示动态分析结果。
7. Tab4： 显示测试进度。
8. Message Area： 显示一些具体的信息。
C++ Test的使用
让我们先来看看一段很简单的程序。
#include "windows.h"
int Sum(int *pNum1, int *pNum2)
{
return *pNum1 + *pNum2;
}
int main()
{
int nSum;int Num1,Num2;
Num1 = 1;
Num2 = 2;
nSum = Sum(&Num1,&Num2);
return 0;
}够简单了吧？并且也许你也写过这些代码。但这些代码书写的风格如何？存在隐患吗？那就用C++ Test分析一下。
先来看看代码风格如何。在上图中就显示出很多，大致可归纳为如下几种：
1. 如果不允许改变参数的内容，声明参数为const。
2. 不要使用tab作为空格。
3. 全局函数或变量前使用::操作符。
4. 所有int型的变量都要以“i”开头。
5. 变量声明，但没有初始化。
6. Return的值要使用括号。
有六条？不太相信自己的眼睛吧？我想要有好的风格，这些建议是比较好的，但在实际工作中可能规定的太细了。要想把一匹野马驯服，还是要慢慢来的。
C++ Test可以设置、编辑、创建静态编译的规则。就让我们来设置一下。
图2打勾的就是选择的规则，在静态分析时就会使用这些规则。在图1的Message Area中第一行显示表示所有int型的变量都要以“i”开头属于User-110规则。如果你想取消这条规则，那你在图2中找到这条规则，把勾去掉就行了，重新静态分析一下，这条提示就没有了。
那么动态分析能做什么呢？我们先来看看结果。
图3
先看第一行，这就是分析结果的总结。它表明的意思是总共产生了51条测试用例，37条测试成功，14条测试失败。先分析第一条失败的测试用例（AUTO_14_A0），以pNum1 = NULL， pNum2=NULL为参数输入，测试失败，这就表明在函数中没有对参数的有效性进行判定，这就是程序的一个隐患。当然用户可以对测试用例进行删除和更改，还可以添加自己的测试用例，以弥补自动生成的用例。
上面提到可以创建用户自己的代码规则，我这里也就不多说了，因为C++ Test自带的帮助已经说的很详细了。
总结
使用了一下C++ Test，初步的个人感受有以下三点：
1. 对项目的代码统一还是很有帮助的，同时也能让编程者慢慢养成好的编码习惯。因为通过静态分析，能强制你书写规范的代码。
2. 对项目的一些简单函数进行测试，特别是边界的测试，排除一些基本的错误或代码的隐患。
最好在项目的一开始就使用C++ Test，边编写代码边检查，这样就不会欠下太多的债。在试用中发现，如果项目比较大时，最好不要直接对一个工程进行自动测试，而应按文件一个一个地测试，否则可能会导致程序死掉。 -
一般人绝对不会的电脑小绝技
2008-09-17 11:15:33
-
Regsvr32.exe
2008-09-16 15:09:24
-
软件测试职业发展三步曲之一
2008-09-09 17:28:35
软件测试职业发展三步曲之一
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模型”里很多职位名词在国内叫法不一，比如有人把初级测试工程师叫做测试员，我不赞同这种叫法，毕竟不是主流；而我的目的，只是通过这些职位的工作内容来告诉大家在职业定位上需要达到的高度，名字嘛，只是个代号而已！
我的设想是写三篇文章，叫做《软件测试职业发展三步曲》系列，本文是第二曲，也是三步曲的核心，首先问世，主题是“软件测试职业发展方向”，将来还会陆续推出第一曲“软件测试职业选择”、第三曲“软件测试技能体系”，呵呵，如果大家对本文表示肯定的态度比较多，我会继续写下去，否则我还是回家干我的山贼那份很有前途的职业吧！^-^ (2006年4月10日)
[ 本帖最后由 songfun 于 2006-12-25 14:58 编辑 ] -
Web 测试经典案例
2008-09-01 15:41:04
-
无痛苦的软件维护——被遗忘的需求
2008-09-01 15:37:59
-
开发知识对测试人员的重要性
2008-08-29 17:52:53
-
黑盒测“外”不测“内”
2008-08-29 17:35:14
文章出处：赛迪网 作者：不详软件测试有许多种方法，其中黑盒测试是广泛使用的两类测试方法之一。
“黑盒”测的是功能
黑盒测试也称功能测试或数据驱动测试。它在已知产品应具有的功能的条件下，通过测试来检测每个功能是否都能正常使用。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。
“黑盒”的两种基本方法
黑盒测试有两种基本方法，即通过测试和失败测试。
在进行通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何。软件测试员只运用最简单，最直观的测试案例。
在设计和执行测试案例时，总是先要进行通过测试。在进行破坏性试验之前，看一看软件基本功能是否能够实现。这一点很重要，否则在正常使用软件时就会奇怪地发现，为什么会有那么多的软件缺陷出现？
在确信了软件正确运行之后，就可以采取各种手段通过搞“垮”软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试案例，被称为失败测试或迫使出错测试。
黑盒测试的设计方法
黑盒测试是以用户的观点，从输入数据与输出数据的对应关系出发进行测试的，它不涉及到程序的内部结构。很明显，如果外部特性本身有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。黑盒测试法注重于测试软件的功能需求，主要试图发现几类错误：功能不对或遗漏、界面错误、数据结构或外部数据库访问错误、性能错误、初始化和终止错误。
具体的黑盒测试方法包括等价类划分、因果图、正交实验设计法、边值分析、判定表驱动法、功能测试等。在使用时，自然要针对开发项目的特点对方法加以适当的选择。
◆ 等价类划分
等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例可以不用考虑程序的内部结构，只以对程序的要求和说明，即需求规格说明书为依据，仔细分析和推敲说明书的各项需求，特别是功能需求，把说明中对输入的要求和输出的要求区别开来并加以分解。
由于穷举测试的数量太大，以致于无法实际完成，促使我们在大量的可能数据中选取其中的一部分作为测试用例。例如，在不了解等价分配技术的前提下，测试了1+1、1+2、1+3和1+4之后，还有必要测试1+5和1+6吗?能否放心地认为它们正确吗?那么1+999…（可以输入的最大数值）呢？这个测试用例是否与其他用例不同？是否属于另外一种类别？另外一个等价区间？这是软件测试员必须考虑到的问题。
等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。 1+999…和1+13有什么区别呢？至于1+13，就像一个普通的加法，与1+5或者1+392没有什么两样，而1+999…则属于邻界的极端情况。假如输入最大允许数值，然后加1，就会出现问题——也许就是软件的缺陷。这个极端案例属于一个单独的区间，与常规数字的普通区间不同。
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能出现同样的错误。使用这一方法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，列出等价类表。
在考虑等价类划分时，先从程序的功能说明中找出每个输入条件，然后为每个输入条件划分两个或更多个等价类。等价类可分两种情况：有效等价类和无效等价类。有效等价类是指对程序的规格说明是有意义的、合理的输人数据所构成的集合；无效等价类是指对程序的规格说明是不合理的或无意义的输人数据所构成的集合。
◆ 边界值分析
软件测试常用的一个方法是把测试工作按同样的形式划分。对数据进行软件测试，就是检查用户输入信息、返回结果以及中间计算结果是否正确。
即使是最简单的程序，要处理的数据也可能数量极大。还记得在计算器上简单加法的全部可能性吗？再想一想字处理程序、导航系统和证券交易程序。使这些数据得以测试的技巧（如果称得上的话）是，根据下列主要原则进行等价分配，以合理的方式减少测试案列：边界条件、次边界条件、空值和无效数据。
边界值分析（Boundary Value Analysis，BVA）是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。实践证明，在设计测试用例时，对边界附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例，常常可以取得良好的测试效果。BVA不仅重视输人条件边界，而且也从输出域导出测试用例。
边界值设计测试遵循的五条原则：
1、如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围边界外的值作为测试用例。如以a和b为边界，测试用例应当包含a和b及略大于a和略小于b的值；
2、若规定了值的个数，分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例；
3、针对每个输出条件使用上述1、2条原则；
4、如果程序规格说明中提到的输入输出域是个有序的集合（如顺序文件、表格等），就应注意选取有序集的第一个和最后一个元素作为测试用例；
5、分析规格说明，找出其他的可能边界条件。
-
软件测试流程
2008-08-29 17:30:41
-
测试一个月后的工作总结
2008-08-29 17:09:35
-
[论坛] Jira简介
2008-08-26 15:27:54
标题搜索
我的存档
数据统计
- 访问量: 9627
- 日志数: 14
- 建立时间: 2008-08-26
- 更新时间: 2010-10-19
