微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响，比如企业类型（微软是生产平台软件和通用软件产品的企业），企业管理体制，企业文化等等。所以我的目的只是给大家一些思路和借鉴。
两类经典的软件测试方法
在具体介绍微软的软件测试方法之前，我想首先从概念，或理念的层面上来理解究竟甚么是软件测试，目的是从中导出微软测试方法的理论根源。
传统上认为软件测试的方法从总体上分为两类。第一类测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的；而第二类测试方法则是设法证明软件是“不工作的”。
提出第一类方法的代表人物是软件测试领域的先驱Dr. Bill Hetzel（代表论著《The Complete Guide to Software Testing》），他曾于1972年6月在美国的北卡罗来纳大学组织了历史上第一次正式的关于软件测试的论坛。他首先在1973年给软件测试一个这样的定义：“就是建立一种信心，认为程序能够按预期的设想运行。Establish confidence that a program does what it is supposed to do. ”后来在1983年他又将定义修订为：“评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为。 Any activities aimed at evaluating an attribute or capability of a program or system. ”在他的定义中的“设想”和“预期的结果”其实就是我们现在所说的用户需求或功能设计。他还把软件的质量定义为“符合要求”。
第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行，并通过。
在软件行业中一般把第一类方法奉为主流和行业标准。1990年的IEEE/ANSI标准将软件测试进行了这样的定义：“就是在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程。The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component (IEEE/ANSI, 1990 [Std 610.12-1990]”这里所谓“既定的状况”也可理解为需求或设计。
尽管如此，这一方法还是受到很多业界权威的质疑和挑战。代表人物是Glenford J. Myers（代表论著《The Art of Software Testing》）。他认为测试不应该着眼于验证软件是工作的，相反应该首先认定软件是有错误的，然后去发现尽可能多的错误。他还从人的心理学的角度论证，将 “验证软件是工作的”作为测试的目的，非常不利于测试人员发现软件的错误。于是他于1979年提出了他对软件测试的定义：“就是以发现错误为目的而运行程序的过程。The process of executing a program or system with the intent of finding errors.” 这就是软件测试的第二类方法，简单地说就是验证软件是“不工作的”，或者说是有错误的。他甚至极端地认为，一个成功的测试必须是发现Bug的测试，不然就没有价值。这就如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的。我并不完全同意这一看法。
第二类软件测试方法在业界也很流行，受到很多学术界专家的支持。大家熟悉的Ron Patton在《软件测试》（ 中文版由机械工业出版社出版，具说此书是目前国内测试新手入门的经典教材）一书的第10页，有一个明确而简洁的定义：“软件测试员的目标是找到软件缺陷，尽可能早一些，并确保其得以修复。”有些软件企业以Bug数量来作为考核测试人员业绩的一项指标，其实就是接受了这样的方法。
两类方法的优劣对比
虽然软件测试总的目的是为了软件产品的质量，但很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。
第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。
第一类测试方法可以与软件的架构和软件开发的计划相配合，使软件测试活动逐层次的展开，从而使软件的功能和质量有计划地逐步完善和提高（关于测试的层次问题，我会在今后的讨论中专门介绍）。第二类测试方法不具备这种过程的渐进性。
第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥，正像Myers先生所说，不容易找到软件的错误（Bug）。而这方面正是第二类测试方法的长处。
这其实仅仅是一个基础，一个很原始的基础。软件测试在微软软件产品开发中的作用、地位远不是这些原始的方法所能达到的，也不是传统软件测试概念所函盖的。微软在软件测试方面有很多特有的做法，和概念上的突破，比如“软件测试的信息服务功能”、“以用户为中心的宏观质量体系”、“分级测试”、“项目的质量管理系统”、“Bug三方会审”、“测试自动化”和“软件测试的软硬件—部门、团队、人和基础设施”等等。这些我会在以后的讨论中分专题进行介绍