自动化测试之前，需要先谈谈质量和效率

测试的目的是保障质量，质量是效率的前提（非常重要）

从发展的角度看公司对质量和效率的重视程度

公司在初创阶段更注重效率：

• 试错阶段，可以犯错误，100件事，犯错99次，1次成功即可
• 依赖个人和团队的能力

公司在发展阶段会越来越重视质量：

• 开始控制流程，减少犯错
• 从依赖个人能力到依赖有效的管理，减少个人犯错的影响
  • 需求评审
  • Design review
  • Code review
  • 上线前风险评估

公司在成熟阶段会以质量为核心：

• 越成熟的公司越怕犯错，因为犯错的成本太高，董明珠说过：犯错成本太高，所以不能犯错
• 犯错的成本并不仅仅是改正错误的成本，更大的损失是客户信任的丧失
• 公司发展的越大，与竞争对手相比谁能活动更长久，拼的不是谁的创新能力越强，而是谁犯的错误越少，引用HP（惠普）大中华区总裁孙振耀退休感言里的一句话：最后高手之间的比赛，就看谁失误少谁就赢得了决赛。

问题：对质量要求太高会束缚公司的手脚，拖累公司发展的脚步，怎么破？

1. 这是必然！类似法律与自由的关系，法律必然束缚自由，真正的自由是在法律允许的范围内无限自由
2. 学习腾讯：另起炉灶，不破坏原来的产品生态结构，如微信，即不影响QQ现有业务，又做出了创新
3. 学习海尔：搞内部孵化，鼓励员工创业

我的一些认识和总结：

• 软件公司的目标不是生产更多的软件，而是生产更多有价值的软件
• 服务公司的目标不是提供更多的服务，而是提供更多有价值的服务
• 高质量不等于高价值，但低质量会降低价值，所以保障质量就是在保障价值最大化
• 产品经理需要证明产品的价值，我们测试人员来保证产品的质量（产品的质量分为设计质量和符合质量，对于测试而言，我们所说的质量，通常指的是产品的符合质量）
• 软件测试的首要目标不是保障软件按时上线，而是高质量的上线
• 质量团队的只对质量负责，不对项目是否延期负责，那是项目经理应该关心的。

如果我们因为项目经理说要赶工期，就放松对质量的控制，那是我们的失责。

那么质量团队不需要关注效率？不是的，项目管理的知识告诉我们，要考核质量团队的内部的测试效率，而不是以研发的整体效率考核质量团队。

这句话怎么理解呢？研发整体效率包括项目管理效率，开发效率，测试效率，运维效率等，测试效率是其中一部分。比如一个项目估时开发要10天，测试要5天，整体15天后上线。那么我们该如何考核测试的效率？是不是15天后如果不能按时上线，测试团队的绩效也要扣分？如果答案是Yes，那么完了，我们可以认为项目经理已经在某种程度上放弃质量了，虽然他没有这么说，但是因为绩效考核的原因，当面临延期风险的时候，质量会为效率让步。正确的答案应该是No，不能用15天后能否顺利上线来考核质量团队的效率，而是要用5天来考核质量团队的测试效率。同样我们不能用15天来考核开发，15天是用来考核项目经理的，10天才是开发的（当然这个项目估时模型比较简单，实际的情况要更复杂些，如bug修复和多轮测试的情况）。道理说出来大家都懂，但在实际工作中，我们经常会遇到提测延期了，项目经理来催促质量团队尽快完成测试的情况，美期名曰为了保证项目上线，辛苦一下（说不好听点就是项目经理为了完成自己的考核指标，来压榨测试的工期）。如果测试答应了，但结果却没能按期完成测试，有些项目经理就会把延期原因算到测试头上，质量团队兢兢业业的对质量负责，甘愿为赶工期而加班，说不定还会落下一个测试效率不行的话柄。

这里面还有一个比较tricky的情况：测试通过的标准是不再有新的严重程度超标的bug产生，即保证提测后不再有bug方可放行。但是情况一，如果你真的在提测后的5天时间里一个bug也没有发现，同样会引来质疑，一个bug都没有，怎么还需要测试5天时间？情况二，如果你在第4天发现了一个严重的bug，然后开发在第5天下班前修复完成并提交了，OK，开发在上线前完成了任务，请问测试能够在上线前完成测试吗？如果你说不能，那5天的测试时间是由你自己来估的啊？自己当初许下的承诺，肯定要自己来担啊！如果是你，你会怎么做？如果没有其它的理由，那么可以预见的结果就是加班，更糟糕的情况是，即使加班也不见得能够按时完成回归测试。通常的做法就是缩小回归测试范围，只回归核心测试用例（有时候我们嘴上不会说，但实际上测试用例还是被删减了，实际不可能也不会每修复一个bug就做一次全回归），而缩小回归测试范围有可能带来的影响就是覆盖度不够，进而不能有效的保证质量。当然，实际情况需要我们必须做出取舍，我不会坚持说全回归一定是必要的。但是做为测试人员，为了达到保证质量的目的，并且还尽可能不加班的话，就需要说服项目经理延期。这很难，项目经理最不喜欢延期了。然后更难的是，如果项目不得不延期了，如何证明理由不是因为测试效率低下？

我们需要有充足的理由和应对的策略（注意，我们这么做并不是为了应付项目经理，而是为了项目质量）。这里我借鉴一下在微软做外包的经验，说一下零bug状态的策略（注：这里的零bug状态，并不是说真的一个bug也没有了，而是说在某一个时间点，不再出现影响产品上线的bug）即：规定项目在某一个时间点达到零bug状态，只有在这个状态达到了，才允许上线。如果在规定的时间内没有达到零bug状态，就需要延期，延期的时间=bug修复+一轮回归测试时间，如果在下一个时间点仍然没有达到零bug状态，就需要再次延期，如此循环，直到达到上线标准。（嗯，肯定有同学在想，我们小公司，那里能和微软比，客户需求紧急，经不起这么反复延期的）这里所强调的延期的理由是产品质量未到上线标准，并没有特指到底是开发还是测试的原因导致了项目延期。这里的角度是，项目管理者首先关注的是质量，而不是追责。在遇到问题影响到项目上线时，首先要判断的是项目能不能以原现预期的质量上线，而不是先问为什么你不能按期完成测试之类的问题。关于小公司不能接受反复延期问题，很简单，那就放松上线标准吗，我又没有说小公司必须都得达到微软那样严苛的上线质量要求。但是项目经理肯定不会同意这么说的，在他们那里，即要按期上线，又要保证质量。哈哈，这就是有意思的地方，明明知道几个小时的加班不可能完全一轮全回归测试，大家都不说，其实不就是默许放松了上线标准吗？

这里有一个前提，开发应该为自己写的代码负责，无论在任何时候出现影响产品上线的bug（需求和产品设计的缺陷除外），都不应该由测试来背锅。很多同学不明白为什么我要在这里强调这一点，开发也会说，我们写出来的bug，肯定不会让你们测试来背锅啊。然而实际的情况是这种测试与开发相爱相杀的场景还在不断上演，举个例子，比如在第4天发现的严重bug，是开发的锅还是测试的锅？开发说，为什么不是在第一轮回归测试就发现了？而是要等到第4天？如果是第一天就发现了，我肯定能及时修复啊。测试会说，第一轮测试是ok的，在第三轮回归时才发现，有可能是你们在修复其它bug时导致的，所以我们没法保证第一轮就发现所有的问题。

我还真遇到过这种情况，测试在上线前一天发现了一个bug，如果要修复这个bug再回归，赶在第二天上线肯定来不及了，项目经理竟然质问为什么测试不能早发现这个bug，到了最后一天才发现而影响工期？我简直无语，如果开发在修复这个bug时又引入了其他的bug，在回归时又被测试发现了，难道又是测试的责任？按照这样的思路，测试在临近上线时就不能再发现bug了，为了保证上线时间，为了维护测试的清誉，测试即使发现了bug也要往肚子里咽。这件事情对于测试团队绝对是一个负向引导，在这样的奖惩机制下，为了保上线时间，测试大部分情况下会做出妥协，简单的回归下部分主要测试用例，就放行了（不要制造麻烦，小问题不要上报）。这也是我所见到的小公司内普通存在的情况，这里忍不住一声叹息。如果上线后不出问题还好，如果出了问题呢？测试能甩锅吗？甩给谁？

这里我想表达的是，测试人员对待自己的工作要有底线，对自己测试过的产品要负责，不能因为保工期而放弃自己的底线，如果确实心里没底，不敢保证上线后不出问题，那么就要争一争，而且要争的有理有据，我们不是为自保而争，而是为了产品质量而争，大道理一定要讲明白。因为无论你争与不争，线上出了问题总是有你的责任，为什么不争一下呢？

最后重审：质量是效率的前提，没有质量的效率永远等于0

自动化测试的目的是什么？自动化测试能提高产品质量么？

自动化测试的目的提高测试效率，并不直接提高产品质量。测试效率提高之后，节省出来的时间可供我们做更多的测试，而更多的测试这部分，可以提高产品质量。所以说自动化测试是间接的保障质量

总结一下，手工测试和自动化测试的重点：

手工测试：保障质量

自动化测试：提高效率

自动化不能取代人工，自动化也不会超越人，能够自动化的东西，肯定是人的思维能够达到的地方

提高效率=节省人力=投入更多的人力来保障质量

附：HP（惠普）大中华区总裁孙振耀退休感言