Jack点评转载的《我的测试秘密和技术》

 

今天在51testing看到一篇转载的文章，很有共鸣。为此结合我的经历和体会，对文中的一些观点点评一把，给大家分享：

6T-fy7Fg6H J i0

~0g/lJ+qY RhT0“最近受邀请要给微软的一个团队讲解我个人的一些测试小秘密和常用的测试技术。其实，测试没有什么太多的秘密可言。如果说如何能发现更多的bug的话，那么我认为最最重要的是passion和experience. 但是，由于他们期望听到的是测试的techniques，我就列了一个我认为最重要的几个方面。现在发出来和大家共享一下吧。

EG![5C;Os ^ x051Testing软件测试网)\.V"AO)G:Ym

——Jack点评：我也认为激情和经验最重要。同样的测试思想和方法好比不同的武器，给不同经验和心态的工程师绝对效果是不一样的。测试管理者们不要指望用工厂生产管理的方式用机器代替人，所有工作都通过工具把对人的依赖弱化掉。测试工程师怎么说也还是知识工作者，不是富士康的操作工。从未听说过设计工作被自动化，实现工作被自动化倒是可行的。类比现在有工具可以自动生成代码，自动生成自动化测试脚本，测试用例，但是这些工具的输入还是由设计者经过人脑分析设计而产生的。51Testing软件测试网v2K;sD4T8H

di#c L-?IA0　　·         Passion, Experience

,v,^+F&vq#Smp0D9y051Testing软件测试网9\Q/W.bq!T6`

　　我觉得experience和passion最重要。有一个周六的半夜我突然有种想法应该给我测试的feature去做code review，就去了office一直工作到5:00am, 结果就发现了两个security bug. 之所以能有这个idea就是因为经验的积累造成，而能在周末凌晨工作几个小时则是因为passion. 我现在完全地享受能发现各种各样bug的生活了，已经对开发没有什么兴趣了。破坏软件真的是很有趣。51Testing软件测试网0b"nF)u9p+Zs7a ~'~

Z4} Aci&d.B0　　·         Understand features deeply

\;_4Zt-t8nm0

b8a9A+j4Pe4F0　　o   Design

:{tDSB0

4Me7l| |#|m0　　o   Architecture

N$vP_d A+_tI\5i4d051Testing软件测试网"Y| H,uNH3mM"Fk

　　o   Implementation51Testing软件测试网 N AO4g%]A@wj:z H9I

^;?`V7Yf0　　o   Customer requirements51Testing软件测试网#?:S7NPR} r)HG)n

.A\5}/cp:n8t{0t0　　理解这些非常的重要。你理解的越深，你就可能发现更多，更好的bug。

R}yk:Sq$|/c:x0

_6Xya*d F#z8u0——Jack点评：我所做过的每一个项目都会深入学习和理解该项目的design、Architecture、Customer requirement，这是我这么多年来做测试的习惯。所以说完全黑盒的测试是不存在的，做好系统测试可以不看代码（时间成本很高，老板不高兴），但一定要和开发人员一样了解design、Architecture、Customer requirement。并且只有你能在这3类文档中发现了其中的缺陷，才能说明你真正的看懂了，并可基于这些资料开始测试用例的系统分析和设计。我甚至认为做一个合格的测试分析和设计人员是必须具备快速学习和理解项目design、Architecture、Customer requirement的能力的。51Testing软件测试网0C8l%_w*d8^!{A

A^ ^ K^7h%iTl0　　·         Tools51Testing软件测试网[l2o4Zr2?+\ E#zrk6H

51Testing软件测试网\-C n_-G}0R:n&E

　　o   App verifier51Testing软件测试网8YS9F`w

3^3Rzk!P"^1O0　　o   Driver verifier

2Aj&F4m iH-A9D0

X:g1[/F yvR0　　o   Fuzzing tools

*p(f6EB+w y051Testing软件测试网 HqU A;mkraW?1k

　　o   Etc.51Testing软件测试网 SS5v#h"i)Egi$~iA

51Testing软件测试网1R0YV`aN(Q

　　Some tools are extremely useful. Some tools are very helpful. 很多人不理解我为什么每天都能发现一两个蓝屏的bug，其实90%的应该归功于这些tools。但是，虽然几乎微软每个人都知道这些tools，但真正经常使用的并不多。我发现一个有趣的问题，绝大多数我发现的bug并不需要特别的技术，而决定于态度。是一个你有没有去测的问题，只要去测，细心去测都能发现他们。51Testing软件测试网@5Yh_-qR'U~ {:i

r9n5V6P1SZb)A:aI4y0——Jack点评：对测试工程师来说用好工具胜过自行开发工具（这是在做开发，而非测试），开发工具是有很大的成本的。当你是一个有丰富测试经验的工程师时，我更希望你能发挥测试的特长，而不是放弃特有的测试经历转向开发重新开始。当然如果你认为你的测试用例集已足够完善和完美，有无事可做那么你可以去写写工具玩，否则的话应将测试工具的开发交由专门的开发人员来实现。

oZb _Tp-s_"c0o051Testing软件测试网b Ypp*zE2p

　　·         Code review+Debugging51Testing软件测试网9t/A M${ iWq

)Ah^B3|j0　　o   Security audit: buffer overflow, memory leak, AV51Testing软件测试网Z.F]B"x`TK/~

_y0~(Q]K8@S1C0　　o   Logic review51Testing软件测试网U jtf]L*_L4BX

51Testing软件测试网[;j?%?oQ

　　Debugging 的技术非常非常重要，这是开发和测试的一个主要技术交集。就在我做完这个经验介绍以后，其他的feature里发现一个bug，他们怀疑是我们的 feature造成的。我出面跟他们的开发和开发组长进行交涉，最后给他们指出他们的代码里问题的所在。Code review和debugging是相辅相成的，不可分割。我一般进行两种code review。一种叫code audit, 不关心代码的逻辑，功能，只是检查有没有buffer overflow, memory leak, AV 等等。一种是logic review, 专门检查代码的逻辑是否合理。Code review是个bug farm, 熟悉之后你能发现大量的bug在里面。51Testing软件测试网`%~j6p!XVD7t

-_3H!H,o&bj!Z0——Jack点评：非常高兴最近我正在实践的代码检视方法与文中的一样：如果时间资源少，先只做code audit（关注内存泄漏，资源泄漏，错误的指针内存使用，字符串缓冲区溢出，数组应用错误等）；只有时间资源多时，才考虑logic review（一直没有时间来开展。） code review可以在测试设计开始之前做，能帮助你对系统实现了解更多，有更多可编写测试用例的场景输入；也可以在所有用例测试完成后来做，对基于场景的测试分析进行补充，毕竟无人能100％的覆盖所有的可能问题场景，通过code review也是一种补充方法。不过，需要强调的是：code review能发现代码编写的错误，却很难发现设计流程的错误（因为你已陷到细节的纠缠中去了，很难再从全局考虑设计了）51Testing软件测试网9LzRSk,^

51Testing软件测试网.YIO6Jk

　　·         Tenet tests:

l??Qr!R0

2g.|4V:J@3v'v$g*z4n0　　o   Reliability: tools, stress

5wl?1X Pt1O j0

Vs1}9Q+xv+Of0　　o   Security: fuzzing, code audit51Testing软件测试网"~ ^.t~ M5u9@/j

?FP2y Kc,d0　　o   Performance: Xperf51Testing软件测试网iN"N~RA

51Testing软件测试网 VO MP%p1p*c;H0a

　　大家一般更多的关注与functionaltest。其实Reliability, Security和Performance测试都非常重要。每一个测试人员都应该具备进行这几方面测试的能力，从而给自己负责的feature经常性的，或者通过Lab进行这些测试，肯定能发现很多bug，这些一般都是非常好的bug。51Testing软件测试网+F^h-N7Vj k

'i!@A8\ v;T j0——Jack点评：压力测试和可靠性测试做的不充分，不精耕细作的项目，绝对质量是不过关的，无论测试报告能多么匹配你公司内部的质量出口标准，只要产品大规模上市应用后，你就会吃到这个苦头的。我甚至认为压力测试和可靠性测试是充分暴露产品bug的重型武器，功能测试用例只是步兵的随身武器。一直以来我每一年都会帮某些项目设计压力测试方案（用例）或可靠性测试用例，每做一个项目，我都能在这些专项测试的测试分析和设计质量上更进一步。

t^r,ly ^B;I Iau0

AzG Q!yy2s*_6Og4^0　　·         Integration test51Testing软件测试网 Yk9]^v'z#dK"u-t

51Testing软件测试网q$FX3F5m:fy

　　大多数人只关心自己的component。其实很多bug发生在集成测试上。你需要学习其他相关的component, 从而能够想象很多cross feature的scenario进行测试，也能发现很多bug。

|"v)EOTr!gE0

S a_u,^7f;q*o!w0——Jack点评：通常我在给项目组补充测试用例设计时，很多都是补充的这类用例。因为经验稍少的人难免会对被测系统内部的对象理解的过于孤立，即使有时进行了正交穷举法也未必能考虑齐全。要做好集成测试的设计，需要测试分析设计人员具备快速进行宽度知识学习和深度知识学习的合理平衡。不过于钻牛角尖，又不过泛导致只能搞穷举正交。51Testing软件测试网&V\,yR8w(uqI(LL

51Testing软件测试网%wa)y,{N

　　·         Looking for test holes

Hw#w*w4lF0

.\r5?'HR.F3_\P$\0　　o   Test cases51Testing软件测试网%}~ U]8eDJ

51Testing软件测试网^_H!D aDw

　　o   Test tools

u'ZG-u&k|d0

&f7e6r7Gk"PBV)D,s0　　o   Test owner history51Testing软件测试网Ca!|2[K#O2S

51Testing软件测试网#?)dp/[` [-G

　　o   Old bugs analysis

Dd:s%k s:iw$n0

)kTT:W+x0　　我在有时间的时候我会通过这几方面去寻找更多的bug。看看有没有没有cover的test case， 看看有没有新的test tool可以尝试，跟别人聊天看看自己component以前test owner的情况，以及分析一下最近发生的一些bug。同一个bug有没有可能出现在其他地方。51Testing软件测试网"s:Tjb}3BMA

51Testing软件测试网#?l7m3o`0T

版权声明：本文出自flysky19的51Testing软件测试博客，欢迎转载……”