网上有《What Test Engineers do at Google》的原文翻译，以及相关中文书籍《google软件测试之道》。今天不会在这里搬内容，写一些读书笔记和感悟。
测试团队成败，组织架构也是影响因素之一。Google的组织汇报关系被划分为不同的专注领域，包括：客户端、地理、广告、Apps、移动等等，所有工程师都汇报给这些专注领域的管理者、总监或副总裁。而测试是独立存在的部门，测试依托在各个产品领域部门内，称之为工程生产力团队。
cdn.xitu.io/2018/9/5/165a8d64ddf65e75?w=1320&h=328&f=png&s=35126">
软件测试开发工程师
职责：负责可测试性和测试自动化体系的长期有效性。
扮演质量顾问的角色
在单元测试方面给予开发人员支持
为开发人员提供测试框架，方便开发提高测试效率
参与设计评审、重构代码增加可测试性，编写单元测试框架和自动化测试框架
更加关注于质量提升和测试覆盖率的增加，SET写代码的目的是可以让SWE测试自己的功能
测试工程师
职责：评估对用户的影响以及软件产品整体目标上的风险
从用户的角度来思考质量方面各种问题
从开发角度来看，他们编写用户使用场景方面的自动化用例代码
从产品角度来看，他们评估整体测试覆盖度，并验证其他工程师角色在测试方面合作的有效性
产品专家、质量顾问和风险分析师
其中，几个重要信息：
开发可以做测试，测试可以写代码，Google其实还没有完全做到这一点
SET需要编码，熟悉系统设计，个人觉得更像测试架构师的角色
没有测试开发比例，开发同时也兼顾测试，专职测试让开发更加有效且高效地做测试
测试开发同工同酬
有外包测试人员
曾经介绍过传统软件测试人员以黑盒测试为主，在团队转型中，我们已经做出了改变，优先解决单一端的全栈测试，并且把单元测试作为一个关注点分水岭。
质量不是被测试出来的，这句看似陈词滥调的话却包含着一定的道理。
从汽车行业到软件行业，如果在最开始设计创建的时候就是错的，那它永远不会变成正确的。试问一下汽车行业的公司，大量召回事实上有质量问题的产品，代价是多么的昂贵。因此，从最初的创建阶段就要做正确，否则即便质检发现了质量问题，也将会陷入混乱的万劫深渊。
然而，这句话也并不像听起来那样的简单和准确。虽然质量不是被测出来的，但同样有证据可以表明，未经测试也不可能开发出有质量的软件。如果连测试都没有做，如何保证你的软件具有很高的质量呢？
有一个简单的办法可以解决这个难题，那就是停止开发与测试的隔离对立。开发和测试应该并肩齐趋。你的每一段代码写完后都要立刻测试这段代码，当完成了更多的代码时就做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分。质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。
质量不等于测试，测试不能保证质量，质量是内建的，不是外加的
质量是开发过程的问题，而不是测试问题
开发对质量负责
开发、测试相融合
写一段代码就立刻测试这段代码，完成更多的代码就做更多的测试，开发完成。
简单统一
测试类型划分：小型测试（70%）、中型测试（20%）、大型测试（10%），其实就是分层理念。弃用令人疑惑的测试类型术语：单元测试、代码级别测试、白盒测试、集成测试、系统测试、端到端测试。
其中一个亮点， Google在2007年，15个试点团队在不同级别运行：测试认证。开发人员遵循一些特定的测试实践，拿到期望结果，则通过认证。
测试成熟度，就是刚刚提到的：测试认证。个人看法：在敏捷团队，如果研发小组得到成熟度认证，可以区分不同程度测试资源投入。
Level 1
Set up test coverage bundles.
Set up a continuous build.
Classify your tests as Small, Medium, and Large.
Identify nondeterministic tests.
Create a smoke test suite.
Level 2
No releases with red tests.
Require a smoke test suite to pass before a submit.
Incremental coverage by all tests >= 50%.
Incremental coverage by small tests >= 10%.
At least one feature tested by an integration test.
Level 3
Require tests for all nontrivial changes.
Incremental coverage by small tests >= 50%.
New significant features are tested by integration tests.
Level 4
Automate running of smoke tests before submitting new code.
Smoke tests should take less than 30 minutes to run.
No nondeterministic tests.
Total test coverage should be at least 40%.
Test coverage from small tests alone should be at least 25%.
All significant features are tested by integration tests.
Level 5
Add a test for each nontrivial bug fix.
Actively use available analysis tools.
Total test coverage should be at least 60%.
测试尽早参与，各个环节参与，多Review文档，代码，架构。Code Review 是专门有一套Submit的流程；
高度自动化，强调持续集成；
测试分大中小测试，大中小范围、执行人、时间和要求不一样；
及早参与测试，毕竟质量不是测试出来的，整个研发过程的第一行编码已经决定了质量的高低，过程中反馈风险，利用有效测试策略消除质量障碍，确保检验处有问题的地方及时修改，避免遗漏上线。
先会爬，再会走，最后跑起来，版本划分短频×××个要点。
金丝雀版本（Canary Channel），不太可靠的版本，并不适用于发布。就像一只金丝雀在煤堆里一样，如果不幸身亡，那说明还有工作要去做。只有超强容忍能力的用户才有可能使用金丝雀版本来试验运行，你不能依赖这样的应用能把实际工作完成。
开发版本（Dev Channel)，是开发工程师们日常工作中使用的版本。所有的同一产品组的工程师都需要去安装这个版本，并在真正的工作中使用他们。
测试版本（Test Channel），是给内部的狗食，如果能够有持续不错的性能表现的话，也可能会是 beta 版本的候选。【译者注，dog food，一般指自己团队的产品，给自己或者公司内部的人尝试使用的中间产品】
Beta 版本或发布版本(The Beta Channel or Release Channel)，是给外部用户使用的第一个版本。只有在之前的各种版本历程中通过了测试和真实用户的枪林弹雨般的验证后，才会成为 beta 版。
上述的这种从爬到走、走到跑的模式，让我们在运行一些测试同时又可以对我们的应用系统做一些试验调整，并从真实用户和每个版本的每日自动化测试那里得到及时的反馈。
对于这样的过程，还有一些分析角度的益处。例如，发现了一个 bug，测试人员可以根据这个 bug 创建一个测试用例，并针对所有的每一个版本都运行这个测试用例，从而可以验证这个 bug fix 是否在所有的版本中都真正得到了修复。
测试成了开发的拐杖
质量需要每一个人的贡献，而不专属于“测试”工程师。我们越不让开发考虑测试的事情，把测试变得越简单，开发就越来越不会去做测试。测试在Google是一个独立的部门，让这个问题更严重。保证质量不但是别人的问题，它甚至还属于另一个部门。责任方很容易确定，出问题的时候也很容易就把责任推卸给质量部门。
开发和测试的组织结构分离有关
测试人员更关注自己的角色，而不是他们的产品，每一个工程师的角色都是为总体产品服务的，而角色本身是次要的。 如果产品不被关注，它就好不了。毕竟，软件开发的最终目的不是编码，不是测试，不是文档，而是完成一个产品。每一个工程师的角色都是为总体产品服务的，而角色本身是次要的。健康的组织一个标志是，人们会说“我在为Chrome工作”，而不是“我是测试”。
任何角色都不应被过分强调。团队的每个人都是在为产品工作，而不是为了开发过程中的某个部分。开发过程本身就是为产品服务的。用户爱上的是产品，而不是开发产品的流程。
在Google，开发与测试的分离造成了基于角色的关联，阻碍了测试人员对产品的关注。
测试人员往往崇拜测试产物胜过软件本身
测试的价值是在于测试的动作，而不是测试产物。相对于被测代码来说，测试工程师生成的测试产物都是次要的：测试用例是次要的；测试计划是次要的；bug报告是次要的。这些产物都需要通过测试活动才能体现价值。所有测试产物的价值，在于他们对代码的影响，进而通过产品来体现。
独立的测试团队，倾向于把重点放在建设和维护测试产物上。如果把测试的目标定位在产品的源码上，整个产品都将受益。因此，测试人员必须把产品方在第一位。
产品经过最严格的测试发布以后，用户几乎必然发现测试中遗漏的问题
产品经过最严格的测试发布以后，用户有多大可能仍然能发现测试中的遗漏的问题？答案是：几乎必然发现。是谁在做测试不重要，关键是进行了测试。内部试用者、可信赖的测试者、众包测试者，以及早期用户都可能比测试工程师更容易发现bug。实际上，TE做的测试越少，支持其他人做的测试越多，效果就越好。
软件测试团队的发展，也是围绕着质量闭环活动而壮大的，不同的质量活动环节，需要不同的人。刚开始创业的时候，可能一人多职能，到了后面可能是专人专职，分工喜欢，不管怎么分，都离不开质量闭环活动。
随着团队不断壮大，技能集合也在扩大，下图是整理的测试技术栈，通过分层来展示每个方面的覆盖策略和工具，可以在此基础上建立梯队能力。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
