微软的测试方法

首先介绍，在业界有两种测试方法：
第一类测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的。
第二类测试方法则是设法证明软件是“不工作的”。

两种测试方法的利与弊：
第一类测试可以简单的视为：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。这一过程的终极
目标就是将软件的所有功能在所有设计规定的环境全部运行，并通过。
尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》）。他认为测试不应该着眼于验证软
件是工作的，相反应该首先认定软件是有错误的，然后去发现尽可能多的错误。而第二类方法认为软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。有
些软件企业以bug数量来作为考核测试人员业绩得一项指标。
第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情
况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。

微软的测试过程，分为两大类：
第一类测试是以需求和设计为本来验证软件的正确性：
第一步：验证需求和设计：
    这里的需求和设计具体来说它一般包括：：（1）由项目经理根据用户要求（信息来源于市场部门，用户支持部门等等）而编写的需求文本（Requirement Specification）
；（2）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（3）由开发人员根据功能文本而编写的实施设计文本（Implementation
Design Specification）。微软的测试人员要参与所有这些文本的审核。
   作为测试人员，审核重点是检查文档对用户需求定义的完整性，严密性和功能设计的可测性。（是他们尽早的进入技术＆业务状态）。

第二步：测试人员要根据已审核通过的需求和设计编制测试计划，设计测试用例。

第三步：实施运行测试是整个开发过程中最复杂的一个阶段。

 这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，总是先运行或执行
简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。因此随着项目开发和测试
的进程，产品的功能不断完善，质量不断提高。有一点要特别提出，就是很多测试要重复运行。特别是基本的自动化测试每天，每个build上都要运行。尽管大多数都是通过的
，很少有新的bug出现，这是防止质量回顾。
 在第三步实施的过程中，测试人员还有一个比较繁琐却很重要的工作就是维护自己testcase。比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计
不周全的领域，二是对于外部的Bug（比如从Beta客户报告来的），没有被现有测试用例所覆盖。

第二类测试
 微软的第二类测试是阶段性的，常常根据需要而带有随机性和突击性。对于这类测试，在微软有一个专门的名称：“Bug Bash（Bug大扫除）”。 Bug Bash通常发生在
项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽
全部智慧来搜寻项目的Bug。
 在微软还有“bug triage（测试，开发＆项目经理，三方会审）”的制度。对于每个Bug，经过会审后不外乎有以下三中归宿（总体上来说）： （1）被确认为“缺陷性”
Bug，这样的Bug必须交开发人员解决，然后由原发现人验证。 （2）被调整为非“缺陷性”Bug，不用开发人员作任何更改，但必须将问题纳入产品用户文档，明确向用户解释，
并告诉用户如何避免和应对。假象：产品的某个功能在系统内存严重不足的情况下，会暂停工作，并给很多不易被用户理解的警告信息。这显然是个Bug（按微软的标准），正
确的应该是，首先软件不应该完全停止工作，其次不应该多次警告，第三，警告信息应简明易懂，并给用户以措施和建议。但是考虑到，一方面这种情况在用户实际使用产品
时发生的机率很低，而另一方面，从开发角度，解决这个问题有很大的技术难度，影响面也太大。这种情况下会把这个Bug改为“文本性”Bug，也就是要求文本遍写人员将这一
情况作一技术性解释，并建议用户不要将此产品同其他消耗大量内存的软件同时使用。这类的Bug在Bug Bash中很常见，因为大家在这种测试活动中思维方式比较超常。1）类
Bug仍然很多，那测试部门很可能需要重新论证原先的测试计划和测试用例设计，看是否需要增加测试用例。

 这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员
甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益；（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug；（3）为调动积极性
，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。（4）可以分专题展开，比如安全性、用户界面
可用性、国际化和本地化等等。微软的第二类测试除了Bug Bash外，经常还有一些专业性的测试，最典型的是针对安全性攻击测试。

确定测试计划有这么几个依据：
 1）产品的功能。功能的量和复杂性直接影响测试的工作量；
 2）质量标准，有公司的标准、行业的标准、市场反馈的标准和客户要求的标准等；
 3）以往的经验，有以往的产品的经验，也有个人的经验。

http://blog.csdn.net/testwin/archive/2005/12/08/546692.aspx