Jack点评转载的《我的测试秘密和技术》
上一篇 / 下一篇 2010-08-10 21:52:35 / 个人分类:正确的测试思想
L|9OU/_u%[(cJ0 51Testing软件测试网$R6C4\g:t\N*U
51Testing软件测试网 ht9B"u y今天在51testing看到一篇转载的文章,很有共鸣。为此结合我的经历和体会,对文中的一些观点点评一把,给大家分享:
H#yH y%i/c0\S(dh r Rwb]S };S0“最近受邀请要给微软的一个团队讲解我个人的一些测试小秘密和常用的测试技术。其实,测试没有什么太多的秘密可言。如果说如何能发现更多的bug的话,那么我认为最最重要的是passion和experience. 但是,由于他们期望听到的是测试的techniques,我就列了一个我认为最重要的几个方面。现在发出来和大家共享一下吧。
)t;XtD]`051Testing软件测试网yei;u)~ x\ u{——Jack点评:我也认为激情和经验最重要。同样的测试思想和方法好比不同的武器,给不同经验和心态的工程师绝对效果是不一样的。测试管理者们不要指望用工厂生产管理的方式用机器代替人,所有工作都通过工具把对人的依赖弱化掉。测试工程师怎么说也还是知识工作者,不是富士康的操作工。从未听说过设计工作被自动化,实现工作被自动化倒是可行的。类比现在有工具可以自动生成代码,自动生成自动化测试脚本,测试用例,但是这些工具的输入还是由设计者经过人脑分析设计而产生的。
%|9^|AD.G1B(h Y0ML)g8n ZV0 · Passion, Experience
:]\$DvU?"s,y;YQ0.y W$Fso0 我觉得experience和passion最重要。有一个周六的半夜我突然有种想法应该给我测试的feature去做code review,就去了office一直工作到5:00am, 结果就发现了两个security bug. 之所以能有这个idea就是因为经验的积累造成,而能在周末凌晨工作几个小时则是因为passion. 我现在完全地享受能发现各种各样bug的生活了,已经对开发没有什么兴趣了。破坏软件真的是很有趣。51Testing软件测试网8ddoF$LuK
51Testing软件测试网@3OcDCIZ· Understand features deeply51Testing软件测试网5G?"h(X3LY vty
51Testing软件测试网"_-L#[$Z;i D|o Design
'Y0b;e {6`:]9O\A0L bvS2}@b&]4I:{L0 o Architecture51Testing软件测试网,A;L:] zg[#U gE
51Testing软件测试网%i%Q E[/F2m&IQIoo Implementation
E7xZy|[5U9Rx9o051Testing软件测试网 w4A;J3Bi,P P7qo Customer requirements51Testing软件测试网J:sR1zX{2d
51Testing软件测试网M3p,}[N)iv理解这些非常的重要。你理解的越深,你就可能发现更多,更好的bug。51Testing软件测试网.N{a)? S*r
-C5k1?;FQb({0——Jack点评:我所做过的每一个项目都会深入学习和理解该项目的design、Architecture、Customer requirement,这是我这么多年来做测试的习惯。所以说完全黑盒的测试是不存在的,做好系统测试可以不看代码(时间成本很高,老板不高兴),但一定要和开发人员一样了解design、Architecture、Customer requirement。并且只有你能在这3类文档中发现了其中的缺陷,才能说明你真正的看懂了,并可基于这些资料开始测试用例的系统分析和设计。我甚至认为做一个合格的测试分析和设计人员是必须具备快速学习和理解项目design、Architecture、Customer requirement的能力的。51Testing软件测试网5] RV E/kQ
51Testing软件测试网-X%b$g*q#zsH$tX· Tools
o`3^$pb0Pyc!I6F+F0 o App verifier
kYXk~ o ao0\ RN].v&y^/k s0 o Driver verifier51Testing软件测试网Pm2?#y,s0|
T*n){P-E e5JY{u5kf0 o Fuzzing tools
\-`4Az"R051Testing软件测试网 IZtwzk"Go Etc.51Testing软件测试网_ O_ VY*a;h G4Q
E]:BS.@'A7_0 Some tools are extremely useful. Some tools are very helpful. 很多人不理解我为什么每天都能发现一两个蓝屏的bug,其实90%的应该归功于这些tools。但是,虽然几乎微软每个人都知道这些tools,但真正经常使用的并不多。我发现一个有趣的问题,绝大多数我发现的bug并不需要特别的技术,而决定于态度。是一个你有没有去测的问题,只要去测,细心去测都能发现他们。
$d3S:ZW s;i BXl03R%R)lG"GqU'z1@o0——Jack点评:对测试工程师来说用好工具胜过自行开发工具(这是在做开发,而非测试),开发工具是有很大的成本的。当你是一个有丰富测试经验的工程师时,我更希望你能发挥测试的特长,而不是放弃特有的测试经历转向开发重新开始。当然如果你认为你的测试用例集已足够完善和完美,有无事可做那么你可以去写写工具玩,否则的话应将测试工具的开发交由专门的开发人员来实现。
.Z~9jU r#u(fEJI051Testing软件测试网ts#I#j)e]#}· Code review+Debugging
.r!G7G%d,gdaC'y)Z0n+t2w%@p4I:kn0 o Security audit: buffer overflow, memory leak, AV51Testing软件测试网/f:` P1{ ^ZrOd
51Testing软件测试网!r-Kf|"_o Logic review
[/]m:l6~.Jr1G_0U&w9OLe/?a8U0 Debugging 的技术非常非常重要,这是开发和测试的一个主要技术交集。就在我做完这个经验介绍以后,其他的feature里发现一个bug,他们怀疑是我们的 feature造成的。我出面跟他们的开发和开发组长进行交涉,最后给他们指出他们的代码里问题的所在。Code review和debugging是相辅相成的,不可分割。我一般进行两种code review。一种叫code audit, 不关心代码的逻辑,功能,只是检查有没有buffer overflow, memory leak, AV 等等。一种是logic review, 专门检查代码的逻辑是否合理。Code review是个bug farm, 熟悉之后你能发现大量的bug在里面。51Testing软件测试网{3E;Qb7SB`Y/lg
ZE#D.Z:kS+s0——Jack点评:非常高兴最近我正在实践的代码检视方法与文中的一样:如果时间资源少,先只做code audit(关注内存泄漏,资源泄漏,错误的指针内存使用,字符串缓冲区溢出,数组应用错误等);只有时间资源多时,才考虑logic review(一直没有时间来开展。) code review可以在测试设计开始之前做,能帮助你对系统实现了解更多,有更多可编写测试用例的场景输入;也可以在所有用例测试完成后来做,对基于场景的测试分析进行补充,毕竟无人能100%的覆盖所有的可能问题场景,通过code review也是一种补充方法。不过,需要强调的是:code review能发现代码编写的错误,却很难发现设计流程的错误(因为你已陷到细节的纠缠中去了,很难再从全局考虑设计了)
O9y k;BG ^d*qO7R0-JHD6hS3~\0 · Tenet tests:
oO5m5r-_"^,n3Pn0F0C%j{ Q)iS0 o Reliability: tools, stress
K2s"RA'{$NH9?4K3g!y T0