Best practices for structuring | Ranorex
Help CenterUser GuideHands-on application topics

構成に関するベスト プラクティス

このセクションでは、品質、保守性、トラブルシューティング、コラボレーションを向上させるためのテストの構成方法についての TIPS を説明します。

テスト デザインの三原則

テストの規模や複雑さに依存せず、構造化されていて、メンテナンスしやすく、より効果的なテストにするため、以下の原則に従ってください。

シンプルにする (Keep it simple)

テスト構成、テスト ケース、モジュール、その他すべてについて、可能な限りシンプルに、必要に応じて複雑にしてください。

ロジカルにする (Keep it logical)

テスト構成、テスト ケース、モジュールなどは、テスト要件と照らし合わせて意味のあるものでなければなりません。項目を不用意に分割しないでください (例: ユーザー名/パスワードの入力と、”ログイン”ボタンのクリックを、別のモジュールに分けている)。あるいは、別々にすべきものを混ぜないでください (例: Web ショップのエンドツーエンドのワークフローを、1 つのモジュールにまとめている)。

怠ける (Be lazy)

可能なものはすべて再利用してください。常に再利用性を意識してください。

テストをドキュメント化する

Ranorex Studio は、名前、説明、レポート アクションなど、テストをドキュメント化するいくつかの方法を提供します。これらは最初、不要なものに思えるかもしれませんが、適切なドキュメントは、テスト スイートを整理し、保守性を向上させ、チームで作業することを助けます。

ドキュメント化されていないテストは、未完成のテストです。

すべてに名前を付ける

テスト コンテナー、モジュール、リポジトリ アイテム、データ コネクタなどに、常に適切な名前を付けてください。チームで作業する場合には、命名規則を使用してください。デフォルト名は、短期的には問題ありませんが、長期的には使用しないでください。

デフォルト名しかないテスト スイート。紛らわしく、メンテナンスが難しく、共同作業するのは困難。
適切な名前が付けられたテスト スイート。すべての項目が一目瞭然。

すべてに説明を付ける

テスト スイート ビューで、テスト スイート、テスト コンテナー、モジュールに説明を追加することができます。追加した説明は、自動的にレポートにも表示されるため、理解の助けになります。

説明の追加は以下の手順でおこないます。

項目の横にある、Description 列をダブルクリックします。.
いくつかの編集オプションを含む、エディターが開かれます。画像を追加することもできます。

説明の例をいくつか示します。

Test suite description editor

In the report

Test container description editor and report view

レポート アクションを追加する

Capture screenshot アクションと Log message アクションを使用することで、画像やメッセージをレポートに追加することができます。これらは、このテストについてあまり詳しくない人が、このレポートを読むときの助けになります。

スクリーンショットのキャプチャ アクションを追加する

Ranorex Studio は通常、Error や Failure が発生した場合のみ、レポートにスクリーンショットを追加します。Capture screenshot アクションにより、任意の場所 (例えば、あるアクションが実行されたときのUI要素を表示するためなど) で、スクリーンショットを追加できます。

ログ メッセージ アクションを追加する

Ranorex Studio は標準で、テスト実行に関する多くの情報をレポートしますが、何らかの情報を追加したい場合もあるかもしれません。これは、Log message アクションによって簡単に追加できます。

空または無効化のままにしない

完成して動作しているテスト スイートには、空の項目や無効化された項目があってはいけません。テスト スイートが、まだ完成していないのであれば、空の項目があっても構いません。動作確認やトラブルシューティングのためであれば、無効化された項目があっても構いません。

無効化されたレコーディング モジュール
空のスマート フォルダー
無効化された Teardown 領域

メインのテスト コンテナーとしてテスト ケースを使用する

テスト ケースは、テストの主な目的 (例えば、データベースへのエントリの追加) を表現するものです。スマート フォルダーは、テスト ケースをより構造化するためのものです。

Note icon

メモ

技術的な意味では、テスト ケースとスマート フォルダーの主な違いは、レポートにおいて、テスト ケースのみが、テストの成功/失敗のカウントの対象となることです。これは、テスト ケースがメインのテスト コンテナーとしての役割を持つということを反映しています。

好ましくない例: スマート フォルダーをメインのテスト コンテナーとして、テスト ケースをそのサブ アイテムとして使用した場合
好ましい例: テスト ケースをメインのテスト コンテナーとして、スマート フォルダーをそのサブ アイテムとして使用した場合

深いテスト スイート階層を避ける

一般的なルールとして、テスト コンテナーの階層は、5-6 階層以上にしないでください。

複雑なテスト要件は、複雑なテスト スイート構造を必要とするように見えるかもしれませんが、必ずしもそうではありません。⇢ 前のセクション で、いくつかのテスト構成タイプの違いと、テスト スイートベースの構成ではなく、プロジェクトあるいはソリューション ベースの構成を使用すべき時について、説明しました。これにより、テスト スイートをシンプルに保ち、メンテナンスの管理がしやすく、柔軟なコラボレーションも可能になります。

テスト ケースを独立に保つ

可能であれば、テスト ケースは他のテスト ケースに依存しないようにしてください。これにより、トラブルシューティングや、さまざまな構成でのテスト実行が容易になります。

これをおこなうひとつの方法は、テスト スイートとテスト コンテナーで、⇢ Setup/Teardown 領域 を使用することです。テスト ケースを、少なくとも 1 つの Setup/Teardown 領域でラップすることをおすすめします。

⇢ テスト シーケンス⇢ TestRun によって、テストをいくつかの異なる構成で実行することができます。

テスト シーケンス設定へのアクセス
テスト シーケンスの設定
テスト スイートごとの TestRun の選択

バリデーションを使用する

ソフトウェアのテストでは、常に、期待する振る舞い/状態と、実際の振る舞い/状態とを比較します。⇢ バリデーション がないテスト ケースは、目的がないテスト ケースになってしまいます。

変数を使用する

モジュールで、定数ではなく変数を使用し、モジュールの再利用性、テストの柔軟性を高めてください。

モジュールで使用されている 2 つの固定文字列
変数に置き換えることで、モジュールの再利用性が高まる

変数をメンテナンスする

変数のクリーンアップを定期的に実行し、未使用のものを削除してください。また、すべての変数に適切なデフォルト値が設定されていることを確認してください。テスト スイートの一部ではなく、レコーディング モジュールを直接実行する場合など、バインドされたデータ カラムから値を取得できない場合に重要です。

未使用の変数
変数のデフォルト値

データ ソースを近くに配置する

データ ソースやパラメーターは、その値を変数に受け渡すテスト コンテナーの近くに割り当ててください。最低でも、データソースが使用される場所から、2 階層以内のテスト コンテナーにしてください。

テスト コンテナーの子孫は、データ ソースを継承します。しかしながら、深い階層からの継承は、起こっている事柄を理解するのを困難にします。

Note icon

メモ

一般的に、データ駆動型テストでは、重要な結果を得ることができるのに十分な品質を確保しつつも、可能な限り少ない量のデータをテストに与えるべきです。

好ましい例: バインドされた変数を含むテスト コンテナーに割り当てられたデータソース
使用される場所から遠く離れたテスト コンテナーへの割り当ては避けるべき

条件分岐を使用する前に再検討する

条件分岐が必要となる場合もありますが、多くの場合、別のテスト コンテナー構成をとることで回避できます。

条件分岐は、複雑さを増大させ、保守性を低下させると共に、共同作業においてしばしば問題となります。これは、条件分岐が複数のテスト コンテナーのレベルに影響する場合、特に問題となります。最低でも、条件分岐が 2 階層以上のテスト コンテナーに影響を与えないようにしてください。

2 つの例を示します。

テスト コンテナーは、条件に基づいてデータソースの一部のみを実行します。
条件分岐を削除してデータソースを調整して、必要なデータのみが含まれるようにすることをおすすめします。

条件が満たされた場合のみ、配下のテスト コンテナーが実行されるテスト ケースがあります。
このような場合には、テスト ケースを 2 つに分割することができます。