我的测试观点与经验转.docx
- 文档编号:5138527
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:65
- 大小:77.20KB
我的测试观点与经验转.docx
《我的测试观点与经验转.docx》由会员分享,可在线阅读,更多相关《我的测试观点与经验转.docx(65页珍藏版)》请在冰点文库上搜索。
我的测试观点与经验转
我的测试观点与经验
初中级篇
克莱沃曼(Jan16,2009)
Contents
前言3
测试与开发4
关于开发与测试4
再度解析开发与测试7
关于测试与开发的工资9
黑盒与白盒11
与同行关于白盒测试,黑盒测试的讨论11
浅谈测试的分类21
黑盒测试就比白盒测试技术含量低?
23
黑盒测试比白盒测试更难,技术要求更高24
测试发展26
关于测试人员的发展26
测试职业发展的三“步”曲29
领导奇怪我为什么不跳槽?
31
测试人员如何能够受到重视?
32
微软的PrincipleSDET到底是什么样的牛人?
34
牛人为什么要做测试?
37
步入安全测试(兼谈个人测试技术发展轨迹)39
自动化测试41
关于我的自动化测试系统41
我对UI自动化测试的理解43
再谈UI自动化测试45
一个UI自动化的小例子48
用一个小例子来说明手工测试,自动化测试,系统命令,编程语言,API的关系52
从微软Windows产品线的测试看自动化测试的重要性55
面试57
我的Oracle面试经历57
我的google面试经历59
记一次加拿大面试61
记一次美国面试62
简历(初中级时期)64
前言
本书收录了我一年多所写的关于软件测试的文章,内容包含初中级测试工程师工作所涉及到的内容。
测试总的来说还是比较简单,我认为作为初中级tester来说,这些文章基本涵盖了应该掌握的知识点,和一定的职业指导与规划。
今后我写文章可能不会再涉及这些方面,而会从更高的角度去讨论测试技术与发展,因此把这些文章编辑成册,以方便大家的阅读。
测试与开发
关于开发与测试
最近总是有一些网友问我一个问题“现在有机会转开发,应不应该转?
”。
我想我也需要单独发表一篇文章来表达一下自己的看法了。
我会从一个新入行的测试人员一直往上发展大概会是一个怎样的情况入手,来表达我的观点“开发技术是测试人员发展的基础,也是测试人员发展的归宿”。
当然了,我现在表达的是测试人员一直往上发展,如果你已经对自己的发展感到很满意了,则不在这里的讨论范畴。
(相信会有不少这样的人来提出自己的疑义)
从你刚入行开始,你面前基本上是有两条路可以发展。
一是技术,二是管理。
先说管理,很多人做了很短的时间就走向了管理,teamlead,甚至manager。
他们的工作已经很少用到技术了,更多的是学习和运用管理的知识。
这样的人不在少数,我当时做测试3个月一转正就是teamlead了,老板也非常希望我专注在管理方面。
可是下一步怎么办?
一般出现这种情况的都是在中小公司,而不是大而正规的外企.下一步你的发展会由于技术不够扎实而出现了瓶颈.第一,你不可能回头去搞技术了,因为你管理的地位,工资都高于技术人员,而且还有年龄的问题,这些因素造成了你只能继续管理。
第二,如果你想跳槽到大的外企搞管理,可能性几乎为零,因为你没有大外企的经验又没有出众的技术。
第三,如果你想在本公司或类似公司往上爬,比如做director,很可惜,这些公司往往不配备testdirector的职位,并且其他director的职位也很难由一个做测试的人来承担。
(可能会有特例,但是应该很少)。
因此,刚入行不久,没有扎实的技术沉淀,就走向了管理,很快就会发展到头了。
再说技术,我们知道测试的最高title就是SDET和SET了。
实际上都是一个东西,微软叫SDET,Google叫SET。
说白了,这种职位本质上就是开发,只不过不是产品的开发,而是测试的开发。
需要很强的开发背景。
因此,一个普通测试人员想要得到这种工作机会,开发的经验是必不可少的。
另外,微软,Google这种最top的公司,基本上已经没有STE,SQAE这种职位了。
而我们大多数人做的测试工作恰好正是这种职位。
顶尖大公司的这种职位都外包了。
因此,你想通过普通的STE,SQAE这种职位进入顶尖公司,可能性基本为零。
因此,如果从技术上来讲发展,无论从title上还是公司上往往上走,开发的功夫都是必须的。
因为我说的是一直往上发展,因此到了SDET后怎么发展?
基本上三条路,第一管理,第二开发,第三继续测试。
先说管理,你从技术上一路走过来再走向管理跟前面讲到的那种管理是天壤之别了。
首先,你已经是在顶尖公司了,其次,你已经具备了高深的技术水准了。
放眼望去,整个测试行业还能有几个适合你的位子呢?
还能有多少人能跟你相提并论呢?
这条路可以lead->manager->director->vp->seniorvp往上发展。
那么发展到了最后还怎么发展呢?
这个时候,我估计应该年纪很大了吧?
钱很多了吧?
享受生活吧。
再说转开发,因为SDET具备了比较强的开发水平(比一般公司的开发人员的水平要高),因此可以比较容易的转向开发。
转向开发之后就属于开发的发展之路了,就不多说了。
最后说继续测试,一直以来都有个疑惑,为什么我从来没见过seniorSDET?
本来SDET可以向senior,principle这条路走下去。
我以前也想过自己发展成testarchitect。
可是,为什么没见过?
依我现在的感觉来说,测试的技术很快就学到头了,开发的技术由于一直是在做测试程序,而不是真正的产品,因此提高的程度也受到了很大的限制。
因此,在技术上来讲,一直工作下去就会维持在一种不是很高技术水平的状态。
这种状态达不到senior的要求。
这也是为什么周围很多SDET不知道工作了多少年,还是SDET。
目前来看,想发展的话,维持在SDET不算现实。
必须走向管理,或者转向开发了。
这也是为什么director在回答我的问题“我在测试方面应该怎么发展?
”。
回答竟然是“短期来看要学好C,长期来看还是C,转向开发”。
根本就没有提到测试。
以上是我自己的分析与理解。
大概几个发展路径
1.QA->management
2.QA->SDET->management
3.QA->SDET->Dev
当然还有其他的可能,比如
4.Dev->QA......
5.QA->Dev......
6.QA->Dev->SDET......
7.Dev->SDET......
8.SDET......
我想大家可以分析一下自己以前的发展之路,看看以后应该如何发展?
当然了,如果自己已经满意了就算了。
我的发展之路是这样的
Dev->QA->Management->SDET->(Lead/Dev/Seniorifpossible)
总而言之,在整个的发展路径中,如果你缺少Dev,都会限制你更好的往上发展。
还有就是发展的高低,一要看title,二要看公司。
很多小公司的manager可能根本都进不了大公司。
很多大公司的普通员工一旦跳槽到小公司很容易就能升职。
比如一个朋友在国内做了6年的外包经理,面试大公司总是失败,因为技术不行。
还有朋友在顶尖公司只是SDET,跳到盛大就是director.
这里我想破除很多测试人员的一个幻想,我强调的一点是“不懂开发的测试没有太大的前途”。
再度解析开发与测试
不久前参加了一个座谈会。
这个座谈会邀请了公司里在测试领域发展非常出色的华人,基本都是testmanager,来给大家解析一些测试发展的问题。
由于可能公司没有华人做到testdirector的职位,因此他们可能已经达到了华人在测试发展的最高点了。
他们应该是很牛的人,为什么呢?
举个例子,我知道两个普通的测试人员回国就是两个大公司的测试director。
而这两个人跟他们的差距还是很大的,可见他们如果在国内应该是多么牛的地位。
当然了,他们在世界的测试领域来说也应该是佼佼者了。
座谈会的焦点没有任何意外地集中在了开发与测试的比较上边来了,这个话题也是多人曾经探讨过,我个人也发表过一些自己的看法的。
这次想总结一下从他们的观点中透露出来的信息以及个人的一些自己理解。
首先说明的是,测试发展的两条路还是管理和技术,由于真正能在管理上发展的像他们那样成功的人实在是太少了,尤其是在公司的内部,因此焦点还是放在了技术发展上。
其次,与绝大多数公司不同的是,这里的工资是按照级别而不是按照工种来区分的。
简单地说就是,同一个级别的开发与测试的工资是相当的,因此在技术发展的焦点上就放在了级别的提升上。
下边是个人的一些总结:
1.他们承认测试发展的ceiling是比开发要低的,比如VP测试出身的只有一个,还说了个什么我没听明白,测试的一个没有。
当然这个对个人来说没有什么问题,我想基本没人能够发展到reach到这个ceiling。
2.测试的senior比例是比开发要低。
3.测试senior比例低的主要原因是很多人没有达到senior就转成开发了。
4.测试通过自己的提高是有机会达到senior的
5.测试从junior发展到中级跟开发是没什么区别的
6.测试从中级发展到高级的时间是一年半到never
7.他们见到很多人在中级呆了很长时间,比如10年,还是停留在这个级别,因为自己不努力了。
从以上的简单总结我们可以看出,首先测试的发展跟开发相比是处于劣势的,其次,通过个人的努力测试是可能跟开发平起平坐的。
这里边就牵扯到一个问题:
怎样通过努力去达到senior?
这里边又牵扯到了另外一个问题,为什么很多人测试没有达到senior就转成开发了?
他们如果不转成开发是否就能达到senior测试呢?
因为他们说很多人10年都到不了senior。
他们的解释是可以做安全测试呀,可以考虑客户的需求呀,等等,等等,去往senior发展。
我想说说自己的理解:
1.我见过的senior确实很少,因此可能理解不够全面,可是我感觉他们应该是具有多年的开发经验的。
也就是说,他们今天能够到达senior这个级别是和他们多年的开发功力密不可分的。
2.由于公司是按照级别来给工资,里边的现实是,如果你想达到senior的级别,你的水平要和senior的开发相当才行。
一个做测试的人,怎么才能达到与senior开发水平相当呢?
除了以前有过多年的开发经验,否则是一件非常困难的事情。
困难的地方就在于,测试相对开发来说还是一个比较简单的工作,在每天做这种相对简单的工作中是不可能像开发人员得到同样的水平进步的。
3.确实测试里边也有很多高端的测试工作或技术,比如安全测试。
可是测试总体来说还是比较简单的,你的老板不太可能会给你时间去学习和分配高端测试的工作给你,否则那些简单的测试谁来做呢?
因此,在工作任务的压迫下,使你转向做高端测试的机会变得比较渺小。
4.当然你自己可以去努力,花大量的业余时间去提高。
可是这里边还有两个问题,一个是你是否能长期坚持,因为这不是工作驱动的,人很容易偷懒或者放弃。
第二是谁来指导你?
如果你身边很少senior的测试,你被指导的机会就会远远小于开发人员。
5.这也就算解释了为什么测试人员要转到开发,很大程度上是不得已而为之,如果想继续往上发展的话。
即使一个人非常的热爱测试工作,他如果想往上继续发展,走向开发,或者走向开发再转回来都变得是一条更现实的路。
因此,我还是鼓励大家,如果有机会做开发,或者转开发就不要犹豫,如果没机会,也要尽量地去学习一些开发知识。
这些对测试的长期发展是很有好处的,我本人也是得益于以前有两年的开发经验。
关于测试与开发的工资
今天查了一下开发与测试的工资水平,一些数据应该能说明一些问题。
我们以硅谷的MountainView为代表(Google总部所在地)。
开发:
JuniorSoftwareEngineer:
$62K
SoftwareEngineer:
$98K
SeniorSoftwareEngineer:
$110K
PrincipalSoftwareEngineer:
$110K
LeadSoftwareEngineer:
$113K
测试:
JuniorQAAnalyst:
$53K
JuniorQAEngineer:
$61K
QATestEngineer:
$76K
SoftwareQAEngineer:
$86K
QATeamLead:
$88K
SeniorSoftwareQAEngineer:
$93K
SQAEManager:
$100K
JuniorSDET:
$95K
SoftwareDevelopmentEnginnerinTest:
$102K
SeniorSDET:
$108K
LeadSDET:
$108K
可见,SDET是测试工资最高的职位了,比一般的SoftwareEngineer还高一些。
不过到了Senior就比开发低一些了,而且根本没有Principle的职位。
即使SDETLead工资也没有高出去。
能够跟开发的工资水平相提并论的测试职位就是SDET了。
黑盒与白盒
与同行关于白盒测试,黑盒测试的讨论
作者:
cleverman 时间:
2007-7-810:
49 标题:
到底什么是白盒测试?
白盒测试,黑盒测试是刚学测试时候的基本概念。
我们大部分人可能做的都是黑盒测试,也就是看不到代码,对产品进行功能测试。
可是什么才算是白盒测试呢?
Codecoverage算不算白盒测试?
自己和别人一样做黑盒测试,可是自己没事的时候也看看代码,在黑盒测试的时候发现bug,自己可以去在代码里定位,找到rootcause。
那算不算是白盒测试呢?
如果不算的话,因为测试的过程中也分析了代码,明显不算是黑盒测试。
如果算得话,自己跟同事做同样的工作,只是自己没事看看代码就可以说别人做黑盒,自己做白盒?
要不算灰盒测试?
我们公司并没有白盒,黑盒测试的概念。
可是这又是测试最基本的概念。
我有点confused.大家讨论一下好吗?
作者:
wyzwise 时间:
2007-7-811:
43
Whitebox就是在全部理解系统的基础上去gothroughsourcecode和architecturedocuments。
Codecoverage(当然是拉)是Whitebox的一个重要的优势和blackbox比较。
。
首先做whitebox的时候要有计划,不要无计划地去看sourcecode,应该去根据你所在的project的designdocument去做特定地区的code分析,还要看看algorithm..这个部分主要通过peerreview去发现,当你感觉可能有问题的时候,应该去和seniordeveloper讨论,并把问题,写成书面的报告报告给经理。
。
。
有经理决定它的priority.在决定是否是需要fix这个。
。
。
现在你是有点混淆了whitebox和greybox的概念,whitebox是在正常情况下,你的project一切的designdocuments都很全的情况下去进行的。
意味这你有fullknowledgeofthesystem。
而greybox是在limitedknowledgeoftheinternalsofasystem..只有在这个project的designdocuments不全的情况下,进行的。
。
。
不知道有没有解决你的问题:
)
[ 本帖最后由wyzwise于2007-7-812:
00编辑 ]
作者:
shanxi 时间:
2007-7-811:
52
白盒、黑盒
自动化、手工
回归等等
具体做事的时候没有区分的那么细致,很少是只做其中一种,基本是交叉着本着解决测试问题的效率来采用。
作者:
cleverman 时间:
2007-7-812:
02
QUOTE:
原帖由 wyzwise 于2007-7-811:
43发表
Whitebox就是在全部理解系统的基础上去gothroughsourcecode和architecturedocuments。
Codecoverage(当然是拉)是Whitebox的一个重要的优势和blackbox比较。
。
首先做whitebox的时候要有计划...
那我说的第二种情况,算不算白盒?
还有就是能不能举个灰盒的例子.
作者:
cleverman 时间:
2007-7-812:
05
QUOTE:
原帖由 shanxi 于2007-7-811:
52发表
白盒、黑盒
自动化、手工
回归等等
具体做事的时候没有区分的那么细致,很少是只做其中一种,基本是交叉着本着解决测试问题的效率来采用。
我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.
作者:
wyzwise 时间:
2007-7-812:
09
QUOTE:
原帖由 cleverman 于2007-7-812:
05发表
我也有这种认为,感觉测试很多理论上的东西,在工作中很不相关.
我现在倒是感觉,真正用的上的,还是开发的理论,而不是测试的理论.
这个一部分是对得,我以前得公司,计划,管理不是很好,所以每次经常什么东西都混在一起,不是很明确。
。
。
其实如果管理好,这些测试的理论是很有用得。
。
。
我现在得team就是按照成型得MVC得testingphase一步一步走,每一步每个在team里面得人都很清楚,都知道什么时候在什么事情。
。
。
测试还是要根据不同阶段做不同得事情得。
。
。
作者:
seifer1754 时间:
2007-7-813:
40
既然白盒,黑盒的概念你都知道了,那么举个例子来说明一下好了。
voidtest(x)
{
if(x<0)return;
if((x+1)<0)
return9;
}
看看上面这个函数,很明显第二个if判断是永远不可能为真,也就是说,采用黑盒的方式,用输入参数x来测试,是永远不可能出现9这个输出的。
那么我们用不用考虑第二个if的成立情况呢?
我这个例子是简单了一些,也没有什么意义。
不过在实际的开发中,还是会出现类似无法被黑盒测试覆盖的路径的,也许这些路径在正常情况下永远不可能被走到,可是我们在做软件设计的时候,必须要考虑到会出现的异常,而专门设计了一个对这种异常情况做出处理的分支。
例如,计算机的寄存器被恶意软件所篡改,如果没有一个对异常处理的分支,很可能会造成系统的崩溃。
那么,既然这种分支需要测试,我们就必须想办法来覆盖这个分支,这就是白盒测试需要考虑的事情了。
我们可以在这个分支判断上设置断点,然后通过修改寄存器的方法来改变装载参数x的寄存器的值,从而使程序能够走x+1<0的分支,使输出结果为9。
这就是白盒测试需要考虑的事情,是对程序的逻辑与路径进行分析测试。
我举的例子可能不是特别恰当,希望你能够明白。
作者:
cleverman 时间:
2007-7-814:
21
QUOTE:
原帖由 seifer1754 于2007-7-813:
40发表
既然白盒,黑盒的概念你都知道了,那么举个例子来说明一下好了。
voidtest(x)
{
if(x
我明白你的例子,不过你认为我说的第二种情况算白盒测试吗?
也就是说跟黑盒测试没有任何区别。
可是,遇到bug自己可以去代码里找到rootcause.
作者:
wyzwise 时间:
2007-7-814:
32
"可是自己没事的时候也看看代码,在黑盒测试的时候发现bug,自己可以去在代码里定位,找到rootcause。
那算不算是白盒测试呢?
"
这个不是testing...是bugfixing:
)
作者:
cleverman 时间:
2007-7-814:
32 标题:
还有
“例如,计算机的寄存器被恶意软件所篡改,如果没有一个对异常处理的分支,很可能会造成系统的崩溃。
那么,既然这种分支需要测试,我们就必须想办法来覆盖这个分支,这就是白盒测试需要考虑的事情了。
”
请问你们公司是必须要测试这种case吗?
我问题的意思是,概念可能没什么难理解的,可是到了实际中去,情况就复杂了。
以我的经验,你说的这种情况是不需要进行测试的。
因为,重要的是怎样防止恶意软件侵入你的计算机,真正侵入进来之后,就麻烦大了。
如果要考虑这种情况的话,那可以设计无数的case了,不算很现实。
请问,你用“必须”这个词是理论上来说呢,还是你们公司就这么要求的呢?
还有就是以我所知,无论是系统软件还是杀毒软件都是注重恶意软件的侵入,而不是侵入之后如何保证自己的程序不受影响。
当然了,现在的UAC是这样考虑的,不过他们也不是在硬件的level来进行测试的。
作者:
cleverman 时间:
2007-7-814:
35
QUOTE:
原帖由 wyzwise 于2007-7-814:
32发表
"可是自己没事的时候也看看代码,在黑盒测试的时候发现bug,自己可以去在代码里定位,找到rootcause。
那算不算是白盒测试呢?
"
这个不是testing...是bugfixing:
)
不对。
真正好的测试人员reportbug的时候,是要写明白代码的rootcause的。
这只是发现bug,怎么能算fix呢?
真正的fix是要开发人员来做的,测试人员没有这个权力。
你找到代码里的问题,不代表就解决了这个问题。
明白吗?
作者:
seifer1754 时间:
2007-7-814:
43
通过黑盒测试的方法发现bug,然后去代码中定位,找出原因。
这个不属于白盒测试,白盒测试和黑盒测试在测试的理念上是不同的,也就是说,设计的用例都是不同的,采用黑盒测试方法设计的用例,不见得能够100%的覆盖代码的所有路径和逻辑。
例如我上文举的例子。
虽然你能够根据黑盒测试方法发现的bug而定位错误,这也只能说明你的编程功底比较强,对代码的理解比较强。
可是这并不能说明你设计的用例能够覆盖所有的代码逻辑和路径。
也就是说,这并不能说明你做的是白盒测试。
在嵌入式白盒测试领域,经常需要追踪寄存器和内存,这些都是典型的白盒测试,你需要在程序中设置很多断点来追踪程序流程。
而黑盒测试,只是考虑函数的输入和输出,对程序的内部逻辑是忽略的,很可能,同样的输入和输出,代码采用了不符合需求的方式而实现了。
所以,即便你能够定位代码的错误,可是你做的是黑盒测试,手中获得的可能只是一份功能需求文档,而不是一份详细的代码流程图,你定位的错误,只是表示程序的功能有问题,不能证明程序的逻辑设计有问题。
这就是白盒测试与黑盒测试的根本区别。
作者:
cleverman 时间:
2007-7-815:
08
那么什么是黑盒测试呢?
不是说黑盒测试是不接触代码的吗?
我以上的例子是有reviewcode的工作的,应该和黑盒测试定义相矛盾呀。
我明白你说的嵌入式白盒测试是属于白盒测试,可是白盒测试肯定不限于只是这种类型吧。
按照你的理解,如果我有详细的代码流程图,做黑盒测试,而我定位的错误也发现了是逻辑设计有问题,那怎么算呢?
你也不能说我用黑盒测试,review代码就一定不能发现逻辑设计有问题吧?
为什么要问这个问题呢?
我所在的公司,当然不是测试嵌入式的,是测试系统软件的。
我们有所有的资源,可是我们的testcase是按照功能来设计的,也就是说不会在代码级设计测试用例。
如果只是设计,执行,那么肯定是算黑盒测试。
可是我们也reviewcode,要求发现bug尽量找到rootcause写到report里。
因此,我们有详细的代码流程图,也可以发现逻辑设计有问题。
我们甚至要在functionalspe
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 观点 经验