微软是怎么做软件测试工作的？(2)

　　第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥，正像Myers先生所说，不容易找到软件的错误(Bug)。而这方面正是第二类测试方法的长处。

　　微软的策略

　　正是因为认识到两类测试方法各有利弊，微软在软件测试活动中将两类方法结合起来，以第一类测试方法为基础和主要线索，阶段性地运用第二类测试方法。

　　微软的第一类测试

　　微软的第一类测试总体上说分为三个步骤进行：审核需求和设计—〉设计测试—〉实施运行测试。

　　前文已述，第一类测试是以需求和设计为本来验证软件的正确性。大家很自然的想到，需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。因此验证需求和设计是微软进行第一类测试的第一步。

　　有必要指出的是，这里所说的需求和设计具体说来它一般包括：

　　由项目经理根据用户要求(信息来源于市场部门，用户支持部门等等)而编写的需求文本(Requirement Specification);

　　由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);

　　由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)。

　　微软的测试人员要参与所有这些文本的审核。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。

　　第二步，测试人员要根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。原因很简单，这类测试关心的是软件是否能正确地实现功能，而不是这些功能如何被具体实施的。

　　从这里大家可以看出这是典型的“黑盒测试”。确实微软的测试主要是从用户角度进行的黑盒测试。

　　这一步的完成就意味着“测试计划”和“测试用例设计”两个文本的完成。“测试计划” 文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”文本要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文本也要被项目经理和开发人员审核。这样经过各种相互的审核，大家对项目形成了基本的共识。

　　第三步的实施运行测试是整个开发过程中最长最复杂的一个阶段。从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试程序、反复运行自动化测试程序，也包括阶段性执行手动测试用例。这一阶段的测试必须在周密的计划下进行，在前面我已提到，这正是第一类测试的特点和长处。

　　这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例;先验证单一的基本功能，再综合的端到端的功能;先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。因此随着项目开发和测试的进程，产品的功能不断完善，质量不断提高。

　　这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，但其价值是显而易见的，就是为了防止质量回归。

　　可见Myers的理论在这里是不适用的。这一阶段测试人员还有一项繁琐但却很重要的工作，就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖。当产品的功能设计出现更改时(在微软这是常事)，所涉及的测试用例当然也要相应地修改。

　　微软的第二类测试

　　微软的第二类测试是阶段性的，常常根据需要而带有随机性和突击性。对于这类测试，在微软有一个专门的名称：“Bug Bash(Bug大扫除)”。

　　Bug Bash通常发生在项目开发各阶段(微软叫里程碑)的末期，比如Beta版发布前，划出一个专门的时间段(通常1-3天)，在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。

　　这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：

　　尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益;

　　要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;

　　为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。

　　可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。

　　微软的第二类测试除了Bug Bash外，经常还有一些专业性的测试，最典型的是针对安全性攻击测试。一般会邀请公司内部，或业界的专家来搜寻产品的安全漏洞。

　　以上我从传统软件测试概念的角度，介绍了微软的策略和两类传统测试方法的具体做法，及其侧重点。这其实仅仅是一个基础，一个很原始的基础。多特有的做法，和概念上软件测试在微软软件产品开发中的作用、地位远不是这些原始的方法所能达到的，也不是传统软件测试概念所函盖的。微软在软件测试方面有很的突破，比如“软件测试的信息服务功能”、“以用户为中心的宏观质量体系”、“分级测试”、“项目的质量管理系统”、“Bug三方会审”、“测试自动化”和“软件测试的软硬件—部门、团队、人和基础设施”等等。这些我会在以后的讨论中分专题进行介绍。

　　_______________________

　　我在前一篇“微软的软件测试方法”中介绍了微软的两类基本测试方法，其基本思想大家应该是比较熟悉的，因为它们还只是传统的软件测试方法的综合。所以单从形式上，它并没有体现出对传统框架的突破。但是从另一个层面来考察微软软件测试时，你会对一些基本的事实感到惊讶。比如，“微软的测试人员和开发人员数量大致相等或略多”，“微软的产品成本中测试大约占40%以上”等等。人们会有疑问，仅仅是作为功能验证和搜寻Bug的测试能消耗这么大量的资源吗?有必要付出如此大的代价吗?

原文转自：http://www.ltesting.net