メインコンテンツまでスキップ

モデルベースのアプローチ

モデルベースのアプローチのスイート構造では、CommonおよびWrapper Functionフォルダを引き続き活用します。また、DAIモデルのStateひとつひとつに対してスクリプトのフォルダを作成し、モデル内のActionsを反映するハンドラーを作成します。


States

一般的に、モデル内のStateはアプリケーション内のページに対応して作成しますが、必ずしもそうである必要はありません。アプリケーションが対応するStateに遷移したときにのみ発生する、依存関係のある一連のアクションをグループ化するために使用できます。

モデル内に存在するStateの種別については、次のリンクを参照してください。

Do:
常にExit Stateを持つこと:
このStateは、実行の完了を表します。無限ループ実行を避けるために、すべてのモデルにExit Stateを設定してください。

Actions

Actionは、ユーザーがAUTに対して行う具体的な操作であるべきです。これには、ボタンをクリックする、フィールドに入力するなどが含まれます。アプリケーションが特定の状態にある場合にユーザーが行う操作を端的に示すものであるべきです。

覚えておくべきこと:モデルは、レイアウトとロジックの点でアプリケーションそのままのかたちであるべきです。モデルを構築する際の各段階で、「これは意味があるか?」「これは有効なアクションか?」を確認しましょう。

Actionの種類については、このリンクを参照してください。

可能な限り、アクションを具体的に、かつ分離してください

理想的には、システムでユーザーが実行できる現実的な操作に対応するアクションのみを追加します。チェックやアサーションなどはそのスニペットに含まれるべきです。これは厳格なルールではありません。たとえば、読み取り専用情報を提供するページでは、「詳細を読んでチェックする」がユーザーにとって有効なアクションとなる場合があります。これはActionとして設定することができます。

別々の個別操作のセットをまとめたActionの作成を避ける

メニューを開き、削除を選択し、確認をクリックし、削除されたかどうかを確認する...などステップを含む「削除」という一つのActionを定義することはシンプルに見えるかもしれませんが、実際にはモデルの文脈で非常に混乱し、プログラミングの観点から見ても非常に複雑です。

これらはすべて別々の具体的なアクションであり、そのように作成されるべきです。スニペットを使用してグループ化されたActionを定義すると、柔軟性が失われ、特定の文脈でのみ機能するActionや混乱を招く状態遷移が発生します。

Action間の条件付き遷移

Actionから別のStateや次のActionへ、複数の遷移選択肢を定義することができます。これらの遷移には、選択条件を適用すことができます。これは、特定の状況に依存する遷移を表すのに便利な機能です。例えば、Actionが成功したら次のStateへの遷移につながり、失敗したらそのStateでエラーメッセージを表示する処理などが可能です。


サブモデル

大規模または複雑なアプリケーションを自動化する際、サブモデルはモデルをより小さい構造化された機能エリアに分割する方法として使用できます。これにより、運用と保守が容易になります。

サブモデルは、独立して個別に開発および実行ができます。アプリケーションの機能エリアを独立させて、状況に応じて新機能を段階的に検証対象に含める運用が可能です。

導入基準は以下に基づき明確に決定できます:

  • この機能エリアをテストするために必要なテストケース(データ駆動型でない)の数。
  • 必要なStateとActionの数が多ければ、ひとつのモデル相当と見なされる場合があります。

この例としては、NopCommerceウェブサイトの登録ページ、銀行アプリの支払いフロー、または電子商取引アプリ/ウェブサイトのチェックアウトなどがあります。

DON'T
ネストされたサブモデルは、デバッグとオンボーディングの複雑さのため避けるべきです。

サブモデルの詳細については、このリンクを参照してください。


変数

  • Global - モデルの全Stateに影響する値
  • State - Stateに含まれる複数のActionで使用される値
  • Local - Action内のスニペットで渡される値

DAIからEPFへの変数の渡し方

DAIとEPF間の循環依存を避けるため、変数をEPFに渡す実装は次の場合に限定しましょう:

  • 変数がStateに対して影響する場合。例えば、ブラウザ名をlaunchBrowser関数に渡す、または異なる権限タイプのログイン詳細。
  • モデルのStep選定に影響する変数。
DON'T
例えば、DAIからEPFのナビゲーション関数に操作内容と検証情報を渡す処理は、モデルのState全体に影響を与えない様、EPF内の一部のスクリプトへ影響範囲を絞るべきです。

EPFからDAIへの変数の渡し方

  • モデルの遷移やStateに変数が影響する場合のみ、DAIに値を返すことに合理性があります。 例えば、ログイン状態やboolean型条件などに応じてルートが変更される場合が該当します。
DON'T
実行中の永続変数としてDAIを使用すること。

DAI変数の詳細については、このリンクを参照してください。