《Google软件测试之道》笔记

介绍

GTAC：Google Test Automation Conference，Google测试自动化大会。

本书出版之前还有一本《微软测试之道》，值得阅读。

质量不是被测试出来的，但未经测试也不可能开发出有质量的软件。质量是开发过程的问题，而不是测试问题。开发要对质量负责，开发也是测试。

几个角色：

SWE：Software Engineer，软件开发工程师，开发角色，需要编写与测试代码，关注于客户（用户）使用的功能代码的实现；
SET：Software Engineer in Test，软件测试开发工程师，开发角色，工作重心是可测试性和通用测试基础框架，为质量服务；
TE：Test Engineer，测试工程师，测试角色，从用户角度做功能性测试，自动化脚本或代码的编写。

测试是独立存在的部门，测试人员在不同项目之间的借调模式。

在一个产品的基本核心功能实现之后，就立刻对外发布使用，然后从用户那里得到真实反馈，再进行迭代开发。Gmail带着beta标签在线上运营四年，早期版本并不意味着是一个不可用的烂版本。

一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta或正式发布版本：

金丝雀版本：每日构建版本，用来排除过滤一些明显不适宜的版本；
开发版本：开发人员日常使用版本，一般每周发布一个。具有一定的功能并通过一系列的测试；
测试版本：通过持续测试的版本。基本上是最近一个月里的最佳版本。可被挑选作为内部尝鲜（dog food，对应地，dogfooder意思是内部试用者）版本，如果该版本有比较持续的优良表现，可作为beta测试的候选版本；
beta或发布版本：由非常稳定的测试版本演变而来，经历内部使用和通过所有质量考核的版本，也是对外发布的第一个版本。

测试类型：

小型测试：一般都是自动化实现，用于验证一个单独函数或独立功能模块的代码是否按照预期工作。小型测试是由SWE来实现，也会有少量的SET参与，TE几乎不参与小型测试。一般需要使用mock和fake。
中型测试：通常也都是自动化实现，一般会涉及两个或两个以上，甚至更多模块之间的交互。重点在于验证这些功能近邻区之间的交互，及彼此调用时的功能是否正确。
大型测试：涵盖三个或以上（通常更多）的功能模块，使用真实用户场景和实际用户数据，一般可能需要消耗数个小时或更长时间才能运行完成。关注所有模块的集成，更倾向于结果驱动，验证软件是否满足最终用户的需求。三种角色的工程师都会参与到大型测试中，通过自动化测试或探索式测试的形式。

Noogler：Google的新员工。

Off-by-one error：OBOE，差一错误，在计数时由于边界条件判断失误导致结果多一或少一的错误，通常指编程中循环多一次或少一次的程序错误，逻辑错误的一种。

SET

Feature Developer：功能开发人员，思维模式是创建，重点在考虑用户、使用场景和数据流程上
Test Developer：测试开发人员，主要思路是去破坏，怎样写测试代码用以扰乱分离用户及其数据。

User Developer：用户开发人员，需要解决的主要问题是面向用户的任务，包括用例(use case)、用户故事、用户场景、探索式测试等。关心这些功能模块如何集成在一起成为一个完整的整体，主要考虑系统级别的问题，通常情况下都会从用户角度出发，验证独立模块集成在一起之后是否对最终用户产生价值。

单元测试展板：Unit Test Dashboard，

Chris/Jay持续构建工具：其他团队通过注册一台机器、填写一个配置文件和运行一个脚本，就能够运行自己的持续集成。

提交队列：Submit Queue，主要功能是保持绿色的构建，即所有测试必须全部通过。这是构建系统和VCS之间的最后一道防线。

TAP：Test Automation Program。

BugDB：Google第一个bug数据库，几张数据库表+一些查询检索功能+一些统计报表数据。

Buganizer：Google内部使用的缺陷管理系统，开源版本的Buganizer被称为问题跟踪工具，在Chromium项目中有使用。

Matrix项目：

Selenium在浏览器内部使用JS实现，而WebDriver使用浏览器本身的API集成到浏览器内部。两种方法各有优劣。Selenium可以瞬间打开一个新的Chrome浏览器，但却不能上传文件或很好地处理用户交互，基于JS实现，必须限定在JS沙箱内。WebDriver构建在浏览器里，可以突破这些限制，但打开一个新的浏览器却比较痛苦。

后来Selenium和WebDriver集成到一个项目，WebDriver成为Selenium项目的一个子集。

在Google，不同团队使用各自的Web自动化框架。Chrome使用PyAuto，Search使用Puppet（有个开源版本Web Puppeteer），Ads使用WebDriver。

DDD：Defect Driven Development，缺陷驱动开发。

测试命名规则

一套测试命名规则：

小型测试：验证一个代码单元的功能，一般与运行环境隔离。外部服务（如文件系统、网络、数据库）必须通过模拟或虚假实现(mock and fake)。为了减少依赖，适当时候也可模拟实现被测类所在模块的内部服务。
中型测试：验证两个或多个模块应用之间的交互，主要目标是验证指定模块之间的交互。
大型测试：验证整个系统作为一个整体是如何工作的。

Google测试执行平台
TODO

大型测试的优点和缺点：

测试最根本的：在考虑外部系统的情况下应用系统是如何工作的；
对外部系统有依赖，因此是非确定性的；
很宽的测试范畴意味着如果测试运行失败，寻找精准失败根源就会比较困难；
准备测试数据会非常耗时；
大型测试是较高层次的操作，如果想要走到特定的代码路径区域是不切实际的，而这一部分却是小型测试的专长。

中型测试的优点和缺点：

不需要使用mock技术，且不受运行时刻的限制，从大型测试到小型测试的一个过渡；
运行速度相对较快，可频繁运行；
可在标准的开发环境中运行，开发人员也可以很容易运行它们；
依赖外部系统，不确定性；
运行速度没有小型测试快。

小型测试的优点和缺点：

为了更容易地就被测试到，代码应清晰干净、函数规模较小且重点集中。为了方便模拟，系统之间的接口需要有良好的定义；
可很快运行完毕，在代码发生变更时就可以且应该立马运行，从而较早地发现缺陷并提供及时的反馈；
在所有环境下都可以可靠地运行；
测试范围较小，可很容易地做边界场景与错误条件的测试，如空指针；
有特定的范畴，可很容易地隔离错误；
有时对子系统的模拟有难度；
使用mock或fake环境，可以不与真实环境同步。

小型测试带来优秀的代码质量、良好的异常处理、优雅的错误报告；大中型测试带来整体产品质量和数据验证。单一的测试类型不能解决所有项目需求。

测试认证

Test Certified，测试认证：如果一个团队完成一系列的测试任务，这个团队会得到一个通过认证的标识。所有团队最初的级别都是0。掌握基本的优秀代码习惯，就达到级别1，然后继续通过水平考核，最终达到级别5。与能力成熟度模型一样，如CMM能力成熟度模型。

测试认证级别摘要

级别1
- 使用测试覆盖率工具
- 使用持续集成
- 测试分级为小型、中型、大型
- 明确标记哪些测试是非确定性的测试
- 创建冒烟测试集合
级别2
- 如果有测试运行结果为红色（失败）就不会做发布
- 在每次代码提交之前都要求通过冒烟测试
- 各种类型测试的整体增量覆盖率要大于50%
- 小型测试的增量覆盖率要大于10%
- 每一个功能特性至少有一个与之对应的集成测试用例
级别3
- 所有重要的代码变更都要经过测试
- 小型测试的增量覆盖率要大于50%
- 新增的重要功能都要经过集成测试的验证
级别4
- 在提交任何新代码之前都会自动运行冒烟测试
- 冒烟测试必须在30分钟内运行完毕
- 没有不确定性的测试
- 总体测试覆盖率应该不小于40%
- 小型测试的代码覆盖率应该不小于25%
- 所有重要的功能都应该被集成测试验证到
级别5
- 对每一个重要的缺陷修复都要增加一个测试用例与之对应
- 积极使用可用的代码分析工具
- 总体测试覆盖率不低于60%
- 小型测试的代码覆盖率应该不小于40%

TE

TE职责的一般性描述：

测试计划和风险分析
评审需求、设计、代码和测试
探索式测试
用户场景
编写测试用例
执行测试用例
众包，crowd sourcing
使用统计
用户反馈

GTA：Google Test Analytics。

测试计划

测试计划应该有的特性：

及时地更新
描述软件的目标和卖点
描述软件的结构、各种组件和功能特性的名称
描述软件的功能和操作简介
不必花过多的时间去撰写，必须随时可以被修改
描述必测点
应该能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足

ACC：Attribute Component Capability，即特质、组件、能力。一种测试计划的替代方法。ACC的指导原则：

避免散漫的文字，推荐使用简明的列表；
不必推销，其受众人群是工程师；
简洁；
不要把不重要的、无法执行的东西放进测试计划；
渐进式的描述：Make it flow。测试计划的每个部分应该是前面部分的延伸；
指导计划者的思路；
最终结果应该是测试用例。

ACC通过指导计划者依次考察产品的三个维度达成这个目标：

描述产品目标的形容词和副词；
确定产品各部分、各特性的名词；
描述产品实际做什么的动词。

能力处于特质和组件的交点。组件(component)执行某种功能(function)来满足产品的一个特质(attribute)，这个活动的结果是向用户提供某种能力(capability)。

风险

确定风险的过程称为风险分析。影响风险的因素很多，试图精确地、定量地计算风险比缓解风险还要麻烦。分析风险的两个要素：失败频率(frequency offailure)和影响(impact)。

GTA中的风险发生频率有4个预定义值：

罕见(rarely)：发生故障的可能性很小，发生问题后恢复也很容易；
少见(seldom)：在少数情况下会发生故障，在使用场景复杂度不高的情况下或使用率较低的情况下，发生的可能性非常小；
偶尔(occasionally)：故障的情形容易想象、场景有点复杂，而该能力是比较常用的；
常见(often)：此能力所属的特性使用量大、复杂度高、问题频发。

估计风险影响的方法：

最小(minimal)：用户甚至不会注意到的问题；
一些(some)：可能会打扰到用户的问题。一旦发生，重试或恢复机制即可解决问题；
较大(considerable)：故障导致使用受阻；
最大(maximal)：发生的故障会永久性的损害产品的声誉，并导致用户不再使用它。

风险相关人员：开发人员、项目经理、销售人员、总监和VP。

一旦风险估计为相关人员所认同，接下来就是风险缓解(Risk Mitigation)。

风险不大可能彻底消除。就软件而言，一种极端的风险缓解办法是去掉风险最大的组件：交付的软件越少，风险越小。缓解风险的措施：

围绕风险大的能力点编写用户故事，并从中确定低风险的使用场景，然后反馈到开发团队，请他们有针对性地增加约束；
编写回归测试用例，以确保问题在重现时可以被捕捉到；
编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性；
插入监听代码(instrumentation and watchdog code)，以便更早地检测到故障
插入代码监听软件，发现新旧版本间的行为变化以发现回归问题。

风险热图

在软件开发中，任何一种可以在10分钟之内完成的事情都是微不足道的，或是本来就不值得做的。

生命周期

包括测试用例和Bug的生命周期。

Test Scribe：

GTCM，Google Test Case Manager，Google测试用例管家。设计思想是简化测试用例的编写。它提供了一种灵活的标签格式，任何项目可以自行定制，这使得测试用例便于查找和复用。最重要的是，将GTCM与Google的基础设施相集成，使得测试结果得以成为头等公民。

cukes：一种行为驱动的测试用例描述

Buganizer的设计目标：

更加灵活的n级组件层次，以取代BugDB简单的项目>组件>版本层次（当时所有的商业bug数据库都是如此）
更好的bug跟踪审计，与分类和维护有关的新工作流
更容易的跟踪一组bug以及创建、管理常用项列表
登录验证，更加安全
创建汇总图表和报告的支持
全文搜索和变更历史
Bug缺省设置
更好的可用性，更加直观的用户界面

WebKit使用Mozilla的Bugzilla来记录问题，chromium.org则使用Issue Tracke。

Bug的各种字段：

Assignee：Assigned to，被指派者
CC：抄送
Attachments：附件
Blocking：阻塞，该Bug修复之后才能被修复的其他Bug的IDs，以逗号分隔。更新此列表会导致所列Bug的Depends On字段被自动更新
Depends On：依赖，该Bug依赖的其他Bug的IDs，在其他Bug被修复之前，该Bug无法修复。更新此列表会导致所列Bug的Blocking字段被自动更新
Changed：变化，只读，该问题的最后修改日期和时间
Changelists：变更列表
Component：组件，必选，有此Bug或需求的实体。创建问题时，这应当是指向组件的完整路径，不限长度。不一定要给出叶子组件（没有子节点）。只有项目和工程经理才能增加组件
Created：创建于，只读，Bug创建日期
Found In：发现于，可选，输入发现Bug时的软件版本号
Last Modified：最后修改，只读，该问题的任一字段被修改的最后日期
Notes：备注
Priority：优先级，必填字段，
Reporter：Reported by，报告者
Resolution：解决方案
Severity：严重性，必填字段，严重性和优先级没有必然联系。如在搜索页的图标中的Google错误拼写的严重程度(severity)比较低，但优先级(priority)高。可供参考的严重程度等级：
- S0：系统不可用
- S1：高
- S2：中
- S3：低
- S4：对系统无影响
Status：状态，必填字段，维护Bug的当前状态。可选字段：New（新建）、Assigned（已指派）、Accepted（已接受）、Fix later（以后修复）、Will not fix（不修复）、Fixed（已修复，问题已经被修复，但结果尚未验证）、Verifier assigned（验证者已确定）、Verified（已验证）
Summary：摘要
Targeted To：目标，用于输入该Bug应该被修复的软件版本号
Type：类型，必填字段，表示问题的类型：
- Bug：缺陷，导致程序无法按预期工作；
- Feature Request：需求，希望加入程序的功能；
- Customer Issue：客户问题，客户反馈的问题；
- Internal Cleanup：内部清理，需维护的东西；
- Process：流程，通过API自动跟踪的东西。
Verified In：验证于，用于输入问题修复被验证的软件版本号；
Verifier：验证者。验证者与被指派者可以是同一个人。

Bug的生命周期
在这里插入图片描述
Google的Bug管理与其他公司有几个关键的不同之处：

Bug数据库是完全开放的；
所有人都提交Bug；
不存在正式的自顶向下的确定Bug优先级的流程

Google Feedback：全公司范围的提交Bug的系统。

Maintenance Mode Testing

Google一向以尽早交付、经常交付、尽快失败(shipping early andoften，and failing fast)闻名于世。资源也会冲向那些最高风险的项目。

淘汰手工测试用例时，使用的指导方针：

总是通过的测试，淘汰！在高优先级的测试都来不及做的时候，低优先级的测试，淘汰！
确保正确理解即将被淘汰的测试用例。从即将淘汰的领域里，挑选几个有代表性的测试。如果可能就与原作者聊一聊，理解其意图，避免失误。
把释放出来的时间用于测试自动化、高优先级的测试或探索式测试。
抛弃之前发生过误报或行为反常的自动化测试。

进入维护模式前的考虑点：

撤离之前，把困难的问题解决掉，而不是轻易放过。
即使一个小型的、负责端到端测试的自动化测试集，也会以近乎为零的成本提供长期的质量保证。如果没有，一定要建立一个这样的自动化测试集。
留下一份how-to文档，以便公司的任何人都可以运行你的测试集，这也会减少你在将来繁忙时还被突然打扰的可能性。
确保有一个问题解决通道(escalation path)，愿意承担一些责任。
时刻准备着返回到你曾经工作的项目里帮忙，这对产品、团队和用户都有益。

QualityBot

利用像素级DOM分析，针对Web页面在Chrome不同发布版本间的比较工具。

BITE

Browser Integrated Testing Environment，浏览器集成测试环境，一款开源的Chrome扩展插件。目标是把尽可能多的测试活动、测试工具和测试数据集中到浏览器和云里，并在上下文中呈现相关信息，从而减少分散操作的麻烦，使得测试工作更高效。

资源越少，目标越明了(scarcity brings clarity)。

RPF：Record and Playback Framework，基于JS的纯Web解决方案，将测试用例脚本保存在云端。RPF甚至可在不支持Selenium和WebDriver测试用例执行的Chrome OS上运行。核心设计理念，是旨在避免查看应用的DOM和在发生变化时重新计算元素的XPaths的痛苦。

RPF还可用于支持BITE中的Bug提交场景。

GTA

一个方便数据输入和风险可视化的Web应用。GTA的UI设计结合ACC的最佳实践。通过统一数据格式，经理和总监们可在一个视图中看到各种产品的风险，易于定位高风险领域并分配资源。

零成本测试流程

端到端的测试流程
在这里插入图片描述
测试流程的要点：

通过GTA进行测试计划：基于风险的、快速的、可自动更新的；
测试覆盖度：每当一个产品部署新版本，bot就会连续抓取网站、索引内容、扫描差异。bot可能不会区分回归和新特性，但它们可以发现所有变化并交给人工去做筛选。
Bug评审：当产品的差别被发现时，它们会被自动的转给人工去做快速判断。是回归还是新特性？在进行差别检查时，BITE可以提供现有的Bug和丰富的测试上下文信息；
探索式测试：频繁的探索式测试由外包测试人员和早期用户执行。这会捕捉到与配置、上下文相关的Bug，以及其他各种各样难以发现和报告的Bug；
Bug提交：只需点击几次鼠标就可提交Bug，大量相关数据被自动附上，包括问题的精确位置、截屏和调试信息
Bug triage和调试：开发或测试经理能看到近乎实时的Bug趋势图、需要用来分析失败原因的丰富的Bug数据，甚至是Bug发现过程的一键重放；
部署新的版本并回到第一步，重复上述步骤。

外部供应商

TEM

Test Engineering Manager，TEM，测试工程经理。

几个建议：了解你的产品、知人善用。

Gmail整合很多Google的产品，如Buzz、Docs、Calendar等

第一，因为它能够提高产品的质量；第二，因为它能提高工程师开发产品的效率。其他答案都没这些重要。

改进

让每个工程师都注重质量。

测试并不能保证质量。质量是内建的，而不是外加的。

几个致命缺陷：

测试变成开发的拐杖：保证质量应是开发者的任务；
开发和测试的组织结构分离：软件开发的最终目的是完成一个产品；
测试人员往往崇拜测试产物(test artifact)胜过软件本身：测试的价值是在于测试的动作，而不是测试产物；
产品经过最严格的测试发布后，必然还存在问题。

SET的角色越来越像开发，而TE的角色向着相反的方向越来越像用户。

TODO

通过互联网交付软件，意味着有能力选择部分用户进行发布，响应这部分用户的反馈，并迅速进行更新。开发者和最终用户之间沟通合作的障碍不复存在。Bug的寿命从几个月变成几分钟。快速地进行构建、交付（给内部试用者、可信赖的测试者、早期或真实用户）、修改、重新迭代交付，让很多用户根本来不及发现缺陷。这是一种更好的软件交付和用户反馈机制。

测试工程会转型成测试设计。少量的测试设计师快速地规划出测试范围、风险热图和应用程序的漫游路线。

随着敏捷开发、持续构建、早期用户介入、众包测试、在线软件交付的不断兴起，软件开发的问题也已经彻底改变。继续死守已存在数十年之久的测试教条无异于刻舟求剑。