テストケースの設定
Eggplantテスト戦略
Eggplantのテストケース作成の手法は、以下の4つの異なるアプローチに整理できます:
- スクリプトベース
- モデルベースからのステップの指定
- モデルベースのState設定に対する探索的テスト
- モデルベースの完全探索的テスト
ベストプラクティスとして、自動化初期には最初の2つのアプローチに集中し、導入に着手しましょう(マウスオーバーで拡大):
スクリプトベース
スクリプトベースのテストアプローチは、Eggplant DAIからスクリプトを指定して実行する方法です。これは、 Test Configとして管理されます。Test Configは、テストケースの管理体系に従いグループとして整理します。
テストケースは、スクリプトで作成した関数をテストステップとして呼び出していく仕組みで作っていきましょう。Testcasesフォルダ内の各スクリプトを、テストケースとして定義します。実行単位は、DAI内のTest configで定義され、処理定義はEggplant Functionalスイート内に保持されます。テストの実行は、Test Case個別に、またはTest configより(手動またはスケジュール設定によって)実行します。(詳細についてはEggplantでのテストケース実行セクションを参照)
このアプローチを使用する理由
- このアプローチは、従来の一般的な自動化やテスト管理に従ったEggplantのシンプルな導入方法です。
- 限られたリソースで手動テストを行っているチームにとって、このアプローチは自動化への迅速かつ簡単なルートであり、後述するモデルベースアプローチへの良い導入となります。
- このアプローチは、常に特定のパス/ルールに従わなければならない、順序の定められたテストケースに適しています。これは、銀行、医療、または防衛アプリケーションで一般的に見られます。既になんらかのスクリプト言語を用いてよく発達したフレームワークを導入している組織である場合、この戦略はテストケースの自動化を構築する上で、親和性の高いアプローチとなります。
- このアプローチの導入は、複雑なアプリケーションをテストする場合にも検討するのがよいでしょう。例えば、多くのバリエーションがある場合、アプリケーションのモデルを作成するにはあまりにも困難/時間がかかるかもしれません。
モデルベース
Eggplantでのモデルベースのテストアプローチでは、AUT/SUTをEggplant DAIで視覚的に表現できます。
モデルにはStateとActionがあり、システム/アプリケーションの機能を表します。これらのState/Actionには、モデルの実行の際の処理となるEggplant Functionalの「snippets」コードが設定されています。
モデル実行のパスは、DAIからテストケースを設定するか、バグハンティングとカバレッジエンジンを最大化するための探索的モードで実行する際に決定されます。詳細については、EggplantのドキュメントのEggplant DAI Model Executionsページを参照してください。
この手法を採用するには、モデルのState/Actionに設定できるように、スニペットとなるEggplantコードを部品として作成する必要があります。
このアプローチを使用する理由
- モデルを作成すると、ユーザーはAUT/SUTを視覚化した、アプリケーションのデジタルツインを得ることができます。 ユーザーは、StateとActionのステップを指定することで、モデルから直接、テストケースを簡単に設定できます。
- この方法でフレームワークを作成することにより、テストアセットのシンプルなメンテナンスが推進され、新機能が追加されたときの迅速なテストが可能となります。
- 集約と優先順位付けアプローチでは- テストケースを構築しますが、一つのStateに複数のActionが設定される方法で、従来のテスト定義手法に沿いながら、 テストの際には、過去のバグや改修実績に基づいて実行するActionの優先順位付けを行います。
- このアプローチは、AUT/SUTの単位でモジュラー化を行ったテスト、または重要なパスからの逸脱が許される場合に導入されるべきです。例えば、小売のウェブシステムやアプリケーションなどです。機能をより小さなサブモデルに分割するか、段階的に自動化することができる大規模なアプリケーションに対するテストでも導入するのがよいでしょう。