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

  7. invest on test engineer’s career 无论产品使用何种方式保障质量,人总是最核心最关键的因素。提高软件质量有无数种方式和无数个因素,如果非要说一个最最重要的方式,那就是激发测试工程师的工作热情。You can only achieve average by working hard, but passion is the one driving to excellence. 为了最大化激发测试工程师的潜能,微软为测试工程师设计一整套完善的职业发展计划。测试工程师主要有两个职业发展路线。一个是Individual Contributor (IC): 不管人,管技术。另外一个是Manager: 偏重于管人和项目。这两个路线没有好坏之分,因人而异。两个路线都是以技术能力为核心,也是加薪升职的最主要考虑因素。经理未必比个人挣钱更多,“Become a manager is not a promotion”。You are paid for what you cover。”what you cover”就像长方形的面积,面积大小有长和宽同时决定。VP管的很多(长),但是深度有限(宽)。而技术大牛管的很少(长),但是很深(宽),所以两个长方形的面积大小差不多。这也就是为什么 有些技术大牛一个人不管但是挣钱和VP一样多。下面是几个测试工程师常见的职位: SDET - 初级测试工程师 ,要求是:executor,如果有个问题需要解决,而且告诉你如何解决,你能够很好地把问题解决了。  SDET 2 - 中级测试工程师 ,要求是:designer,如果有个问题需要解决,你自己找出办法去解决。  Senior SDET -…


code coverage, what is for after all?

I was reading discussions on software testing code coverage. The discussion was dominated by what the code coverage number for unit test or overall test  are correct or desired. 40%, 60%, 80%, even 100%? some claims that google only requires 60%. some asked me what are code coverage number requirement in microsoft. as far as i know,…


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

4. Drive quality upstream 我们都知道bug越是滞后发现,修复的成本越高。据微软统计,如果产品发布以后需要发布一个热修复,它的直接成本是150万美元(间接成本在200万美元),而在发布之前的一个月发现的话,修复成本是5万,设计阶段修复成本是1千,需求阶段修复成本是1百。在需求分析阶段,测试人员主要职责就是验证需求分析的可行性和可靠性。PM和DEV的共性是易于乐观,倾向于把实际情况简单化,所以会作出很多假设。比如用户肯定不会这么使用,用户肯定知道如何用,所有用户的环境肯定都有该配置。但是实际情况下总会有用户不知道如何用,总会有用户会不按“预先设计”的方式使用,总会有用户环境没有该项配置。所以测试人员的主要职责就是找出这些假设并提出疑问并加以验证。 在dev设计阶段,测试人员需要验证设计,同样找出dev的假设然后疑问这些假设是否合理,看看该设计是否处理很多没有预料的但是有可能会发生的情况,比如用户输入特殊字符,非常规操作,非常规流程,机器重启,死机,数据库连接中断,网络中断,内存耗尽等等。除了验证设计是否处理非正常情况外,测试人员的另外一个更为重要的职责是验证设计的可测试性。可测试性是指测试软件容易的程度。软件的可测性对于提高软件的质量至关重要。道理很简单,如果你的软件很难测试,无从下手,测试一个用例需要几个小时甚至几天的话,你的软件质量也就无从保证。提高软件可测试性通常的做法是把软件模块化,松耦合,模块内部运行状态可见,模块内部运行分支可控制。在评审一个设计时通常问的问题是该如何测试该模块,是否容易测试它,能不能单独测试它。如果不可以的话,需要重新考虑设计。因为一个设计的很容易测试的模块和产品可以使得后期的测试代价大大降低。微软大部分复杂系统都会有一个“one-box”版本,该版本是个假的模拟系统但是拥有真正系统的几乎所有功能,它可以运行在任何机器上。系统的绝大部分功能都可以在该模拟系统上快速方便验证。我在培训的时候很多学生问,他们在后期测试的时候遇到许多无法测试或者很难测试的困境,问我该如何解决。在具体了解困难和困境之后,我发现他们的测试策略非常单调,只能把产品部署到有限的测试环境下从用户界面上做端到端的测试。如果想测试某个特定模块或功能需要好几个其它模块配合起来才可以。我就坦率的说如果你的软件是这么架构设计的话而且已经到了这一步,世界上没有人可以解决你现在面临的困难。因为看起来好像你是卡在现在这一步了,但实际上根本问题是在前期,在需求或设计。就像解决河流的水质污染问题,你在下游无论多大的代价也只能稍微改善,解决问题的根本方法是在解决上游的污染源。或者像隔靴挠痒,隔着厚厚的靴子无法挠到关键地方,必须能够把靴子脱掉直接挠。           5. Getting better every day 软件测试的目的一个是找出bug,另外一个是衡量软件的质量。通过测试来了解产品哪些地方薄弱,哪些地方不稳定. 通过监控测试的结果,包括功能测试,性能压力测试,安全测试,本地化测试,容错测试等等来反映当前软件的质量。这也是持续集成的一个重要原因,它一方面短期迭代,另一方面可以在最短的时间内知道软件的质量,同时跟踪软件质量重开始到发布,软件质量的变化曲线。衡量软件质量的通常指标有:测试用例通过率/趋势,bug数量,种类/趋势,代码覆盖率等等。另外测试在开发周期中通常做的其它工作还有:bug root cause analysis, Bug analysis, Test case failure analysis, test gap analysis, Bug talk, bug share, CCS data analysis等等。这一方面促使产品质量逐渐变好,而且是看得见的好。另外也促使自己放下繁忙的工作静心思考一下,如何更有效率更进一步提高质量。           6. Engineering agility 随着软件即服务和云计算的兴起,它们给开发管理,质量管理,运营管理等提出了很多新的挑战。以前那种保密开发测试2-3年再突然发布的策略无法适应互联网应用服务的要求,而是逐渐演变成快速开发出产品基本原型,然后就发布,根据用户反馈不断加以改进的方式。质量管理方面,基于服务的产品除了关注功能性能,还有其它特别重要的方面,比如scalability, high availability, fault tolerance, disaster recovery, etc.. 这些都是桌面型产品所没有的或不重视的。微软从2010年开始在很多组开始实践如何提高服务型产品的质量,比如Azure, Bing, etc…。其中最为根本的一点就是提高整个团队的敏捷度,团队能够跟的上快速迭代交付的节奏。这需要从产品设计上到测试自动化,工具,基础设施上得以保障。另外一个非常重要的实践就是TiP (test in production) 或 crowd-sourced testing. 我们在前面谈到“drive…

2

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

因为工作在微软的缘故,无论我在给国内企业做软件测试内训的时候,还是在质量技术大会上做演讲的时候,问的最多的一个问题就是:微软如何做测试的?前几天看见有人在新浪微博上讨论是否需要专职QA,再有我刚刚决定带领两个google在西雅图的测试工程师一起翻译google的新书《how google tests software》。微软以前也有一本书《how we test software at microsoft》。所以几件事情碰到一起,有感而发,决定写一个“xx公司如何测试的”系列文章。目的不是为了回答以上问题,旨在通过分析对比如Microsoft,Google, Amazon, Facebook等在保证产品质量的诸多具体实践, 和大家分享一下我个人认为这些公司在保证软件质量中的最为关键的几个实践和经验。希望大家有所收获和思考。我们今天先谈谈微软在提高软件质量上有哪些值得学习和借鉴的经验:  1. Evolving test role 微软的正式测试工程师可以追溯到1990年左右,以后以每年大概500人递增。现在大概有1万左右的测试工程师。回顾走过的20多年,其中最为明显的特征就是微软对软件测试和质量控制的认识不是一成不变的,而是随着经验的积累,产品的演变不断演变,同时测试工程师的职责也不断在演变。最开始叫software test engineer (STE),主要职责是设计测试用例,手工黑盒测试。2000年左右演变成Software Design Engineer in Test (SDET),主要职责是设计测试用例,开发测试自动化代码,测试基础设施和测试工具。同时把繁琐的简单的手工测试外包给印度和中国的外包公司。2005年以前公司的测试文化基本上是:产品质量是测试人员的责任,测试人员保证产品质量,测试人员很多时候像给开发打下手为开发服务。2005年后随着敏捷和软件及服务的出现,测试的角色逐渐从依赖测试来提高产品质量转变成用测试来建立保证产品质量的具体要素。测试不再像给开发打下手,而是转变成一个独立的岗位为产品质量服务。2010后,随着软件即服务和云计算的日趋成熟,微软很多产品组转向开发服务型的产品,同时测试人员的角色为了适应新的挑战而继续演变,比如现在很多组开发也做测试,测试也做开发,两者间的界限越来越模糊。正是测试的这种灵活性和对不同时期不同产品的适应性使得每个发布产品的质量得以有效保证。   2. Set full-time test role 微软的产品一直以桌面产品为主,比如Windows, Office, SQL server, etc…。这些类型的产品的共同特点就是对发布版本的质量要求非常非常高,它要求产品在发布之前必须修复几乎所有的bug,至少不可以有关键性bug。因为万一漏掉一个关键性的bug,召回产品或发布热修复的代价太大。所以每个产品组在产品开发过程中投入大量的测试人员来全方位,反反复复测试, 包括功能测试,性能压力测试,本地化国际化测试,安全性测试,使用性和兼容性测试,等等。这些大量繁重的工作不可能都有dev来做。有了专职的测试人员不仅大大减轻了开发人员的工作量,而且通过测试人员特有的、经过专门训练的技能可以在产品发布之前找出更多、更为关键的bug。所以在这种情况下,专职测试人员不仅是有用的而且是必须的,他们对提高软件质量起到至关重要的作用。在像windows和office这两个最大的产品组,专职测试人员的数量和开发一样多,再加上大量外包公司的测试人员,可以说测试人员的数量实际上是开发的将近两倍。但是,如前所述,随着从桌面产品逐渐转向服务型的产品(软件即服务),专职测试人员的作用在逐渐下降。主要原因是:首先产品质量不再是光光通过“测试”来提高了;其次对发布版本质量要求有所降低,因为服务型产品不是安装在用户机器上而是部署在微软自己的数据中心里,如果有bug,开发人员可以很快修复然后及时更新产品(而不是像桌面产品需要召回),所以热修复的成本大大降低了;还有就是利用用户来做测试(我们在下面会具体再谈)。所以在服务型产品中,专职测试人员的作用不再像以前那样显得至关重要。微软现在许多组在削减测试,或者转成dev,即使保留测试的头衔,做的工作也不是严格意义上的测试了。另外一点值得说明的是,虽然专职测试人员数量有所减少,但是并不意味着测试的覆盖率就一定减少了。很多时候实际上是测试的覆盖率更多了,这主要是因为开发做越来越多的测试,同时测试的效率提高。  3. Heavily invest in test automation 测试自动化不是万能的,但是没有测试自动化是万万不能的。测试自动化可以把测试人员从枯燥重复的手工测试中解脱出来做更多更有有技术含量的工作。当然测试自动化需要前期投入,而且不稳定的测试自动化还会把测试人员拽到疲于维护的泥潭中。但是这不是否定测试自动化的理由。没有用好测试自动化并不代表它没有用。而且,敏捷测试,持续集成,快速交付,等等都是以测试自动化为基础的。公司可以根据具体情况采用逐步提高的策略,比如先自动化每日构建,再自动化部署,然后自动化最关键的测试用例,次关键的测试用例,等等。微软测试工程师有超过80%的时间是在写测试代码。它们包括测试自动化代码,开发基础设施代码以及开发测试工具。默认情况下自动化所有测试用例,除非你有合理的理由不自动化。我个人的准则是:如果手工重复运行一个过程超过3次,就是时候自动化了。通常在一个发布周期的计划阶段,PM,dev,test,根据本次发布的时间长短和内容各自做计划,然后汇总讨论,制定一个最终的符合各个角色的发布计划。Pm和dev决定本次发布中的产品新功能,测试决定本次发布中的测试有关的工作量,比如为新功能而添加的测试自动化,为修改现有功能而修改测试,需要开发或改进的测试工具或基础设施。经过讨论后大家一致同意最终计划。计划好后,大家就根据各自的计划并行工作,当然中间大家及时沟通进度,如果需要,调整计划。这个过程的好处是把与测试自动相关的所有工作都放到开始项目计划中来,包括新功能测试自动化,现有代码的维护,工具的创建和改进等等,这不仅逐步提高测试自动化覆盖率,而且使得基础设施和测试工具逐渐成熟和完善。成熟和完善的设施和工具同时极大提供了开发效率和速度,比如大部分产品组都有daily execution 和checkin quality gate:  × Daily execution: 每天晚上,自动生成每日构建,自动部署到测试环境,自动运行测试用例。对于失败的测试用例,系统自动报bug,并且对测试日志和产品日志进行自动分析,把相关信息放到bug中。最后自动发送测试结果到整个组。第二天早上到办公室,每个人都会看到已经运行完的测试报告。这使得测试可以有更多的时间自动化更多的用例,更多的时间分析测试缺口或做探索性测试。  × Checkin quality…


any update on managed fault injection in testapi?

there is an issue with fault injection api in the latest testapi version (0.6). unfortunately the testapi project on codeplex doesn’t seem to be actively maintained any more. so i’m working on creating an new project on codeplex for managed fault injeciton only. the new project will have full functionality instead of the current limited version. before…

1