《Google软件测试之道》之学习笔记01

Google软件测试介绍

软件测试团队->工程生产力(Engineering Productivity)

http://googletesting.blogspot.com/2011/01/how-google-tests-software.html

1.1 质量不等于测试

质量不是被测试出来的，质量不等于测试，每写完一段代码立刻测试这段代码，当完成更多的代码时做更多的测试，直到开发和测试融为一体，才能得到质量。

1.2 角色

"You build it, you break it, you fix it"

软件开发工程师(SWE: Software Engineer)

增加功能性的代码或提高性能的代码

对容错设计、故障恢复、测试驱动设计、单元测试负责

软件测试开发工程师(SET: Software Engineer in Test)

关注于质量的提升和测试覆盖率的增加，增加可测试性，甚至进行代码重构，编写单元测试框架和自动化测试框架

提供测试支持

软件测试工程师(TE: Test Engineer)

专注于用户角度的测试，模拟用户使用场景、编写自动化脚本或代码，组织各种类型的测试，分析、解释测试运行结果，驱动测试执行

模块级别和功能级别的测试应有SWE和SET完成

TE需要确认开发人员的测试工作是否到位，任何明显的bug都表明早期开发人员的测试工作存在不足或比较马虎

TE应更注意常见用户使用场景，是否满足性能期望，在安全性、国际化、访问权限等方面是否满足用户需求

与各方讨论基本设计带来的风险、功能逻辑复杂性和错误避免的方法

1.3 组织结构

一般，测试和开发人员隶属于同一个工程产品团队，管理者通常来自产品经理或开发经理，测试总是给开发让路

SET和TE没有遵循这个模式，测试成为一个独立的部门，平行于各个产品部门，测试人员以租借的方式进入产品团队，不直接向产品团队汇报

1.4 爬、走、跑

Google在一个产品的核心功能实现后立即发布，然后根据用户反馈再进行迭代

Chrome开发过程中的版本：

金丝雀版本：每日构建，排除明显不适宜的版本，这个版本可能无法使用应有的基本功能

开发版本：开发人员日常使用的版本，每周一个。具备一定的功能并通过了一系列的测试。所有相关的工程师都需安装，在日常使用，如不满足日常工作的需求，会被打回金丝雀版本

测试版本：通过了持续测试的版本，是最近一个月里最好的版本，也是工程师在日常使用中最稳定最信任的版本。可作为内部尝鲜(dog food)版本，若变现持续优良，可作为beta版本的候选

beta版本或发布版本：有非常稳定的版本演变而来，经历了内部使用和通过了所有质量考核

1.5 测试类型

小型测试

一般都是自动化实现的，用来验证一个单独函数或独立功能的代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差一(off-by-one)等错误

运行时间短，通常在几秒或更短的时间内完成

由SWE来实现，少量有SET参与，TE几乎不参与，但TE会运行这些测试

测试一般需使用mock和fake才能运行

mock对象是指对外面依赖系统的模拟，在运行时刻可以根据假设的需求提供期望的结果

fake对象是一种虚假的实现，内部使用来固定的数据和逻辑，只能返回特定的结果

中型测试

一般也都是自动化实现的，会涉及两个或两个以上的模块之间的交互

测试重点在于验证这些“功能近邻区”之间的交互，以及彼此调用时功能是否正确

SET会驱动这些测试的实现和运行，SWE会深度参与，编码、调试和维护这些测试，开发后期，TE会通过手动或自动的形式执行这些测试

大型测试

涵盖三个或以上的模块，使用真是用户使用场景和实际用户数据

一般需消耗数小时或更长时间才能运行完成

SWE、SET、TE都会参与其中

关注端到端的使用场景以及在整个产品或服务之上的操作行为

小中大型测试，相当于单元测试、集成测试和系统测试

能够自动化的应以自动化的方式实现，包括日常工作

回归测试中手动部分可通过定点点击或录制技术实现自动化，手动测试更倾向于关注新功能