微软的软件测试策略

看了51testin论坛上 软件质量管理 精华板块中《微软的软件测试方法》一文，深有感触！原文链接地址：http://bbs.51testing.com/thread-39630-1-1.html

以下是自己整理的测试策略，微软作为全球软件行业的大哥，在管理上自有一套，很多都值得我们学习！

策略1：
总体上说分为三个步骤进行三大步骤：审核需求和设计—>设计测试—>实施运行测试
1.验证需求和设计：(1)由项目经理根据用户要求（信息来源于市场部门、用户支持部门等等）而编写的需求文本；(2)由项目经理根据需求文本而编写的功能设计文本；(3)由开发人员根据功能文本而编写的实施设计文本。测试人员要参与所有这些文本的审核。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。
2.测试人员要根据已审核通过的需求和设计编制测试计划，设计测试用例。。“测试计划” 主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文档也要被项目经理和开发人员审核。这样经过各种相互的审核，大家对项目形成了基本的共识。
3.实施运行测试是整个开发过程中最长最复杂的一个阶段。从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。因此随着项目开发和测试的进程，产品的功能不断完善，质量不断提高。这一阶段测试人员还有一项繁琐但却很重要的工作，就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时（在微软这是常事），所涉及的测试用例当然也要相应地修改。

策略2：
微软的测试是阶段性的，常常根据需要而带有随机性和突击性。对于这类测试，在微软有一个专门的名称：“BugBash（Bug大扫除）”。BugBash通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。
    微软的第二类测试除了Bug Bash外，经常还有一些专业性的测试，最典型的是针对安全性攻击测试。一般会邀请公司内部，或业界的专家来搜寻产品的安全漏洞。