多くのテストシナリオでは、アプリケーションにログインしてから機能を検証する必要があります。mabl では、トレーナーでステップを記録することでログインを自動化できます。これらのテストがクラウドで実行されると、常に新しいインスタンスから開始されます。つまり、ログイン後の操作を検証するすべてのテストは、それぞれ独立して認証を行う必要があります。なぜなら、Cookieやキャッシュなどのセッションデータは、同じプラン内の後続の実行には引き継がれないためです。
mabl では、フローを使ってこのプロセスを簡単にできます。アプリのログインを一度トレーニングすれば、同じ種類のログインが必要な他のテストでも再利用できます。ログインフローを活用すると、テストのカバレッジをより早く追加でき、各テストごとにログインステップを個別に管理する手間も減らせます。
この記事では、mablのテストでログインフローを作成・管理する際のベストプラクティスについて説明します。
ログインのアサーション
ベストプラクティスとして、ログイン後にアサーションステップを追加して、ログインの成功を確認することをお勧めします。
テスト用クレデンシャルの使用
mablはデータを安全に保存するために、ワークスペース固有の暗号化キーでクレデンシャルを暗号化します。アプリケーションの安全性をさらに高めるために、次のことをお勧めします。
- テストで利用するための、テスト用クレデンシャルをアプリケーションに作成する。
- テストでは、個人を得的できるようなクレデンシャルを使用しない。
クレデンシャル設定方法の検討
アプリケーションにログインする方法として、mablクレデンシャルを使用する方法があります。mablクレデンシャルはワークスペースレベルで設定でき、実行時にアプリケーションに渡される特殊な変数クラスです。
次の理由から、mablクレデンシャルを使用してログインフローを作成することをお勧めします
- ワークスペースの所有者は、ユーザーの役割を割り当てて、mablのクレデンシャルへのアクセスを管理できます。これには、リソースグループを使用して特定のユーザーへのアクセスを制限する機能も含まれます。
- フローやテストにクレデンシャル情報が記載されることがない。
- mablクレデンシャルはmabl内で特別な暗号化が施されて保存される。
- mablのクレデンシャルをクラウドクレデンシャルとして保存することで、セキュリティを強化できます。
MFAログインのサポート
アプリケーションが多要素認証を使用している場合は、MFAログインのオプションをご覧ください。
環境別クレデンシャル
mabl では、環境ごとに異なるクレデンシャルを割り当てることはサポートしていません。異なる環境で実行する際に異なるログイン用クレデンシャルが必要な場合は、回避策として mabl のクレデンシャルの代わりにプランで環境変数を使用することを検討してください。この方法の欠点は、現時点ではリソースグループを使用して環境変数へのアクセスを制限できないことです。
この制限があなたのワークフローに影響する場合は、mabl Product Portalでお知らせください。
ログインフローの命名規則の設定
ログイン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など) をテストの自動化に使用する。
mablトレーナーは、Googleアカウントへの自動ログインをサポートしていません
