展望2011

2011年工作、学习和生活总结

上一篇 / 下一篇  2012-01-30 18:19:48 / 个人分类:测试经验

51Testing软件测试网Rd'fV\

 

5Vk["P qOl*S0

2011工作学习生活总结

$h H)^%_HSI;lIn#T*@0

和前几年相比,2011年是收获和变化最少的一年。实际上能总结的经验很少,但还是勉为其难的总结一下吧。

1[0wB&} o.dd5\'k5s8L0

 

3x&JP9i5p0

工作:2011年基本上没有大变化,按部就班的工作着,虽说行业的工作经验有所增加,但技术方面进步很小。而且由于只能做黑盒测试,工作兴致没有前几年那么高。51Testing软件测试网p4sZ,@*?

 51Testing软件测试网:Hs@PYkY5E

测试技术:测试经验方面,自动化测试在前半年有不小的进步。后半年最大的收获应该是做了一些性能测试的工作。最后在年底的时候,逐渐进入到灰盒测试。51Testing软件测试网O1]];QbM"}.J

 

E F*n\7Eq'CK0

编程技术:大半年和2010年一样,看不到代码,所以编程技术方面几乎没有进步。好在年底的时候又可以看到代码了,所以2012年又可以系统的学习工作相关的编程技术了。51Testing软件测试网,Iy?8j4TU R i,_k

 

I4j]!u\%?2@,U2z0

游泳:业余最大的兴趣所在,2011年基本上能坚持下来,直到后来感冒和春节,才暂停了。年后将恢复锻炼,最起码一周一次。51Testing软件测试网G![m1O#Z?iR

 

CQ.~`%UG8\0

阅读:主要还是在中午的时候,使用ipad看,记忆中看完整的只有《步步惊心》。。。囧。果然还是看拿在手上的书比较舒服。2012年继续阅读,找自己感兴趣的书来看,比如科幻类/悬疑类的。51Testing软件测试网^Fp M8B d}

 

E1k~Id q0

狗狗:2011年“家宜”仍然是健健康康的,就是自己懒惰,一天溜一次,有点委屈“家宜”了。2012年呢,早上或晚上出去锻炼时,顺便家宜出去遛狗。

,K#eE$w?/`X g"g0`0

 

sH0p6xpc/qn0u3r4F0

测试经验

自动化测试

0Dk;s U c{S-@{"M0

使用公司以前开发的自动化测试平台ATS后,果然提高了工作效率。一方面可以继续使用对象库,另一方面比action灵活很多。

}Hr3i'Ip*e%j0

 51Testing软件测试网!I!m"]|)n

自动化测试远远不止录制脚本这么简单的步骤就可以了,录制好的脚本还需要修改很多地方,不断的调试发现问题解决问题,最后的脚本才能算成功的完成,但可能还存在问题,需要后续的测试过程中发现。51Testing软件测试网2W1{*ke KA

 51Testing软件测试网a8X&Ml;`'E+G e[

自动化测试的编码调试阶段,至上而下的编程,流程如下:在服务器上写case,定义好function,在本地编写function,在本地调试function,所有function调试通过后,将function复制到服务器上,通过ATS调试case。其中用到了一些基本库中的一些function,不过要先理解它们的作用才能使用好。

XRAAV!Gw0

 

i:[W?9d_~0

 51Testing软件测试网gOm q X%] J1Q%Z

测试需求和测试用例51Testing软件测试网[j4GsBk3j1q j(W'S

程序的实现方式要不要写入到测试需求中,这个问题,后来想一想,还是不需要写入测试需求的好,因为实现方式是什么无所谓,关键是找到这种实现方式下的缺陷,只要各种情况都测试到了,基本上就能说这种实现方式是OK的,即使和当时的设计不一样。但如果是特定条件下的规则,那么这个特定条件还是要写入到测试需求中的。51Testing软件测试网&D1MK"[(Q?Qn*\4H:k4f

 

)G6v:A`d0?0

在编写新feature的测试需求和测试用例时,要考虑到该版本之前的测试需求和测试用例,是否有相应的变化和潜在影响,都要归入测试范围。

0E2f/x`e7b0

 51Testing软件测试网VT{ h;mu j

 51Testing软件测试网8CX3b;u[q3e

定位问题51Testing软件测试网8y9H Mj2H@#o1h

由于看不到代码,只能从日志中定位问题,但光看日志还是有困难,特别是没有提示错误或者看不明白。这个时候,就可以找一个正常的相同网元的环境,和正常的日志进行比较,不同之处就是出现错误的地方。而且把经常出问题的功能相关的正常日志先记录下来,下次出问题的时候,就可以直接比较了。

0L$q|qaM0

 51Testing软件测试网TC+g5@ `2}h4t

 51Testing软件测试网fgeB c&V

BUG总结

/s'\7Fm|'m0

由于在需求和设计阶段,考虑问题不够全面,导致测试时才出现分歧和严重问题,结果只能以limitation的方式release出去,真的是非常的糟糕。如果客户没有要求就不实现,要求的又实现的不彻底有limitation,这样的服务态度,这项目早晚要完蛋。测试只能说是发现问题,要不要实现和修改的权利,都掌握在其他人手里。

9c(c:VD ?&P,F4\J_[E0

 51Testing软件测试网|H2]p|P]]

只要是科学技术,最起码要有严谨的态度,否则会导致“失之毫厘,谬以千里”,特别在数字方面,不管误差有多大,如果不相等就不正确,就应该被改正,不能因为误差很小就可以忽略。

1Lpz\r'rOW0

 51Testing软件测试网I0Kv_7l

之前发现很多严重问题,由于SRS没有考虑到,客户没有要求,所以都提交为limitation,但我个人认为,做产品时,不能只想着客户能容忍错误到什么程度,而应该想着比客户要求的做的还要好还要完美,做客户之前没有考虑到的,这才是对待客户的态度。51Testing软件测试网.ok8x:`es6uK

 51Testing软件测试网 Q.IJ0N7L,a

发现的一些问题,虽然SRS没有要求,但逻辑上说不过去的,也不应该不去管它,规则要一致,不能有些功能按规则A设计,另外有些功能按规则A相反的规则B设计,这样逻辑上是说不通的。这类被SE否决的BUG到底要不要提MR,目前还不确定。51Testing软件测试网 F u V$LR.YG:[

 

TZ;N2?)Y9^HF0

根据前一段时间的测试经验,发现很多BUGlimitation在需求和HLD上就可以发现的问题,结果等到测试执行过程中才发现,这样开发人员往往不愿意修改。所以以后有新feature需要测试时,在SRSHLD review之后,立刻开始test case的编写,在开发release之前,就把SRS/HLD中的问题提出来。51Testing软件测试网d)n5mcu dL

 51Testing软件测试网s gN[e#_/ySP:n

 

*DS!m ~tPt0

性能测试51Testing软件测试网i'e(Fb[jPt]dn$n5P

性能回归测试的测试范围,一方面要考虑主要基本功能的压力测试,另外要考虑该版本实现的feature对性能方面可能会产生什么样的影响,比如说修改了某个报表的功能,可能会对性能产生影响,那可以做一下这个报表的性能测试。51Testing软件测试网eP HLy#XS

 51Testing软件测试网k*qTHJp&A'@D)U^

 51Testing软件测试网6X k0R#vf

漏测经验51Testing软件测试网[j#X.Z!n/x.? Q

有一个新feature的测试任务完成,发出去的版本中,居然少了个配置文件。测试的时候却没有发现,严格来说,测试时发现了异常,该配置文件的链接文件显示为一闪一闪的,但没有多留意,后来也没有比较配置文件是否有改变(因为是修复MR的版本,肯定配置文件不会修改),就直接用老的配置文件替换。看来以后升级步骤一步都不能少,即使是版本发布的比较急的时候。

6G-[(o tSM0

 

Q:J2fNUV(J\0

另外一次的测试任务,现场发现个问题,但在测试过程中没有发现。原来是在修改一个BUG时引入了新问题。由于这个BUG并没有修复,所以并没有做相应的回归测试。所以以后在验MR的时候,虽然该MR验证FAIL,但在release之前,仍然要对其会影响的功能进行测试。另外一方面,以后使用和现场一致的组织机构用户登录进行测试,现有的组织机构只有一级,有些和组织机构的问题将不会暴露出来51Testing软件测试网(\Zs KX(I


TAG:

~~IT 之旅~~ 引用 删除 simplezhuo   /   2012-03-24 18:23:15
好久了才看到你的文字
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

Open Toolbar