[アーカイブ] Windows 8 の手動テストをリモートの実機で行う方法

<オリジナル投稿 2012年10月11日 本ポストの情報はオリジナル投稿時点のものです。マイクロソフトの正式な見解や製品の仕様を保証するものではないことをご了承ください。>

MSC 2012、 Developer Camp 2012 Japan Fall でデモを行った Windows ストアアプリのリモートでの手動テスト (含む、探索的テスト)ですが、設定など社内外から質問があったこともあり、共有しておきます。ちなみに、MSDN ライブラリには、より詳細に記載されています (「Microsoft テスト ランナーを使用したデバイス上で実行されている Windows ストアアプリのテスト」)。

何ができるのか

テスト対象のデバイス実機上での手動テストを行ったときに、その時の操作（たとえば、どこをタップしたら何が開いたのかなど）を記録してくれます。また、診断に必要な情報（システム情報やイベントログ、デバッグ履歴など）を収集してくれます。このとき、設定しておけば、デバイス上の操作を動画としてキャプチャもしてくれます（Test Manager 2012 からは音声も収集できます）。
テストの結果は、ステップごとに記録が自動で残りますし、バグ起票も、ボタン一発で、ステップごとにどこをタップしたら何が起きたのかなどスクリーンショットを手でいちいちとらなくても記録を即時共有することができます。
探索的テストでは、実行した操作ステップから再現性のある最適な手順だけに整理したりすることができますし、これまたボタン一発で、テストケースとして残すことができます。探索的テストでバグ発見→即時、バグ起票→テストケース作成のスムーズな流れができ、しかも、開発者はバグ票から操作ログ、デバッグ情報、ビデオキャプチャの情報も見ることができるので、「再現しないバグ」扱いにせず、効率的にバグ修正作業を行えるわけです。テスターからすると、バグとテストケース（プロダクトバックログ項目も）、ビルド番号が紐づいている状況なので、バグ修正後、速やかにテストケートに基づいたテストを行うことができます。
ね、便利でしょう？ここまでやらないといけない時代ですよ。

必要な環境

これを実現するには以下の環境が必要となります。

• Team Foundation Server 2012
  TFS は、チームの基盤です。テスト環境、テスト構成、テストケース、バグ、ビルドなどテストになくてはならない成果物を有機的につなぎ追跡可能にしてくれます。これ必須です。
• Microsoft Test Manager 2012
  手動テストの設定と実行、追跡のために使います。メインで使うのはこちらです。テストを実行する環境に用意しておきます。
• Remote Tools for Visual Studio 2012 ( 無償ダウンロード )
  デバイス実機上でのリモートテストをや、デバッグ、プロファイリングのために必要なサービスです。デバイス上にセットアップします。
• Visual Studio Agents (DVD メディア/MSDN サブスクリプションで入手)
  テストコントローラーとテストエージェントが含まれています。テストコントローラーは、TFS、テスト対象の実機デバイスとそれぞれに通信できればOKです (要するにテスト対象デバイスは、TFS と通信する必要はありません)。たとえば、手っ取り早く試すなら TFS のサーバーにテストコントローラーもセットアップしてしまえばいいです。

必要なのは、これだけです。

テストコントローラーのセットアップ

テストコントローラーの構成ウィザード (といっても1ステップですがw)で設定するだけです。

テストを行うため、それなりに権限を委譲する必要があることは念頭に置いてください。ログオンアカウントを設定します。それと包括的なテスト管理を実現するため、TFS のチームプロジェクトコレクションと通信できるように設定します。これだけです。
権限周りついては、MSDN ライブラリ (「Microsoft Test Manager を使用したラボ環境でのテスト コントローラーの設定」) をご覧ください。

リモートツールとテストエージェントのセットアップ

この二つのツールは、テスト対象となるデバイス実機上にセットアップします。

リモートツールは、 x86, x64, ARM とありますので、まず、適切なアーキテクチャのものをインストールしてください。そのうえで、「Microsoft Test Tools Adapter 構成ツール」を起動してください。設定内容は触れるまでもないでしょう。以後、デバイス起動時に既定ではサービスが起動しますので、いちいち起動に気を使うこともありません。
テストエージェントも基本的には同様にインストールして、設定を軽く行うだけです。「Test Agent 構成ツール」を起動します。

設定のポイントは、実機で操作するしかるべき権限のあるユーザーを設定することと、「対話型プロセス」とすることです。対話型でないと実機上の操作を制御できませんので、これは忘れないでください。あと、テストコントローラーと通信しますので、「テストコントローラーへの登録」で、先に設定したテストコントローラーのアドレスを設定してください。
あとは、「設定の適用」で権限チェックなど行いつつ、設定してくれます。
ここまでうまくいけば、デスクトップに、ツールが現れます。

※この画面では、ステータスが、「テストを実行しています」になってます。今まさにリモートでの手動テストがこの実機で行われいることを示しています。設定後は通常、このステータスが、「オンライン」になっているはずです。

準備の確認

手動テストが行える環境が整ったかどうかは、Test Manager から確認できます。

テストコントローラー単位で、複数のエージェントの制御ができることがわかります。エージェントのサービスをリモートからOn/Offや、エージェントの設定を行うこともできます。

テスト設定とテスト環境

あとは、テストをするだけですが、いくつか設定しておく必要があります。それはテスト環境です。ソフトウェア開発のテストは多種多様です。それを Test Manager では整理し、整合性の取れる運営が行えるようにいくつかの設定でわけています。とはいえ、それはこれらを手動で把握と設定をしようとするよりはるかにシンプルです。
Test Manager では、手動と自動のテストについて、「テスト設定」と「テスト環境」の組み合わせを設定し、テストを実行することができます。これらは、Test Manager の「テストセンター:計画:プロパティ」で設定と確認が行えます。

「手動での実行」、「自動での実行」という項目のところが該当箇所です。拡大してみましょうか。

既定では、Test Manager を実行している環境のテスト情報を収集するようになっています。これはスタンドアロンのデスクトップアプリや、Web サーバー側のデータ収集や診断が不要なブラウザ上でのWebアプリなどのテストに適した設定ですね。
テスト設定、テスト環境ともに、ハイパーリンクがあるので想像つくと思いますが、このリンクから設定へ飛ぶことができます。
テストの設定: リモートテスト用に一つ作っておきましょう。コピーもできますので、「Local Test Run」をコピーして修正でもいいでしょう。たとえば、「Remote Test Run」を新規に作ります。

設定は以下です。まぁ、想像つく設定項目ですね。

ロールを決定します。たとえば、3層アプリであれば、ロールとして、「データベース」、「アプリケーションサーバー」、「スマートクライアント」なんかがいいですね。これらのロールごとに、データの収集と診断のための情報として何を得たいのかを次に設定できます。

このようにロールごとに、収集する項目を選びます。「システム情報」にチェックを入れれば、OSの情報やメモリ使用量、画面解像度など自動で収集してくれます。「ビデオレコーダー」でリモートであっても、そこで操作した動画をキャプチャしてくれます。

Test Manager 2012 から音声もキャプチャできるようになりました。あとはフレームレートなどを設定します。実機デバイスから収集したい情報を選択しましょう。
テストの環境: ラボセンターのラボで設定と確認ができます。

設定は、エージェントで設定したものと同様です。

UI を伴うテストを実行したいので、「UI テストを実行するように環境を構成する」にチェックを入れます。あと、ロールを選択します。ロールは、先のテスト設定で決めたものから選択できます。
テスト計画のプロパティで、以下のように設定されていれば、以後、このテスト計画下で実行されるテストは、リモート実機上での手動テストとなるわけです。

重要な余談ですが、Test Manager は TFS ですべての情報を持っていますので、テスト対象のビルドも設定できます。

テスト対象となるビルド定義とその品質指標を決定できます。ある一定の品質を満たしたビルドだけがテスト対象とすることができるように制御できるわけです。また、現場のテスト対象のビルドも明示されています。この情報は重要で、以後、テスト結果、バグ票などで「どのビルドでテストが成功/失敗したのか、バグを発見したのか」が自動で設定されます。

上記はバグ票の情報です。バグが修正されたら、これまた自動起票でどのビルドで修正されたのかもインプットされます。ここまでの統合が他でできるのか想像してみてください。
ちなみに、どのビルドをテスト対象とするのかの判断材料も示してくれます。

これは、今テスト対象に採用しているビルドから、他のビルドにテスト対象を変えたときに、どのプロダクトバックログ項目が実現できているのか、どのタスクが完了しているのか、どのバグが修正されているのかを作業項目の単位で把握することができることを示しています。もちろん、これらとソースコードの変更セットは完全にトレースできますので、細部までたどることができますが、この手の判断をビルドとソースコードの変更セットだけで判断しているという現場多いですよね？そんな細かい粒度で正しく把握できるのでしょうか？もっと楽しましょうよ。安全にトレーサビリティ確保しましょうよ。

テストの実行

テストの実行は、もちろん、Test Manager から行います。このとき、テストを実行する先をローカルから、リモートデバイスに変更することができます。



このとき、まだデバイスにストアアプリをインストールしていない場合も、リモートでインストールすることができます。

先に設定したようにテスト計画として、リモートテストを既定にしておくこともできますが、テスト実行の際に、変更することも可能です。

これは、探索的テストでも同様です。


実行すると、Test Manager が Test Runner に変形するのではなく、テストケースを伴う場合は、テスト手順が全画面に、探索的テストの場合は、リッチテキストエディタが全画面に表示されます。

リモート環境での操作やキャプチャを自在に取得できます。リモート環境の画面ショットの取得は以下の感じにサクサク行えます。

収集したキャプチャ画面は、リッチテキストに盛り込まれます。

バグ起票を行うと、操作手順とその際に画面のどこをタップしたのかなど自動で記録されます。

少し拡大してみましょうか。

探索的テストの場合は、特にですが、手順が多すぎた場合は、適切に修正もできます。

ビデオレコーダーも設定してあれば・・・。

テストケースも一発で作成してくれます。

Visual Studio 2012 からもバグの情報として同じものが共同所有された状況となります。

ビデオ動画も見れます。

まとめ

ご覧いただいたように、すこし設定をしておくだけで、TFS を中心として、開発とテストのライサイクルで分断されがちな情報がシームレスに共有、共同所有された状態を維持することが容易であることがわかります。この環境下で、リモートでのデバイスの実機手動テストも行えるわけです。複雑になりがちなさまざまな事柄をシンプルにしていくことがこれからのソフトウェア開発では不可欠です。それを実現できる環境をもっている現場ともっていない現場の差はどうなるのでしょうか？その一端を感じていただければ幸いです。手順は、一見複雑に思うかもしれませんが、私は何もマニュアル見ないで設定できました。原理が想像つけば、とても簡素であることがわかります。