经常有人问我如何成为一个好的经理，我在许多专栏中也多次谈到。但是很少有人反问：如何成为一个好的员工？

下面是我在最优秀的员工身上发现的他们共有的10大特征，公司应该竭尽所能吸引具有这些特征的员工。 如果你具有这些特征，你可能就是这些最好员工中的一个了。

第一：你必须对你的产品有强烈的好奇心。你必须亲自使用你做的产品。这一点非常重要，不仅在计算机世界里，在其他高速发展的科技行业也是一样。如果你对自己的产品不热情，你很快就会被淘汰了。

第二：你必须擅长和客户讨论他们是如何使用你的产品的，他们喜欢什么，不喜欢什么。你需要不停宣传你的产品同时很现实地清楚知道你的产品中的不足和需要提高的方面。

第三：一旦理解了客户需求，你必须很乐意地去思考该产品中如何帮助客户。比如，如果你是开发软件的，你可以问自己我的产品如何让用户更享受工作，如何让用户更乐于学习，如何让用户在家里更乐于使用？

前面三点彼此关联。成功来自于你理解和对产品，使用的技术和用户的需求的深深关注。

第四：做为员工中的一员，你应该保持和公司一样的长远策略。员工需要专注于自己一生的目标，比如发展自己的能力。这种动力需要很强的自律但是会有好的回报。当然管理层也应该鼓励这种自我激励。比如如果你是销售，每月的销售量是很好的考核标准。当销售量超过预期是很好，但是如果超过预期销售量是你唯一的动力，你可能会错过类如团队合作和发展等有助于长期成功的方面。

第五：你必须在某个方面有特别的专长同时又有广博的知识。特别是大公司需要可以快速学习的员工。没人可以保证今天的特长明天还管用。所以必须好学。

 第六：你必须灵活利用给你的机会。微软为每个员工提供多种不同类型的工作。我们鼓励对管理感兴趣的员工在不同领域理工作，即使需要不停换工作。

第七：好的员工想学习一些经济商业知识。你的公司为什么要做这个产品？业务模式是什么？如何赚钱的？很奇怪有些公司不告诉员工这些东西。员工需要明白业界的成功与失败，这样她才会明白他们的价值所在。

 第八：你必须关注你的竞争对手。我很喜欢哪些留意市场动态的员工。我们的竞争对手聪明在哪里？从他们哪里学什么？如何避免他们犯的错误？

第九：你必须思考。分析问题但是不可以一直在分析。了解各种可能的折衷以及他们的影响。比如是有一点信息后就快速行动呢？还是等待更多信息后在行动呢？学会在两者间的折衷。现实考虑问题，有效利用时间，考虑如何给别人清晰的意见。

 最后：不要忽略那些明显的特征比如诚实，守信，努力。这些特征不用说至关重要。

• 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之所以采取这种质量控制策略和它的产品特点密切相关：

1. 用户对社交产品质量的容忍度相对较高。比如发微博，现在连不上，等一会在连接也可以，现在发布不出去可以等一会再发，粉丝数量统计有误，没有人太关心。其实facebook并不认为自己的质量差。他们认为产品的质量高低不是有多少个failed测试用例,有多少个bug来确定的，而是有用户对质量的期望值来决定的。如果用户对产品质量的期望值很高很高，一个bug漏掉了都会照成质量差的印象，用户很有可能放弃使用。相反，如果用户的期望值一般，100个bug漏掉了都不会影响用户继续使用。所以facebook产品发布的条件是满足用户对质量的期望值即可。
2. 相对宽松的产品发布周期。不想微软或google很多产品已经在市场上，用户对下一版本的发布时间和新增加功能的期望很高，这往往给产品开发组的压力很大。Facebook基本没有这个问题，它有适合自己的发布期限，不用受到外界干扰。
3. 产品发布和监控流程比较完善，即使有漏测的bug，对用户的影响可以控制在最小而且可以及时发现及时修复。

Facebook质量控制中引以为豪而且倍受瞩目的就是“没有专职测试工程师”。我这里需要专门讨论一下：

1. 什么是“专职测试工程师”？ 头衔里面有“测试”的工程师？专门找bug的工程师？专门做质量控制的工程师？等等。
2. Facebook的确没有带“测试”头衔的工程师，也没有专门运行产品找bug的工程师。每个人都是开发工程师。但是他们的实际工作有区别，有的专门做面对用户的产品，有的专门做测试，开发工具，有的专门做产品的构建和持续集成工具和流程，有的专门做发布和监控的工具和流程。如果按照传统意义上的开发和测试的划分的话，除了第一类外，其他都可以看做专职测试工程师。
3. Facebook不是惟一一个没有带“测试”头衔工程师的公司，很多软件公司都没有，比如twitter.
4. 很多人把专职测试工程师指专门运行产品找bug的工程师。微软在2005年去掉STE (software test engineer )岗位，就已经没有这一类型的专职测试工程师了。

 所以个人认为，专职测试工程师是个非常模糊的结论。尤其现在我们对产品质量控制方法的不断演变和提高，“测试”的概念不仅仅是指找bug了，所有围绕提高产品质量的工作都是测试。头衔上有没有“测试”不重要，有没有“测试”岗位不重要，重要的是如何有效保证和提高产品质量。

“Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place? The reason Google can get by with so few dedicated testers is because developers own  quality.”

However, not surprisingly, there are arguments on this. Some, particularly fulltime tester/QA believe dev doesn’t have mindset or required skill set to do good testing. On other hand, you can’t ask one to test their own codes. Human is very bad on verifying her own work. Asking dev to test her own codes is like asking a wolf to guard sheep. It just won’t work.

…

…

Really?

…

Before we jump into any conclusion, let’s look at how things got evolved with a coding example. Assume dev was asked to provide an API to calculate tax based on the income, factor and a value stored in database. (disclaimer: the code example is to make a point with obvious bugs, no offense to dev :))

In old days, dev doesn’t test her code but simply hands over to tester for quality assurance. The code very likely looks like this:

class Tax {

     ......

     public double CalcTax(int income, int factor)

      {

            DBConnection c = ConnectToDB();

             Int t = c.GetValue();

            Return income/(factor*t);

    }

 }

Why? Because dev’s role is to writing products codes to build the features, not assure its quality. Quality is tester’s responsibility, so I don’t need to care and I don’t want to care. My performance is measured against how many lines of codes I write (or how many new features I build).

Now, dev needs to do the testing… the code probably looks like this:

class Tax {

      ......

     public double CalcTax(int income, int factor)

      {

            if factor == 0 then return 0;

             DBConnection c = ConnectToDB();

             Int t = c.GetValue();

             if (t==0) t=0; // this is bug.

            Return income/(factor*t);

    }

}

assume dev made a mistake, it actually want to write if (t==0) t=0.1; the bug will stay undetected, due to its dependency on values in database. if there is no zero in the test db, the bug probably slip to customers that has zero in their db.

Then, dev owns quality... the codes probably looks like this:

create fake database mock.

TestCase1.CalcTax(100, 1);

TestCase2.CalcTax(100,0);

TestCase3.CalcTax(100,1) with mock db to let GetValue() return 0;

.....

 class Tax {

       .....

     Database db;

     public Tax(Database d) { db = d;}

     public double CalcTax(int income, int factor)

      {

           if factor == 0 then return 0;

            DBConnection c = db.ConnectToDB();

             Int t = c.GetValue();

            if (t== 0 ) t=0.1;

            Return income/(factor*t);

    }

}

so, what we learned?

1. Dev owns quality means better codes.
2. Dev owns quality means find bug easily.
3. Dev owns quality means find bug early, much earlier. We know the later you find a bug, the more expensive to fix.
4. Dev owns quality means reduce the hand off, more efficient and more fast.
5. Dev owns quality means test ability. When dev owns quality, dev has to think about how to test it when write code. They can’t be tested manually. Test automation is the only way to go, otherwise, he is not going to have time to write new codes any more but doing manual testing all the
   time :)

Here,you might think this is TDD. Dev owns quality means use TDD. Well, not exactly.  My experience with TDD is more in the ideally world. I don’t see any team yet use pure TDD. Most teams use what we called delay TDD. You still write code first, and then write test, then do the refactoring, in the end submit both code and test at the same time. This is more nature way to develop software and achieve the same goal of TDD, meanwhile it’s much easy to adopt vs pure TDD which is completely opposite of what you came along. furthermore, dev owns quality can be extended to owning functional testing, i.e not only making sure unit works by unit testing, but also make sure component works by functional testing.

What’s the cost of dev owning quality? “Slowing down?” Yes or no. the problem is that we only see the cost of doing unit tests, but not see the cost of not doing it. since dev need to writing a lot of testing which takes time. Of course, she will spend less time writing product codes, which eventually slow down building new features. However, if you see the whole application life cycle, developing feature is just one phase of it. There are maintenance, livesite, and application getting more and more complex. Some industry researches show that it actually shorten application life cycle, because without early testing, a lot of bugs are found at the late stage and even in the customer’s environment, this start to eat dev’s time and eventually slow down dev. in contrast, dev owns quality makes software component robust at the first place. It’s like building a highway v.s. bumpy road, initially car goes faster on bumpy road since it takes time to build highway. But once highway is ready, the car goes much faster than running on bumpy road.  This actually leads to another question that is there any situation that unit testing doesnot doing any good? yes, there is. again, take the high way as an example, if you go that road only once or twice, you probably don't want to build a highway. however, if you have to go on the road again and again for the next 5, 10 years, i think you better start to build highway.

By far, I hope you are with me that dev owns quality is a good thing. But what if dev agree but still don’t do it? Many students told me that “we all know /agree this in theory, but dev just don’t do it for whatever reasons, how can I change it?” Here I’m going to share with you a few tips you can try.

First off, there is no silver bullet for it. Dev born to be writing product code, they don’t like testing  in nature. It is a hard and long effort to make the change. So you got be prepared (hopefully you are not discouraged). On other hand, challenge goes with opportunity. Based on my  experience, the change from the state that dev refuse to testing  to the state that dev love testing, are not one step task, it usually take a few phases.

1. awareness. Your first task to convince dev that dev owning quality is good thing or industry trend. If they agree, you are half way to success. if they don't agree, any effort you try to push is useless. so, you got to get them on board first. no exception.

2. make unit test as part of code complete criteria. Once dev agree it’s good thing to unit testing their own codes, you can start to make rules on it. For example, we must have unit tests for every API before we declare code complete. Here is tricky part, at the end of the first iteration, very likely you still don’t see any unit test.  That’s ok, make an exception, but the key thing is let the team knows we are make an EXCEPTION this time. I bet at the beginning of second iteration, dev will start to consider unit test into their overall work. Hopefully at the end of 2^nd interation, you will see a little unit test. Again, it's not good progress but it’s good sign. Just be patient. Make another EXCEPTION and let the team knows. So on and so forth, after a few iterations, you will suprisely see there are a lot unit test in place.

You also can try peer pressure or indirect push tips to make the unit test coverage transparent, so the team knows who write unit test, who doesn’t.

Reward those devs or teams having better unit tests. measure dev's performance based quality of codes, not number of lines of codes. build a culture that team take pride of their unit testing results.

Working with dev to improve unit test framework and make unit test as easy as possible. Image you are devs, you take 1 minute to write one line of product code, and takes 2minutes to write its unit tests, now takes 30 minutes to run unit tests. You won’t do it either, right? So the most efficient way to push dev to do unit test is to make it as easy as possible.

3. make it default. After the team is armed with tools/framework for unit testing, you can make it default. For example, block the checkin if no unit test. Showing unit test cc before checkin, etc…

If dev owns quality, what a tester will do?  Will fulltime tester be phased out?  i will try to answer these questions in my next blog, also talk about tester's core competency, so, stay tuned....

Amazon是一个很传奇的公司，它1995年的时候以一个网上书店起家，在短短的十几年里成为全球最大的在线购物公司。更为甚者，他在2005推出的AWS云计算服务更是被业界公认为云计算的鼻祖，也是现在全球最大最成功的云计算服务提供商。我一直坚信成功的产品一定是由成功的质量控制做保障的，采取什么样的测试策略只有两个决定因素。一是企业文化，二是产品特点。在分析Amazon的测试策略之前，我们先看看它的企业文化。

业界关于amazon企业文化和成功要素有很多，我觉得实际上最为核心的只有一个，就是他们的“low margin, large volume”理念。就是通过单个商品的低利润和巨大的销售量来最终提高公司利润和公司业务向前发展。工程团队的理念就是要保障企业文化得以顺利实施，所以Amazon的工程团队的理念就是如何保障公司“low margin, large volume”的企业文化。Amazon工程团队有以下特点：

• 独立的团队：在Amazon，负责产品功能模块的每个团队相对独立。他们对该模块的所有功能，性能，开发，质量，上线，维护等从头到尾的绝对负责。我们在Google中也可以明显看的这一特征.
• 敏捷的团队：为了保障团队的敏捷，Amazon采用“2个比萨饼”的原则来看控制一个团队的大小。也就是2个比萨饼就可以吃饱（5－7个人）的大小。团队内部和团队之间尽量减少工作的交接，一方面减少因为交接照成的不必要延迟，另一方面避免互相推卸责任。Amazon是最早采用敏捷开发（scrum）的公司之一，他们现在绝大多说产品组都是用scrum，据说有超过400多个CSM.
• 面向服务的产品体系架构。在01年的时候，Amazon随着它的产品线迅速扩大，业务逻辑越来越复杂，现有的产品体系架构极大地限制了整个公司的高速发展。他们重新设计了基于面向服务的，松耦合体系架构，使得各个模块独立开发，修改和维护。所以Amazon可以在不牺牲质量的同时，快速推出新产品新服务。

 很遗憾的是Amazon很少公开谈论他们的质量管理流程和策略，不过通过有限的资料，还是不难看出他们的质量管理的策略：

•  
  开发对质量负责：因为每个团队对模块完全负责，并且要做到敏捷。Amazon要求开发对质量负责：从设计，写代码开始一直到代码上线。开发做测试不仅可以尽快地发现bug，而且可以避免过分依赖测试人来提高质量，更为重要的优点是开发在设计是会考虑代码的可测试性 （因为他们自己要测试，肯定想方设法使得测试更为容易些），从而使得模块容易测试，容易维护，松耦合，最终极大提高模块质量。因为开发做了大量的测试，Amazon专职测试工程师也比较稀少（据说对开发的比例是1:7左右）。测试的主要职责是负责复杂用户环境下的测试，以及开发测试工具，流程和基础设施。而且很多产品组把一部分功能测试外包，所以即使Amazon的测试工程师不多，但是整个产品的测试工作却没有一点减少。
•  
  自动化测试：这里我就不在多说了，和microsoft, google一样，他们开发了大量的测试工具和流程基础设施来提高测试效率。开发专注于写代码和测试，不用在搭建环境，部署，运行测试用例，和反馈上浪费时间。除了测试自动化外，他们也开发了一整套用以产品上线，维护和监控的工具和流程。只有这样，开发才有可能既要写代码，又要对代码质量从头到尾负责。
•  
  数据驱动的决策流程：和google一样，Amazon全方位监控它的应用服务的运行状态，从每个API调用时间，到用户使用产品的每一步骤。根据对这些数据的分析和挖掘，开发团队决定如何提高产品质量。

 如果大家熟悉Google的软件质量实践应该可以发现，Amazon和google在软件质量控制的理念和实践有非常的相似之处。有所不同的是，google的很多项目以实验性为目的，最初没有任何专职测试。只有等到项目真的被重视后，测试才开始介入。做为互联网产品的两个大哥大，他们的测试方式或许可以代表着互联网产品的测试发展方向吧。下一次我们介绍最后一个公司的测试策略－facebook。

首先要订正的是该事件实际上不属于安全性的范畴而是高可用性的问题。安全性通常是指是否可以访问未授权的资源或数据（当然DoS攻击也是安全性问题），这里所指的是用户部署在云里的服务是否可以一直可用。 所以真正的问题是云计算是否高可用?

在回答该问题前我们需要分清楚云计算里的两个基本概念：计算服务和存储服务。

计算服务是指云计算提供商提供给用户的用以进行运算的服务。它通常是以实例单元来衡量的，比如一个虚拟机可以是一个实例单元。用户在购买或使用计算服务时可以是一个或多个实例单元。比如用户的在线购物应用程序，一个实例单元可以扛得住1000用户的访问量的话，如果你通常会有10000个用户同时访问的话，你至少需要10个运算实例。如果在高峰值时有50000个用户同时访问，你需要购买50个运算实例。而在低峰期是如果只有2000个用户访问的话，你可以只购买2个运算实例就可以了。所以你可以方便灵活地更具用户访问量来调整购买实例的数据量，这样既不会浪费，也不会不足。这就是我们所说的云计算的最大优点之一：弹性伸缩，按需使用和按使用付费。但是，要做到这一点，每个运算实例必须是"无状态"的，也就是每个运算实例完全相同，不可以在运算实例的本地机器上保存任何状态数据。原因很简单：如果你在本地保存数据的话，只有你自己实例能够使用。在前面10000个用户访问量的例子中，在增加再多的运算实例也没有帮助，因为只有你有数据，别的再多机器也帮不上忙。

但是在实际的应用程序中我们又必须处理和保存数据。所以为了运算实例"无状态"而又可用保存数据，云计算提供商必须提供第二个服务：存储服务。

存储服务很简单就是给用户保存数据用的。但是数据是用户业务的核心中的核心，绝不可以出现任何差错。所以存储服务必须使用足够的措施来保证数据的万无一失。绝大多数的公司都采用两中方式：一是：把用户数据划分成块，每一块是一个存储单元。每个存储单元分多次保存在多个服务器上。这有两个好处：一是如果一个服务器宕机了，其它服务器上的数据还可用；另一个是负载均衡以提高读数据的效率。这些服务器都在同一个数据中心，所以使用同步复制，即使把同一个数据块写多次也不会影响写数据的效率。但是把同一个数据的多个拷贝存放在同一个数据中心无法应付大的灾难，比如数据中心失火，地震或城市断电等。所以大部分公司把数据再一次复制保存到另外一个城市的数据中心里（两个数据中心最少相距150公里）。如果一个数据中心瘫痪，可以把用户请求切换到另外一个数据中心。因为两个数据中心的数据复制较慢，所以通常采用异步复制的方式，每隔10分钟复制一次。另外一点是第一种同步复制是默认的，用户不用做任何配置，也是免费的；但是第二个异步复制需要用户提出，而且可能有额外的费用。

所以有了存储服务后，用户就可以把数据或状态保存到存储服务理，而实现运算实例的无状态了。可以随时增加或减少实例数量，一个实例宕机也没有问题，还有其它实例在处理。实际上在数据中心里机器宕机，网络断掉，硬盘坏掉每天都在发生，但是用户感觉不到。如果用户把自己的应用服务同时部署到多个数据中心的话，即使一个整个数据中心宕掉的话，用户的访问请求可以快速切换到另外一个数据中心，用户也不会感觉到任何问题。这就是运算服务的高可用性：服务器宕掉了没有问题，整个数据中心宕掉了，同样没有问题。但是我们可以看的要做到这一点，用户必须做两件事情：1.你必须有最少两个运算实例，道理很简单：如果只有一个，它宕掉的话没有其它实例，当然做不到高可用性。2.你的应用程序必须在多个数据中心部署，一样的道理。最少两个才可以做到双保险。

我们再来看看亚马逊的本次宕机事件。因为当地暴风雨导致数据中心断电，在切换到备用电源后，备用电源出现故障。所以导致整个数据中心宕掉了。在切换到其它数据中心的时候有发现切换程序出现故障，导致无法切换，所以最终导致用户应用服务不可用。另外它都只是计算服务宕掉了，并没有影响数据服务，或则数据没有丢失。等到计算服务回复后，系统恢复正常。所以计算服务宕机很正常，如果数据丢失麻烦就大了。其实这一次恶劣天气照成数据中心断电本来可以体现亚马逊云计算高可用性的一个经典案例，但是很可惜的是它的切换程序出了问题，反而成了失败案例。

所以我们可以看出在保证应用程序的高可用性和数据的安全性上，没有一家单个公司可以做到像亚马逊，微软或其它云计算提供商那样的完备，根本不是一个级别上的比较。我们对亚马逊宕机反应强烈只不过是我们对云计算有着不切实际的期望（100％高可用性）。殊不知我们对自己公司办公室的服务器经常宕机习以为常了。 当然云计算提供商在保证高可用上还要继续努力，但是它也不应该是质疑或反对云计算的理由。另外一点就是要高可用性不是与生俱来的，而是要求用户必须做很好的设计，充分利用云计算提供的机制，而不是把应用程序扔到云里面就万事大吉了。一个最简单的道理：不要把所有鸡蛋放在一个篮子里。

话说清朝的时候慈禧太后听说西方国家有个新的交通工具，汽车，它坐在舒服跑的很快。于是就叫人买了一辆回来。但是用的时候没有人会开，于是不得不把汽车用几根柱子绑起来做成了轿子，让几个人抬着。因为汽车太沉，几个轿夫步履蹒跚，走不了几步就得歇歇。结果以前半个时辰的路走了好几个时辰。而且到了后因为门很窄，汽车做的轿子过不去，她也不得不老远就下来自己走一段。慈禧太后很不高兴就得出结论：

1. 汽车前期投入大，维护成本高。
2. 没有轿子走的快。
3. 很多地方汽车都不适用。
4. 汽车是个大忽悠的东西，根本不管用。

那么我们现在对敏捷的认识是不是和慈禧对汽车的认识类似呢？是因为我们不会用敏捷呢，还是因为敏捷就是个忽悠？

在国外通常一个概念出来之前已经有很多年的实践积累，然后为了大家交流方便或者提高普及度给其一个名字。所以是先有实践，再有概念。但是在国内正好相反，我们先把国外“先进“的概念引进来了而把产生概念的多年实践忽略掉了。但是概念又太虚不能当饭吃，最终还是需要具体东西和具体做法。所以不得不根据概念来设计出各种各样的做法来。这些做法听起来不错，非常符合概念，但是在项目中一使用就不灵了，旧的问题没有解决，新的问题一大堆。最终得出汽车是个大忽悠的结论。

敏捷和云计算是两个非常典型的例子。很多人为了敏捷，文档不要了，计划不要了，测试用例也不要了，认为几个人站在走廊里沟通沟通就把一切都搞定了，因为敏捷了嘛。但是问题并没有因为“敏捷“了而被解决掉，于是乎得出敏捷是个忽悠的结论。云计算也一样，很多人认为云计算就是数据中心，所以大家大兴土木建立数据中心。但是建完数据中心以后呢？没啥用处呀。那大家都在吹捧云计算，不就是个大忽悠吗。 殊不知，人家是因为业务需要很多年了已有数据中心，为了提高数据中心的使用率，开始对公众开放资源，所以才有了云计算。

先有概念再造实践的做法违背了事物发展规律，不仅解决不了现有问题，而且带来新的问题。敏捷是个好东西，在特定情况下。我们需要搞明白的是它要解决什么问题的？它是如何解决的。而不要在乎它叫什么名字或则防止生搬硬套。还有越是先进的东西对人和基础设施的要求越高。比如飞机再好，没有飞行员或则没有机场也没有用。高铁跑的越快对铁道的要求越高。

软件测试也是一样，做质量控制不是为了赶时髦。如果你的项目只做3个月就彻底结束了，而且就3－5个人，不会有人离开也不会有人进来，也不需要和其它任何项目打交道，或则你的产品在早期实验阶段，你可以不要文档，不要计划，不要记录bug，完全靠口头交流。否则的话：

1. 不能没有文档:  但是要减少不必要的文档，避免过于详细的文档，使用易于更新和维护的动态文档。

1. 不能没有计划: 距离现在越远计划越模糊，但是距离现在越近计划越详细。

1. 不能没有纪律:  

与其在琢磨如何敏捷测试，不如一步一步把自动化做好，把持续集成做起来，创建更多的测试工具以提高测试效率，把质量反馈系统做起来，把dev提交代码前的质量检查做起来，把在产品中测试做起来， 把测试工程师的素质提高上去，。。。。

等到这些都建立起来了后，你发现自己其实已经很敏捷了。

---------------

关注我：新浪微博：@billliu_seattle https://www.weibo.com/windowsazure 或twitter: @billliu_seattle

昨天请了一个在facebook的做网站性能测试的大牛来给我们分享facebook做性能测试的经验。她在google做了5年的测试在2年前跳到facebook。在提到其它公司在推崇google的测试实践时，她把google的测试狠狠抨击了一番。她说google的广告做的很好，很多google演讲的数据，比如每天有多少个build；一个build有多么快速，测试运行有多快速，等等数据有过分夸张。可能某一个组的某些测试做的还可以，但绝不是代表整个公司，甚至不能代表大部分组，至少她在google工作的5年里没有看见过。而且很多内部工具真正的做法，实际效果都不像外面传说的那样神奇。

James 在3月份离开google回到微软。虽然他在博客中强调他离开的原因是不同意google的产品策略以及公司文化的变化，但是我觉得他的根本原因还是他对测试的的看法和公司高层有不小的分歧。而且从他最近写的有关软件后期测试的文章可以很明显地感觉到。James 和其它两个工程师合写新书。书还没有出版，两个作者就先后离开了google，另外一个早就转成了开发。即使在他的新书中，James在最后展望google的测试的章节中，他就承认因为google的测试工程师是用租借的方式分配到产品组中，这使得测试工程师对产品没有归属感。这很令人担忧。很典型的例子：if you ask a dev what she is doing in google, she will say i'm working for chrome, search, g+, etc.. whatever component/product she is working on. however, if you ask a tester what she is doing in google, she will say i'm a tester.

前两天和两个在google测试的工程师聊天，他们也是一直在摇头。而且承认搞测试还是在微软（这两个工程师都在微软工作过）。

google测试实践真的值得推崇吗？

是不是因为google成功了我们就默认为他的所有做法都值得追随？

那么我们到底该从google学习什么样的成功经验呢？

我想把这些问题留给读者自己去琢磨和思考。

----------------------------------------

关注我：新浪微博：@billliu_seattle https://www.weibo.com/windowsazure 或twitter: @billliu_seattle

 首先申明的是本人并没有在google工作过所以没有第一手的经验，仅以一个旁观者的身份来分析google的质量控制实践。主要信息来源于google测试博客，在西雅图google工作的朋友聊天和项目上合作，以及James的新书<<how google tests software>>。不过旁观者有旁观的优势，可以看见整个森林；相比较许多在大公司工作的工程师往往专注于一个产品或者一个团队，只看见了一颗树木J。不管如何，个人观点仅供参考。

 我们前面在微软的质量控制实践中谈到，因为微软大部分的产品还是以桌面型产品为主，比如windows, office,sql server等等。桌面型产品的最大特定就是产品召回或发布热修复的成本太大，而且运行很多关键业务，这就迫使微软必须在产品发布之前投入大量人力物力来充分测试产品用以保障产品的高质量。与微软不同的是，google采用不同的策略来保证软件质量。在理解分析google的质量策略之前，我们必须了解google的采取该策略的根源：

1. Google质量文化：google起源于校园。在有限的资金下，那时候创始人只能使用廉价的机器，把多个廉价的机器放在一起来提高处理能力。这些廉价的机器最大的问题是经常死机或报废，所以google在起始阶段就必须有很强的容错能力。也就是说在系统在部分机器死机或报废的情况下仍然可以提供服务。或者说，系统部分可以出错但是整个系统不可以宕机 （Graceful Degradation）。Google这个从一开始因为被迫置入的高容错能力反而成就了现在他们运行在数据中心上的服务的巨大优势。我们知道通常硬件的出错概率大概在万分之一，如果有一万台机器，其中一台出错概率就达到百分之百。在现在的数据中心里少则几万台，多者几十万台的机器。所以产品的容错能力已经不是可有可无，而是必须有的功能。所以google信奉的原则是单个模块可以出错可以有bug，它通过系统强大的容错能力来保障系统的整体高质量。
2. 互联网产品：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

这个就不用多介绍了，搞互联网或基于服务的产品的项目组，如果不使用持续集成的话有点太out了。Google的持续集成是行业的领先者，一方面有强大的测试自动化和完善的基础设施做为保障，使得开发测试工程师不用在如何部署，如何运行，如何分析结果等等上浪费时间，而是专注于开发和测试自动化。代码提交后会有成千上万个测试用例自动运行，并且很快返回结果以供进一步分析之用。另一方面，google继续优化现有的工具和基础设施来进一步提过持续集成的效率。比如在做持续集成中最为头疼的一个问题是运行那些测试用例？运行多了当然会延长运行时间从而降低了效率，运行少了又有漏测的风险。Google开发了一套测试用例分析工具用以分析代码和测试用例的依赖关系。如果修改了某行代码后，该工具决定哪些测试用例必须运行，也就是说不多不少。微软也有类似的工具在帮助测试人员决定运行测试用例的优先权，但是个人感觉效果不太好。所以我也对google的工具到底效果如何应用情况很感兴趣。

另外一点就是持续集成是以自动化做为基本保障的。测试自动化不是万能的，但是没有测试自动化是万万不能的。注意的是测试自动化不仅仅解放了人，也不仅仅是为了回归，更为重要的一点是逼迫开发在设计的时候就考虑到如何自动测试该模块从而大大提高模块的可测试性（我们知道这是提高软件质量的一个重要指标）。当然除了测试自动化外，google开发了许许多多的工具和平台来大大提高测试效率。

4. Measure everything

客观上说以上几点我都觉得没什么特殊之处，但是下面这个绝对让我受益匪浅：measure everything。从最底层的硬件驱动器，到操作系统的CPU, memory,  disk IO, 再到每个API的调用， 最后到最高层的用户体验，Google监控和衡量所有的这些活动。然后对监控和衡量的数据进行数据挖掘和分析，从而对整个系统的运行情况了如指掌。一方面，如果有bug的话，它可以在最短的时间内发现并根据监控的数据很快找到bug的根源加以修复；另一方面根据详细的监控数据清楚地表明哪些地方需要改进，尤其是在系统性能方面；再一方面就是了解用户的使用情况和规律从而为产品功能的改进提供精确的数据和预测。Google认为： If you can’t measure your product/component, don’t build it。

小结，google是互联网公司成功的代表，他在互联网产品上的质量控制实践和经验对于广大的互联网公司有值得借鉴意义。在产品发布速度和产品发布质量的权衡和取舍中，google选择发布速度。在保障基本产品质量的前提下，用最快的速度把产品推到市场中，然后通过丰富的反馈渠道和工具再不断演变。这样即控制了用户又保障了质量，而且也做到了对没有用户的产品：fail fast, fail cheap。除了google之外，在西雅图的另外一家公司也是互联网产品的大哥大，特别是在在线销售和云计算应用服务类型的产品。所以下一次和大家探讨：提高软件质量实践――Amazon 篇。

----------------------------------------

关注我：新浪微博：@billliu_seattle https://www.weibo.com/windowsazure 或twitter: @billliu_seattle

 探索性测试有很多很多的定义：

百度百科的定义：“同时设计测试和执行测试”。 嗯。。什么意思？

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”。啊。。 糊涂了。。。

有人说：“手工测试就是探索性测试”。  更糊涂了。。。

又有人说：“探索性测试就是一遍探索一遍测试”。 彻底糊涂了。。。。

。。。。。

 那么探索性测试到底是啥玩意啊？

我们先来看一个例子吧。很多人都玩过猜数字的游戏吧。我心里想一个数字，你来猜。你可以问任何问题，我回答“是”还是“不是”。然后你通过不断问问题和我的回答来最终猜到我心想的数字。在猜对的情况下问的问题越少得分越高。比如，我心里想了一个数字。你可以问“大于零？”，我说“是”。你现在知道是正数了，你然后问“小于100？”，我说“是”。你现在知道是小于100的正数，你然后问“小于50？”，我说“不是”。你现在知道是介于50和100间的数。你继续再问几次后因该就能猜对了。

在这个简单的游戏中有两个策略至关重要：

1. 你要根据前面问题的答案来分析和设计下一个问题。第一个问题可能不着边，但是第二个问题会让你跟接近你想要的答案。第三个会更加靠近，以此类推。
2. 仅仅根据前面问题的答案来设计下一个问题可以最终帮你猜对数字，但是要想用最少的问题来猜对数字不仅要根据前面问题的答案，而且需要对问题本身其它知识加以综合运用使用其它策略和技术。比如在知道是小于100的正数后，你可以使用binary search，最多猜6次就可以猜对；如果你不知道binary search，你可以猜是否小于90？小于80？小于70？… 猜上十几次也可以猜对；或者猜是否小于99？小于98？小于97？… 猜上几十次也可以猜对。所以采用不同策略直接决定你猜对的速度。

所以两个关键因素：前面问题的答案＋有效的策略。

  探索性测试和猜数字游戏完全一样。在这里要猜的数字就是你要找的bug。你问的问题就是你做的测试，每个问题的答案就是你测试过程中产品的输出。第一轮你只有一个非常模糊的范围比如测试某个模块的某个功能。在你测试的时候通过观察产品的反应和输出来判断分析下一步做什么会发现bug。当然实际测试中不会像猜数字那样直接和简单。

  下面我们来看一下一个真实的测试例子。有一次我在测试一个用户界面的录入页面。用户可以输入比如姓名，年龄，等等很多信息，最后系统根据输入的内容处理保存到数据库中。当然我对每一个输入框都会尝试不同的数据比如空值，很长的字符串，空格等等，系统都没有问题。但是我注意到每次保存的时候系统都会生成一个本地文件，该文件的名字是其中一个输入框的我的输入。该输入框的唯一限制就是不可以为空不可以超过255个字符。我想到文件名字中不可以有斜杠“\”，于是我就在该输入框中如入“ab\cd”，它通过了输入校验，但是保存的时候系统就崩溃了。这就是探索性测试一个非常典型的例子，通过观察分析上一次测试的产品反应和输出来判断系统会有问题的地方，然后设计调整步骤和测试数据反复尝试直到完全验证模块没有问题或找到bug.

  探索性测试和手工测试的区别：手工测试通常是指完全按照预先设计好的步骤一步一步人工测试直到验证了所要验证的功能。如果结果和预期结果一致，则验证通过；如果不一致，则是bug.可以看出手工测试过程单调没有思考没有变通。在上面的猜数字的游戏中你明明已经知道是正数，你还在按照游戏开始前设计的步骤问大于－100？ 大于－90？。。。。当然现实生活中没有这样的傻子，在你“手工”测试的时候你或多或少已经使用“探索性”了，只不过你没有意识到罢了。所以很多人误认为探索性测试是个时髦新测试技术，研究了半天又不知道到底新在那里和自己一致做的有什么不同。或者恍然大悟原来自己已经探索了很多年了。但是探索性测试有效率高和效率低之分，所以有人干脆就把效率高ET的才叫ET, 效率低的ET叫手工测试。这也是让人糊涂的原因之一吧。

 测试自动化就是把手工测试的每个步骤有测试自动化工具来完成。好处是不用人做了，缺点是测试过程中仍然没有思考没有变通。

 Ad-hoc测试（随机测试）：没有预先设计好的步骤，也没有明确目标，也没有策略。在上面猜数字的游戏中你明明知道是正数，你还在东一榔头，西一棒槌的乱猜等于100？等于－100？等于0？。。。当然也有可能被你一不小心蒙对了。

 探索性测试和测试自动化各有各的优缺点。至于什么时候开始测试自动化，什么时候开始ET，先测试自动化后ET,还是先ET后测试自动化需要看项目产品具体情况了。没有绝对对错，以尽早发现bug,发现更多的的bug为宗旨。另外既然ET和测试自动化的各自优缺点，微软有些组最近两年在尝试“探索性测试自动化”的方式来把探索性测试和测试自动化相结合，充分发挥各自的优点。看到这里你可能要恨我了，我刚学会测试自动化，你又提倡ET了；我刚搞清楚ET，你又开始提倡探索性测试自动化了。。。 呵呵，人类发展过程就是通过社会分工，扬长避短。专注于做自己擅长的事情，把自己不擅长做的事情交给擅长的人去做。社会发展是如此，云计算是如此，测试也是如此。有人说过：“The computer is incredibly fast, accurate, and stupid （test automation）. Man is unbelievably slow, inaccurate, and brilliant (exploratory test). The marriage of the two is a force  beyond calculation。”

 其实我们可以看到探索性测试入门容易或者你已经在做了多年了，难得是有效地探索性测试，或者做效率高的ET（否则被别人不屑为手工测试了J）。那么如何根据前面的测试结果来分析和思考，如何才能敏锐地嗅觉到通向bug的种种线索？当然有多种方式来训练自己这方面的能力。还有如何衡量考核ET的效率，投入和产出比率？欲知详情，请听下回分解。。。。

 或者把这篇文章在微博上转发5次，我会发私信告诉你，哈哈。。。。

----------------------------------------

关注我：新浪微博：@billliu_seattle https://www.weibo.com/windowsazure 或twitter: @billliu_seattle

1. 对测试的要求太高了

在国内培训的时候经常遇到的一个说法：“（比如测试自动化，工具，流程）的确好处很多，但是它对测试的要求太高了”。刚开始的时候我很惊讶，第一次听到对测试要求太高的说法，后来听多了才慢慢意识到这才是问题所在。如果你认为国内的测试比国外落后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。

----------------------------------------

关注我：新浪微博：@billliu_seattle https://www.weibo.com/windowsazure 或twitter: @billliu_seattle