互联网企业是时候甩掉你的测试部门啦！（How google test software读书笔记）

在传统软件行业浸淫了10年，带领的研发团队经历了如下几个阶段：

初创期-10人左右的团队，全能研发工程师，从需求到研发到测试到运维，一个人全搞定，超高效率的时代，成就感爆棚；

发展期-30~50人左右团队；团队中开始出现专职的1~2个测试人员，此时的测试人员完全隶属在开发团队中，和研发团队打成一片，不过测试人员更侧重于全局测试和压力，安全等专业性测试

壮大和成熟期-100+以上的团队，随着团队的发展，软件质量越来越差，线上问题越来越多，专职测试人员越来越多，开始有独立的测试部门，开始有专业的测试技能，测试越来越细，覆盖度越来越广；和开发的界限开始划分的无比明确，不同的KPI，不同的部门目标，甚至团队之间的协作也开始采用流程来协同和规范；

相信目前超过100+以上的研发团队都经历的无比类似的曲折过程。

当测试部门逐步壮大起来时，我当时的团队100个人员左右，测试人员就站到3成的比例，研测比达到了2.5:1。可是质量真的被提升了吗？大多数同学都会发现通过测试来保证质量的过程是无比痛苦的，是在测试和研发的对立，斗争和各种资源内耗中取得一点点的提升。这些真的值得吗？

测试无法把握需求，不产生代码，仅仅靠最后的测试来把好最后一道质量关真的可以吗？这样的权责不对等，导致测试部门为了保障自己的利益，而设置各类关卡，送测流程就是其中最典型的产物。

Google也经历的类似的过程，在2011年左右决定解散测试团队，全面融合到研发团队中，研发人员需要同时拥有和测试的技能；仅仅保留少量的非常专业的测试顾问，负责超大型项目的测试设计，或者是研发团队测试能力建设工具。

Facebook从一开始就打出了不要测试人员的宣言，软件的质量理应由创立这些代码的人自己保证。

对于我自己，经历了痛苦的研发与测试对立产生的巨大内耗的过程。我也对研测感到深恶痛绝。保持组织的高效，一定要做大组织的解耦，按照业务模块即最终的业务目标和结果划分成足够小的业务单元，让业务单元自运作起来。只有这样才能充分激活组织活力，保证组织高效。跟美国的要州权，不要大政府是一个道理。

分享我的How google test software读书笔记：

google软件测试改进方向：更名为工程生产力部门，原来的测试人员拆分到各个产品团队。

.质量是内建的，而不是外加的

.测试的第一个致命的缺陷：

测试成了开发的拐杖，越不让开发考虑测试的问题，把测试变得越简单，开发就越来越不会去做测试。

.测试在google作为一个独立的部门，把开发养的太懒了。

测试的第二个致命的缺陷：

.分离的组织

.测试人员更关注角色，而不是产品。

.测试人员崇拜测试的产物胜过软件本身

第三个：迷信测试的产物胜过软件本色

第四个：经过最严格测试的产品还是会有bug

0.文化

• 将自动化做到，力争“克服人类智慧的 最后一英寸的”，.google feedback团队：聚类算法自动识别充分记录并确定最频繁问题，有一个dashboard用于显示经过处理的数据，帮助产品团队进行分析。
  
• 共享与开放：任何的一个工程师都可以访问google所有的代码；.google bug数据库完全开发，任意工程师可以看到任一项目的任一bug，也可以为任一项目提交bug；
• 同僚奖金：peer bonus,鼓励大家提供共享代码库；如果找到更好解决方案，也鼓励去重构和改变。
• 创新：20%时间 可以投入到“业余项目”中
• 质量不等于测试。当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。
• 开发人员对自己的代码负责。google的文化：从代码审核时的：测试在哪儿，到厕所文化贴上的最佳测试实践。
• google内部是分布式和自我管理的文化，“州权“是常态，大政府理念会收到嘲弄。

经典语录：

• 对一个坏点子或考虑欠周的产品，即便再多的测试，也无法把它变成一个成功的产品；
• 但如果测试方法不当，却会扼杀一个本来有机会成功的产品或公司，至少拖慢产品的速度，让竞争对手有机可乘。

1.角色

SWE:增加功能性代码  

SET:关注质量提升和测试覆盖率的增加  

TE：代表用户

2 不同的版本

金丝雀版本:每日构建版本

开发版本：每周发布一个，产品工程师都会安装这儿版本，在日常生活中真正使用它

测试版本：通过了持续测试的版本，一个月发布一个

.dogfood 内部尝鲜版本：

.beta或发布版本

3.测试类型

.小型测试：涵盖单一的代码，在完全虚假实现的环境里

.中型测试：涵盖多个模块，且重点关注模块间的交互，运行在虚假实现环境或者真实环境中

.大型测试：真实的环境，真实的用户数据与资源

  基于用例的测试与探索性测试：基于用例的测试尽量采用自动化方法实现，而专业测试人员更多的进行需要创新性思维的探索性测试。

.众包：大众用户带来大量的硬件和配置，提供多种不同的视角。编写产品导览，直接将用户引导到应用的特定部分；还可以编写多个导览指南，分发给不同的大众用户。悬赏奖励最佳Bug发现者

.在google有几个团队，在于外包接洽或者组织众包型的探索式测试时，更愿意使用比较一般性的故事，而不是太细节的测试用例。很细节的测试用例反而导致外包人员在一遍又一遍的重复执行时产生厌倦感，而用户故事则为具体行为留出了更大的余地，从而使测试变得更有趣。

4.测试计划：

.10分钟测试计划；30分钟可以获得 80%的完整性

.不输出测试用例的测试计划是耍流氓

5.一个版本的构建过程：库构建目标，测试构建目标：

1.编码

2.设定为公共库

3.编写单元测试用例，编写外部mock

4.创建测试构建目标

5.构建并允许测试目标

6.运行静态代码分析工具

7.申请代码审核

6.google测试计划的方法轮：ACC：特质，组件，能力

样例：google+

特质：社交 表达 轻松  相关  可扩展 隐私

组件：profile people  stream cicles

能力：

profile：

社交：与好友和联系人分享个人信息和偏好设置

表达：用户可以创建虚拟世界里的自己

表达：用google+表达你的个性

7.工具：

自动化测试框架

持续构建的框架

bite：从报bug的冗余工作中释放出来

GTA:测试分析系统

RPF：录制回放框架

.测试机器人:quality bot

.零成本测试流程

google 称为工程工具团队。 这些工具支持开发人员完成高质量的软件编写，构建和发布。

• 源码工具：一系列用于简化创建工作环境、提交代码变更、代码风格检查的工具。可以用工具浏览数亿万行的代码，发现并预防重复的代码。还有用于建立大规模索引和代码重构的工具。
• 开发工具：集成开的发环境的一些插件，让其他各种工具适应google的代码并连接后端的云服务。代码审查工具，通过在审查阶段嵌入相关的信号，来快速完成高质量的代码审查。
• 构建框架：构建系统支持自动式，交互式，可以把原本需要数小时的任务缩短到数秒
• 测试基础架构：规模化的持续集成，开发人员的每次代码提交都会引发自动测试；另一方面是规模化的web测试，每个google产品都会启动数十万个浏览器会话，对各种不同的浏览器平台组合进行测试。
• 本地化工具
• 度量，可视化和报表：管理所有产品的bug，跟踪所有研发活动中工程师的各项指标。