微软的软件测试方法

这里的“技术”指的是具体的战术问题，比如说如何使用某种工具来解决某一特定测试问题，或者某一类型软件有哪些测试手段等等。而这里的“方法”指的是宏观的战略问题，或者叫方法论，这包括从软件测试的概念或理念，到企业软件质量控制体系；从软件测试的过程，到测试团队的设置及其职责的界定等等。

　　作为测试人员，热衷于“技术”讨论和交流是一件可喜可贺的事。从中可以感觉到软件测试在中国迅速发展的开端和潜力。但是作为企业的管理决策者，是否也应该以同样的热情来思考“方法”问题呢？特别是当一个软件企业的软件测试从无到有，或者当企业已有一定的软件测试的投入，但发现其实效并不显著，甚至由于测试的引入而带来了新的管理上的混乱。

　　这个时候方法论的思考，更有利于发现问题的根源。

　　即便是一个基层的测试人员，当积累了一定的技术经验后，也应该不时从日常的具体工作中走出来，在一个较高层次上进行回顾总结和借鉴，并试着提出一些优化和改进的措施，这无论对专业上还是对事业上的成长都是非常有意义的。微软在软件测试方面有很多值得一提的经验，在此我想以我个人的体会和思考，同大家一同进行一些探讨。

　　这里有一点须要特别说明，尽管微软的方法已被微软的实践多次证明是成功的，非常有效的，但这并不意味着这些方法在中国的软件企业中有广泛的可行性。一种方法是否可行还受到很多其他因素的影响，比如企业类型（微软是生产平台软件和通用软件产品的企业），企业管理体制，企业文化等等。所以我的目的只是给大家一些思路和借鉴。

　　两类经典的软件测试方法

　　在具体介绍微软的软件测试方法之前，我想首先从概念，或理念的层面上来理解究竟甚么是软件测试，目的是从中导出微软测试方法的理论根源。

　　传统上认为软件测试方法从总体上分为两类。

　　第一类软件测试方法是试图验证软件是“工作的”，所谓“工作的”就是指软件的功能是按照预先的设计执行的；而第二类测试方法则是设法证明软件是“不工作的 ”。

　　提出第一类方法的代表人物是软件测试领域的先驱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数量来作为考核测试人员业绩的一项指标，其实就是接受了这样的方法。

　　两类方法的优劣对比

　　虽然软件测试总的目的是为了软件产品的质量，但很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。

　　第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。而第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。

　

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