51Testing软件测试网U$[4JQ/dG/k.d
2n4g'\1y3`!O02011年工作、学习和生活总结
y*F,{4o+d+K5\0k0和前几年相比,2011年是收获和变化最少的一年。实际上能总结的经验很少,但还是勉为其难的总结一下吧。
[h0o'SrUY0
x'[0Z0QK^2[E)h%AO%J0工作:2011年基本上没有大变化,按部就班的工作着,虽说行业的工作经验有所增加,但技术方面进步很小。而且由于只能做黑盒测试,工作兴致没有前几年那么高。
EOYn]bv
]8oy`0 51Testing软件测试网L{8B*s(df |
TJ ]%L
测试技术:测试经验方面,自动化测试在前半年有不小的进步。后半年最大的收获应该是做了一些性能测试的工作。最后在年底的时候,逐渐进入到灰盒测试。51Testing软件测试网Ig#JX,cT
51Testing软件测试网c8r1SI1Uh
编程技术:大半年和2010年一样,看不到代码,所以编程技术方面几乎没有进步。好在年底的时候又可以看到代码了,所以2012年又可以系统的学习工作相关的编程技术了。51Testing软件测试网p0K9us
k?
-sI2n;^@8b]h0游泳:业余最大的兴趣所在,2011年基本上能坚持下来,直到后来感冒和春节,才暂停了。年后将恢复锻炼,最起码一周一次。51Testing软件测试网^#t@V8ia
3oc?&J)y!z0阅读:主要还是在中午的时候,使用ipad看,记忆中看完整的只有《步步惊心》。。。囧。果然还是看拿在手上的书比较舒服。2012年继续阅读,找自己感兴趣的书来看,比如科幻类/悬疑类的。
5h]t"w.Ln.o0f v
M0 51Testing软件测试网?H$gA!Lj'tIR
狗狗:2011年“家宜”仍然是健健康康的,就是自己懒惰,一天溜一次,有点委屈“家宜”了。2012年呢,早上或晚上出去锻炼时,顺便家宜出去遛狗。
f2VT+L*uR
uCn0 51Testing软件测试网3k D
_9}^ K.H!n
测试经验
自动化测试51Testing软件测试网#Egt/BdJk
使用公司以前开发的自动化测试平台ATS后,果然提高了工作效率。一方面可以继续使用对象库,另一方面比action灵活很多。
,~vaf,AG'F)t0 51Testing软件测试网ih*ZGZ*p.[b
自动化测试远远不止录制脚本这么简单的步骤就可以了,录制好的脚本还需要修改很多地方,不断的调试发现问题解决问题,最后的脚本才能算成功的完成,但可能还存在问题,需要后续的测试过程中发现。
n&OUZ\tq0
C4\&{S*z1c3c.a;h0自动化测试的编码调试阶段,至上而下的编程,流程如下:在服务器上写case,定义好function,在本地编写function,在本地调试function,所有function调试通过后,将function复制到服务器上,通过ATS调试case。其中用到了一些基本库中的一些function,不过要先理解它们的作用才能使用好。
!p hR3gIQze@0 51Testing软件测试网j9w2L4f"Hc
w ]F)e7o
Q1{Bs0测试需求和测试用例51Testing软件测试网'LR q6hBOZ"D+_$jQ
程序的实现方式要不要写入到测试需求中,这个问题,后来想一想,还是不需要写入测试需求的好,因为实现方式是什么无所谓,关键是找到这种实现方式下的缺陷,只要各种情况都测试到了,基本上就能说这种实现方式是OK的,即使和当时的设计不一样。但如果是特定条件下的规则,那么这个特定条件还是要写入到测试需求中的。51Testing软件测试网I4wex#c eHOP
5{*d`5UDo0在编写新feature的测试需求和测试用例时,要考虑到该版本之前的测试需求和测试用例,是否有相应的变化和潜在影响,都要归入测试范围。51Testing软件测试网7};ubS6Y0@"J}7O
Y"{e8hc2g
51Testing软件测试网Us;NcW@7cC
fLn1v!I6wZ0定位问题
0st-n%yab b0由于看不到代码,只能从日志中定位问题,但光看日志还是有困难,特别是没有提示错误或者看不明白。这个时候,就可以找一个正常的相同网元的环境,和正常的日志进行比较,不同之处就是出现错误的地方。而且把经常出问题的功能相关的正常日志先记录下来,下次出问题的时候,就可以直接比较了。
(A&W/I
|"bp:y0 51Testing软件测试网:^EQ;["o9W:`
51Testing软件测试网qmxm~5Y
BUG总结
.lm7Jh,?,_N0由于在需求和设计阶段,考虑问题不够全面,导致测试时才出现分歧和严重问题,结果只能以limitation的方式release出去,真的是非常的糟糕。如果客户没有要求就不实现,要求的又实现的不彻底有limitation,这样的服务态度,这项目早晚要完蛋。测试只能说是发现问题,要不要实现和修改的权利,都掌握在其他人手里。
@!P Gq1v~0 51Testing软件测试网 W!wZa*cN9ue
只要是科学技术,最起码要有严谨的态度,否则会导致“失之毫厘,谬以千里”,特别在数字方面,不管误差有多大,如果不相等就不正确,就应该被改正,不能因为误差很小就可以忽略。
RS?/X"\ PC0 51Testing软件测试网%U ?Aj2u}m p
之前发现很多严重问题,由于SRS没有考虑到,客户没有要求,所以都提交为limitation,但我个人认为,做产品时,不能只想着客户能容忍错误到什么程度,而应该想着比客户要求的做的还要好还要完美,做客户之前没有考虑到的,这才是对待客户的态度。51Testing软件测试网J4pFSYo
51Testing软件测试网!g!]e,gN,V3?
发现的一些问题,虽然SRS没有要求,但逻辑上说不过去的,也不应该不去管它,规则要一致,不能有些功能按规则A设计,另外有些功能按规则A相反的规则B设计,这样逻辑上是说不通的。这类被SE否决的BUG到底要不要提MR,目前还不确定。
G eHbxnb0
-_6\^1I.L1l0根据前一段时间的测试经验,发现很多BUG和limitation在需求和HLD上就可以发现的问题,结果等到测试执行过程中才发现,这样开发人员往往不愿意修改。所以以后有新feature需要测试时,在SRS和HLD review之后,立刻开始test case的编写,在开发release之前,就把SRS/HLD中的问题提出来。51Testing软件测试网-K.T(u.ey#l(Ry!q[?$f
$[;S~^5z0 51Testing软件测试网s3x|7{)zM~
性能测试
d5D_a1ap
yO0性能回归测试的测试范围,一方面要考虑主要基本功能的压力测试,另外要考虑该版本实现的feature对性能方面可能会产生什么样的影响,比如说修改了某个报表的功能,可能会对性能产生影响,那可以做一下这个报表的性能测试。
*i"I#]0x$j0
sUV;}b*R0
(bX C`%cm1K/F/Wl0漏测经验
#OMjNq3l0有一个新feature的测试任务完成,发出去的版本中,居然少了个配置文件。测试的时候却没有发现,严格来说,测试时发现了异常,该配置文件的链接文件显示为一闪一闪的,但没有多留意,后来也没有比较配置文件是否有改变(因为是修复MR的版本,肯定配置文件不会修改),就直接用老的配置文件替换。看来以后升级步骤一步都不能少,即使是版本发布的比较急的时候。51Testing软件测试网1M$XU+dz8Jb:\9|/P
,T*^1bp(W8BgA"w0另外一次的测试任务,现场发现个问题,但在测试过程中没有发现。原来是在修改一个BUG时引入了新问题。由于这个BUG并没有修复,所以并没有做相应的回归测试。所以以后在验MR的时候,虽然该MR验证FAIL,但在release之前,仍然要对其会影响的功能进行测试。另外一方面,以后使用和现场一致的组织机构用户登录进行测试,现有的组织机构只有一级,有些和组织机构的问题将不会暴露出来
A2GM8L&F;W0?0