微软的软件测试方法(续1)

   我以前做无线产品的产品类测试，现在做J2EE的项目类测试。在产品类测试中，几乎所有既定计划完成后的时间都可以用来找缺陷，因此也没有Bug大扫除的说法。不过做项目类的测试就不一样了。项目测试中每个人员所受到的进度和成本的压力和不平衡的问题要超过产品测试。因此，我暂时叫它“随机测试”。这2个之间的区别肯定会有，甚至有时候很大。另一方面，做项目时，测试人员和客户的软件水平参差不齐、相差很大。要让他们理解测试是需要使用不同的语言的。相对来说，“随机测试”更容易理解。经常遇到的情况是，项目开发进度Delay、Bug来不及改，因此出现测试可用时间不充分的风险，这是基本上无法组织“随机测试”。开发和修正效率较低时，往往会增加测试的成本，此时还会出现成本超支，无法组织“随机测试”的现象。在项目类测试中，缺陷发散的问题所带来的压力要远比产品类的大。客户多半都能看到缺陷的情况，而且很多客户都会直接问基层员工：“这么简单的一个问题为什么现在才发现？为什么不修正？为什么要这么长时间来修正？”。这样一来，本身进度和质量压力已经很大的项目组，受到这么一折腾，很可能会“爆掉”。这个是公司所不愿看到的。我们目前的做法是：无论是随机测试的问题，还是其它测试的问题，只要它没有被正确Closed，那么都需要测试和开发Manager进行沟通，相关测试和开发人员陈述意见和建议。如果Manager之间还不能解决，那么问题要上升到类似CCB的组织进行裁决。一般这个时间是在做最后一轮测试前，也就是上线前一段时间。已经正确Closed的问题，谁都不会去纠缠

TL_geong,感谢你提供了一些项目开发的经验，确实它与产品开发有一些不同。这里我有些疑问向你请教：首先，你们为什么把“随机测试”放在最后，等几乎所有既定计划完成后才进行？难道是认为“随机测试”不如“既定计划测试”重要？根据我的经验，很少有项目会在后期阶段有所谓的空余时间来做些随意性的工作。放在最后有时间再做，结果往往是取消或者草草了事。我们认为一类，二类测试是同等重要的，第二类测试对于验证第一类测试的覆盖性起很大的作用（没有哪种工具能取代），第二类测试若发现大量真正的Bug，那第一类测试的原先设计和计划就一定要相应调整。所以微软会在每个理程碑都有“Bug Bash”，而不是把它放在最后。我感到把“随机测试”放在最后就像一场赌博，赌你们的测试计划很完备周密。若不是这样，最后，一场成功的“随机测试”会给你揭露出一大堆问题，而恰恰这时，项目交货的日子到了。该如何收拾这场残局呢？要知道这还不是最坏的结局。最坏情况是你们最后没有机会做“随机测试”，或做了但不成功，结果那一大堆Bug溜到了你们的客户手中。这对你们或你们的用户支持将是一场灾难。第二个问题是，你们为什么会把缺陷发散的压力加在基层员工身上？难道当初的测试计划没有经过大家审查吗？如果经过了大家的审查，即使有不周全，甚至范了低级错误也不应该由个人承担。第三个问题是关于你提到的CCB组织，这是个上层权利部门吗？在微软，Bug命运由测试部门作主，若开发和管理不服，一般会请市场部门或客户支持部门提供进一步的信息，因为他们更接近客户

     微软的软件测试方法（二）我在前一篇“微软的软件测试方法”中介绍了微软的两类基本测试方法，其基本思想大家应该是比较熟悉的，因为它们还只是传统的软件测试方法的综合。所以单从形式上，它并没有体现出对传统框架的突破。但是从另一个层面来考察微软软件测试时，你会对一些基本的事实感到惊讶。比如，“微软的测试人员和开发人员数量大致相等或略多”，“微软的产品成本中测试大约占40%以上”等等。人们会有疑问，仅仅是作为功能验证和搜寻Bug的测试能消耗这么大量的资源吗？有必要付出如此大的代价吗？应该有理由相信，微软作为一个软件企业，其每一份投入都是有意义的，因此也可断定微软在软件测试方面的努力一定超出传统测试方法的范畴。历史回顾为了更好的理解微软件测试在方法和理念上的突破，我想首先回顾一下软件开发和软件测试的发展历史，并从中揭示其必然性。Edward Kit在他的畅销书“Software Testing In The Real World : Improving The Process（1995，ISBN: 0201877562）”中将整个软件开发历史分为三个阶段：第一个阶段是60年代及其以前，那时软件规模都很小、复杂程度低，软件开发的过程随意。开发人员的Debug过程被认为是唯一的测试活动。其实这并不是现代意义上的软件测试，当然一阶段也还没有专门测试人员的出现。第二个阶段是70年代，这个阶段开发的软件仍然不复杂，但人们已开始思考开发流程问题，并提出“软件工程Software Engineering”的概念。但是这一阶段人们对软件测试的理解仅限于基本的功能验证和Bug搜寻，而且测试活动仅出现在整个软件开发流程的后期，虽然测试由专门的测试人员来承担，但测试人员都是行业和软件专业的入门新手。第三个阶段是80年代及其以后，软件和IT行业进入了大发展。软件趋向大型化。与之相应，人们为软件开发设计了各种复杂而精密的流程和管理方法（比如CMM和MSF），并将“质量”的概念融入其中。软件测试已有了行业标准（IEEE/ANSI），它再也不是一个一次性的，而且只是开发后期的活动，而是与整个开发流程融合成一体。软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。测试与开发的融合在这一历史发展过程中，最值得注意的是测试与开发流程融合的趋势。人们对这种融合也许并不陌生。比如测试活动的早期展开，让测试人员参与用户需求的验证，参加功能设计和实施设计的审核。再比如测试人员与开发人员的密切合作，随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。的确这些都是测试与开发融合的表现形式，而且初期的融合也只反映在这个层次上。90年代以后，软件的规模和复杂程度迅速提高，这种形式上的融合也迅速走向更深层次，更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。在微软，测试的确有这样的地位和作用。这就是为什么微软在软件测试上有如此大的投入。开发对测试的依赖现代软件开发，特别是大型软件开发通常会遇到以下两个问题：（1）在开发初期，如何能够展开大规模团队，群体齐头并进，而同时保持开发的有序性。从而有效利用资源，缩短开发周期。（2）在开发后期，如何解决深层次的Bug，如何面对设计更改，而能够保证产品的质量不出现或少出现回落。对于小型简单的软件，这两个问题也存在，但不突出，而且容易解决。但对于复杂的大型软件的开发，这两个问题常常会成为难以逾越的障碍。通常大型项目的功能丰富，但架构、层次也会相当复杂。稳妥的开发方式是，一次投入少量的人员，逐层开发，逐层稳定。但这种方式显然资源利用率低，开发周期长，不能满足现代软件和IT行业高速发展、瞬息万变的需要。因此大型项目需要大型团队。在微软，产品开发团队（主要包括开发、测试和项目管理）一般都有百人以上规模，有些产品甚至上几千人（Windows2000的开发部门曾有3000多人）。这样大规模的人力资源作用在一个动态的，内部相互联系的系统中，若没有有效的协同，其混乱是不可避免的。试想，有两个开发人员，分别在开发两个不同的功能模块，其相互有依赖关系。为了相互协调，他们可以随时进行当面讨论。如果这种关系发生在五个开发人员和五个功能模块之间，这种协调就只能通过定期的会议来进行。而一个大型项目，会有许许多多这样的关系，而且很多时候这种关系有着不确定性和不可预见性。当一个开发人员编写一段新的代码或对已有代码进行改动和调整时，他（或她）常常无法确定，或无法完全确定究竟有哪些相关的模块会受到影响，以及在什么请况下这种影响会带来什么结果。因为系统的复杂性已远远超出了人的逻辑思维、技能和经验所能力及的范畴。因此这种传统的协调手段是远不能满足需要的。在微软，这种协调是通过测试来实现的。具体来说就是：每日建造+自动化测试。关于每日编译和自动化测试，我将来会作专门介绍，这里简单的说就是每天都建造一个新版本，每个版本都要运行通过一定量的自动测试用例，以检验当天工作的质量。这里所说的质量当然有一般意义上质量的概念，但同时它也反映项目在开发过程中的整体协调性。自动测试的最大优点在于它的高度可重复性。一个理想的自动测试系统能够让人随时、方便和迅速的运行大量的测试用例。因此一个开发人员可以通过检查当天的自动测试结果来分析前一天代码的质量（事后检查），也可以在当天存入代码前，先运行自动测试以进一步确保存入代码的质量（事前检查）。在微软，每日建造都是在午夜开始，完成后紧接着就是全面的自动测试，到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过，开发人员则必须协同测试人员一起立刻找出原因，解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败，很大一部分开发团队会受到影响。为尽量避免这种情况，要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试，全部通过后在存入。如开发人员没有按照这样的要求，而擅自存入质量不高的代码而造成大量测试失败，这种不负责任的行为是要受到严厉批评的。从这一过程可以看出，开发人员依赖测试来保证开发工作的质量，使开发整体地协调地向前推进。