开场主旨演讲 - 可测试的 JavaScript - 设计应用的可测试性
Mark Trostler（Google）
可测试的 JavaScript 是一个进程。无论是从空白可选广告开始，还是已经实施的应用（或在两者之间实施），都可以简单、简洁且有效地测试 JavaScript 代码，这是一项必要功能。无法测试的代码将被重写。
尽管 JavaScript 在许多环境中运行的环境非常独特，但也有一些源自其他语言且久经考验的“可测试”方法，这些方法也适用于 JavaScript。当然，JavaScript 开发者在编写和测试代码时仍面临着一些独特的挑战。
哪些模式支持代码测试？哪些反模式会阻碍测试？哪些指标和常识性指南可用于衡量代码的可测试性？创建可测试代码的流程现在开始了，具体是什么？
和我一起来学习编写可测试 JavaScript 的过程。我们将会调查可显著提升可测试性，从而显著提升代码的可维护性、正确性和长效的想法、模式和方法。无论您是编写客户端 JavaScript 还是服务器端 JavaScript 来掌控此过程，都会大大提高代码的质量。
打破矩阵 - 大规模 Android 测试
Google、Stefan Ramsauer (Google) 和 Valera Zakharov (Google)
您准备好服用红色药了吗？
移动设备改变了人们与计算机互动的方式。这很棒，但作为工程师，我们面临着一个不断增长的环境矩阵，它运行我们的代码。过去考虑少量浏览器和屏幕分辨率的日子已经结束了。工程师该如何应对矩阵？我们将介绍 Google 如何在工作站、云端和脑中抵御这一测试问题...
“我试着摆脱你的内心，Neo。但我只能向你显示门门情况。你必须竭尽所能才能做到。”
Android 界面自动化
Guang Zhu（周光） (Google) 和 Adam Momtaz (Google)
随着 Android 在移动世界越来越受欢迎，应用开发者和 OEM 供应商正在探索如何对应用或整个平台执行界面驱动的端到端测试。在本演讲中，我们会简要介绍 Android 上的现有界面自动化解决方案，并将介绍最近发布的 Android UI Automator 框架。该框架将继续对框架、典型用例和工作流进行内部介绍。
Appium：移动应用自动化
Jonathan Lipps（酱汁实验室）
Appium 是一个 Node.js 服务器，可自动处理原生和混合移动应用（iOS 和 Android）。Appium 的理念指出，应用不得为了实现自动化而进行修改，也应该能够使用任何语言或框架编写测试代码。最终，他们构建了 Selenium WebDriver 服务器，该服务器就像是本机语言一样。Appium 可在真实设备和模拟器上运行，并且是完全开源的，因此是开始进行移动测试自动化的绝佳友好方式。在本演讲中，我将简要介绍为 Appium 设计提供依据的原则，谈论其他移动自动化框架领域的 Appium，以及引入这种魔力的架构。最后，我会深入分析用于全新移动应用的简单测试的代码，并演示如何在 iPhone 和 Android 上运行此测试。
构建适用于 Google+ 移动版的可扩展移动测试基础架构
Eduardo Bravo (Google)
以有意义的、稳定且可伸缩的方式测试原生应用是一项挑战。为了解决上述问题，Google+ 开发了多种有效的解决方案。我们当前的测试基础架构为 iOS 和 Android 应用提供了正确的工具，让开发团队可以确信新的更改不会破坏现有客户。
Espresso：Android 界面测试入门
Valera Zakharov（Google）
开发可靠的 Android 测试应该和提取浓缩咖啡一样简单快速。遗憾的是，使用现有工具后，您可能感觉更像是生成双重焦糖汁-调味面-倒中-低温-十五投入式拿铁 - 令人困惑，很少保持一致。Espresso 是一个新的 Android 测试框架，可让您快速编写简洁、美观且可靠的界面测试。核心 API 体量小、可预测且易于学习，但也支持自定义。Espresso 测试会清楚地说明他们的预期、交互和断言，而不会干扰样板文件、自定义基础架构或混乱的实现细节。测试的运行速度最快 - 无需等待、同步、睡眠和轮询，可以让框架在静止时优雅地操作和断言界面。开始享受编写和执行界面测试的乐趣 - 试用 Espresso。
使用 WebDriver 进行 Web 性能测试
Michael Klepikov (Google)
在网络性能测试中，我们知道如何分析网页加载情况。不过，我们需要超出页面加载的范围：现代应用具有很高的互动性，因此操作往往不会重新加载整个页面，而是更新它。我自己也包含不同的人，他们将 WebDriver 集成到了 Web 性能自动化测试框架中，这有助于实现性能测试，但依然能将性能测试与界面测试套件的其余部分分开。我提议利用最近添加的 Logging API 将性能测试功能直接内置到 WebDriver 中。这样，就可以在运行常规功能测试时收集性能指标，从而将性能测试无缝集成到整体开发和测试流程中。而且，它对几乎每个大型组织创建的自定义构建/测试工具链造成的干扰也更低。
我将通过新一代 ChromeDriver（适用于 Chromium 浏览器的 WebDriver）演示这一点。
持续地图数据测试
Yvette Nameth (Google) 和 Brendan Dhein (Google)
持续测试通常是指运行单元测试和集成测试。但是，当服务器处理的数据实际上是最大的变化原因时，您如何确保数据的使用方仍然有用，并且不会因为更改率或不良更改而崩溃？我们将通过 Google 地图的示例讨论连续数据测试的技巧。
在失败的 build 中自动查找问题根源 - 即是谁破坏了 build？
Celal Ziftci (UCSD) 和 Vivek Ramavajjala (UCSD)
持续构建是 Google 的重要基础架构之一。当某个 build 失败时，请务必快速查明罪名变更列表 (CL)/变更列表，以便可以对其进行修复，使其重新回到绿色。
问题检测解决方案适用于中小型企业 build，但不适用于大型集成 build。
我们的犯罪根发现者会在很短的时间内自动获取大型 build 的 Kulprit CL。根据过去 9 个月内多个项目的生产使用情况，Culprit Finder 的成效非常好。欢迎观看我们的讲座，了解我们如何实施罪魁祸首、其在生产环境中的成功程度及其外观和效果。
软件产品线质量实证研究
Katerina Goseva-Popstojanova（西弗吉尼亚大学）
软件产品线在产品线系统中表现出高度共性，并且出现了大量可能的变体。根据从两个中型规模开发（一个中型工业产品线和一个大型不断发展的开源产品线）中提取的案例研究，我们通过探索性地探索了系统重用是否提高了质量，并且支持根据以往的故障、源代码指标和变化指标成功预测未来的故障。我们的研究结果证实，在软件产品线设置中，其他故障的发现结果与变化指标具有更高的相关性，而非静态代码指标。质量评估结果显示，尽管旧包装（包括共通性）不断变化，但它们的故障密度仍然较低。此外，随着产品不断完善，开源产品系列的质量也不断提高。基于通用线性回归模型的预测使用在发布之前的模型上构建的模型，根据软件包发布后的错误对它们进行了准确的排名。结果还表明，发布后的故障预测有助于了解其他产品线信息。
AddressSanitizer、ThreadSanitizer 和 MemorySanitizer -- C++ 动态测试工具
Kostya Serebryany（Google）
AddressSanitizer (ASan) 是一款工具，可用于查找 C/C++ 程序中的缓冲区溢出（堆栈、堆和全局）和释放后使用 bug。 ThreadSanitizer (TSan) 可在 C/C++ 和 Go 程序中查找数据争用。MemorySanitizer (MSan) 是一个开发中的工具，用于查找使用未初始化内存 (C++) 的工具。这些工具基于编译器插桩（LLVM 和 GCC），因此它们的运行速度非常快（例如，ASan 只会减慢 2 倍）。我们将使用这些工具分享我们在大规模测试方面的经验。
闭幕主旨演讲 - 畅饮海洋 - Google 规模的 XSS
Claudio Criscione (Google)
跨站脚本攻击 (XSS) 与现代网络黑暗世界的中年黑死病一样流行：它很普遍，很糟糕，而且很少会有技术检测方法检测到它为时已晚。DOM XSS 是一种特别讨厌的变体，因为它需要检测真实浏览器或等效机制：几乎没有自动化解决方案时的困难问题。
我们需要强大的自动驾驶工具，在开发生命周期的早期阶段确定 DOM XSS，以供安全团队以外的工程师使用：我们只想要一款可以扫描庞大、快速移动、高度复杂且模糊和冷漠的应用语料库的产品。当然，我们什么也没找到。因此，我们自行开发了一款以 DOM XSS 为目标的 Web 应用扫描器，它基于标准 Google 技术而设计。它在 App Engine 中运行，并利用强大的 Chrome 浏览器和数百个 CPU 作为安全扫描平台。
它也是 Google 测试工厂的不错选择：它位于我们的测试基础架构内部，而不是安全团队的工具。
在本次演讲中，我们概述了新颖的方法，我们在将系统规模扩大到 Google 规模时遇到的挑战，以及针对 JavaScript 密集型应用进行检测和抓取模型背后的想法。