あらゆる継続的インテグレーションのプロセスに自動化テストを統合する

ウォーターフォールモデルのように開発フェーズとテストフェーズを厳密に分離する時代は過ぎ去りました。今日では、迅速なフィードバック、迅速なイテレーション、かつてない速度での頻繁なリリースが重要です。そのため、高い要求に対応するためには、アジャイルな方法論が必要です。チームの成功は、適切なツールを備えたサポートインフラに依存します。ここで重要な役割を果たすのは、間違いなく自動化です。

開発環境がすでに構成されている場合、貴重な時間を無駄にして欲しくありません。Ranorexはあらゆる継続的インテグレーション・プロセスに統合することができます。今回は、テスト自動化をCIシステムに統合するメリットと、その方法について紹介します。

自動化テストと継続的インテグレーション

継続的インテグレーションの考え方は、頻繁にコードの変更を促進し、これらの変更がアプリケーションやシステムに与える影響について迅速にフィードバックを得ることです。開発サイクルにテスト自動化を含めると、コードの変更が行われるたびに自動的にテストすることができます。

そのため、基本的に開発者がコードの変更をGitやTFVCなどのバージョン管理システム(VCS)にコミットするたびに、テスト対象のアプリケーションとRanorexのテスト自動化プロジェクトのビルドがCIシステムで実行されます。その結果、テスト対象のアプリケーションに対してテストが自動実行されます。

自動テストの結果を評価するために、継続的インテグレーションツールは、テスト実行ファイルの戻り値またはその出力テキスト(例えば、失敗の場合は「TEST FAILED」)を調べます。Ranorexでは、戻り値 ‘0’ はGUIテストスクリプトの実行が成功したことを示し、戻り値 ‘-1’ は失敗したことを示します。各チームメンバーは、ビルドが終了すると自動的に通知を受け取ります。この通知には、ビルドログとテスト実行レポートが含まれます。

RanorexをCIシステムに統合するメリット

  • 各コードの変更が即座にテストされるため、潜在的に発生するバグがより早く発見され、最終的にそのバグを修正することが容易になります。
  • テスト自動化レポートにより、各チームメンバーがコードの状態について即座にフィードバックを受けることができるため、透明性が向上します。
  • RanorexはどのようなCIツールにも容易に統合できます。

Ranorexのテスト自動化をCIシステムで設定する

※Ranorexのテストを実行したい各マシンに、Ranorexをインストールする必要があります。その際、有効なライセンスが必要です。Ranorexのライセンスについての詳細は、価格についてのページを参照してください。

テスト対象のアプリケーションとテスト自動化プロジェクトでコミットされた各変更は、自動的にテストされる必要があります。言い換えれば、すべての変更は、以下の3つのステップを実施する必要があります。

  • テスト対象のアプリケーションを構築
  • Ranorexのテストスイートの構築
  • Ranorexのテストスイートの実行

はじめに、CIシステムに以下の作業を設定する必要があります。

  1. テスト対象のアプリケーションのビルド
    最初のビルドステップでは、テスト対象のアプリケーションをビルドします。アプリケーションの起動ファイルは、Ranorexのテストスイートプロジェクトから起動される必要があります。そのため、テスト対象のアプリケーションをビルドするビルドステップを追加します。(例:MSBuildビルドステップ、Antビルドステップなど)
  2. Ranorexのテストスィートの構築
    2番目のステップでは、テスト対象のアプリケーションを自動化するために実行ファイルを生成する必要があります。そのためには、ビルドステップ(MSBuild、またはVisual Studio)を追加し、ビルド対象となるRanorexのプロジェクトファイル(*.csproj)を選択します。
  3. Ranorexのテストスィートの実行
    3番目のステップでは、先に生成されたRanorexの実行ファイルを実行します。テスト自動化プロジェクトの *.exe ファイルをトリガーとする実行ステップを追加し、必要であればコマンドライン引数を定義します。

    テストの実行は、プロジェクトがビルドされたのと同じシステム上でトリガーされるはずです。別のシステムで実行をトリガーしたい場合は、ビルドした実行ファイルと関連するすべてのファイルをそのシステムにデプロイする必要があります。テスト対象のアプリケーションとRanorexテストスイートは、コンソールセッションではなく、必ずデスクトップで実行してください。

頻繁なコード変更に対するテストの自動化

テスト対象のアプリケーションやテスト自動化プロジェクトのコードが頻繁に変更される場合、ビルドのたびにすべてのテストケースを含むテストスイート全体を実行するのはあまり意味がありません。その代わり、変更の影響を受けるテストケースだけを実行する必要があります。それには、実行コンフィギュレーションを使用します。

ユーザーガイドに記載されているように、テストスイートで直接、実行構成を追加および編集することができます。

コマンドライン引数を使用して、実行構成をトリガーすることができます。
たとえば、次のコマンドラインは、テストスイートの実行ファイル(TestCIProject.exe)を”/rc”オプションにて実行構成(/rc:SmokeTest)で実行し、”/zr”と”/zrf”オプションにて圧縮レポートファイル(Report.rxzlog)を指定フォルダー(/Reports/)に生成し ます。

TestCIProject.exe /rc:SmokeTest /zr /zrf:Reports/Report.rxzlog

Ranorexのコマンドライン引数の詳細については、ユーザーガイドを参照してください。

テスト自動化レポート – フィードバックの重要性

No news is good news” (便りのないのは良い知らせ) は、、アジャイルチームには絶対に当てはまりません。チーム全員が、開発者であろうとテスターであろうと、コードの状態、つまり自動テスト実行の結果について知っていることが重要です。これは難しいことではありません。ビルド後のアクションを追加するだけで、ビルドログと生成されたzip形式のレポートが添付されたメールがチームメンバーに送信されます。

※Ranorex Studio バージョン 7.0 以降では、生成された Ranorex レポートファイルの JUnit 互換のコピーを作成することができます。XMLベースのJUnitテストレポートは、CIビルドプロセスに簡単に統合できるようになりました。

Ranorexを特定のCIシステムに統合する

特定のCIツールを使っていますか?BambooJenkinsHP Quality CenterTeamCityMicrosoft Test Managerなど、あなたのCIツールにRanorexを統合する詳しい方法は、以下のセクションをご覧ください!

このように、Ranorexのテスト自動化を継続的インテグレーション・プロセスに組み込むことは簡単です。テスト対象のアプリケーションとテスト自動化プロジェクトの各コードの変更が自動的にテストされるため、透明性が向上し、バグをより早く発見することができます。

(この記事は、開発元 Ranorex 社 Blog 「Integrate Automated Testing into Any Continuous Integration Process」2021年10月21日の翻訳記事です。)