提高软件质量实践――google 篇

很多人应该都看过James whittaker的博客或新书 《how google test software》,在这里我不想重复他的内容,而是从另外一个角度来分析对比google是如何保障它的产品质量的。  首先申明的是本人并没有在google工作过所以没有第一手的经验,仅以一个旁观者的身份来分析google的质量控制实践。主要信息来源于google测试博客,在西雅图google工作的朋友聊天和项目上合作,以及James的新书<<how google tests software>>。不过旁观者有旁观的优势,可以看见整个森林;相比较许多在大公司工作的工程师往往专注于一个产品或者一个团队,只看见了一颗树木J。不管如何,个人观点仅供参考。  我们前面在微软的质量控制实践中谈到,因为微软大部分的产品还是以桌面型产品为主,比如windows, office,sql server等等。桌面型产品的最大特定就是产品召回或发布热修复的成本太大,而且运行很多关键业务,这就迫使微软必须在产品发布之前投入大量人力物力来充分测试产品用以保障产品的高质量。与微软不同的是,google采用不同的策略来保证软件质量。在理解分析google的质量策略之前,我们必须了解google的采取该策略的根源: Google质量文化:google起源于校园。在有限的资金下,那时候创始人只能使用廉价的机器,把多个廉价的机器放在一起来提高处理能力。这些廉价的机器最大的问题是经常死机或报废,所以google在起始阶段就必须有很强的容错能力。也就是说在系统在部分机器死机或报废的情况下仍然可以提供服务。或者说,系统部分可以出错但是整个系统不可以宕机 (Graceful Degradation)。Google这个从一开始因为被迫置入的高容错能力反而成就了现在他们运行在数据中心上的服务的巨大优势。我们知道通常硬件的出错概率大概在万分之一,如果有一万台机器,其中一台出错概率就达到百分之百。在现在的数据中心里少则几万台,多者几十万台的机器。所以产品的容错能力已经不是可有可无,而是必须有的功能。所以google信奉的原则是单个模块可以出错可以有bug,它通过系统强大的容错能力来保障系统的整体高质量。 互联网产品:google是互联网公司成功的代表。互联网产品的最大特点就是“快”:产品定义快,开发快,反馈快,死掉的也快。所以为了有效利用有限的测试资源,google信奉的另外一个原则是:build the right it before you build it right.也就就是说只有确认了产品的确是用户需要的产品(build the right it)之后才开始提高它的质量(build it right)。道理很简单如果未知产品是否正确的情况下,没有必要浪费资源来提高它的质量。所以google的大部分产品测试人员介入较晚,开发人员不得不自己先测试以保障基本质量。  在理解了goolge对产品质量认识这两个根本出发点后,就不难理解google采用什么样的测试策略了: 1. Dev owns quality Google认为:谁写的的代码谁负责,谁开发的模块谁负责质量。所以开发在写代码的同时也要花很多时间测试,主要是单元测试和模块测试。Google坚信软件质量是先天就创建出来的,而不是通过后天测试测出来的。让开发做测试对产品质量负责不是件容易的事情,google通过主要三个途径:一是减少测试人员数量,所以开发不得不做测试;而是通过一些活动比如test certificate program来正面影响开发做测试;最重要的第三点是通过建立强大的完善的基础设施,使得开发很容易地写测试自动化很容易地运行测试。   2. Tester is to enable developer to test effectively 这个是对传统意义上的测试人员的职责非常大的改变。传统意义上的测试人员的主要职责是寻找产品中的bug。既然google要求开发对质量负责,当然就不太需要传统意义上的测试人员了。所以google中的测试更多时间是在开发测试自动化,开发测试工具,开发基础设施。相对花很少的时间做真正意义上的测试了。所以后来干脆把测试部门从原来的“Test Service”改名子为“engineering productivity”。测试的主要职责是让开发更为容易地做测试。  但是最近两年,随着它的产品的日趋成熟和越来越复杂,google开始加强产品的后期测试。主要原因是虽然开发可以做很多单元和模块测试来保障模块的质量,但是很多bug是在和其它模块集成的时候才被发现。所以google把测试工程师分成两种:一种是和开发一起负责开发的,最要做单元测试,测试工具等。另外一种是面向用户的测试工程师,主要做面向用户的集成场景测试。   3.Continuous Integration…

4

if it still not working

if you’re sure that you followed exact steps in my previous blogs, but it seems the tool still not working. there are a few known issues that you can check to see if it’s your case: 1. .NET 4.0     the current version (TestAPI 0.4) does NOT work on .net 4.0 platform. so if you install…

3

Fault Injection to Web application or Windows service

I have been busy since this march when i moved to Azure team. since then, a newer version of TestAPI (v0.5) was released. we take a few bugs fix in this release. one of them is .net 4.0 compatible. in my previous post, i mentioned that you need to set the enviornment varible for .net 4.0 application….

3

Dev owns testing, Dev owns quality, really?

You might hear a lot about dev owns quality recently. James whittaker, the former engineering director of Google, spends quite a lot pages in his new book <<how Google Test software>>  to articulate why dev should own testing, and why should dev owns quality, like this: “Who better to do all that testing than the…

3

优秀员工的十大要素

前两天整理自己在微软的工作邮箱时候,偶然看到多年以前比尔·盖茨写给员工的一份邮件,我一直保存偶尔翻出来看看。他在该邮件中列出了成为公司优秀员工的10大要素。   经常有人问我如何成为一个好的经理,我在许多专栏中也多次谈到。但是很少有人反问:如何成为一个好的员工? 下面是我在最优秀的员工身上发现的他们共有的10大特征,公司应该竭尽所能吸引具有这些特征的员工。 如果你具有这些特征,你可能就是这些最好员工中的一个了。 第一:你必须对你的产品有强烈的好奇心。你必须亲自使用你做的产品。这一点非常重要,不仅在计算机世界里,在其他高速发展的科技行业也是一样。如果你对自己的产品不热情,你很快就会被淘汰了。 第二:你必须擅长和客户讨论他们是如何使用你的产品的,他们喜欢什么,不喜欢什么。你需要不停宣传你的产品同时很现实地清楚知道你的产品中的不足和需要提高的方面。 第三:一旦理解了客户需求,你必须很乐意地去思考该产品中如何帮助客户。比如,如果你是开发软件的,你可以问自己我的产品如何让用户更享受工作,如何让用户更乐于学习,如何让用户在家里更乐于使用?   前面三点彼此关联。成功来自于你理解和对产品,使用的技术和用户的需求的深深关注。   第四:做为员工中的一员,你应该保持和公司一样的长远策略。员工需要专注于自己一生的目标,比如发展自己的能力。这种动力需要很强的自律但是会有好的回报。当然管理层也应该鼓励这种自我激励。比如如果你是销售,每月的销售量是很好的考核标准。当销售量超过预期是很好,但是如果超过预期销售量是你唯一的动力,你可能会错过类如团队合作和发展等有助于长期成功的方面。 第五:你必须在某个方面有特别的专长同时又有广博的知识。特别是大公司需要可以快速学习的员工。没人可以保证今天的特长明天还管用。所以必须好学。  第六:你必须灵活利用给你的机会。微软为每个员工提供多种不同类型的工作。我们鼓励对管理感兴趣的员工在不同领域理工作,即使需要不停换工作。 第七:好的员工想学习一些经济商业知识。你的公司为什么要做这个产品?业务模式是什么?如何赚钱的?很奇怪有些公司不告诉员工这些东西。员工需要明白业界的成功与失败,这样她才会明白他们的价值所在。  第八:你必须关注你的竞争对手。我很喜欢哪些留意市场动态的员工。我们的竞争对手聪明在哪里?从他们哪里学什么?如何避免他们犯的错误? 第九:你必须思考。分析问题但是不可以一直在分析。了解各种可能的折衷以及他们的影响。比如是有一点信息后就快速行动呢?还是等待更多信息后在行动呢?学会在两者间的折衷。现实考虑问题,有效利用时间,考虑如何给别人清晰的意见。  最后:不要忽略那些明显的特征比如诚实,守信,努力。这些特征不用说至关重要。      

2

提高软件质量实践―― Facebook 篇

Facebook从04年的哈佛校园的学生项目在短短的7-8年的时间中快速增长为拥有10亿用户的世界上最大的社交网络,又一次见证了互联网创业成功的奇迹。同时它的产品研发流程也成为了众多互联网产品公司的追逐对象。今天我们来看一下facebook在产品质量控制方面的实践。有人说,现在的google象早期的微软,现在的facebook象早期的Google. 我觉得无不道理。 虽然facebook已经早已不是创业公司,但是不难看出它在产品研发和质量控制仍然保持着创业公司的风格。在产品研发上,他们以小的研发团队为核心,遵循几个非常重要的原则: Be there from start to ship: 每个工程师自始至终负责产品。从最开始的一个想法,到开发原型,到内部审核,反馈,到产品开发,上线和维护,全部有工程师自己搞定。 Show work early and often:  facebook非常看重反馈,尤其早期内部反馈。他们鼓励工程师有了想法后,尽快开发出原型,尽快得到反馈。 Gets your hands dirty: 动手去做,去实现。 Don’t fall in love: 互联网产品是不断变化的,不需要等到把一个产品设计的很完美了才发布。   为了遵循以上原则,facebook工程师采用以下质量控制手段来保证产品质量: 开发对质量负责: 开发从设计,实现,测试,到部署都要自己做。其它做工具,流程的工程师通过开发工具和流程来帮助开发人员更为简单方便地做测试,做部署和做监控。每个开发人员有自己单独的测试环境,测试环境就是运行在开发本地机器上,部署非常简单快速。测试环境用的是真实的用户数据。 持续集成和测试自动化:每周发布一次。星期天晚上,要发布的构建从主线上分支出来到发布分支,到星期二的中午如果没有大的问题,就可以上线了。所有的测试运行控制在10分钟以内,所以不需要考虑不运行哪些测试用例。运行所有测试用例。 (只是听说,没有经过考证。) 内测 (dog food):发布之前,公司员工使用要发布的功能。2-3天之内可以有几百个或上千个人在使用新功能。负责要发布功能的开发人员在星期天晚上到星期二中午之间会做大量的测试 (一边上班,一边刷微博,岂不是很爽 🙂 )。 发布风险控制:新功能本身质量可能有问题,新功能也可能影响其它现有功能。为了减少或控制这些风险。Facebook开发了一整套完善的发布,控制,监控流程和工具。做到:1.测试通过后,产品质量基本有保证。2.即使有漏测的bug,只会影响很少量的用户。3.及时监控到问题。4.及时修复。 产品监控:监控产品的系统的运行状态。    Facebook之所以采取这种质量控制策略和它的产品特点密切相关: 用户对社交产品质量的容忍度相对较高。比如发微博,现在连不上,等一会在连接也可以,现在发布不出去可以等一会再发,粉丝数量统计有误,没有人太关心。其实facebook并不认为自己的质量差。他们认为产品的质量高低不是有多少个failed测试用例,有多少个bug来确定的,而是有用户对质量的期望值来决定的。如果用户对产品质量的期望值很高很高,一个bug漏掉了都会照成质量差的印象,用户很有可能放弃使用。相反,如果用户的期望值一般,100个bug漏掉了都不会影响用户继续使用。所以facebook产品发布的条件是满足用户对质量的期望值即可。 相对宽松的产品发布周期。不想微软或google很多产品已经在市场上,用户对下一版本的发布时间和新增加功能的期望很高,这往往给产品开发组的压力很大。Facebook基本没有这个问题,它有适合自己的发布期限,不用受到外界干扰。 产品发布和监控流程比较完善,即使有漏测的bug,对用户的影响可以控制在最小而且可以及时发现及时修复。   Facebook质量控制中引以为豪而且倍受瞩目的就是“没有专职测试工程师”。我这里需要专门讨论一下: 什么是“专职测试工程师”? 头衔里面有“测试”的工程师?专门找bug的工程师?专门做质量控制的工程师?等等。 Facebook的确没有带“测试”头衔的工程师,也没有专门运行产品找bug的工程师。每个人都是开发工程师。但是他们的实际工作有区别,有的专门做面对用户的产品,有的专门做测试,开发工具,有的专门做产品的构建和持续集成工具和流程,有的专门做发布和监控的工具和流程。如果按照传统意义上的开发和测试的划分的话,除了第一类外,其他都可以看做专职测试工程师。 Facebook不是惟一一个没有带“测试”头衔工程师的公司,很多软件公司都没有,比如twitter. 很多人把专职测试工程师指专门运行产品找bug的工程师。微软在2005年去掉STE (software test engineer…

2

探索性测试揭秘

最近看了不少有关探索性测试的讨论和观点,老实说越看越糊涂。所以忍不住吐槽一下,在这里和大家讨论一下探索性测试。希望对于想学习和尝试探索性测试的朋友有所帮助澄清,或者是更加糊涂,^_^。  探索性测试有很多很多的定义: 百度百科的定义:“同时设计测试和执行测试”。 嗯。。什么意思? Cem 老人家的正式定义:“a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project”。啊。。 糊涂了。。。 有人说:“手工测试就是探索性测试”。  更糊涂了。。。…

2

软件质量控制实践――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

Fault Injection For Managed Code

Introduction  As part of software testing, we often want to know how the software behaves under failure conditions and to know whether the software system correctly handles error conditions, such as low memory, loss of network connectivity or dependent components unavailable, etc… This actually particularly important for managed code of which big parts are to handle exception. However, this…

1

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