你的定位

　　测试早早已然不是为了发现产品的bug而存在了。

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

　　做什么事情

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

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

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

　　在集成阶段，用例提交（手工，自动化），开发同步参与用例的评审。检视自己代码是否有需求遗漏

　　系统测试中，重点是发散性测试，场景级测试，以及用户级测试。

　　Google模式好么？

　　本来开发测试不分家，这样20：1，甚至比0的情况都是可以的。

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

　　这么一来，理论上，顶级的开发人员就不需要多少测试人员，因为BUG会很少，测试起来也容易，版本发布当然快。

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

　　你的模式

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

　　我想，这是一个多大的创新，于此，我又相信wps的稳定性在未来会超出微软的办公套件了。

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

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

　　但一旦能力上去了，一定要往这个方向走。

　　需要敏捷么？

　　敏捷不算啥，更为直接的可以算是“持续交付”，达到这点其实非常easy：

　　1、以自动化为核心，一切工作皆自动化。

　　2、团队有共同的目标，遵循：先测试，后开发；保持主线clean；重构，测试，交付；

　　如果大家都是这样的理想主义，必然可以成功。

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

　　最后，无论测试成什么样，最终还是要看市场需求，借用一句话：“台风来了，是猪也能飞起来的”。

　　一旦找到合适的测试模式，它可能就是你的“敏捷”模式。

版权声明：本文出自 lyfi2003 的51Testing软件测试博客：http://www.51testing.com/?312752

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。