找到测试的敏捷点

　　你的定位51Testing软件测试网]fD$Yo(F

@M"^n O4w0Z0　　测试早早已然不是为了发现产品的bug而存在了。

w&F9yF#s ~0　　它应当是保证快速发布版本的手段，而发布的标准正是测试检验的结果是否达成市场预期。例如，互联网产品BUG容忍度高，可以带一些非功能性BUG，这时也可以先发布；但一个网关设备，要求不能有任何宕机问题。

　　做什么事情

EAdSv2Gx8Rc4n)C yi0　　测试先行，在需求阶段中，将需求细化成测试点；

　　在设计阶段，一起进行设计与架构，重点就可测试性进行评估与设计。可测试性是隐性的客户需求，至关重要，关乎接下来测试的难易程度与开发DEBUG效率。51Testing软件测试网9NS`W#y

o
P7_m
O3t0　　在编码阶段，同步细化测试点，参与开发代码评审，review，完成测试代码，检视需求点

　　在集成阶段，用例提交（手工，自动化），开发同步参与用例的评审。检视自己代码是否有需求遗漏51Testing软件测试网~W8rS]&Q;{

R%U/}Tt4^3tK0　　系统测试中，重点是发散性测试，场景级测试，以及用户级测试。51Testing软件测试网 GI0q}P${_0X%?*r

Q`}!ZP5b!} v_[+G*A(z0　　Google模式好么？51Testing软件测试网mUKb0MHeiREB?

+\!d:C _nzr0　　本来开发测试不分家，这样20：1，甚至比0的情况都是可以的。51Testing软件测试网oV'k0X8~qn1_

　 　为什么这样说呢？可以说，未来的开发人员即测试人员，测试人员即开发人员。不会编码的测试人员不是好的测试人员，同样不会测试的开发人员不是好的开发人 员。制造跟发现BUG永远是一对兄弟，开发不能等着测试发现问题，而是在开始就想到如何避免出现问题。测试不能等开发把东西做好了才测，应该一开始就分析 如何保证在设计一开始就避免引入BUG。51Testing软件测试网_e'e:Aa*x

　　这么一来，理论上，顶级的开发人员就不需要多少测试人员，因为BUG会很少，测试起来也容易，版本发布当然快。51Testing软件测试网m uD(bDJ#o9p.A C

1[FRWUx@3a~0　　好的测试人员能顶住很多重复工作，利用自动化，利用编码能力，利用强有力的预防手段，防止大量无用功。

　　你的模式

'mfyi1^3M-W Z0　　我依稀记得前不久，WPS测试团队提出并实践的从互联网上爬取DOC文档来自动验证wps的稳定性的解决方案。

　　我想，这是一个多大的创新，于此，我又相信wps的稳定性在未来会超出微软的办公套件了。51Testing软件测试网I~s#{)j3zBFq

　　你需要我上面说的模式吗？不一定。

　　视情况而定。测试与开发的比例说明不了任何问题，能够说明问题的只有是否按市场预期完成整个项目活动，成本是否控制在合理水平，每个人是否得到自己想得到的东西，例如技术水平提高，管理能力。

　　但一旦能力上去了，一定要往这个方向走。51Testing软件测试网7ycN}2gO

　　需要敏捷么？51Testing软件测试网~kyb1Mz6eo

　　敏捷不算啥，更为直接的可以算是“持续交付”，达到这点其实非常easy：51Testing软件测试网*M$pW.v(\c

N)u-vm Y,D|cp,i4R0　　1、以自动化为核心，一切工作皆自动化。

　　2、团队有共同的目标，遵循：先测试，后开发；保持主线clean；重构，测试，交付；51Testing软件测试网0s5e/~pRo2Mnx.RM

　　如果大家都是这样的理想主义，必然可以成功。51Testing软件测试网X(TZ&y8w

@A0D0[f+Kv0　　至于真的需要这么“敏捷”吗？看情况，你喜欢精英型团队，它是非常好的模式，如果是传统型，一定不适合你。

　　最后，无论测试成什么样，最终还是要看市场需求，借用一句话：“台风来了，是猪也能飞起来的”。51Testing软件测试网!I,i5R6oCZ uE;OA

Q"_+w,^m"rM0　　一旦找到合适的测试模式，它可能就是你的“敏捷”模式。51Testing软件测试网.sIND^o5\

版权声明：本文出自 lyfi2003 的51Testing软件测试博客：http://www.51testing.com/?31275251Testing软件测试网5^bm-rY
cQ i