開会の基調講演 - テスト可能な JavaScript - テストしやすいようにアプリケーションを構築する
Mark Trostler（Google）
テスト可能な JavaScript はプロセスです。空白のスレートから開始しても、すでに実装されているアプリケーション（あるいはその中間）でも、JavaScript コードをシンプルかつクリーンに、効果的にテストできます。テストできないコードは書き換えられます。
JavaScript は実行環境が多種多様であるため、独特なものですが、JavaScript にも当てはまる、他の言語による実証済みの「テスト可能な」手法がいくつかあります。もちろん、JavaScript デベロッパーがコードを記述してテストする際に直面する固有の課題は依然として存在します。
コードをテスト可能にするパターンとはテストの妨げになるアンチパターンは次のうちどれですか。コードのテスト性を測定するために使用できる指標や常識的なガイドポストは何かテスト可能なコードを作成するプロセスが開始されたら、次は何をすればよいでしょうか。
テスト可能な JavaScript を作成するプロセスを詳しく説明します。Google は、テストのしやすさ、ひいてはコードの保守性、正確性、寿命を大幅に向上させるアイデア、パターン、手法を調査します。クライアント側の JavaScript を作成する場合でも、サーバー側の JavaScript をマスターする場合でも、このプロセスをマスターすることでコードの品質が大幅に向上します。
マトリックスの破壊 - 大規模な Android テスト
Thomas Knych（Google）、Stefan Ramsauer（Google）、Valera Zakharov（Google）
赤い錠剤の準備はよろしいですか？
モバイルによって、人間とコンピュータとの関わり方は様変わりしました。これは素晴らしいことですが、エンジニアは、コードが実行される環境のマトリックスが絶えず直面しています。少数のブラウザや画面解像度しか考慮しない時代が到来しました。エンジニアはマトリックスにどのように対処できますか？ここでは、Google がワークステーション、クラウド、頭の中でこのテスト問題にどのように対処しているかを説明します。
「Neo に関しては、ただ、ドアしか見せることはできません。確認するのはあなたです。」
Android UI 自動化
Guang Zhu（徐光）（Google）と Adam Momtaz（Google）
Android がモバイルで普及するにつれ、アプリ デベロッパーと OEM ベンダーは、アプリまたはプラットフォーム全体の UI をエンドツーエンドでテストする方法を模索するようになりました。Android での既存の UI 自動化ソリューションを簡単に確認しながら、最近リリースされた Android UI Automator フレームワークを紹介し、その後、フレームワーク、一般的なユースケース、ワークフローの内部を引き続き説明します。
Appium: モバイルアプリ向けの自動化
Jonathan Lipps（Sauce Labs）
Appium は、ネイティブ モバイルアプリとハイブリッド モバイルアプリ（iOS と Android の両方）を自動化する Node.js サーバーです。Appium の考え方では、アプリを修正するためにアプリを変更することはできません。また、テストコードはどの言語またはフレームワークでも作成できる必要があります。その結果、モバイルと同じようにネイティブに動作する Selenium WebDriver サーバーが使用されます。Appium は実際のデバイスとエミュレータ上で動作し、完全にオープンソースであるため、モバイルテストの自動化を開始するのに最適な素晴らしい方法です。このトークでは、Appium の設計の基本原則、他のモバイル自動化フレームワークにおける Appium を紹介し、その魅力を引き出すアーキテクチャを紹介します。最後に、新しいモバイルアプリの簡単なテストのコードについて掘り下げ、Appium が iPhone と Android でこのテストを実行する例を示します。
Google+ モバイル向けのスケーラブルなモバイルテスト インフラストラクチャの構築
Eduardo Bravo（Google）
ネイティブ アプリを有意義で安定かつスケーラブルな方法でテストするのは困難です。G+ は、モバイルが提示する複雑なテストシナリオごとに適切なインフラストラクチャを提供することで、こうした問題に取り組むための効率的なソリューションを開発しています。現在のテスト インフラストラクチャでは、iOS アプリと Android アプリの両方に適切なツールが提供されています。開発チームは、新しい変更が既存のクライアントに影響を与えないという確信を与えています。
Espresso: Android UI テストを最初から実行
Valera Zakharov（Google）
エスプレッソのショットを撮るのと同じくらい、信頼性の高い Android テストの開発も迅速かつ簡単でなければなりません。残念なことに、既存のツールでは、ダブルショット キャラメル ソースを逆さまにしたシングル ヒープ ハーフ デカーフ ラテを作るような感じがします。わかりにくくて一貫性がありません。Espresso は、簡潔で美しく、信頼性の高い UI テストを迅速に作成するための新しい Android テスト フレームワークです。コア API は小さく、予測可能で、習得も簡単ですが、カスタマイズも可能です。Espresso のテストでは、ボイラープレート、カスタム インフラストラクチャ、乱雑な実装の詳細を妨げることなく、期待、インタラクション、アサーションが明確に述べられます。テストは最適に動作します。待機、同期、スリープ、アンケートはすぐに実行し、UI が静止している間はフレームワークが正常に操作してアサートします。ぜひ実際に UI テストの作成と実行を始めましょう。Espresso をお試しください。
WebDriver によるウェブ パフォーマンス テスト
Michael Klepikov（Google）
ウェブ パフォーマンス テストでは、ページの読み込み速度を分析する方法がよくわかりました。しかし、ページの読み込みだけでなく次の段階に移行する必要があります。最新のアプリは高度にインタラクティブで、オペレーションはページ全体を再読み込みするのではなく更新する傾向があります。私を含め、さまざまな人が WebDriver をウェブ パフォーマンス テストハーネスに統合しました。これにより、パフォーマンス テストは他の UI テストスイートとは別に分離されます。最近追加された Logging API を利用して、WebDriver 自体に直接パフォーマンス テスト機能を組み込むことを提案します。これにより、通常の機能テストの実行中にパフォーマンス指標を収集できるため、パフォーマンス テストの開発とテストのフロー全体とよりシームレスに統合できます。また、大規模な組織の大半が作成するカスタムビルド/テスト ツールチェーンへの負荷も軽減されます。
新世代の ChromeDriver（Chromium ブラウザ用 WebDriver）を使ってデモを行います。
マップの継続的なデータテスト
Yvette Nameth（Google）、Brendan Dhein（Google）
継続的なテストでは通常、単体テストと統合テストを実行します。しかし、サーバーで処理するデータが実際に変更の最大の要因である場合、データ利用者が引き続きそのデータを使用できること、そして変化の速度や不適切な変更でクラッシュしないようにするにはどうすればよいでしょうか。継続的なデータテストの手法について、Google マップの例を使って説明します。
失敗したビルド内で自動的に原因を見つける - ビルドを中断したのは誰ですか？
Celal Ziftci（UCSD）、Vivek Ramavajjala（UCSD）
継続的ビルドは、Google の主要なインフラストラクチャの一つです。ビルドが失敗した場合、ビルドを緑色に戻すために、原因の変更リスト（CL）や変更リストを素早く特定することが重要です。
原因検出ソリューションは、小規模および中規模のビルドに存在しますが、大規模な統合ビルドには存在しません。
私たちのファルファインダーは、非常に短い期間で、大規模なビルドの CL CL を自動的に見つけることを目標にしています。過去 9 か月間の複数のプロジェクトでの本番環境の使用状況から、非常に有望な結果が得られています。この動画では、このファインダーを実装した方法、本番環境における成功例、使用感と外観について説明します。
ソフトウェア プロダクト ラインの品質の実証的調査
Katerina Goseva-Popstojanova（ウェスト バージニア大学）
ソフトウェアのプロダクト ラインは、プロダクト ライン内のシステム間で高い共通性を示し、バリエーションが十分に明確になっています。2 つのケーススタディ（中規模の工業用プロダクト ラインと大きくなったオープンソースのプロダクト ライン）から抽出したデータに基づき、体系的な再利用によって品質を向上させ、以前に経験した障害、ソースコード指標、変更指標から発生する潜在的な障害の予測成功をサポートすることを経験しました。調査の結果、ソフトウェア プロダクト ライン設定において、静的コードが指標よりも障害と指標の関係が高いことがその他の調査結果で確認されました。品質評価結果によると、古いパッケージ（共通性を含む）は継続的に変化していますが、フォールト密度は低くなっています。さらに、オープンソース プロダクト ラインは、リリースに伴って品質が向上しました。一般化された線形回帰モデルに基づく予測では、以前のリリースで構築されたモデルを使用して、リリース後の障害に応じてパッケージを正確にランク付けしました。その結果、リリース後の障害予測は追加のプロダクト ライン情報の恩恵を受けることも明らかになりました。
AddressSanitizer、ThreadSanitizer、MemorySanitizer -- C++ 用動的テストツール
Kostya Serebryany（Google）
AddressSanitizer（ASan）は、C/C++ プログラムのバッファ オーバーフロー（スタック、ヒープ、グローバル）と use-after-free バグを検出するツールです。ThreadSanitizer（TSan）は、C/C++ プログラムと Go プログラムにおけるデータ競合を検出します。MemorySanitizer（MSan）は、初期化されていないメモリ（C++）の使用状況を検出する開発中のツールです。これらのツールはコンパイラ インストルメンテーション（LLVM と GCC）に基づいており、高速に動作します（たとえば、ASan では速度がわずか 2 倍になります）。これらのツールを使用した大規模テストの経験を共有させていただきます。
基調講演の締めくくり - 海洋の飲用 - Google 規模で XSS を探す
Claudio Criscione（Google）
クロスサイト スクリプティング（XSS）は、現代のウェブ アプリケーションにおける中世黒人のペスト病に相当するもので、今は広く普及しています。しかし、手遅れになるまでは技術的を検出する方法はほとんどないか、まったくないのです。DOM XSS は特に厄介な問題で、実際のブラウザや同等のものを検出するために必要です。自動化ソリューションがほとんどなく、難しい問題です。
開発ライフサイクルの早い段階で、セキュリティ チームの外部のエンジニアが使用できる DOM XSS を特定するために、高性能で自動化されたツールが必要でした。私たちが必要としていたのは、動きの速い、非常に複雑で難解なアプリケーションのコーパスをスキャンできる製品だけでした。そのため Google は、標準的な Google テクノロジー上で設計された DOM XSS をターゲットとするウェブ アプリケーション スキャナを独自に構築しました。App Engine で実行され、強力な Chrome ブラウザと数百の CPU をセキュリティ スキャン プラットフォームとして使用します。
また、Google のテストの武器として、セキュリティ チームの一員としてではなく、Google のテスト インフラストラクチャに属しています。
この講演では、Google の規模に合わせてシステムをスケーリングする際に直面した課題と、JavaScript を多用するアプリケーションでの検出とクロールモデルに対する考え方について、新たなアプローチについて説明しています。