企业Web应用中的敏捷测试和瀑布测试-2

上一篇 / 下一篇  2012-08-21 10:10:30 / 个人分类:杂谈

-_Sr tutG0  环境51Testing软件测试网Z9rF'R4a:D-U+W

51Testing软件测试网paT@ [wL,{u$U

  在开发过程的各个阶段都要用到测试环境,从而确保应用程序的正常运行。越到后期,测试环境与预期的产品环境就会越相似。测试环境一般都会包括一 个开发环境,让开发者集成代码并运行一些测试。系统集成环境跟开发环境有些类似,不过它会集成更多的第三方应用程序,也许还有大批量的数据。试机环境几乎 是产品环境的镜像,也是应用程序变成产品之前的最后一个阶段。

#Y8JJ7p"iR W051Testing软件测试网x g0G8b2S

  敏捷项目和瀑布项目所需的环境没太大区别,其中一个不同之处在于,敏捷项目从项目伊始直至项目结束,都要用到所有的环境。在敏捷项目中,保证所 有的环境都一直正常工作也是很重要的。无论因为什么原因让某个环境出现故障,都要立刻让它重新工作起来。在这个话题上,敏捷和瀑布还有另外一点差异,那就 是环境的计划和资源分配对它们的影响不同,尤其是当各种环境被项目之外的团队进行管理的时候,其差异尤为显著。

0~7F JL8e051Testing软件测试网+ssGU%e

  开发集成环境

2iy M2\3h$F)D0

5| q;|4T!V&sPl0  开发者在开发环境中集成代码,开发应用程序。瀑布项目对开发环境的重要性不会考虑太多;开发环境中的代码一直都不能工作,到了开发者需要彼此集 成代码的时候才想起来使用,而这时项目已经临近尾声。在敏捷项目中,开发环境是整个开发工作中不可分割的一部分,在开始编码之前就必须准备就绪。这个环境 会被用来持续地集成代码和运行测试套件。无论因为什么原因造成环境故障,都要立刻修复。51Testing软件测试网,`D/L d0YRL6Z

51Testing软件测试网6P UVN1u:z\MXa

  开发环境应该考虑以下几点:51Testing软件测试网#x(sI1`^v!f]$d

51Testing软件测试网3\B2?:_V ts

  1、集成代码、构建和测试的时间加起来不要超过15分钟。51Testing软件测试网 X.bZN$B?O]y Er

51Testing软件测试网Kr%@['p0~Ed$dz

  2、每个开发人员所用的环境跟开发环境保持一致(硬件环境可以不一样,但软件环境一定要一样)。

VaG Rfa,qx051Testing软件测试网v})g3ka%H

  3、所用的数据要尽可能跟产品数据保持一致。如果产品数据过于宠大,难以载入,也可以只取一部分。在每个发布周期的开始阶段,这些数据要从产品数据中重新更新。51Testing软件测试网3V9D6{]9r

h*SC$S ^j4[0  4、管理这个环境的责任应该落在项目团队身上。51Testing软件测试网nW3G{"E ?"h

51Testing软件测试网_.Q St V5bI"L5O.M9s

  5、向这个环境中部署的频率大约是以小时计算。

u3Q z!}$z)a~051Testing软件测试网&bm,}}~p-OV? V

  6、自动部署。

E-u(PQQ0

b9\1{4Ol%fF0  系统集成环境51Testing软件测试网+B,^4y|^

51Testing软件测试网C:S"iIR-U)~

  系统集成环境用来将所开发的应用程序和其他应用程序进行集成。在瀑布项目中,这个环境只会在项目临近尾声的时候才会用到,而且倾向于多个项目共 用一个集成环境。在敏捷项目中,一旦开始编码,这个环境就要准备就绪。应用程序会被频繁部署到这个环境中,继而开始执行功能测试、集成测试、可用性测试和 探索性测试等等。应用程序的演示是在这个环境中进行。51Testing软件测试网 Z{7`'TM8f%qF:G2^G3M

51Testing软件测试网 },_9T }:d.KxxN|"C

  系统集成环境应该考虑以下几点。51Testing软件测试网r5zQ^$GVMRo!D

+a+F'^6k;z0  1、集成点应该被真正的外部应用程序所代替。外部应用程序应该处于测试状态,而非真正的生产版本。

(L_3yaut1}051Testing软件测试网 T!RBs0[3ou ny)U3}&S

  2、把产品环境的架构复制过来。

&x y{u0T'lIKjY0

/LfX4L(I[.? X0  3、把这个环境中所使用的数据应该是产品环境数据的副本,每个发布周期的开始阶段,都要从产品数据中重新更新。51Testing软件测试网-U ? jQD?

$}2u{vd2j K0  4、建立运行这个环境中所有测试的系统集成持续构建。51Testing软件测试网f'D R.qA

.u/sH]nS(?`2A0  5、管理这个环境的责任应该落在项目团队身上。51Testing软件测试网Y:[$]iD{"s

51Testing软件测试网8l*[:}3R zp7P.A#[bj

  6、向这个环境中部署构建的频率大约是以天计算。51Testing软件测试网4@*[wF-Zb.kB*k

MQIT!OxeE0  7、自动部署应用程序。

4h&h;T6K f;U P7W051Testing软件测试网 Op M:W @!h+[ xml

  试机环境51Testing软件测试网B+uo(TwJov

b#_xA A2f]3Ip@0  试机环境用来验证应用程序可以部署为产品,而且工作正常。为了达到这个目的,试机环境应该完全复制产品环境,包括网络配置、路由器、交换机以及 计算机性能等等。在瀑布项目中这个环境往往需要“预订”也要有一个计划,计划在这个环境中进行多少次部署以及何时进行部署。敏捷项目对这个环境不像对开发 环境和集成环境那样依赖;不过在项目的整个生命周期中,还是需要常常进行部署。51Testing软件测试网l_1Y;m g2R?/p

5dB9a*X Af4^0  试机环境应该考虑以下几点:51Testing软件测试网y!X&H4O,E

51Testing软件测试网z @w(n\M`C

  1、这里的数据应该是产品数据的完整副本,每次应用程序部署前都要更新。51Testing软件测试网#cnh o^

1f1G}%Z4L0  2、用它来验证UAT, 性能测试和非功能测试(稳定性、可靠性等等)51Testing软件测试网[vr8W c+{PR

3NK2z,S9@HZ0  3、向这个环境中部署构建的频率大约是以迭代计算,如每两周一次。51Testing软件测试网[4] Z3~;J

51Testing软件测试网u&\,[8U!C#q:g

  4、管理这个环境的人应该就是管理产品环境的人,让他提前接触应用程序并进行知识传递。

&F_!_%zm0m6n3DyQ8i0

~d#K*@F6`+mG ^0  5、自动部署应用程序。

^fuy"q [&a3?051Testing软件测试网6thq6q(tmQR*R

  产品环境51Testing软件测试网VG&@4Oi3Ti

3]6Eo l|FS x0  产品环境是应用程序正式上线时的环境。产品校验测试就在这个环境中执行,同时会做一些度量以检验测试成果。瀑布项目和敏捷项目在这里的区别不大。在敏捷项目中,发布过程会尽力做到自动化,为向产品环境中频繁发布提供条件。51Testing软件测试网7H;~7[wo

)yT*k y4He ] m9i0  产品环境应该考虑以下几点:

1]:W(e Q,Q`051Testing软件测试网!L] M3R\x

  1、在应用程序正式上线之前,在产品环境中做回归测试。

v J:q*U:?!h)\2L GA0

HAY-FF.jv L KO0  2、要做度量,以检验测试成果,例如在前三个月到六个月之前,用户报告了多少问题,问题的严重性如何。

h)KF@*iQ+W-U"C0

#j{'hC#EkF H0  无论是哪种项目,要保证时间期限,就都得做到在需要用到环境的时候就有一个环境可供使用。瀑布项目会设法遵守严格的计划,便于对环境做安排。敏 捷项目的灵活性更强。也许有了足够的功能就可以进入试机环境了,或者业务人员会决定产品提前上线。为了做到向试机环境快速部署,然后进入产品环境,就要有 系统集成环境以及有关过程的辅助。

6F ]'o3n b6H0

)JI;Y/]0a*`2I0  问题管理

v%IMO7u(E051Testing软件测试网B0n(Ux1H%r]

  问题包括缺陷(bug)和变更请求。瀑布项目有着严格的缺陷和变更请求管理,而敏捷项目饱含变化,所以就没有那么严格的变更管理。如果需要有变更,就创建一个(或是一些)故事,放到待处理事项里面。高优先级的故事会放到下一次迭代中完成。

^,mt&js7{9[r2W0f3K051Testing软件测试网 z%Puvl(Z

  缺陷管理在敏捷项目中依然适用。如果有人发现一个正在开发故事有缺陷,大家就会进行非正式的沟通,发现缺陷的人把它告诉开发人员,缺陷立刻被修 复。如果某个缺陷并不属于当前迭代中开发的故事,或者属于当前故事,但并不严重,那就用缺陷跟踪工具记录下来。这个缺陷会被当做故事处理;也就是说,会创 建一张故事卡,让客户排优先级,放待处理故事里面。团队需要进行权衡:要找问题所在,为大家理解这个问题并安排优先级提供足够的信息,但又不能在一个对客 户而言优先级并不是很高的缺陷上面花太多时间。51Testing软件测试网0zc ~6q#N]"j#GP6Z;B

51Testing软件测试网9Y5Qsb*`.F

  瀑布项目和敏捷项目的缺陷内容(描述、组件、严重程序等)是一样的,除了一个字段以外:敏捷项目多了一个字段- 业务价值,如果可能的话就用币值描述。这个字段表示如果缺陷被解决的话可以带来多少业务价值。将业务价值跟缺陷关联以后,客户就更好地判断这个缺陷跟新功 能相比是不是更有价值,是不是应该有更高的优先级。

#P1[6q Z9w @051Testing软件测试网/MP,Q[;l k

  工具51Testing软件测试网O$v*G8Ua U/}0{

el-X(e6|*j hI oJK q0  所有项目都要用到工具,只是程序不同。瀑布项目用工具来强化过程以及提高效率,这有时会造成冲突。敏捷项目用工具辅助提升效率,与过程无关。在 敏捷项目中,所有的测试都应该可以在任何团队成员的个人环境中运行,也就是说,所有人都可以使用那些自动化测试用例的工具。所以敏捷项目中会经常用到开源 产品,这又意味着使用这些工具需要不同的技能。开源工具不像商业工具那样有齐备的文档和完善的支持,用这些工具的人要有很强的编码能力。如果有人编程能力 偏弱,就可以通过跟人结对来提升个人技能。在敏捷项目中也可以使用商业工具,但是大多数商业工具在开发的时候都没有考虑敏捷过程,所以敏捷项目匹配起来就 不太容易。而且要让商业工具跟持续集成配合,可能要写很多代码才行。51Testing软件测试网,Kf&tf$S9n6A;MJ

"N9w3l:X.q0  项目中应该考虑为下面一些测试任务使用工具

)g+GcK|.s OR;n'm051Testing软件测试网7]+V^|8yhk

  1、持续集成(如CruiseControl, Tinderbox)51Testing软件测试网Xr*z@3Er*{hL[$A

51Testing软件测试网_7_(uK!jR$U

  2、单元测试(如JUnit, NUnit)

$]X:P k/H7T,h"e.{0

0Cy P`mX5Ii9J0  3、代码覆盖率率(如Clover, PureCoverage)51Testing软件测试网}Mq Mvc*Z X

51Testing软件测试网4yv o @^Q-d a8Sw

  4、功能测试(如:HttpUnit, Selenium, Quick Test professional)

$R z8\.M'v3B?0

{3v DkRx:K0  5、用户验收测试(如:Fitness, Quick Test Professional)

L(U8@@D051Testing软件测试网a9~nco2ku8HX

  6、性能测试(如:JMeter, LoadRunner51Testing软件测试网:G;ICY&\

Z@@Z0U^,o,i0  7、问题跟踪(如:BugZilla, JIRA)

&ztEESh:O051Testing软件测试网v;aj7GAvk$v$w2C |

  8、测试管理(如:Quality Center)51Testing软件测试网o$].r3Wtt

51Testing软件测试网2f$fV$PtC

  报表与度量

7u`3L8iM~bv5d0

Kk$N'N;d!@zB0  度量数据是用来衡量软件质量和测试成果的。在瀑布项目中,有些测试度量指标需要在测试之前就把所有测试用例都写好,而且仅在应用程序开发完毕时 进行一次测试。这种指标包括:每个测试用例执行的时候发现多少缺陷,每天执行的测试用例会发现多少缺陷。这些度量数据收集起来以后,便用来判断应用程序是 否已经就绪并可以发布。在敏捷项目中,功能完成的时候测试用例就已经写好且运行完毕,这就意味着用来度量瀑布项目的一些指标是无法应用在这上面的。51Testing软件测试网nC1u-_q7cWJ

51Testing软件测试网\K CID(V*i{

  回到收集度量数据的原因上来-衡量软件质量和测试成果,你可以看看下面这些概念。51Testing软件测试网IV\5Z,~~

51Testing软件测试网:ZU E{9F)o`%d~

  1、用代码覆盖率度量测试效果;这对于单元测试尤其有效。51Testing软件测试网;DB9N'@G9^w| s

51Testing软件测试网(Wt4v9uwD|a

  2、在探索性测试阶段发现的缺陷数量可以说明单元测试和功能测试的效果。

_G~}:k0

%u8L7w e3G0z0  3、在UAT阶段发现的缺陷表示先期的测试并不像UAT一样充分,我们应该关注业务过程, 而不是软件的bug。如果UAT发现了很多功能性问题,而不是软件的bug,这就表示团队对故事或是变化的需求理解不足。51Testing软件测试网 eH Y K_

y,b0Uv3Cj(a0  4、故事完成以后所发现的缺陷数量能够作为衡量软件质量的好手段。这些缺陷包括在集成测试、非功能测试、性能测试和UAT测试中发现的缺陷。

8u UMA3}'b"w7qTl+dOa0

:SXO'e sdZ|TO0  5、缺陷重现率。如果缺陷常常重现,软件质量就很低。

'nq W?M4[;M.`?051Testing软件测试网$]\\H$n!m)y

  测试角色

U'H-o\"@0

u~W pF e.[9Ne0  测试角色并不是跟单个资源一一对应的。一个资源可以担任多个测试角色,一个测试角色也可以由多个资源负责。下面列出的这些角色是确保项目测试效 果所必需的。一个优秀的测试人员应该具备所有这些角色的特征。敏捷项目和瀑布项目都有这些角色,只是扮演这些角色的人不同。在敏捷项目中,所有团队成员都 是怎么扮演各个角色的。这并不是强制性的规定;每个团队各有差异,不过这种做法也算得上是不错的组合。

+]zO-J%a'V0S(i [051Testing软件测试网ZsHO S&s6ES7@

  测试分析人员要了解需求、架构、代码等各个产物,从而判断哪些需要做测试,哪些是测试要重点关注的地方。

#Q7{c.Ak`0

`K+}{o-@0  在瀑布项目中一般是有一个(或多个)资深的资源来担任这个角色。他们检查相关文档(需求、设计、架构),编写测试计划、编写高层的测试用例描 述,然后把所有的东西都交给一个初级员工,让他填补详细的测试脚本。敏捷项目鼓励所有团队成员一起担任这个角色。开发人员的关注点是通过分析代码和设计来 编写单元测试,但是他们也会协助业务分析师或者测试人员编写功能测试,还会参与非功能测试和性能测试的分析。业务分析师和测试人员紧密协作,编写功能测试 和用户验收测试,并执行探索性测试。客户/最终用户会被邀请参与用户验收测试。

N.PCX GDxy0

fS8OD3xA0  测试脚本编写员51Testing软件测试网&j%[D~-m%S |h4M

51Testing软件测试网(uY \v)o(a*[

  该角色就是编写详细测试脚本的人。这些脚本可能供手工执行,也可能被自动化。瀑布项目中的脚本编写就是个初级员工,他根据测试计划和测试用例描 述来编写手册,每一步都描述的很详尽、自动化脚本编写员就得是更资深的人了,开发人员也会参与单元测试用例的编写。敏捷项目会大量使用开发人员来编写测试 脚本,主要是因为测试脚本是自动化执行的。51Testing软件测试网(a0s,f `a

51Testing软件测试网h.~I5r nw8@

  测试执行员51Testing软件测试网 Y+~pt.jG+d/\

KU,M\'_xN0  不管是手工测试还是自动化测试都有这个角色,不过在自动化的时候,这个角色的扮演者就是一台电脑。测试执行员会执行详细测试脚本,判断哪些测试 失败,哪些测试通过。瀑布项目一般都用测试人员来做这件事情,而敏捷项目则鼓励所有人都来参与,尤其是测试人员、业务分析量和客户。

6xj#\g2e8{S&V@}0

)n&W wnz5y0  环境管理人员

2W*{Esuq%F+{T3c051Testing软件测试网 Zj~8_@ qf

  这个角色管理测试环境,包括应用程序运行的环境以及支持自动化测试的基础架构。他们还会关注外部接口和用作测试的数据。这个角色在瀑布项目和敏捷项目中很相似。51Testing软件测试网7S N_4?&x1R.M_EI

+TT)p]xpA0  问题管理人员

nr@Z1w6G*N'}G0

&kk [/ciP[%d0  问题出现以后就要解决。这个角色可以帮助筛查问题,确保它们被正确地创建,有各种属性,如严重程度、优先级、组件等等。这个角色还要管理问题的生命周期,并提供工具支持。这个角色在瀑布项目和敏捷项目中很相似。

J'P!h*[ |$A4}*O051Testing软件测试网;|&e7po-l%P

  故障检测人员

_-|2L$c+W9bEH051Testing软件测试网Sy@*TJ#Vz~

  这个角色当问题出现的时候就要去做故障检测工作,判断是不是软件缺陷。如果是软件缺陷,他们就要去找出问题根源、可能的解决方案和变通措施。这个角色在瀑布项目和敏捷项目中很相似。

#O,s^H"B {LQ051Testing软件测试网dh%O0`P}

  敏捷团队所注重的是让各个角色得到充分发挥,而比较少关心谁在做什么事情、谁对哪些事情负责。测试人员和其他团队成员之间没有界限,他们共同的 目标是生产出更高质量的软件,每个成员都要尽一切可能帮助达成这个目标。在敏捷团队中,测试人员可以从所有人那里得到帮助,而他们又可以帮助其他人提高测 试技能。这种方式能够确保团队中的每个人都在为交付高质量应用程序而付出。51Testing软件测试网0R!ut8W1{/L}


TAG:

 

评分:0

我来说两句

Open Toolbar