2009年度工作、学习和生活总结51Testing软件测试网:QOM:Kbr\
2009年,我在工作上的收获比较少,生活上有较大的改进,仅以此文档对2009年的工作、学习和生活做一个总结。同时展望下2010年。
#l3a QZR(N'Dq/O*M$h0以需求为依据
小心无需修改的功能被开发人员修改了的情况出现 在修改版本的测试时,虽然开发人员修改了某一个功能,可是需求中本来是不需要修改的,测试人员一定要先了解修改之前的该功能是什么样的,然后根据用户需求,来看开发人员修改这个功能是否正确,而不是因为开发人员修改了就一定要根据他修改后的来测试。51Testing软件测试网R(__3EZ"o-QOV$Uj
)}J8@)k0O0开发人员对某需求变更不知道导致BUG产生 有时开发人员根据需求文档上的开发,结果在测试这边发现BUG依据的需求和他理解的需求不一样。所以,当需求发生变更时,应该及时更新需求文档,并通知到所有开发和测试人员。51Testing软件测试网8v{fXNe
rf{0e b%D6?q#i0测试需求中应包含隐形需求 有些设计上的功能需求,需求文档上没有说明也比较正常。这个需求的实现也许是处于安全性的考虑,用户需求中并没有提到,而且在程序使用中也体会不到。但是在测试的时候,一定要作为一个测试需求进行测试。51Testing软件测试网VX+i%O\Y0?s
!O2_7pP(J:l4B
Z0t(^R0测试人员更想要知道的是用户需求而不是修改内容 在版本的维护阶段,开发人员说要测试某个东西的时候,只会说修改了哪些功能,而没有提到原始需求或者说修改原因是什么,这里的原始需求就是客户想要这个版本哪些功能需要改进、哪些问题需要解决。测试的依据和来源都是需求,版本修改内容有哪些确实也很需要了解,但是修改原因和用户原始需求也是测试开展必不可少的条件之一,不然可能测到最后,在客户那才发现没有到达客户的要求。
m7b9A7j
PZ7\0 51Testing软件测试网y1Ddp9_:M%pE
不能和开发人员一样片面性的了解需求 有的开发人员会把他修改的内容全部告诉你,只是把他负责的子系统的修改告诉你,可是测试毕竟考虑的是整个系统的运行,考虑的是整体功能有哪些,测试需求是什么,如果只听他的介绍,只会进行片面的测试,全局性考虑就不够。51Testing软件测试网Lf*R#h6j%}
RH;x(sA0测试环境的维护
更新程序时,不建议测试人员自己删减代码 在测修改版本时,如果没有得到需要更新的程序,而有开发人员编写的代码修改具体步骤和代码,但最好不要自己根据文档中所写的代码修改内容自己进行修改后测试,因为测试结果不一定准确,测试过程中发现问题,也不一定是BUG,因为可能我修改后的程序和真实开发人员修改后的程序存在差异。还是基本上还是需要开发人员提供修改的程序或代码文件。
uUG*{H
w7],u0 51Testing软件测试网a
NR u'Wkl-E
测试环境中,修改配置文件后,记得测完要还原 在测试过程中,为了方便执行某些用例,需要修改原本正确的配置项,比如数据库里某个配置表,后台中某个配置文件。但测完之后没有把这个配置还原回原来正确的配置,在下一次测试时,另外一位不熟悉这块时,可能会出现因为配置不正确而导致某个BUG没有被发现,所以,建议,每次修改配置测试完之后,再把配置修改回去。也可以在每次测试时,去了解所测东西的实现,就会注意到配置是一个输入数据,测试分析后,发现配置上的问题。
BKZ!~|0
B_Gv i u5f0经验多次证明,白盒测试可以发现黑盒测试没有发现的BUG 灰盒测试,也就是使用白盒测试技术来增减测试用例是非常有必要的。有一次,测试某个功能,设计用例时,从黑盒的角度看,有些组合情况的测试用例没有必要执行,然后从白盒的角度看,为了要达到基本的语句覆盖,把这些测试用例给加了进来,结果白盒加入的用例执行后就发现了BUG。所以,在黑盒测试执行完之后,再检查代码看是否需要补充测试用例51Testing软件测试网/]@o6V%e6zU
51Testing软件测试网X0[_"a'V\rQ(J
输入数据要考虑全面 有次,偶然发现个BUG,触发的条件是数据库中某种情况的发生,如果不把数据库中的来源数据当做输入数据的一部分,就会遗漏这个测试用例而发现不了这个BUG,但往往在设计测试需求的时候是考虑不到这个的,只有在设计白盒用例的时候全面分析所有输入数据才有可能发现这些测试用例51Testing软件测试网Um)f*K&E%H1A
m5v a1U+_"B!z0定位问题或BUG
定位问题主要有2种方式 一种是运用调试技术,把日志打印出来,定位到具体某一行某个变量值等,另一种是根据错误信息和代码判断可能出错的地方在哪里,然后尝试解决。对代码实现非常熟悉时,后者可能比前者更快,但是不熟悉的话,用第二种办法反复猜测尝试修改后可能还没有解决问题,这样反而会比第一种办法要慢,前者比较按部就班,但是一定能够定位到问题,所以根据对代码实现熟悉程度来选择使用方法一还是方法二。总之问题始终会被解决的。51Testing软件测试网}1XPaa[
.p'p8cwx {Uw0程序“当”掉时,比较难定位代码错误出处 在一次项目测试中,发现了几个数据溢出的问题,自己在定位时,使用DEBUG打印来跟踪,结果没找到原因,然后问开发人员,原来是某个字段的长度太短了,结果在某行代码处被赋值时出现了异常,使用打印语句的办法,是没办法定位到这一行,因为当错误代码行被执行后,程序还在往下继续运行,过了一段时间后程序才“当”掉,而我根据DEBUG信息的指引,一直追踪到后面的代码行去了。51Testing软件测试网OI+I&T6R%w bB1K
51Testing软件测试网R9iZiw"J
模块测试比系统测试容易发现和定位一些BUG和问题 模块测试或集成测试和系统测试有个很明显的区别在,在系统测试中发现的BUG一般是用户可见的界面部分,虽然容易看到,但如果没有执行这个BUG出处的模块就有可能在界面上看不到这个BUG。如果系统测试发现的不是BUG而是环境问题,定位起来也非常麻烦,可能会提交不是BUG的问题。而如果是模块测试或集成测试,在对整个系统模块结构了如指掌的情况下,能很快在非用户可见的地方发现这个BUG,而且也很容易定位到具体某个模块某行代码,当然也可以比较快的判断是不是环境问题。
,R0Ff;th'yk0放松下反而容易想到问题的关键 有几次,尝试了大半天都没有解决的问题,在上个洗手间或在下班回家的马路上,再次思考解决该问题的整个过程,反而很容易想到问题的关键之处或新的解决办法。51Testing软件测试网R(D|^%T#k4jzI Y
p
i\Uo_g1o
whm0提交BUG
描述BUG时尽量详细和用词准确 在描述BUG时,描述的语句一定要比较详细和准确,因为如果和实际的现象有出入的话,开发人员光看到你的描述,可能会往错误的方向上找原因,虽然最后发现的确是有BUG,但还是会因为你描述不准确的原因,而感觉测试人员不够专业。
Q&wc(Edi(^1{0 51Testing软件测试网gfL!c5F1r;E3w0b
BUG被开人员rejected,不等于说一定不是BUG 每次看到自己好不容易发现的BUG,在TD上被开发人员rejected时,心情都有点低落,可是再一细想,他们拒绝修改不等于我们提交的没有意义,因为他们只是按照自己的想法认为这不是BUG,比如认为这种情况不可能出现,可是实际上上线后会不会出现我们提到的问题就很难说了,根据经验,客户之前也提过一些在我们看来不是问题的问题,还有一些问题虽然局部看没有什么问题,可是一旦出现,影响的范围却难预料。
_(pH7p-TT0
6~&tN P;SwB~1D-g0发现开发人员自己发现并修改的BUG,学习和借鉴 测试过程中,更新测试版本,在更新测试版本的时候,留意修改的文件有哪些,然后比较修改的代码是什么,因为很可能有些BUG自己没发现,而开发人员已经修改好了,这也是一次提高测试经验的机会。
D
K aZDAy'S0 51Testing软件测试网 c;l%t|"t @Ej
Ch
开发人员
有的开发人员对自己的程序自信过度 有时提交BUG,某些开发人员的第一反应就是环境问题或是其他子模块的问题,反正不是他所负责程序的问题,这种自以为是的开发人员让人感觉很不舒服,必须等到测试人员得把BUG定位后才去修改,而且态度还心不甘情不愿的。当然也会有一些开发人员,会尽力帮助测试人员解决问题,而不是一味的推卸责任,能和这样的开发人员合作,测试进度也会加快,其实这也能反映了开发人员的能力差异,能力强的人自然对任何问题都会去想办法去定位和解决,能力弱的人害怕面对问题,反正自己觉得自己做的没有错误就行了,不管别人怎么样。
.ddo {mZ ]0 51Testing软件测试网\B2_5q ` o4q#Y
修复BUG
最好不要告诉开发人员怎么修改BUG 有次发现一个BUG,而且自己已经知道怎么修复它,然后看着开发人员在机子上调试,而且修改了几次都没有调通,这个时候我有一点点暗爽,哈哈,不过我还是没有告诉开发人员怎么修复,让他自己去发现吧,毕竟这是他自己写的程序,如果由测试人员来告诉他怎么修改,岂不是让他很没有面子?测试人员自己修复BUG,只是自己的一种工作乐趣,并不是工作职责,所以还是不要越权的好
VP n_
@:~`0 51Testing软件测试网Rk hre3V)D
gk
漏测经验
测试不能有半点疏忽和松懈 有次漏测经验,而且和钱有关,最后的解决方案是项目组的人平均补充这个损失的钱。后来反省漏测的原因,一个是在单元测试阶段,没有仔细的做这个模块的单元测试,因为这个模块是出差的时候新加的,之前并没有测到,出差的时候也没有想到要对这个新模块仔细进行单元测试,只是做了相关的系统测试。第二个原因是系统测试阶段,测试用例中遗漏了这个无效用例,如果做的是单元测试,一定会考虑到这个无效用例的,因为其他有类似功能的模块的单元测试用例中就包含了这个用例,确实是我在设计系统测试用例的时候疏忽了。结果最后导致了漏测。51Testing软件测试网;JwHZ_gB
51Testing软件测试网r/c&fWr
GRGF
有时看到问题了,却没注意到是BUG 有的问题注意到了,但没有把它当做BUG来提,的确是大意了,仔细想来,是因为惯性思维,之前在测试另一个版本时,出现一样的问题,但因为知道是硬件设置的原因,所以在心理上留下了这个问题不是BUG的观念,然后接着测试这个版本的时候,看见了相同的问题,也就想当然的认为和前面的问题一样是硬件设置问题,而没有想到可能是个BUG。所以下次测试时,每发现一个问题时,一定要再次确认下是不是BUG,不是BUG的话,是什么原因产生的。
3?+BN1y.YXF0 51Testing软件测试网?6F4zGC
白盒分析后确保被删的用例不会出问题 有一次测试时,自己对白盒测试太自信了,虽然从黑盒的角度看,这些用例是必须要执行的,可是当时看了代码后,觉得不执行也没什么关系,导致最后的漏测,实在是不应该。51Testing软件测试网SDl6gj \Wj
技术学习收获
2009年技术方面有3个大方面上的收获。51Testing软件测试网Bey y im)e
v
1.完成了《C语言程序设计》书上每章后的编程练习题,年底该书从头到尾再看了一遍。
6M*k1tU/e*v02.在某个项目测试中,修改了测试工具,有一定量的coding,并且利用该工具顺利完成了后台的模块驱动测试。
"T\,L@5A
hy03.为了测试V9MIS,学习了新编程技术,DELPHI,学习了入门教程,基本有办法读懂程序来解决各种问题。51Testing软件测试网(n3R5}Wf~,I/q
51Testing软件测试网@/C9W
_fHz
改进生活
2009年,生活中最大的收获就是学会了游泳,而且迷恋上它,目前学会了蛙泳和自由泳,正在苦练自由泳,坚持游泳使得身体更健康了。除了游泳,还学起了吹口琴,谈不上可出师,但可吹奏教程上10几首简单歌曲。也开始从图书馆借书看了,可以不用花钱,而且时间限制逼迫你短时间内必须要看完借来的书,看书的数量比2008年要多了。年底开始也开始去电影院看喜欢的电影,平均1个月看2场。另外,生活作息方面也有了改善,基本都能在晚上11点之前睡,包括周末,工作日每天早上基本也都能在6点半之前起床。
#M"U$d9d:{*B0 2009年还有很多收获,比如配置了笔记本、买了新手机。至于2009年的积蓄,都转给老爸老妈了,2010年继续努力。
E1E-]g5{:u2n0 2010年,除了要把09年养成的习惯继续进行外,已经开始拾起我大学时选修的体育科目——健美操了,办了健身次卡,每周2天去健身房,前一段时间去跳健美操时,依然还是非常有感觉,当然比游泳的喜爱程度要少些,主要是喜欢随着音乐的节奏而跳动的感觉。
M&vG wf;``1b0 2010年,我还想去几个地方旅游,目前想去的有北京、云南、香港,目前只有想法,还没有实际计划。
1a b\0z.U~/N"Zj/C3h-t0 从以前所谓的工作狂,变成现在开始慢慢享受生活了。51Testing软件测试网
R2ab)j,w1[