《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的寿命从几个月变成几分钟。快速地进行构建、交付（给内部试用者、可信赖的测试者、早期或真实用户）​、修改、重新迭代交付，让很多用户根本来不及发现缺陷。这是一种更好的软件交付和用户反馈机制。

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

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

Chrome OS测试计划

测试主题

风险分析

每次构建版本的基线测试

LKG每日测试

LKG：Last Known Good，最新可测试版本。LKG的每日测试：

• 一系列功能验收测试的手工执行（可以限定每天在一种类型的硬件环境中执行）​
• 功能回归测试自动执行
• 在每日构建版本上，滚动式地持续执行Web应用程序的测试（包括自动和手工测试）​
• 滚动式执行压力测试、可靠性测试、稳定性测试等。在每日构建版本上反复执行这些测试，直到没有新问题出现，然后转为每周执行
• 持续地进行手工探索式测试和漫游式测试

发布版本测试

包括如下测试：

• 站点兼容性：Chrome浏览器测试团队负责对前100名站点(Top100)在Chrome OS上进行验证；
• 场景验证：对Chrome OS对外展示或者向合作伙伴发布的示例性场景（可能最多有两到三个示例）进行验证；
• P0 bug验证：验证所有已被修正的优先级为P0的bug。验证80%的自上次发布版本以来记录的优先级为P1的bug；
• 全面压力和稳定性测试：执行一次压力和稳定性测试；
• Chrome OS手工测试用例：执行所有的Chrome OS手工测试用例（可以分派给不同的测试人员和不同的硬件环境）​。

其他

手工测试与自动化测试：

开发和测试的质量关注点：

发布通道：

用户输入：

测试用例库：

测试仪表盘：

虚拟化：

性能：测试团队的目标是辅助性能指标测量的执行、报告和趋势总结，而不是直接开发性能测试。

压力、长时运行和稳定性测试：Long Running测试；通过底层平台进行故障注入。

Autotest：测试执行框架，

OEM厂商：测试和开发团队共同努力为OEM厂商发布相关的手册和自动化测试用例，OEM厂商负责检测构建版本和硬件的质量。

硬件实验田：这些实验田机器主要通过HIVE架构来管理。疑问：这个HIVE不是大数据那个Hive，网络上没有搜到相关的资源。

端到端测试自动化集群：

测试浏览器的应用管理器：

浏览器的可测试性：

硬件：

时间线：

主要的测试驱动力：

相关文档：

Chrome漫游测试

Chrome漫游测试包括：

• 购物漫游
• 学生漫游
• 国际长途电话漫游
• 地标漫游
• 通宵漫游
• 公务漫游
• 危险地带漫游
• 个性化漫游

O3D：参考wikipedia。