アプリケーションへのログイン

多くのテストシナリオでは、アプリケーションにログインしてから機能を検証する必要があります。mabl では、トレーナーでステップを記録することでログインを自動化できます。これらのテストがクラウドで実行されると、常に新しいインスタンスから開始されます。つまり、ログイン後の操作を検証するすべてのテストは、それぞれ独立して認証を行う必要があります。なぜなら、Cookie やキャッシュなどのセッションデータは、同じプラン内の後続の実行には引き継がれないためです。

mabl では、フローを使ってこのプロセスを簡単にできます。アプリのログインを一度トレーニングすれば、同じ種類のログインが必要な他のテストでも再利用できます。ログインフローを活用すると、テストのカバレッジをより早く追加でき、各テストごとにログインステップを個別に管理する手間も減らせます。

この記事では、mablのテストでログインフローを作成・管理する際のベストプラクティスについて説明します。

• テスト用クレデンシャルの使用
• クレデンシャル設定方法の検討
• 命名規則の設定

テスト用クレデンシャルの使用

mablはデータを安全に保存するために、ワークスペース固有の暗号化キーでクレデンシャルを暗号化します。アプリケーションの安全性をさらに高めるために、次のことをお勧めします。

• テストで利用するための、テスト用クレデンシャルをアプリケーションに作成する。
• テストでは、個人を得的できるようなクレデンシャルを使用しない。

クレデンシャル設定方法の検討

アプリケーションにログインする方法として、mablクレデンシャルを使用する方法があります。mablクレデンシャルはワークスペースレベルで設定でき、実行時にアプリケーションに渡される特殊な変数クラスです。

次の理由から、mablクレデンシャルを使用してログインフローを作成することをお勧めします。

• ワークスペースの所有者は、ユーザーの役割を割り当てて、mablのクレデンシャルへのアクセスを管理できます。これには、リソースグループを使用して特定のユーザーへのアクセスを制限する機能も含まれます。
• フローやテストにクレデンシャル情報が記載されることがない。
• mablクレデンシャルはmabl内で特別な暗号化が施されて保存される。
• mablのクレデンシャルをクラウドクレデンシャルとして保存することで、セキュリティを強化できます。

クレデンシャルのその他のアプローチ

mablクレデンシャルには下記の2つの制限事項があります。

• 環境ごとに異なるmablクレデンシャルを設定することはできない。
• 1つのプランはmablクレデンシャルを1セットしか使用できない。

環境ごとに異なるクレデンシャルが必要なプラン、あるいは複数のクレデンシャルが必要なプランの場合、代替手段として下記の表の方法を検討してください。

ログインフローの命名規則の設定

ログインFlowの命名規則を設定しておくと、チームの他のメンバーがFlowを再利用しやすくなり、二度手間を省くことができます。

命名に利用できる情報として、ユーザーの役割やアプリケーション名があります。例を示します。

• User login - main app
• Admin login
• Employee login - HR portal

ログインの自動化に関する制限事項

mablは、以下のような自動化対策がとられたアプリケーションに対する自動ログインをサポートしていません。

• reCAPTCHA または CAPTCHA
• NTLM

自動化防止対策は、一般的にGoogle、Apple、Facebook、LinkedIn、GitHubなどのソーシャルIDプロバイダーによって使用されています。ソーシャルIDプロバイダーを使用するアプリケーションをテストするときには、アプリケーションにログインを公開するために、次のいずれかの代替手段を検討してください。

• ユーザー名/パスワードによるログインを代わりに使用する。
• テスト環境に自動化ユーザー専用のログインツールを公開する。
• IDプロバイダーが提供するツール (サービスアカウント＋Google IAPなど) をテストの自動化に使用する。