要点：

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

两类方法的优劣对比
很明显这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。
第一类测试方法以需求和设计为本，因此有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于大型软件的测试，尤其是在有限的时间和人力资源情况下显得格外重要。
第二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点，走入歧途。
第一类测试方法的缺点是缺乏灵活性，不利于测试人员主观能动性的发挥，不容易找到软件的错误（Bug）。而这方面正是第二类测试方法的长处。

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

微软的第一类测试
微软的第一类测试总体上说分为三个步骤进行：审核需求和设计—〉设计测试—〉实施运行测试。
需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。因此验证需求和设计是微软进行第一类测试的第一步。
同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。
从测试的过程来看，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。
为了防止质量回归有很多测试用例是要反复运行的。

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

通常Bug Bash会产生超乎寻常数量的Bug。
一般我们认为，产生Bug的量越大越好。因为，如果产生Bug的数量少，你很难判断是因为产品的质量确实很高，还是Bug Bash做得不彻底。而且事实往往是后者。
但同时会造成收敛的缺陷趋势出现严重的发散现象。

那么对Bug Bash所产生的大量Bug该怎么办？
在微软，有“Bug Triage （测试，开发和项目管理，三方会审）”的制度。
对于每个Bug，经过会审后不外乎有以下三中归宿（总体上来说）：
（1）被确认为“缺陷性”Bug，这样的Bug必须交开发人员解决，然后由原发现人验证。
（2）被调整为非“缺陷性”Bug，不用开发人员作任何更改，但必须将问题纳入产品用户文档，明确向用户解释，并告诉用户如何避免和应对。
      考虑到，一方面这种情况在用户实际使用产品时发生的机率很低，而另一方面，从开发角度，解决这个问题有很大的技术难度，影响面也太大。这种情况下会把这个Bug改为“文本性”Bug，也就是要求文本编写人员将这一情况作一技术性解释。这类的Bug在Bug Bash中很常见，因为大家在这种测试活动中思维方式比较超常。
（3）被完全否定，立刻关闭，不再纠缠。
      这类的情况在Bug Bash中也很常见。因为参与Bug Bash人并不都很了解产品功能的准确用法，误报是难免的。尽管对这类问题没有直接的后续措施，但这些信息仍然是有一定价值的，因为将来用户中的新手很可能会犯同样的毛病，而产品支持部门如果预先有这样的经验，就能及时准确地提供帮助。所以这些信息要保存在Bug的管理库中，以备将来产品支持部门查询。
经过这样的会审，筛选，如果（1）（2）类Bug，特别是（1）类Bug仍然很多，那测试部门很可能需要重新论证原先的测试计划和测试用例设计，看是否需要增加测试用例。必要时还要尽早提出更改项目总体计划和发布日期。 大量Bug的出现也许不是件愉快的事，但和把这些Bug留给用户相比，代价要小得太多了。

一些基本的事实
微软的测试人员和开发人员数量大致相等或略多
微软的产品成本中测试大约占40%以上

历史回顾 
软件开发历史四个阶段：
第一个阶段是60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试，当然一阶段也还没有专门测试人员的出现。
第二个阶段是70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出“软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。
第三个阶段是80年代及其以后，软件和IT行业进入了大发展。软件趋向大型化。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。
第四个阶段是90年代以后，软件的规模和复杂程度迅速提高，测试与开发流程的融合也迅速走向更深层次，具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。在微软，测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。

在微软，产品开发团队（主要包括开发、测试和项目管理）一般都有百人以上规模，有些产品甚至上几千人（Windows2000的开发部门曾有3000多人）。这样大规模的人力资源作用在一个动态的，内部相互联系的系统中，若没有有效的协同，其混乱是不可避免的。试想，有两个开发人员，分别在开发两个不同的功能模块，其相互有依赖关系。为了相互协调，他们可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间，这种协调就只能通过定期的会议来进行。而一个大型项目，会有许许多多这样的关系，而且很多时候这种关系有着不确定性和不可预见性。当一个开发人员编写一段新的代码或对已有代码进行改动和调整时，他（或她）常常无法确定，或无法完全确定究竟有哪些相关的模块会受到影响，以及在什么请况下这种影响会带来什么结果。因为系统的复杂性已远远超出了人的逻辑思维、技能和经验所能力及的范畴。因此这种传统的协调手段是远不能满足需要的。
在微软，这种协调是通过测试来实现的。具体来说就是：每日建造+自动化测试。
关于每日编译和自动化测试，这里简单的说就是每天都建造一个新版本，每个版本都要运行通过一定量的自动测试用例，以检验当天工作的质量。
全面的自动测试，到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过，开发人员则必须协同测试人员一起立刻找出原因，解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败，很大一部分开发团队会受到影响。为尽量避免这种情况，要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试，全部通过后在存入。如开发人员没有按照这样的要求，而擅自存入质量不高的代码而造成大量测试失败，这种不负责任的行为是要受到严厉批评的。
从这一过程可以看出，开发人员依赖测试来保证开发工作的质量，使开发整体地协调地向前推进。

开发对测试的这种依赖性对测试和测是人员提出了更高的要求。
在理念上，软件测试已远不仅仅只是软件功能的验证和Bug的搜寻；
在具体方法上，自动测试和测试工具的使用已成为基本的要求。

一个软件企业要提高其软件开发的能力，特别是针对大型软件的大规模的快速开发能力，在测试方面对传统理念和方法进行突破是必要的。

---

原文全文：http://www.51testing.com/?157364/action_viewspace_itemid_90429.html