【转】敏捷测试的挑战
上一篇 / 下一篇 2010-03-23 13:37:57 / 个人分类:敏捷测试
参考:Bret Pettichord 的《Agile Testing - What is it? Can it work?》和《Agile Testing Challenges》51Testing软件测试网GOj)G-nH"F8lpj[J
51Testing软件测试网C5_Il1Q7rsn
我们从上下文驱动测试的七大原则(www.context-driven-testing.com)可以看出,上下文驱动测试倾向于快速的反馈和适应变化的环境。所以上下文驱动测试的很多原则和做法可以应用到敏捷开发的软件测试中来。51Testing软件测试网QD1A!u ZO;U!x h"_
51Testing软件测试网RYYgr{
什么是敏捷开发?51Testing软件测试网du r-c"u(T!DqJ
敏捷开发是递增式的、迭代的、不断调整的开发模式。我们逐渐地建立起软件系统,能看到系统在成长,能展示进度。通过多次发布或项目的阶段检查点,每一次都比上一次靠近目标。迭代包括需求的开发和测试,典型的迭代周期是2周。目标随着从上一次的迭代中学到的东西、反馈以及商业机会而调整。
](eD&RHSYm1bC0 51Testing软件测试网g j+wBh:wy
在敏捷开发中,工作被分解成“故事”,也叫特性或用例,组合成任务分派给不同的程序员。定义好接受标准,开发直到单元测试和接受测试通过才算完成。51Testing软件测试网 uH:X[i*S,d*[t
Y H @
(Wf%R"w I0敏捷开发讲求合作,结对进行编程,避免个人拥有专门的知识,代码属于项目组共有。
%_-r(m0{$F|"{'V2_y+s.u0
L?2l,l#e8D0在敏捷开发中不存在回退,讲究持续地集成,单元测试(通常使用测试驱动的开发方式),持续地进行回归测试。51Testing软件测试网7M2gR_0@)@#a-g%u
51Testing软件测试网]'b3G+I}3sgiH
为什么以前的开发模式不再适用?
9K
X#Jg/h0以前的开发模式要求有详细的测试计划,但是缺乏足够的时间来写,而且测试计划受很多因素的影响经常改变。51Testing软件测试网!N2R(l"y3H
)b;S_b].F$[x0以前的开发过程会专门留出一个阶段来测试,但是你不能定义进入和退出的标准,测试阶段会随之而过。51Testing软件测试网d"i%u0K2\8Q_
51Testing软件测试网Qk}0pk
以前的开发模式强调变更控制,但是现在的软件需求变更非常频繁,变更成了家常便饭。51Testing软件测试网H/W)xgC G
ef`9N
oJd5i&Bi}0以前的开发模式要求测试要对软件做出权威的判断,但是测试很难做出权威的关于软件正确性的判断。
Sa'tyvW+a
m;oa0 51Testing软件测试网$z5k]+umE&R
测试的作用
%ah^e/elX0有价值的东西有么提供产品,要么提供服务。那么测试提供什么产品或服务呢?有人认为测试提供调试通过的、经过测试的软件。这是错误的回答。测试不提供产品,测试提供信息,关于开发过程中的软件的状态的信息,以便基于这些信息做出决定。51Testing软件测试网$@w/}&j4L;lo^_P
2Ql9s"J)O\0敏捷测试的挑战之一:测试员是否不再需要了?51Testing软件测试网
C0Qjz}6_![ wU.t
既然有开发人员做单元测试了,我们还需要测试员吗?有些项目团队采用了敏捷开发方式后把测试员都给解雇了,然后过了不久他们就后悔了。51Testing软件测试网B4p$T2~Zc^$K Z+P
测试可以是除QA或测试员外的人来做,例如业务分析员,有些项目团队让开发人员来做接受性测试。51Testing软件测试网B#\8x!b C0g
4a&T!G1FkGbR0但是有专门的测试员带来两个好处:
;R5u
j }2H
C01、 专注于用户使用而不是软件的技术实现
A
^W3wPG02、 专注于发现软件的错误而不是证明完整性51Testing软件测试网2oe0dW-gzJrB
i J RKq:P)O4U[1q0敏捷测试的挑战之二:测试不完整的软件
yx`*[8G&o!J!g-i8?0频繁的迭代产生的测试版本很多时候是不完整的,测试员如何测试这些不完整的代码呢?51Testing软件测试网9k/W2V#HSToFn
51Testing软件测试网;UP0wm8K%w![J*nB'T
“故事”应该从业务价值方面来定义。一个“故事”应该在一个迭代周期内完成。好的“故事”是不容易定义出来的,但是差的故事对测试人员的影响比对开发人员的影响还要大。有时候测试人员需要帮助定义“故事”。51Testing软件测试网2f2M
S+}A{-Xd
v+m1c:UT\4YUV`0敏捷测试的挑战之三:可接受性测试是否过于简单了?
F*d.|4V]cP0测试人员如果只是做可接受性测试,只是验证“故事”是否完整,岂不是太简单了?这样怎么能做好测试呢?
a,d)pB"En0 51Testing软件测试网 Q
wu&VlfT{
其实,每一个迭代都需要额外的测试,而不仅仅是局限于验证“故事”的完整性。
在迭代测试中还要按需进行下面类型的测试 :51Testing软件测试网E6dy!?J"}3u
探索性测试:同时学习系统、计划和执行测试,寻找bug、遗漏的特性和改进的机会。51Testing软件测试网1fl4gK$^$wP[
组合交互测试:专注于特性之间的交互。51Testing软件测试网J"VkgF C.j S
场景测试:模拟真实世界的场景进行测试。
-j(p\l7L\
`0疲劳测试:长时间地执行软件
e\Y$T*y)f&JM0业务循环测试:基于月末、季度末等业务循环的边界来执行场景
"F-i5~"L8K-g9o0压力测试:对系统施加强大的压力进行测试51Testing软件测试网#si+kQx
v0]2[
G|q\I~0敏捷测试的挑战之四:把测试员作为项目组的一部分51Testing软件测试网&cS*hq,m4A5vp
把测试员作为项目组中的一员不是牺牲了他们作为一个组织的完整性吗?51Testing软件测试网qa-}jJL@\q
51Testing软件测试网.H3Yl e|/M
x*D
测试员一直被认为是受压迫的对象,经常坐在一起互相诉苦、互相支持。现在是时候结束这种情况了。测试员应该跟开发人员和分析师坐在一起,当项目组中有更多的正式或非正式的沟通时才有可能达到敏捷。
(]/v K
Ob\;^c0 51Testing软件测试网weo5DZ4K
敏捷测试的挑战之五:测试什么时候完成?
1v:} CP/y(p#H/xC0没有专门分配的时间来完成测试,我们怎么知道什么时候测试应该结束?
)Z%t/QGcIX*k[v0敏捷测试员需要根据项目和产品的风险来调整测试。基本上测试的优先级应该跟“故事”的优先级一致。BUG列表也提供了测试完整性的提示。51Testing软件测试网8v[,tq N9F+n
:dS1{7K+a1o@q0一个好的测试员是永远都能找到需要完成的测试来做的。
P:d)w.Ud1fV8g0 51Testing软件测试网!M/t[\ f
MV
为什么需要跟开发人员结对进行测试呢?因为开发人员对潜在的错误有一定的洞察力,测试员对约束和错误的时机有一定的洞察力。而他们在一起能使自动化测试更加成功。51Testing软件测试网4i-y3B&j:A#]a
@v,`0[
zW0测试员应该自动化可接受性测试,使用与开发环境一样的编程语言来编写可接受性测试的代码,重用单元测试的框架,使软件更加可测。51Testing软件测试网.kKU'A/dvx
51Testing软件测试网)K9T U_3|4jE"}1g
利用“灰盒”测试。设法弄清楚系统各模块之间的关系,分析变更的影响,看什么是需要测试的,什么是可以不测试的。弄清楚bug,bug的表面现象是什么?产生bug的根本原因是什么?弄清楚风险,使用解决风险的测试策略,调整测试目标。51Testing软件测试网1\T|5}X
(D!hp.Z(THSu0敏捷测试的挑战之六:我们还需要bug跟踪系统吗?51Testing软件测试网5I~gSj*w(e_/e3ltC,n
有些人说敏捷团队不需要跟踪bug,只需要把发现的bug尽快修正就行了。
vJoHo],hLN0 51Testing软件测试网r)y-t2P-Z`0e
这种做法只适用于开发过程的测试,如果是一个完整迭代的测试,你就需要bug跟踪系统,因为有些bug不是在这个迭代马上修改的。51Testing软件测试网a(hQ$u)c-~@lB
ngS
ek;h.z0敏捷测试的挑战之七:用什么质量标准来度量敏捷项目?
\&Ij
YZ%O!N0其中一个最好的质量标准是发布后逃逸的bug数量。不辛的是,这是个事后的衡量标准。
K'{U;H!z!O:k2w_0 51Testing软件测试网+yj }z8R_$o
采用每个迭代后计算逃逸bug数量的方法能标识代码的质量。
G? e&S#`B-G-y!Rc"^0 51Testing软件测试网(TA8Fp3XD$tL7V6P|
我们还可以从bug学习到很多东西:
-A VYe)t j!t%u"F01、 是否有些类型的bug在可接受性测试中发现的,其实是可以在单元测试就发现呢?如果是,把它加入到单元测试。51Testing软件测试网'k%~;k6B+sh$w5mE.p
2、 我们是否能让bug的发现过程或bug的诊断更简单?51Testing软件测试网!`yD:l{]R(f
3、 我们是否能让程序员不那么容易犯这种普通的错误?51Testing软件测试网#W,VJ'Y2R3U$W(O'v
hj
51Testing软件测试网
{c6k2Bq
敏捷测试的挑战之七:回归测试
'gSo(^ed4e0伴随着频繁的迭代,我们需要频繁地重新测试,单元测试是不足够的。我们怎样有效地进行用户层面的回归测试呢?51Testing软件测试网{D)CGe.h2p4EKP
51Testing软件测试网.?M!~)?Vkuj
你不一定需要在每次的迭代都做完整的回归测试。可以每个迭代运行一部分的测试。需要某种程度上的用户层次的自动化回归测试。51Testing软件测试网;[0x2k&en:v%f;C*nJ
51Testing软件测试网A~j#KS3l
敏捷测试的挑战之七:回归测试工具
"V(j&G4Yj^4FD0大部分的商业测试工具在敏捷环境下都不是很好用。大部分有这些缺点:
U
pk0L#{y_01、 指定的语言
dO bK?
e3yu{0s0P0大部分商业测试工具会指定某种语言,例如:WinRunner(TSL)、SilkTest(4test)、Robot(Test Basic),但是一些新的工具也开始使用标准语言,例如:Astra QuickTest(VB Script),XDE Tester(Java)51Testing软件测试网/}
^5q|n6T
参考http://www.stickyminds.com/se/S2326.asp51Testing软件测试网!Q&r