Azure DevOps Server または Azure DevOps Services を使用したローカル・テストの実行

このトピックでは、Azure DevOps Server（旧称 TFS）からローカル・マシンに保存されている OpenText Functional Testing テストを実行する方法について説明します。

注: このトピックでは、UFT One Azure DevOps extension バージョン 24.2.* を使った作業について説明します。最新の機能を活用するため、既存のタスクのバージョンを 24.2.* に更新することをお勧めします。この拡張機能バージョンを使用する場合は、ADM-TFS-Extension GitHub リポジトリから、対応する UFT.zip ファイルをインストールしたことを確認してください。

ローカル・マシンに保存されたテストの実行

Azure DevOps サーバで：

  1. パイプラインを作成します（注：TFS を使用している場合は、この手順をスキップしてください）。

    1. 空のジョブ・テンプレートを使用して、ビルド・パイプラインまたはリリース・パイプラインを作成します。

      注：ビルド・パイプラインは、リリース・パイプラインを明示的に作成しない場合に作成されるパイプライン・タイプです。

    2. テストを実行するエージェントが含まれているエージェント・プールを選択します。

    3. パイプライン変数に、UFT_LAUNCHER 変数を追加します。変数の値には、UFTWorking フォルダへの完全パスを指定します。

    詳細については、Microsoft Azure のドキュメントを参照してください。

  2. 実行ごとに新しい OpenText Functional Testing インスタンスを起動するのではなく、起動済みの表示された OpenText Functional Testing インスタンス（存在する場合）を使用してテストを実行するには、次のように定義します。

    新しいパイプライン変数 LEAVE_UFT_OPEN_IF_VISIBLE を定義し、その値を true（または yes または 1）に設定します。

    OpenText Functional Testing は、実行が終了しても起動したままになります。

  3. UFT One タスクを追加し、ビルド順序の適切な位置にステップを配置します。

    注: リリース・パイプラインを使用している場合は、関連するステージにタスクを追加してから、ビルドにステップを配置します。

    1. ［Task catalog］領域で、［Test］タブを選択します。利用可能なすべてのテスト・タスクのリストが表示されます。

    2. ［Test］タブから、［UFT One File System Run］タスクを選択し、［Add］をクリックします。ビルド・パイプラインの一部として、新しい空のタスクが追加されます。

      注: リリース・パイプラインを使用している場合は、タスクはデプロイメント・プロセスの一部として追加されます。

  4. ビルド・ステップについて、次の情報を入力します。

    オプション説明
    Display name

    Azure DevOps Server CI システムの標準設定では、設定済みの記述子がタスクに使用されます。ステップにわかりやすい名前を付けます。

    Testsテスト、テスト・バッチ・ファイル、または実行するテストが格納されたフォルダ。複数のテストの場合、テストのパス、名前、またはテスト結果のパスをコンマで区切る必要があります。
    Timestamp pattern

    ［Extensions］タブでレポートに使用されるタイムスタンプ・フィールドの値の形式を定義します。

    標準設定値は yyyy- MM-dd HH:mm:ss です。

    Timeout

    テストの開始または実行に問題がある場合に待機する時間（秒単位）。フィールドを空白のままにすると、タイムアウトは発生しません。

    Cancel run on first failure

    テスト実行の 1 つのテストが失敗した場合にジョブ全体をキャンセルするかどうかを選択します。

    Generate 'Failed Tests' report

    失敗したテスト・ステップに関する情報を提供するレポートを生成するかどうかを選択します。実行後、レポートは［Extensions］タブにあります。

    別の方法として、テストとそのパラメータのリストを含むバッチ・ファイルを示します。

    • 複数のテストを指定するか、同じテストをパラメータを変えて複数回指定します。
    • reportPath パラメータを使用して、テスト結果のパスを定義します。

    バッチ・ファイルは、拡張子を .mtbx にして、次の構文を使用します。

    <Mtbx>
 <Test name="test1" path="c:\tests\APITest1">
 <Parameter name="A" value="abc" type="string"/>
 ....
 </Test>
 <Test name="test2" path="c:\tests\test2">
  <Parameter name="p1" value="123" type="int"/>
  <Parameter name="p4" value="123" type="float"/>
   ....
 </Test>
 <Test name="test3" path="c:\tests\APITest3" reportPath="c:\reports\APITest3">
</Mtbx>

  5. （オプション）OpenText Functional Testing のテスト結果情報を Azure Storage の場所にアップロードするように実行ステップを設定します。

    OpenText Functional Testing の結果を Azure Storage にアップロードすると、テストの実行後に Azure DevOps ポータルから結果にアクセスできます。

    Azure Storage を OpenText Functional Testing テスト結果用にセットアップで説明されている手順を実行したことを確認します。

    次に、UFT One File System Run ビルド・ステップで次のオプションを入力します。

    オプション説明
    Do you want to upload the UFT report to the storage account?

    ［Yes］を選択します。

    Artifacts to upload

    html 実行結果レポートのみをアップロードするか、すべての OpenText Functional Testing 結果ファイルのアーカイブをアップロードするか、またはその両方をアップロードするかを選択します。

    注: API テストを実行するときは、アーカイブをアップロードすることをお勧めします。これは、スタンドアロンの html 実行結果レポートには、キャプチャされたデータに関する情報が含まれていないためです。RequestBody および HttpRawRequest ステップの内容は、アーカイブに含まれている html ファイルにあります。

    Report file name

    パイプライン名とビルド番号に基づいた標準設定のファイル名をそのまま使用するか、任意の名前を入力します。

  6. モバイル・デバイスまたはクラウド・ブラウザでローカル・テストを実行するには、Digital Lab オプションを設定します。

    Azure タスクで定義した設定は、OpenText Functional Testing の［記録と実行環境設定］で定義された設定よりも優先されます。Azure で指定していない設定については、［記録と実行環境設定］が使用されます。

    タスクを 24.2.0 より前のバージョンからアップグレードする場合：Azure タスクの Digital Lab 設定は、［Use Digital Lab］オプションの下にまとめられています。Azure タスクを新しい拡張機能にアップグレードする場合は、Digital Lab の設定が引き続き有効になるようにこのオプションを選択する必要があります。

    Digital Lab への接続の設定：

    オプション説明
    ServerDigital Lab サーバのアドレスを、http[s]://<サーバ名>:<ポート> の形式で指定します。
    Authentication type

    Digital Lab への接続に使用する認証モードを選択します。

    • Basic authentication：ユーザ名とパスワードを使用して認証します。

    • Access key authentication：Digital Lab から受け取ったアクセス・キーを使用して認証します。

    User name と Password：［Basic authentication］を選択した場合は、Digital Lab サーバのログイン資格情報を入力します。

    Access key：［Access key authentication］を選択した場合は、Digital Lab から受け取ったアクセス・キーを入力します。

    Use proxy settings

    プロキシを使用して接続する場合は、次の情報を入力します。

    Proxy Server：プロキシ・サーバのアドレス（形式：<プロキシ・サーバ名>:<ポート>）。

    Use proxy credentials：特定のアカウントを使用して Digital Lab サーバに接続できるようにします。

    Proxy user name and password：［Use proxy credentials］が選択されている場合に、Digital Lab サーバへの接続に使用される資格情報です。

    テストするデバイスとアプリケーションの詳細を指定するには、［Use Device Lab］を選択します。

    オプション説明
    Device

    モバイル・テストのデバイス情報を指定します（DeviceID、Manufacturer、Model、OSType、OSVersion など）。

    これらのフィールドの値を取得するには、Get Digital Lab Resources タスク（旧称 UFT Mobile Get Resources）を実行します。

    DeviceID の値が指定されている場合、他のフィールドは無視されます。

    例：

    DeviceID: "123456789"

    Manufacturer: "Samsung", Model: "SM-G920F"

    OSType: "ANDROID", OSVersion: "7.0"

    Launch on start

    テストの開始時に自動的に起動するアプリを選択します。

    • Home Screen：デバイスのホーム画面。

    • System App：カメラなど、デバイスにプリインストールされたシステム・アプリケーション。

    • Digital Lab App：Digital Lab でホストされるアプリケーション。

    System Application：デバイス上でテストするシステム・アプリケーションを指定します。

    Main Digital Lab Application：［Digital Lab App］を選択した場合、テストするメイン・アプリケーションを指定します。

    値の形式は、「Identifier: "<アプリ識別子>", Packaged: "<Yes/No>"」とする必要があります。Identifier は必須で、Packaged はオプションです。アプリ識別子を取得するには、Get Digital Lab Resources タスク（以前の名前は UFT Mobile Get Resources）を実行します。

    Additional Digital Lab Applications

    テストする追加のアプリケーションを指定します。

    値の形式は、「Identifier: "<アプリ識別子>", Packaged: "<Yes/No>"」とする必要があります。Identifier は必須で、Packaged はオプションです。アプリ識別子を取得するには、Get Digital Lab Resources タスク（以前の名前は UFT Mobile Get Resources）を実行します。

    Install選択すると、テストの開始時にアプリケーションがインストールされます。
    Restart選択すると、テストの開始時にアプリケーションが再起動されます。
    Uninstall選択すると、テストの終了時にアプリケーションがアンインストールされます。

    このテスト実行で開くブラウザを記述するには、［Use Cloud Browser Lab］を選択します。

    • テストするアプリケーションの URL を指定します。ブラウザでこの Web ページが開きます。

    • ブラウザの地理的な場所、ブラウザを実行するオペレーティング・システム、ブラウザの種類、バージョンなどのブラウザ情報を指定します。

      これらのフィールドに使用する値を取得するには、Get Digital Lab Resources タスクを実行します。

      特定のバージョンまたは次のいずれかを指定できます。

      • latest：Digital Lab サーバでサポートされている最新バージョン。

      • latest-1：Digital Lab サーバでサポートされている 2 番目に新しいバージョン。

      • latest-2：Digital Lab サーバでサポートされている 3 番目に新しいバージョン。

      サポートされているバージョンのリストについては、「Digital Lab サポート・マトリクス」を参照してください。

  7. このステップについて、次のような CI システムの制御オプションを設定します。

    Enabledステップをこのビルドの一部として実行するかどうかを指定します。
    Continue on errorこのステップでエラーが発生した場合に、ビルドを停止するか、続行するかを CI システムに指示します。

  8. パイプラインを実行するように設定します。

    ビルド・パイプライン：パイプラインを保存してキューに格納します。

    リリース・パイプライン：リリースを作成してパイプラインをデプロイします。

    パイプラインが実行されると、OpenText Functional Testing テストは追加したタスクの一部として実行されます。

先頭に戻る

テスト結果の表示

テストの実行後、次の方法で実行結果を表示できます。

ビジュアル・レポート

実行結果の［Extensions］タブに、次の要素が含まれるレポートが表示されます。 

  • ［UFT Report］セクションに、テストの実行ステータスが表示されます。また、OpenText Functional Testing レポートおよびアーカイブが Azure Storage にアップロードされている場合は、そのリンクも表示されます。

  • ［Run Summary］に、実行したテストの数および各ステータスの割合が表示されます。

  • ［Generate ‘Failed Tests’ report］オプションを選択した場合は、［Failed Tests］セクションに、失敗したステップの詳細な内訳が表示されます。

注:  

  • リリース・パイプラインを使用している場合、これらの結果はステージ・レベルで利用できます。

  • テスト実行の途中でジョブを中止すると、［Extensions］タブが表示されないことがあります。［Extensions］タブが利用可能で、［Generate 'Failed Tests' report］オプションを選択した場合でも、［Failed Tests］セクションは表示されません。

実行結果ファイルの取得

  • 失敗結果の詳細は、UFTWorking/res/Report_<ビルド実行番号> フォルダにある junitreport.xml ファイルに JUnit 形式で保存されます。

  • OpenText Functional Testing html レポートとアーカイブ・ファイルが Azure Storage にアップロードされている場合は、ストレージ・コンテナでアクセスできます。

  • テスト実行の途中でジョブを中止すると、ジョブが停止するまでに実行されたすべてのテストの結果が、%UFT_LAUNCHER%\res\Report_###\ フォルダの Results###.xml ファイルに保存されます。

Team Foundation Server（TFS）から OpenText Functional Testing テストを実行する場合

OpenText Functional Testing の実行結果を、TFS ビルドの実行結果の［Summary］タブで確認することもできます。

例：

先頭に戻る

ビルドの中止時の OpenText Functional Testing ライセンスの解放

テスト実行を完了する前にビルドを中止した場合、OpenText Functional Testing ライセンスが使用中のままになります。

ライセンスを解放するには、clean.vbs スクリプトを準備し、ビルドの中止後にコマンド・ラインから直接スクリプトを実行します。

あるいは、スクリプト・タスクをパイプラインに追加して、タスクによってライセンスが自動的に解放されるようにすることもできます。

注: スクリプトの実行時に OpenText Functional Testing が表示されていてビジー状態の場合、cleanup.vbs がそれを中断できない可能性があります。その場合、ライセンスを解放するには、OpenText Functional Testing を手動で停止して閉じる必要があります。

コマンド・ラインからスクリプトを実行してライセンスを解放するには、次の手順を実行します。

  1. OpenText Functional Testing が実行されているクライアント・マシンで、次の内容で clean.vbs ファイルを作成します。

    Copy code
    On Error Resume Next
    Set qtApp = CreateObject("QuickTest.Application")
    If qtApp.Launched Then
    qtApp.Test.Stop
    qtApp.Test.Close
    End If
    qtApp.Quit
    Set qtApp = Nothing

  2. ビルドを中止した後、コマンド・ラインからスクリプトを実行します。

  3. ライセンスが解放されたかどうかを確認します。ライセンスの解放を確認する手順を参照してください。

ライセンスを自動的に解放するスクリプト・タスクをパイプラインに追加するには、次の手順を実行します。

  1. clean.vbs ファイルを準備します。ステップ 1 を参照してください。

  2. パイプラインに、コマンド・ライン・タスクを追加します。

  3. 新しいタスクで、次のように入力します。 

    • ［Script］ボックスに、次の行を入力します。

      cscript <clean.vbs ファイルのパス>

    • ［Run this task］オプションで、［Even if a previous task has failed, even if the build was canceled］を選択します。

    このスクリプト・タスクは常に自動的に実行され、ビルドが途中で中止されたかどうかに関係なく、ビルドの最後に OpenText Functional Testing を閉じてライセンスを解放します。

    注: リモート Azure エージェントを管理者として実行することをお勧めします。

ビルドが終了したら、ライセンスが正常に解放されたかどうかを確認します。ライセンスの解放を確認する手順を参照してください。

ライセンスが解放されたかどうかを確認するには、次の手順を実行します。

  1. AutoPass License Server で、［使用状況レポート］メニューをクリックします。

  2. ［UFT Enterprise Concurrent User］で、［履歴］タブをクリックします。

  3. ページの下部にある表で、［クライアント情報］カラムを確認し、ライセンスに関するレコードを探します。

    • そこにライセンス・レコードがあれば、ライセンスは正常に解放されています。

    • ライセンスが［使用中］タブにある場合、ライセンスは使用中のままです。

先頭に戻る

その他の参照項目：