软件质量控制实践――Microsoft篇(1)

因为工作在微软的缘故，无论我在给国内企业做软件测试内训的时候，还是在质量技术大会上做演讲的时候，问的最多的一个问题就是：微软如何做测试的？前几天看见有人在新浪微博上讨论是否需要专职QA，再有我刚刚决定带领两个google在西雅图的测试工程师一起翻译google的新书《howgoogletestssoftware》。微软以前也有一本书《howwetestsoftwareatmicrosoft》。所以几件事情碰到一起，有感而发，决定写一个“xx公司如何测试的”系列文章。目的不是为了回答以上问题，旨在通过分析对比如Microsoft,Google,Amazon,Facebook等在保证产品质量的诸多具体实践，和大家分享一下我个人认为这些公司在保证软件质量中的最为关键的几个实践和经验。希望大家有所收获和思考。我们今天先谈谈微软在提高软件质量上有哪些值得学习和借鉴的经验：

1.Evolvingtestrole

微软的正式测试工程师可以追溯到1990年左右，以后以每年大概500人递增。现在大概有1万左右的测试工程师。回顾走过的20多年，其中最为明显的特征就是微软对软件测试和质量控制的认识不是一成不变的，而是随着经验的积累，产品的演变不断演变，同时测试工程师的职责也不断在演变。最开始叫softwaretestengineer(STE)，主要职责是设计测试用例，手工黑盒测试。2000年左右演变成SoftwareDesignEngineerinTest(SDET)，主要职责是设计测试用例，开发测试自动化代码，测试基础设施和测试工具。同时把繁琐的简单的手工测试外包给印度和中国的外包公司。2005年以前公司的测试文化基本上是：产品质量是测试人员的责任，测试人员保证产品质量，测试人员很多时候像给开发打下手为开发服务。2005年后随着敏捷和软件及服务的出现，测试的角色逐渐从依赖测试来提高产品质量转变成用测试来建立保证产品质量的具体要素。测试不再像给开发打下手，而是转变成一个独立的岗位为产品质量服务。2010后，随着软件即服务和云计算的日趋成熟，微软很多产品组转向开发服务型的产品，同时测试人员的角色为了适应新的挑战而继续演变，比如现在很多组开发也做测试，测试也??开发，两者间的界限越来越模糊。正是测试的这种灵活性和对不同时期不同产品的适应性使得每个发布产品的质量得以有效保证。

2.Setfull-timetestrole

微软的产品一直以桌面产品为主，比如Windows,Office,SQLserver,etc…。这些类型的产品的共同特点就是对发布版本的质量要求非常非常高，它要求产品在发布之前必须修复几乎所有的bug，至少不可以有关键性bug。因为万一漏掉一个关键性的bug，召回产品或发布热修复的代价太大。所以每个产品组在产品开发过程中投入大量的测试人员来全方位，反反复复测试，包括功能测试，性能压力测试，本地化国际化测试，安全性测试，使用性和兼容性测试，等等。这些大量繁重的工作不可能都有dev来做。有了专职的测试人员不仅大大减轻了开发人员的工作量，而且通过测试人员特有的、经过专门训练的技能可以在产品发布之前找出更多、更为关键的bug。所以在这种情况下，专职测试人员不仅是有用的而且是必须的，他们对提高软件质量起到至关重要的作用。在像windows和office这两个最大的产品组，专职测试人员的数量和开发一样多，再加上大量外包公司的测试人员，可以说测试人员的数量实际上是开发的将近两倍。但是，如前所述，随着从桌面产品逐渐转向服务型的产品（软件即服务），专职测试人员的作用在逐渐下降。主要原因是：首先产品质量不再是光光通过“测试”来提高了；其次对发布版本质量要求有所降低，因为服务型产品不是安装在用户机器上而是部署在微软自己的数据中心里，如果有bug，开发人员可以很快修复然后及时更新产品（而不是像桌面产品需要召回），所以热修复的成本大大降低了；还有就是利用用户来做测试（我们在下面会具体再谈）。所以在服务型产品中，专职测试人员的作用不再像以前那样显得至关重要。微软现在许多组在削减测试，或者转成dev，即使保留测试的头衔，做的工作也不是严格意义上的测试了。另外一点值得说明的是，虽然专职测试人员数量有所减少，但是并不意味着测试的覆盖率就一定减少了。很多时候实际上是测试的覆盖率更多了，这主要是因为开发做越来越多的测试，同时测试的效率提高。

3.Heavilyinvestintestautomation

测试自动化不是万能的，但是没有测试自动化是万万不能的。测试自动化可以把测试人员从枯燥重复的手工测试中解脱出来做更多更有有技术含量的工作。当然测试自动化需要前期投入，而且不稳定的测试自动化还会把测试人员拽到疲于维护的泥潭中。但是这不是否定测试自动化的理由。没有用好测试自动化并不代表它没有用。而且，敏捷测试，持续集成，快速交付，等等都是以测试自动化为基础的。公司可以根据具体情况采用逐步提高的策略，比如先自动化每日构建，再自动化部署，然后自动化最关键的测试用例，次关键的测试用例，等等。微软测试工程师有超过80％的时间是在写测试代码。它们包括测试自动化代码，开发基础设施代码以及开发测试工具。默认情况下自动化所有测试用例，除非你有合理的理由不自动化。我个人的准则是：如果手工重复运行一个过程超过3次，就是时候自动化了。通常在一个发布周期的计划阶段，PM,dev，test,根据本次发布的时间长短和内容各自做计划，然后汇总讨论，制定一个最终的符合各个角色的发布计划。Pm和dev决定本次发布中的产品新功能，测试决定本次发布中的测试有关的工作量，比如为新功能而添加的测试自动化，为修改现有功能而修改测试，需要开发或改进的测试工具或基础设施。经过讨论后大家一致同意最终计划。计划好后，大家就根据各自的计划并行工作，当然中间大家及时沟通进度，如果需要，调整计划。这个过程的好处是把与测试自动相关的所有工作都放到开始项目计划中来，包括新功能测试自动化，现有代码的维护，工具的创建和改进等等，这不仅逐步提高测试自动化覆盖率，而且使得基础设施和测试工具逐渐成熟和完善。成熟和完善的设施和工具同时极大提供了开发效率和速度，比如大部分产品组都有dailyexecution和checkinqualitygate：

×Dailyexecution:每天晚上，自动生成每日构建，自动部署到测试环境，自动运行测试用例。对于失败的测试用例，系统自动报bug,并且对测试日志和产品日志进行自动分析，把相关信息放到bug中。最后自动发送测试结果到整个组。第二天早上到办公室，每个人都会看到已经运行完的测试报告。这使得测试可以有更多的时间自动化更多的用例，更多的时间分析测试缺口或做探索性测试。

×Checkinqualitygate:开发在提交代码之前通过运行一个简单命令可以把相关测试自动运行一遍。这使得开发从一开始就提交高质量的代码。

即使在做手工或探索性测试，测试工程师也尽可能使用测试工具来自动化其中步骤，从而使得测试人员完全专注于应该专注的地方，比如思考探索尝试，而不是在别的地方浪费时间，比如准备测试数据，搭建测试环境，分析日志，报bug等等。打个简单的比喻，比如你要从北京到上海开会，手工测试就好像你骑自行车过去，你的目的是开会但是你结果把大量时间浪费在路上了。测试自动化就好像你乘飞机过去。还有看起来来好像飞机票很贵，成本比骑自行车要大，但实际上最后骑自行车的成本要高的很多。只不过很多成本你当时看不到罢了。

所以很多我给做培训的公司的经理抱怨说我们也想做单元测试，做测试自动化，但是就是成本负担不起。我就说你只看到“做”的成本，因为它很直接；而看不到“不做”的成本，因为你不能马上看到。业界无数公司，项目已经证明在单元测试和测试自动化在提高软件质量方面“不做”的成本要比“做”的成本大的多得多。

软件质量控制实践――Microsoft篇(2)

4.Drivequalityupstream

我们都知道bug越是滞后发现，修复的成本越高。据微软统计，如果产品发布以后需要发布一个热修复，它的直接成本是150万美元（间接成本在200万美元），而在发布之前的一个月发现的话，修复成本是5万，设计阶段修复成本是1千，需求阶段修复成本是1百。在需求分析阶段，测试人员主要职责就是验证需求分析的可行性和可靠性。PM和DEV的共性是易于乐观，倾向于把实际情况简单化，所以会作出很多假设。比如用户肯定不会这么使用，用户肯定知道如何用，所有用户的环境肯定都有该配置。但是实际情况下总会有用户不知道如何用，总会有用户会不按“预先设计”的方式使用，总会有用户环境没有该项配置。所以测试人员的主要职责就是找出这些假设并提出疑问并加以验证。

在dev设计阶段，测试人员需要验证设计，同样找出dev的假设然后疑问这些假设是否合理，看看该设计是否处理很多没有预料的但是有可能会发生的情况，比如用户输入特殊字符，非常规操作，非常规流程，机器重启，死机，数据库连接中断，网络中断，内存耗尽等等。除了验证设计是否处理非正常情况外，测试人员的另外一个更为重要的职责是验证设计的可测试性。可测试性是指测试软件容易的程度。软件的可测性对于提高软件的质量至关重要。道理很简单，如果你的软件很难测试，无从下手，测试一个用例需要几个小时甚至几天的话，你的软件质量也就无从保证。提高软件可测试性通常的做法是把软件模块化，松耦合，模块内部运行状态可见，模块内部运行分支可控制。在评审一个设计时通常问的问题是该如何测试该模块，是否容易测试它，能不能单独测试它。如果不可以的话，需要重新考虑设计。因为一个设计的很容易测试的模块和产品可以使得后期的测试代价大大降低。微软大部分复杂系统都会有一个“one-box”版本，该版本是个假的模拟系统但是拥有真正系统的几乎所有功能，它可以运行在任何机器上。系统的绝大部分功能都可以在该模拟系统上快速方便验证。我在培训的时候很多学生问??他们在后期测试的时候遇到许多无法测试或者很难测试的困境，问我该如何解决。在具体了解困难和困境之后，我发现他们的测试策略非常单调，只能把产品部署到有限的测试环境下从用户界面上做端到端的测试。如果想测试某个特定模块或功能需要好几个其它模块配合起来才可以。我就坦率的说如果你的软件是这么架构设计的话而且已经到了这一步，世界上没有人可以解决你现在面临的困难。因为看起来好像你是卡在现在这一步了，但实际上根本问题是在前期，在需求或设计。就像解决河流的水质污染问题，你在下游无论多大的代价也只能稍微改善，解决问题的根本方法是在解决上游的污染源。或者像隔靴挠痒，隔着厚厚的靴子无法挠到关键地方，必须能够把靴子脱掉直接挠。

5.Gettingbettereveryday

软件测试的目的一个是找出bug,另外一个是衡量软件的质量。通过测试来了解产品哪些地方薄弱，哪些地方不稳定.通过监控测试的结果，包括功能测试，性能压力测试，安全测试，本地化测试，容错测试等等来反映当前软件的质量。这也是持续集成的一个重要原因，它一方面短期迭代，另一方面可以在最短的时间内知道软件的质量，同时跟踪软件质量重开始到发布，软件质量的变化曲线。衡量软件质量的通常指标有：测试用例通过率/趋势，bug数量，种类/趋势，代码覆盖率等等。另外测试在开发周期中通常做的其它工作还有：bugrootcauseanalysis,Buganalysis,Testcasefailureanalysis,testgapanalysis,Bugtalk,bugshare,CCSdataanalysis等等。这一方面促使产品质量逐渐变好，而且是看得见的好。另外也促使自己放下繁忙的工作静心思考一下，如何更有效率更进一步提高质量。

6.Engineeringagility

随着软件即服务和云计算的兴起，它们给开发管理，质量管理，运营管理等提出了很多新的挑战。以前那种保密开发测试2－3年再突然发布的策略无法适应互联网应用服务的要求，而是逐渐演变成快速开发出产品基本原型，然后就发布，根据用户反馈不断加以改进的方式。质量管理方面，基于服务的产品除了关注功能性能，还有其它特别重要的方面，比如scalability,highavailability,faulttolerance,disasterrecovery,etc..这些都是桌面型产品所没有的或不重视的。微软从2010年开始在很多组开始实践如何提高服务型产品的质量，比如Azure,Bing,etc…。其中最为根本的一点就是提高整个团队的敏捷度，团队能够跟的上快速迭代交付的节奏。这需要从产品设计上到测试自动化，工具，基础设施上得以保障。另外一个非常重要的实践就是TiP(testinproduction)或crowd-sourcedtesting.我们在前面谈到“drivequalityupstream”，也即是提前测试。testinproduction正好相反是“drivequalitydownstream”，也即是在产品环境中测试。传统的桌面产品发布之后就不再测试了。服务型产品，产品发布后继续测试。它的基本出发点是：无论投资多少建立测试环境用以模拟产品运行环境，测试环境和真正产品环境总会有不同。无论花费多大的代价做前期测试，都不可能找出所有的bug。所以无论在发布之前花费多大的代价做测试，在产品上线后总会发现新的bug。现在既然发布产品更新非常快和容易，为什么不干脆在真正产品环境中来测试，或者利用真正的用户使用真正的产品来测试（当然用户意识不到）。一旦发现bug,马上修复，马上更新。这不仅减轻了前期测试的投入，而且提高的测试效率。看看我们在测试环境中发现的bug有多少没有被认为是“真正”的bug就明白了。当然要做到testinproduction,需要很多具体的流程、技术，工具作为保障。不能影响用户的关键业务，不能让用户发现过于简单的bug。除了基本的测试自动化基础设施和测试用例外，常用的一些TiP技术有：A/Btesting,exposecontrol/slicingmodel,on/offfeatures,chaos-monkey,measuring/monitoring.

软件质量控制实践――Microsoft篇(3)

7.investontestengineer’scareer

无论产品使用何种方式保障质量，人总是最核心最关键的因素。提高软件质量有无数种方式和无数个因素，如果非要说一个最最重要的方式，那就是激发测试工程师的工作热情。Youcanonlyachieveaveragebyworkinghard,butpassionistheonedrivingtoexcellence.为了最大化激发测试工程师的潜能，微软为测试工程师设计一整套完善的职业发展计划。测试工程师主要有两个职业发展路线。一个是IndividualContributor(IC):不管人，管技术。另外一个是Manager:偏重于管人和项目。这两个路线没有好坏之分，因人而异。两个路线都是以技术能力为核心，也是加薪升职的最主要考虑因素。经理未必比个人挣钱更多，“Becomeamanagerisnotapromotion”。Youarepaidforwhatyoucover。”whatyoucover”就像长方形的面积，面积大小有长和宽同时决定。VP管的很多（长），但是深度有限（宽）。而技术大牛管的很少（长），但是很深（宽），所以两个长方形的面积大小差不多。这也就是为什么有些技术大牛一个人不管但是挣钱和VP一样多。下面是几个测试工程师常见的职位：

SDET－初级测试工程师，要求是：executor，如果有个问题需要解决，而且告诉你如何解决，你能够很好地把问题解决了。

SDET2－中级测试工程师，要求是：designer，如果有个问题需要解决，你自己找出办法去解决。

SeniorSDET－资深测试工程师，要求是：planner，你自己去发现问题，然后找出解决办法。

PrincipalSDET－首席测试工程师，要求是：thinker，能发现问题并且发现问题的共性，不仅解决问题而且避免问题出现。

对经理的要求也大致如此，除了技术上也要过硬外，还要求经理为手下的人尽可能创造机会以帮助他们成功。

另外微软鼓励测试工程师创造性思维，鼓励员工创建好的测试工具用来提高测试效率，好的想法也可以可以申请测试专利或发表论文，并且被邀请到国际性测试会议上做演讲。微软内部有一个测试工具库，有将近1万个测试工具。本人就有一个测试??具在微软内部50多个产品组广泛使用，我也多次做演讲，现在正opensource。

最后，我总结的测试工程师必须具备的硬技术能力：

至少一门编程语言，比如C++/C#/Java，最好也了解设计模式的基本概念，比如：open-closeprinciple,designtointerfaces,favoraggregationoverinheritance,encapsulate bypolicyandrevealbyneed,etc…

至少一个脚本语言，比如DOSbatch,powershell,perl

熟悉测试基础，比如功能测试，性能压力测试，安全测试，本地化测试。

基本测试技能，比如等价类划分，边界值分析，黑白盒测试，组合测试，基于模型测试，探索性测试等

Xml

P/invoke

Reflection

Threading

Codecoverageanalysis

Networkknowledge,suchasTCP/IP,HTTP,HTTPS,WCF

Faultinjection/dependencyinjectionandmocking

还有微软鼓励测试工程师takeresponsibility,makeadifference。鼓励员工在做好本职工作同时在某一项技术领域专的更深。比如前面提到的一些测试基础(testfundamentals)包含功能测试，性能压力测试，安全性测试，本地化测试，容错测试,TiP等等。可以鼓励测试团队的每一个人选一个领域去专研，把他培养成不仅是产品组里的go-toperson,而且成为公司内乃至更大范围的领域专家。这不仅对产品的质量有帮助，更是对员工本身职业发展的极大激励。工程师是一群特殊的人类，如果一直重复做一件事（比如本职工作），很容易厌倦失去兴趣；相反越是有难度，有挑战，有影响力的工作，越是激发工程师一定要搞定，做好的斗志和恒心，哪怕是没有任何报酬，不为别人，为的是自我价值的实现。英语里有句话：it’snotwhatyouhavetodomakeyousuccess,it’swhatelseyoudo.thatwillmakeadifference.所以不仅仅把本职工作做好（这是最低要求了），更进一步将会使你脱颖而出。“更进一步”不是指你的本职工作，也不是让你加班加点，而是指那些自己喜欢的可以实现自我价值，同时对产品质量有深刻影响的东西。没有人逼你做这些东西，你完全可以选择按部就班或平平庸庸。最后引用功夫熊猫里的一句话立志：It’snotaboutwhereyoucamefromorwhatyouwere,it’saboutwhatyouchoosetobe。所以，whatyouchoosetobe?

好了，关于微软的话题就此打住。感觉好像在写长篇小说，没完没了，越聊话题越多。:)

小结，英语里面有句话“littlestepsleadtobigchange”。我觉得这句话用来描述微软走过的测试路最恰当不过了。微软有几百个产品组，发布过几千个产品。很难有一个或几个因素决定产品的质量。但是上面几个是我个人认为是诸多因素中的几个至关重要的。微软是世界上最伟大的软件公司…..（没有之一）。尤其是在测试方面，微软的投资比其它任何公司都多，在软件测试理论和实践上绝对是首屈一指的领先者。微软就像一个健壮的中年人，而google像一个20岁的青年，facebook可能只是teenager。但是google,facebook这些公司起源于互联网应用服务，在互联网应用服务质量管理方面的确有很多出色的实践。所以下一次和大家探讨：提高软件质量实践――Google篇。

对测试的要求太高？

微软的软件质量控制实践三篇写完了，收到很多评论。不可能一一回答，所以在这里我挑几个评论最多的和有代表性的，和大家再多讨论一下。希望有所帮助。

在国内培训的时候经常遇到的一个说法：“（比如测试自动化，工具，流程）的确好处很多，但是它对测试的要求太高了”。刚开始的时候我很惊讶，第一次听到对测试要求太高的说法，后来听多了才慢慢意识到这才是问题所在。如果你认为国内的测试比国外落后N年的话，我觉得“对测试的要求太高了“的观念就是导致这个落后的根本原因。我一直在观察和对比国内外测试的区别，当然有技术上的，工具上的，流程上的区别等等，但是这些差别都只是表象，根本的差别是观念上的差别，也就是测试在研发中的真正角色。这个不是找到多少个bug的问题，也不是采用什么测试方法的问题，而是是否把测试做为支撑研发两条腿中的一条腿的问题。测试是一个专门的职业，和开发一样有不同级别。初级人员解决简单的事情，高级人员必须负责解决复杂，高难度的事情。这样才能形成一个完善的测试人员职业发展体系。很多测试经理一直很困惑说我们也在加大在测试上的投资，参加很多技术、流程、管理培训，但是效果都不好。原因就是我们不能总是希望通过学习一个技术，或一个工具来解决观念上的问题，当然没有效果。也容易跟风，刚学会手工测试，又要测试自动化了；刚学会测试自动化；又要ET了。刚学会ET，又要敏捷了。没有观念就没有主见。所以改变观念才是提高软件质量的根本途径。

2. Dev不愿意修改bug.

这是一个很多测试抱怨的问题：自己辛辛苦苦找到一个bug，开发却认为不是bug。或者更???令人气愤的是开发在没有沟通之前直接resolved as “by design” or “not repro”。这个情况通常在质量控制成熟度级别（1级或2级）较低的组出现较多。根本上解决的办法是提高整个组的成熟度级别，当然需要在很多方面加以提高，这个问题就随之而去了。可以使用以下几个策略：

首先这里牵涉到两个问题：一个是resolve as “not repro”的问题。很多时候dev resolve as ‘not repro’是因为bug本身不清楚没有足够的信息来判断或进一步investigate（当然他应该和你确认一下先）。所以测试在报bug是一定要记录足够信息。基本原则是当别人在看该bug是否有足够的信息来判断该bug是怎么回事或进一步investigate。我总结过一个好的bug描述应该是Concise,Accurate, Searchable, Entirety, 也就是 CASE 原则。可能你会觉得这需要太多的时间才能报一个bug了。的确是，但是总比你花了两天找到一个bug，花了10秒钟就把bug写完了，结果过两天dev resolve 成not repro强吧。另外就是自动报bug的工具，还有就是创建bug模板等都可以减少报bug的时间。

其次是’by design’的问题。很多时候测试不服气认为就是bug，但是开发不同意修改。我想借用一句话来说明我的观点：a good idea is not really good until it is accepted. 也就是说如果你不可以说服别人接受你的主意，再好的主意也没有用。同样的道理你认为的bug，如果不能说服别人，它也不是一个bug。或者bug只有在被修复时才是真正的bug。如果dev/test有分歧的话，通常PM负责一个功能，应该有PM做最后决定；如果没有PM的话，通常有整个team来决定。当然如果你非常肯定，可以继续找更多的理由来支持你的观点。但是最终如果还是不能说服别人的话，还是要服从team的决定，虽然我们常说真理往往掌握在少数人的手里，但是绝大多数时候都是少数人考虑不周。另外一点就是我们通常很少在是不是bug上有分歧，而是在什么时候修复上有分歧。这是另外一个话题了，需要考虑很多其它非技术因素了。

3. 如何做到自动报bug,并把相关的信息放到bug 里面.

我在comments里已经回答过了，就把它拷贝一下吧以是完整：我前面提到微软有很多工具来提高测试人员的工作效率，也就是说把时间花在需要专注的地方而不是在其他繁琐的地方浪费时间。其中一个好的实践就是自动报bug。其实整个过程比较直接：首先用来管理bug的工具应该会有API接口，所以可以使用工具来自动报bug。其次是添加分析处理工具，测试的出错信息比较容易获取，比如测试用例出错了，或者抛异常或者返回错误结果，可以容易地把异常信息或错误信息放到bug里面；分析产品的日志找到错误点有写难度，需要和dev共同努力把测试日志和产品日志通过某些属性（时间戳或操作id）关联起来。或者简单地把相关日志、windows event log,等拷贝到network share，在bug中指向该路径即可。还有对于UI测试，如果测试错误，一定要把当时的屏幕截图抓下来放到bug中去。还是那句话，专注于应该要专注的地方而不是把时间浪费在其它步骤上了，测试用例出错，不应该花太多时间去报bug （最多2分钟）。同样道理有了bug后dev可以直接去investigate，而不是花时间去找日志在那里？那里出错了？等等。有条件的产品组还可以进一步提高，比如工具自动报bug的时候可以到到数据库里根据异常或错误信息查找一遍看一看以前有没有类似的bug，或者做BI，这些信息对于将来的分析和决策非常有帮助，而且也可以帮助预防bug。