Google软件测试之道

Google软件测试之道

质量和测试的关系

书中的观点是：

• 质量不是被测试出来的，如果在最开始设计的时候就是错的，那它永远不会变成正确。

• 质量不等于测试。当你把开发过 程和测试放到一起，就像在搅拌机里 混合搅拌那样，直到不能区分彼此的 时候，你就得到了质量。

我的看法：

• 狭义的测试指的是今天国内普遍认为的，由专职的QA针对软件功能进行测试。

• 广义的测试指的是从代码编写开始，每一次代码被执行的过程，这里包括单测，自动化测试，集成测试，端到端测试，产品走查，上线之后的用户使用等流程。

• QA永远只能在有限的条件下执行部分代码，而且随着软件越来越庞大，端到端测试能模拟的情况也会更加苛刻，端到端测试能覆盖的情况会更少，能预防出问题的概率也就更有限。

• 随着软件复杂度的提升，QA所能看到的往往只是冰山一角，不了解冰山下的原理而执行的端到端测试，是成本高且效率低的做法，很难有打蛇打七寸的效果。

• 要想从根本上提升软件质量，深入到冰山里面，在理解软件到底在做什么的条件下进行测试才能提高质量。这大概就是google把大量的测试工作交给研发人员，而收到较好的产品质量的根本原因吧。

• 在对产品上线速度有极致追求的情况下，人为的测试

角色

SWE(Software Engineer)

软件开发工程师，增加功能、提高性能

SET(Software Engineer in Test)

软件测试开发工程师，也是开发角色，重心在可测性测试和通用测试基础框架上。

• 更关注质量提升和测试覆盖度的增加。

• 写代码的目的是可以让SWE测试自己的功能。

• SET针对各个模块的依赖提供了mock或fake的实现。

TE(Test Engineer)

测试工程师，承担着产品专家、质量顾问、风险分析师的角色。

• 把用户放在第一位思考

• 组织整体质量实践、分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试

• TE运行许多测试的同时，也负责和其他团队的TE、合同工编制的测试人员、以众包形式参与的测试者、内部尝鲜者、beta测试者以及早期用户进行合作交流，与各方讨论基本设计带来的风险、功能逻辑复杂性和错误避免的方法。

SWE负责功能的实现和这些独立功能的质量。SET让开发者可以很容易的编写测试代码， 从而达到独立功能模块的质量要求。TE则是专注于用户角度的测试，验证可执行的代码 与数据集成之后，是否可以满足最终用户的需求。

我的看法

• 从Software Engineer In Test角色的设置看，google很重视自动化测试。其并不否认模块测试和端到端测试，但希望能把这些测试尽可能的自动化，以提升测试效率，尽可能的发现问题。

• 需要注意的是，Software Engineer In Test不是写自动化测试，而是写自动化测试工具，测试还是SWE自己写，只有SWE最清楚自己的代码到底是怎么运行的。

• TE有点像我们的QA，但又差别巨大

测试认证计划

测试认证是：如果一个团队完成了一系列的测试任务，这个团队会得到一个通过“认证”的标识。所有团队最初的级别都是 0。如果掌握了基本的优秀代码习惯，就达到级别1，然后继续通过水平考核，最终达到级别5，与外部的能力成熟度模型一样，例如CMM能力成熟度模型（译注：http://www.sei.cmu.edu/cmmi/start/faq/related-faq.cfm）

我的看法

具体的认证计划当然也很有意义，但更让我感兴趣的是，这么一个全公司范围内的制度，是如何一步步落地的。

从书中描述的认证计划创始人的访谈中，我们能窥探一二。首先这个制度不是一个从上到下强制执行的政策，也就是说，测试团队不是找到公司的CEO，CTO这类高级管理人员沟通，说我们有个好东西，推行下去吧。这样容易导致几个问题

1. 高层很容易因为不了解下面的具体情况而误判，执行了一个不适合团队的政策。

2. 执行团队很少有反馈的机会，毕竟这可是大老板排班决定的。

3. 一个没有和具体情况结合，缺少反馈的制度，通常缺乏生命力。执行者可能是抱着完成任务的心态去执行，能希望这样的态度有什么好的结果呢？

反观书上落地的路径，这样一个制度就像是一个产品，我相信创始人可定得到了上层的授意，不然不太容易拉通公司多个部门的资源。（可能我想的也不对），创始人先找了一些种子用户——既具体指定团队，和他们充分沟通，不断调整获得反馈，在反对的声音中也在让产品使用用户需求，然后由种子用户扩散出去，逐渐形成全公司范围内的标准。