自動化ワークフロー (仕様ファースト)

仕様ファースト自動化ワークフロー

仕様ファーストは、自動テストコードを実装する前にテストケースを設計するというアプローチです。このワークフローでは、まず TestRail でテストケースの大枠と設計を作成するため、さまざまなフォーマットでテストケースを作成し、レビュー、カテゴリ分け、優先順位付けを行って、自動化するテストケースを選択できます。このアプローチは、TestRail ですでに文書化されているテストケースを自動化するチーム、より詳細にテストケースを文書化する必要がある状況にあるチーム、TestRail を使用して、自動化するテストケースやその時期に優先順位を付けたいチームなどに適しています。

コードで直接テストケースを作成しており、TestRail にテストケースが保存されていない場合は、コードファースト自動化アプローチが参考になるでしょう。

TestRail CLI を使用すると、TestRail のテストケースの ID をどのようにテスト自動化フレームワークに追加するかに応じて、 name または property 値を渡すことで、--case-matcher オプションを利用できます。

利点:

- コードの構造が変化した場合もケースのマッピングが保たれます。
- 自動作成によってテストケースが重複する可能性が減ります。
- 詳細なテストケースの設計と計画が可能です。
- 整備されたテスト文書が必要なチームに適しています。

欠点:

- コードにケース ID が記載されていないテストケースは作成されず、結果もサブミットされません。
- 手作業でマッピングする必要があり、面倒でエラーが発生しやすくなります。

テストケースのマッピング

TestRail のテストケース ID をテスト自動化コードに追加する方法は 2 つあります。

- --case-matcher "name" オプションを使用する場合
  - テストケースの ID をテスト名に追加します。そうすると、ケース ID がテストケース名の一部として JUnit レポートに表示されます。次のように、さまざまなパターンに従って ID を追加できます。[C123] test_case_1, test_case_1 [C123], C123 test_case_1, C123_test_case_1 test_case_1 C123, test_case_1_C123
  - ```
  <testcase classname="tests.LoginTests" name="C123_test_case_1" time="650">
  </testcase>
```
- --case-matcher "property" を使用する場合
  - JUnit レポートに test_id というプロパティが追加されるように設定する必要があります。
  - ```
  <testcase classname="tests.LoginTests" name="test_case_1" time="650">
      <properties>
          <property name="test_id" value="C123"/>
      </properties>
  </testcase>
```

使用するケース ID は、テストケースページに接頭辞 C 付きで表示される ID です。

TestRail CLI を使用した自動テスト結果のアップロード

TestRail CLI は簡素で効率的であるよう設計されています。仕様ファースト アプローチでは、TestRail CLI をインストールし、TestRail インスタンスを設定したら、コマンドラインから JUnit 形式の結果ファイルを渡してすばやくランを作成し、テスト自動化プロジェクトのテストケースのテスト結果を追加できます。

下のサンプルは、テスト名にテストケース ID を含む JUnit XML の例です。この場合、--case-matcher "name" オプションを使用して TestRail のテストケースと比較しますが、後の手順は --case-matcher "property" オプションを使用する場合も同じです。下記のような簡単なコマンドを実行し、テスト結果を TestRail に送信できます。

仕様ファーストアプローチを採用する場合は、-n オプションを使用して自動テスト作成をスキップすることを推奨します。それでも、コードに ID が含まれていないテストを作成したい場合は、-y オプションを使用できます。ただし、後でコード内で ID をマッピングしなかった場合、次に CLI を実行したときに該当テストケースが重複して作成されることに注意が必要です。

JUnit XML のサンプル：

<testsuites name="test suites root">
  <testsuite failures="0" errors="0" skipped="1" tests="1" time="0.05" name="tests.LoginTests">
    <properties>
      <property name="setting1" value="True"/>
    </properties>
    <testcase classname="tests.LoginTests" name="C2647_test_case_1" time="159">
      <skipped type="pytest.skip" message="Please skip">
        skipped by user
      </skipped>
    </testcase>
    <testcase classname="tests.LoginTests" name="C2645_test_case_2" time="650">
    </testcase>
    <testcase classname="tests.LoginTests" name="C2648_test_case_3" time="159">
      <failure type="pytest.failure" message="Fail due to...">
        failed due to…
      </failure>
    </testcase>
  </testsuite>
</testsuites>

TestRail CLI コマンド：

$ trcli -n \
>    -h https://INSTANCE-NAME.testrail.io \
>    --project "TRCLI Test" \
>    --username user@domain.com \
>    --password passwordORapikey \
>    parse_junit \
>    --case-matcher "name" \
>    --title "Automated Tests Run" \
>    -f results.xml

Parsing JUnit report.
Processed 3 test cases in 1 sections.
Checking project. Done.
Creating test run. Run created: https://INSTANCE-NAME.testrail.io/index.php?/runs/view/123
Adding results: 3/3, Done.
Submitted 3 test results in 5.5 secs.

プロセスが終了した後、テストランおよびテスト結果ページに移動すると、TRCLI Test プロジェクトに Automated Tests Run という名前の新しいランが表示されます。TestRail CLI が TestRail のテストランへの直接リンクを出力していることにも注目してください。

テストランを開くと、各テストケースの結果が表示されます。失敗したテストケースをドリルダウンし、JUnit レポートから直接インポートされたエラーメッセージを確認できます。これはテスト中に起きた問題の概要をすばやく把握するのに便利です。

仕様ファースト自動化ワークフロー

テスト ケースのマッピング

TestRail CLI を使用した自動テスト結果のアップロード

目次

テストケースのマッピング