51Testing软件测试网^j M^H7U
%J9QR4n-fI+q02011年工作、学习和生活总结
-MiM,@)ll#T0和前几年相比，2011年是收获和变化最少的一年。实际上能总结的经验很少，但还是勉为其难的总结一下吧。
u!G"KODX t \F0 51Testing软件测试网I(XF5g,t#?
工作：2011年基本上没有大变化，按部就班的工作着，虽说行业的工作经验有所增加，但技术方面进步很小。而且由于只能做黑盒测试，工作兴致没有前几年那么高。51Testing软件测试网 ]fa,fZ
(m xRp'ZJ%e z%f0测试技术：测试经验方面，自动化测试在前半年有不小的进步。后半年最大的收获应该是做了一些性能测试的工作。最后在年底的时候，逐渐进入到灰盒测试。
:J&E-\_b IO#V1x0 51Testing软件测试网*zl,x$Zb B?g!eW
编程技术：大半年和2010年一样，看不到代码，所以编程技术方面几乎没有进步。好在年底的时候又可以看到代码了，所以2012年又可以系统的学习工作相关的编程技术了。
g/P A8cR0 51Testing软件测试网~
} Dsk y eR@j
游泳：业余最大的兴趣所在，2011年基本上能坚持下来，直到后来感冒和春节，才暂停了。年后将恢复锻炼，最起码一周一次。51Testing软件测试网 J W/e&{Qll0[/Z
7\5O1K(d?8^ d.x+w0阅读：主要还是在中午的时候，使用ipad看，记忆中看完整的只有《步步惊心》。。。囧。果然还是看拿在手上的书比较舒服。2012年继续阅读，找自己感兴趣的书来看，比如科幻类/悬疑类的。51Testing软件测试网:b&K J&He)?i N
g4WV`:Z0狗狗：2011年“家宜”仍然是健健康康的，就是自己懒惰，一天溜一次，有点委屈“家宜”了。2012年呢，早上或晚上出去锻炼时，顺便家宜出去遛狗。51Testing软件测试网4w6V G FnOLa
51Testing软件测试网} h%b \ U j1]
测试经验
自动化测试51Testing软件测试网bfp r0Cw
使用公司以前开发的自动化测试平台ATS后，果然提高了工作效率。一方面可以继续使用对象库，另一方面比action灵活很多。
;PNa Zy&` N*ycKS/dP0
H6i.ma u2w6Q0自动化测试远远不止录制脚本这么简单的步骤就可以了，录制好的脚本还需要修改很多地方，不断的调试发现问题解决问题，最后的脚本才能算成功的完成，但可能还存在问题，需要后续的测试过程中发现。
+x:cJ%t/[.ZX9NY0
b2@2PN4|GP[!_7b0自动化测试的编码调试阶段，至上而下的编程，流程如下：在服务器上写case，定义好function，在本地编写function，在本地调试function，所有function调试通过后，将function复制到服务器上，通过ATS调试case。其中用到了一些基本库中的一些function，不过要先理解它们的作用才能使用好。51Testing软件测试网|0VB0M.z1yN)}
:X HOV1d M,A0 51Testing软件测试网:E ~V(u z%AU0c
测试需求和测试用例51Testing软件测试网
W A vK?2v
程序的实现方式要不要写入到测试需求中，这个问题，后来想一想，还是不需要写入测试需求的好，因为实现方式是什么无所谓，关键是找到这种实现方式下的缺陷，只要各种情况都测试到了，基本上就能说这种实现方式是OK的，即使和当时的设计不一样。但如果是特定条件下的规则，那么这个特定条件还是要写入到测试需求中的。51Testing软件测试网"J.CtI_:e
` T F(O KF:]Z0在编写新feature的测试需求和测试用例时，要考虑到该版本之前的测试需求和测试用例，是否有相应的变化和潜在影响，都要归入测试范围。51Testing软件测试网:? d5D I {]*n4V&t
51Testing软件测试网V^]:U#m
51Testing软件测试网D+L ||!t
定位问题
W;L%k,O B8~RM9N0由于看不到代码，只能从日志中定位问题，但光看日志还是有困难，特别是没有提示错误或者看不明白。这个时候，就可以找一个正常的相同网元的环境，和正常的日志进行比较，不同之处就是出现错误的地方。而且把经常出问题的功能相关的正常日志先记录下来，下次出问题的时候，就可以直接比较了。51Testing软件测试网D]1I Q9{0M
51Testing软件测试网B5y(O4Tos
J_O
[i@0BUG总结51Testing软件测试网X m1Z"~7mB ~@
由于在需求和设计阶段，考虑问题不够全面，导致测试时才出现分歧和严重问题，结果只能以limitation的方式release出去，真的是非常的糟糕。如果客户没有要求就不实现，要求的又实现的不彻底有limitation，这样的服务态度，这项目早晚要完蛋。测试只能说是发现问题，要不要实现和修改的权利，都掌握在其他人手里。51Testing软件测试网 M1s^@ryO
&u0cz
A'|0只要是科学技术，最起码要有严谨的态度，否则会导致“失之毫厘，谬以千里”，特别在数字方面，不管误差有多大，如果不相等就不正确，就应该被改正，不能因为误差很小就可以忽略。51Testing软件测试网2o P+? Dr"j M/C
&VK7P0h E3` Z0之前发现很多严重问题，由于SRS没有考虑到，客户没有要求，所以都提交为limitation，但我个人认为，做产品时，不能只想着客户能容忍错误到什么程度，而应该想着比客户要求的做的还要好还要完美，做客户之前没有考虑到的，这才是对待客户的态度。
u8z#XOd0
O bFy7k0发现的一些问题，虽然SRS没有要求，但逻辑上说不过去的，也不应该不去管它，规则要一致，不能有些功能按规则A设计，另外有些功能按规则A相反的规则B设计，这样逻辑上是说不通的。这类被SE否决的BUG到底要不要提MR，目前还不确定。
9D i r-|9yT/x\0 51Testing软件测试网$ZD)H/Ww
根据前一段时间的测试经验，发现很多BUG和limitation在需求和HLD上就可以发现的问题，结果等到测试执行过程中才发现，这样开发人员往往不愿意修改。所以以后有新feature需要测试时，在SRS和HLD review之后，立刻开始test case的编写，在开发release之前，就把SRS/HLD中的问题提出来。51Testing软件测试网L+x&xmRw
s _O6c.Zr
51Testing软件测试网v5}_7t9L6C
^v2N8N
51Testing软件测试网$l$whz-~"e(RZ
性能测试51Testing软件测试网 \y{"E4^EKKg8kaN
性能回归测试的测试范围，一方面要考虑主要基本功能的压力测试，另外要考虑该版本实现的feature对性能方面可能会产生什么样的影响，比如说修改了某个报表的功能，可能会对性能产生影响，那可以做一下这个报表的性能测试。51Testing软件测试网mX:n\lXLg
,Y Vqk n p0 51Testing软件测试网6l'M&S+YOB7nv
漏测经验
Dv5Z1{2N0有一个新feature的测试任务完成，发出去的版本中，居然少了个配置文件。测试的时候却没有发现，严格来说，测试时发现了异常，该配置文件的链接文件显示为一闪一闪的，但没有多留意，后来也没有比较配置文件是否有改变（因为是修复MR的版本，肯定配置文件不会修改），就直接用老的配置文件替换。看来以后升级步骤一步都不能少，即使是版本发布的比较急的时候。
e4dH:d3ne0 51Testing软件测试网-fJ q/D,d_
另外一次的测试任务，现场发现个问题，但在测试过程中没有发现。原来是在修改一个BUG时引入了新问题。由于这个BUG并没有修复，所以并没有做相应的回归测试。所以以后在验MR的时候，虽然该MR验证FAIL，但在release之前，仍然要对其会影响的功能进行测试。另外一方面，以后使用和现场一致的组织机构用户登录进行测试，现有的组织机构只有一级，有些和组织机构的问题将不会暴露出来51Testing软件测试网 {5D\2Q d(H;]
