開会の辞
Yvette Nameth（Google）
基調講演を開く
Jürgen Allgayer（Google）
クロス アプリケーション/クロスデバイス テストの Uber チャレンジ
Apple Chow（Uber）と Bian Jiang（Uber）
2015 年 3 月に Uber に加わった後すぐに、モバイルアプリの UI テストツールを調査するという、Uber 独自の課題に直面しました。Google のサニティテストの多くでは、エンドツーエンドのテストシナリオを完了するために、ライダー アプリとドライバ アプリが相互に通信/調整を行う必要があります。このセッションでは、Octopus と呼ばれる、プラットフォームに依存しないソリューションを紹介し、異なるデバイスで実行される異なるアプリ間で通信を調整する方法を学習します。このソリューションは、さまざまなアプリまたはデバイス間での調整/通信が必要なテスト（マルチユーザー ゲーム、マルチユーザー メッセージ/通信アプリなど）に導入できます。
ロボット支援テストの自動化
Hans Kuosmanen（OptoFidelity）、Natalia Leinonen（OptoFidelity）
OptoFidelity は、R&D テスト自動化ソリューションの開発と提供に 10 年の経験を持つフィンランドのハイテク企業です。このセッションでは、モバイル デバイス UI パフォーマンス テストで使用する非侵入型テスト方法に関する経験と今後の展望を紹介します。Chrome OS チームは、OptoFidelity のロボット ソリューションを使用して Android デバイスと ChromeOS デバイスのエンドツーエンドのレイテンシを測定しています。
楽しくて利益をもたらすジャグリング チェーンソー: モバイル クロス プラットフォーム統合テストから得た教訓
Dan Giovannelli（Google）
モバイル開発は難しいものです。テスト インフラストラクチャの構築は難しい。クロス プラットフォームでの作業は困難です。この 3 つを組み合わせることで、災害のレシピが手に入ります。このセッションでは、Dan Giovannelli 氏がクロス プラットフォーム モバイル テスト インフラストラクチャ プロジェクトでの自身の経験を紹介します。うまくいったこと、間違っていること、間違っていること、初めにわかっていたかったことについて語ります。 モバイル エンジニア以外のエンジニア向けにモバイル ツールを設計する場合の分析情報については、The Matrix の概要、独自のゲームで勝る方法をご覧ください。
実際のデバイスを使用したモバイルゲーム テストの自動化
Jouko Kaasila（Bitbar/Testdroid）
モバイルゲームは、現在のアプリストアで最大の収益を生み出しているカテゴリです。したがって、どのゲームでも、ユーザーのゲームがどのデバイスでもどのバージョンでも確実に動作するようにすることは、最優先事項となっています。これを検証するうえで重要であるにもかかわらず、モバイルゲームのテストを自動化するための例やフレームワークはほとんどありません。ゲーム会社はグローバル市場をカバーする必要のある規模では対応できない手動テストに頼る必要があります。1 つの主な理由は、モバイルアプリとしてのゲームならではの性質です。OS によって提供されるすべての UI サービスが画面に直接アクセスせず、ほとんどのテスト自動化フレームワークが役に立たないためです（従来のオブジェクトが公開されていないため）。
幸いなことに、標準的なモバイルテスト自動化フレームワークを使用し、創造性や一般に公開されているライブラリを使って、ゲーム用の実際のモバイル デバイスでテストの自動化を推進する方法があります。そのプレゼンテーションでは、Testdroid の Jouko Kaasila が、実際の例と 3 つのサンプルコードを使用して 3 つの異なるアプローチについて説明します。
スープのダンプのコンポーネントを設定する方法
Toni Chang（Google）
不安定なテストの安定化に長い時間を費やしてきたユーザーは、テストを分解する必要があることに同意するでしょう。しかし、すべてのシナリオを検証するには E2E テストが必要だと考えているチームメイトによって、その方法がわからない場合とそうでない場合があります。コンポーネントで商品を表示することに慣れていないと、アイデアを把握することが難しい場合があります。ここでは、スープダンプの抽象的な例を使用して、不可欠な部分をコンポーネントに分解し、コンポーネントにテストを適用する方法を紹介します。
E2E テストをコンポーネント テストに変換して最終的なプロダクトに自信を持てるようにする楽しい取り組みをご紹介します。これが、独自の商品に対する新しい視点を提供する一助となれば幸いです。
Chromecast テストの自動化
Brian Gogan（Google）
モノのインターネット（IoT）によって、コネクテッド デバイスが急増しています。さまざまな相互運用デバイス間での動作の検証は、テストの重要な課題です。Chromecast をテストするには、いくつかのアプローチを採用しました。プロダクトから信頼性の高い品質シグナルを生成するために、開発したテスト フレームワーク、ラボのインフラストラクチャ、テストツールの概要を説明します。騒がしいネットワーク環境で動作するプロダクトをテストする場合の課題を詳しく説明します。Chromecast などのデバイス用のテストツールは初期段階にあることを提案し、ソフトウェア テスト エンジニアリングのイノベーションの機会を提供します。
Android アプリのテストに Robots を使用する
Dr.Shauvik Roy Choudhary（Georgia Tech/Checkdroid）
Monkey などのソフトウェア ロボットを使用すると、多くの手作業なしで Android アプリをテストできます。Android アプリを動作させるためのテスト入力を自動的に生成することを目標に、学術部門で提案されているツールが複数あります。この講演では、代表的なテスト入力生成ツールのセットを紹介し、比較研究の強みと制限事項に焦点を当てます。 これらのツールの内部と、それらのツールを使用してアプリケーションをテストする方法について学びます。 調査の詳細とツールを使用した VM の設定については、http://bear.cc.gatech.edu/~shauvik/androtest/ をご覧ください。
テストが不安定ではない
Alister Scott（Automattic）
不安定なテストは、自動化されたテスト エンジニアのバグです。ある人（おそらくアリスター）は、「同じテストを何度も繰り返し、結果が異なる」と言いました。不安定なテストでは絶望は終わりませんが、不安定なテストや不安定なテストなどはないでしょう。この問題を別の視点から見る必要があります。復元力のある永続的なテストの構築に時間をかけるよりも、より確定的でテスト可能なシステムの構築により多くの時間をかける必要があります。Alister がテストの不安定さがシステムの下に実際の問題を隠した例と、より優れたシステムを構築してテストの不安定さをどのように解決できるかを紹介します。
大規模な自動ビジュアル テスト
Adam Carmi（Applitools）
自動化されたビジュアル テストは、開発 / テスト コミュニティにおける主要な新たなトレンドです。この講義では、ビジュアル テストの概要と自動化が必要な理由について学習します。ビジュアル テストの自動化に関連するいくつかの技術的な課題と、それらの最新ツールによる解決方法を紹介します。ブラウザ間やクロスデバイスのビジュアル テストを可能にする最先端のテクノロジーのデモを行い、大規模なビジュアル テストで成功するための重要なヒントを提供します。
Hands 回帰テスト
Karin Lundberg（Twitter）と Puneet Khanduri（Twitter）
あなたのチームはサービスの大規模なリファクタリングを完了し、すべての単体テストと統合テストに合格しました。おめでとうございます！しかし、これで終わりではありません。ここで、何も破損していないかどうか、まだ発見していない潜在的バグがないことを確認する必要があります。では、Diffy を始めましょう。
単体テストや統合テストなどのコードの確実な動作を実現するツールとは異なり、Difffy は新しいサービスと古いサービスのインスタンスを並べて起動し、それぞれにレスポンスのサンプルを転送して、それらの比較から得られた回帰を返します。これにより、変更されたサービスの動作を比較します。
また、このツールをオープンソース化したばかりで、Twitter のオープンソース プロジェクトの中でも特に人気が高まっています。
Android アプリのユーザー補助機能の自動テスト
Casey Burkhardt（Google）
このセッションでは、Android プラットフォームにおけるコア アフォーダンスのアフォーダンスを紹介し、ユーザー補助機能に関するよくあるデベロッパーの問題について説明します。新しい Android ユーザー補助機能テスト フレームワークと、Espresso と Robolectric テスト フレームワークへの統合について学びます。最後に、既存の Android プロジェクトのテストにユーザー補助チェックをいかに簡単に追加できるかについて学習します。
統計データのサンプリング
Celal Ziftci（Google）と Ben Greenberg（MIT 大学院生）
テストでは、本番環境データのサンプルを使用することが一般的です。以下に例を示します。
- サニティテスト: 本番環境データのサンプルをシステムにフィードし、何か問題があるかどうかを確認します。
- A/B テスト: 大量の本番環境データを取得し、システムの現在のバージョンと新しいバージョンを実行して、出力の差分を調査します。
本番環境データのサンプルを取得するには、通常、次のようなアドホックなソリューションを使用します。
- 特定のフィールド（数値フィールドなど）の分布を手動で確認する
- 完全にランダムなサンプルの選択
しかし、これらのアプローチには重大な欠点があります。まれなイベント（エッジケースなど）を見逃し、本番環境でバグがキャッチされないリスクを高める可能性があります。このリスクを軽減するため、チームは非常に大きなサンプルを選択しています。しかし、このような大規模なサンプルには、さらなる欠点があります。
- 未確認のイベント
- テストのランタイムが大幅に増加する
- 差分が大きすぎて人間には理解できず、繰り返しが多い。
この講演では、次のような本番環境データから「適切な」サンプルを「スマート」に選択する新しい統計データ サンプリング手法を提案します。
- 貴重なアクティビティを見逃さないようにサポート
- 重複を排除して、選択したサンプルのサイズを最小化します。
この手法では、まれなケースや境界線上のケースを検出し、サンプルサイズを最小限に抑えることができます。また、デベロッパーによるテストの出力と差分を確認するという手動の負担を暗黙的に軽減します。また、並列実行（MapReduce など）もサポートしているため、大量のデータを短期間で処理してサンプルを選択できます。
Google Nest 自動化インフラストラクチャ
Usman Abdullah（Nest）、Giulia Guidi（Nest）、Sam Gordon（Nest）
Thoughtful Home に対する Nest のビジョンは、相互接続されたインテリジェントなデバイスが連携して、家の安全性、エネルギー効率、認知度を高めることです。このセッションでは、このビジョンの実現を支援するために構築された自動化インフラストラクチャとテストツールに焦点を当てます。Google Nest のさまざまなチームが、クロスプラットフォームとデバイス/機能固有のシステムの両方で、自動回帰テストと分析に取り組んできました。実際のプロダクト テストの特定例を使用して、ループテスト インフラストラクチャのプロダクト間ハードウェアと電力回帰分析ツールについて説明し、カメラとモーション検知に固有のツールセットについても説明します。
イベント生成ツール
Roussi Roussev（Splunk）
この講演では、Splunk でソフトウェア イベント ジェネレータを開発して使用した経験を紹介します。 大規模な実験機を搭載させずにイベント ジェネレータが現実世界を理解するうえで不可欠な粒子物理学に触発され、ログ ジェネレータにより、最新および従来のサードパーティ ソフトウェアとの多くの統合をテストする方法が改善されました。このトークでは、現実的なログを生成する基本的な機能と課題について説明します。
マルチスレッド テスト合成
Murali Krishna Ramanathan （バンガロール、インド科学研究所）
不正な同期や不適切な同期が原因で発生するマルチスレッド ライブラリの微妙な同時実行エラーは、多くの場合、静的手法のみを使用して正確に特定することは困難です。一方、動的検出器の有効性はマルチスレッド テストスイートに大きく依存しています。マルチスレッド テストスイートを実行すると、データ競合、デッドロック、アトミック違反などの同時実行バグの特定とトリガーが可能になります。通常、このようなマルチスレッド テストでは、呼び出しを公開するオブジェクトとメソッドの特定の組み合わせを呼び出して、バグを公開する必要があります。 バグの事前の知識がないと、このようなテストの作成が難しくなる可能性があります。
この講演では、スレッドセーフな違反を検出するためのテストを合成するための、軽量でスケーラブルな手法を紹介します。マルチスレッド ライブラリとシーケンシャル テストスイートについて、完全に自動化された分析について説明します。この分析では、シーケンシャル実行トレースを調査し、同時実行クライアント プログラムを生成します。このクライアント プログラムは、ライブラリ メソッド呼び出しを使用して、同時実行バグの発生を助長する可能性のある状態へと共有オブジェクトを発生させます。十分にテストされたさまざまな Java ライブラリのテスト結果が、多くの複雑なバグを明らかにするためのアプローチの有効性を示しています。
Netflix でストリーミング テストを有効にする
Minal Mishra（Netflix）
6,900 万人以上のユーザーのストリーミング エクスペリエンスは、Netflix にとって最も重要な課題です。これを迅速に改善するために、アダプティブ ストリーミング アルゴリズムを JavaScript レイヤに移行しました。これは、クライアントの JavaScript ソフトウェアを頻繁にリリースするという、特有の課題で、消費者のストリーミング エクスペリエンスに直接影響を与えました。サービス アプリケーションに広く採用されてきた継続的デリバリー パラダイムを借り、チェックイン ライフサイクルのリスクをなくし、頻繁なアップデートの提供に使用しました。このトークでは、ソフトウェア アップデートを可能にするこのパラダイムの主要なコンポーネントについて説明します。以下では、JavaScript クライアントとツールのロールアウト手順を詳しく掘り下げ、現行バージョンと正常性を正確に比較します。また、このプロセスによって直面する課題についてもお伝えします。
模擬のインターネット
Yabin Kang（LinkedIn）
インターネットをモックし、Linkedin の新しいモック システムについて説明します。このモック システムでは、サービスレベルの統合テスト用にすべての送信トラフィックをモックできます。また、Linkedin のモック戦略についても簡単に説明します。知識と学んだことを全員で共有します。
GPS Monitoring Station 受信機の効果的なテスト
Andrew Knodt（Lockheed Martin）
空軍で使用されている既存の GPS モニタリング ステーションは保守が難しくなっているため、GPU アクセラレーションによるソフトウェア定義無線（SDR）アプローチに置き換える取り組みを進めています。この特殊な GPS 受信機に固有のテストチャレンジの概要と、いくつかのテスト方法を確認します。GPS アプリケーションに注力する一方で、これらのテスト方法は他の本番環境レベルの SDR 作業にも簡単に適用できます。
ウェアラブル デバイスにおける自動化
Anurag Routroy（Intel）
ウェアラブル技術は個人や企業での使用が増加しており、Android 市場で確固たる地位にあるすべての企業がこの将来の技術への注目を切り替えています。そのため、ウェアラブル サポートを使用してアプリを作成するため、ウェアラブル デバイスでアプリをテストする労力も増加します。そのため、ウェアラブルの自動化は、テストの労力を減らし、効率を高めるうえで重要になります。
統合インフラストラクチャと CI 統合テスト（Docker/Vagrant）
Maxim Guenis（Supersonic）
デベロッパーは、開発、デバッグ、継続的な統合サイクルを進める際に、動作可能なローカル開発環境を準備し、CI ツールで使用する Docker と Vagrant を統合することでこの問題を解決できます。この組み合わせにより、開発マシン上でスタックレベルでアプリケーションを制御しながら、統合テストでも同じスタックを使用できます。 このセッションでは、次のトピックについて説明します。
- CI 統合テストでの Docker の使用
- 単一の Docker やアプリではなく、スタックの制御。
- 開発環境とテスト環境のバージョン管理。git と Docker ツールを使用して簡単に分散できます。
- Mac と Windows で Docker を実行するためのシームレスなサポート。
不要なテストビットの排除
Patrick Lam（ウォータールー大学）
テストスイート向けの静的分析手法を専門にすることで、興味深い結果を得ています。以前に、ほとんどのテストは単純な直線コード、つまり一連のセットアップ ステートメントの後にアサーションで構成されるペイロードが続くことを学びました。静的分析により不要なセットアップ ステートメントを識別して、デベロッパーがテストケースを簡素化、高速化できる仕組みをご紹介します。
テストスイートの有効性とカバレッジはあまり相関していない
Laura Inozemtseva（ウォータールー大学）
テストスイートのカバレッジは、多くの場合、障害を検出する機能のプロキシとして使用されます。しかし、コード カバレッジとテストスイートの有効性の相関関係を調査した以前の研究では、これらのテストスイートの特性の性質と強さに関するコンセンサスが得られませんでした。さらに、多くの研究が小規模または合成のプログラムを使用して行われていたため、結果が大規模なプログラムに一般化されているかが不明瞭でした。また、一部のテストではテストスイートのサイズの絡み合った影響が考慮されていませんでした。Google は、実際の Java プログラムに対するテストスイートのサイズ、カバレッジ、有効性の関係を評価することで、これらの調査を拡大しました。この調査は文献上で最大のものです。これらのスイートのステートメント カバレッジ、意思決定カバレッジ、変更条件カバレッジを測定し、ミューテーション テストを使用してフォールト検出の有効性を評価しました。スイート内のテストケースの数が制御されている場合、カバレッジと有効性の間には低～中程度の相関関係があることがわかりました。 また、カバレッジを強化しただけでは、サービスの効果を詳細に把握することができません。
RpcReplay による疑似バックエンド
Matt Garrett（Google）
テストを高速で安定した状態に保つことが非常に重要です。これは、サーバーが多くのバックエンドに依存している場合には困難です。デベロッパーは、長時間テストと不安定なテストのどちらかを選択するか、疑似実装を作成してメンテナンスする必要があります。代わりに、これらのバックエンドから記録されたトラフィックを使用してテストを実行できます。これにより、両方の利点を生かし、開発者は実際のバックエンドに対して迅速にテストを行えます。
Chrome OS Test Automation ラボ
Simran Basi（Google）と Chris Sosa（Google）
現在、ChromeOS では 60 以上の Chromebook/ボックスがそれぞれ専用のソフトウェアで出荷されています。現場では、6 週間ごとに新しいシステムが提供されます。これは、200 人以上のデベロッパーによる継続的な継続的インテグレーション システムの検証なしでは実現できません。このセッションでは、テスト自動化ラボでアーキテクチャ全体を重点的に説明します。また、Moblab（モバイル（テスト）ラボ）というラボも実施します。これは、1 つの Chromebox で実行できるテスト自動化インフラストラクチャ全体です。このシステムの多くは、Google と同様にテストを実行できるように多くのパートナーによって使用されています。