Octomind: E2E テストを最初から始めるにはどうすればいいですか?
Octomindを始めるのにこの記事が役立ちそうなので、日本語でまとめました。
関連記事としてこちらもどうぞ。
E2E テストを最初から始めるにはどうすればいいですか?
エンドツーエンドのテストを始めたい開発者向けのOctomindチュートリアル
より早く機能をリリースしなければならないというプレッシャーにさらされているとき、テストの品質はたいてい最も犠牲になります。同様に、ユニット テストや統合テストが不足しているアプリケーションで、もっと早く発見すべきだったバグが発生し始めたとき、TDD の取り組みを強化するよりも早く最も重要なユーザー フローをカバーできるため、エンドツーエンド テストを導入して回帰を検出することがよくあります。
しかし、専用のテスト チームがなければ、Playwright などの自動化フレームワークを学習、構成、統合することで、開発者はコードの作成や機能の出荷に集中できなくなります。
それが、私たちが Octomind を構築している理由です。私たちは AI を使用して、自動化テストの経験がなくても、エンドツーエンドのテスト スイートをゼロから作成することを自動化します。
Octomind を使いこなすにはどのような手順を踏む必要があるかを説明します。これにより、自分の Web サイトやアプリで試してみたいかどうかがわかります。
1. はじめに
開始はできるだけ簡単にできます。テストしたいサイトの公開 URLを入力するだけで、すぐに開始できます。
しかし、Octomind はパブリック URL に限定されません。オンボーディング フローでのみ、将来のデプロイメントをテストおよび検証するための「既知の良好な」状態またはテスト用語の「ベースライン」を作成する必要があります。テスト スイート全体は、単一の API 呼び出しまたは SDK 呼び出しで、任意の内部環境 (開発を含む) で実行できます。
しかし、これは少し先へ進むので、テスト実行のセクションでこれについて説明します。
サインアップ フローに戻ると、プロジェクト名として URL を使用することをお勧めしますが、完全に自由です。次に、標準のアカウント作成とログイン フローがあり、ログインすると Octomind の AI エージェント(以降はエージェント と呼びます) がサイトにアクセスできるかどうかを確認し、テスト ケースの作成に取り掛かります。
2. テストの作成
では、Octomind はどのようにして何をテストすべきかを知るのでしょうか?
当社の LLM は、何千もの異なるタイプのサイトやアプリケーションに対して継続的にトレーニングおよび評価されています。このデータ セットを使用すると、各サイト タイプを分類し、関連するテスト ケースを導き出すための独自のコンテキストを作成できます。
エージェントは常にCookie バナーと必要なログイン フォームの検出から開始します。これは、ログイン フロー自体をテストしている場合を除き、ほとんどのテストでは、すべてのテスト実行の前にこれらのいずれかまたは両方を完了する必要があるためです。
必要なログイン フォームが見つかった場合は、テスト資格情報を入力するように求められます。または、認証されていないことをテストするには、資格情報を空白のままにしておきます。
将来のログイン テストで使用するために、設定パネルから後で入力することもできます。
次に、Octomind はサイトを分析して、最も論理的なテスト ケースの初期セットを決定します。テスト スタック ビューには、各テスト ケースの進行状況と手順が表示されます。
エージェントは通常、3 ～ 4 個のテスト ケースから開始します。これはシステム上の制限ではなく、実用的な制限です。エンドツーエンドのテスト範囲を拡大する最善の方法は、小さく始めて徐々に拡張することです。
最初のテストの実装には多少時間がかかる場合があります (現在対応中です)。エージェントが各テスト ケースを完了すると、テストの合計数とアクティブ テスト数が更新され、テストが正常に実行され合格したことを示します。
3. テスト実行
すべてのテスト ケースが実装されると、Octomind はアクティブなテストを実行し、最初のテスト レポートを作成します。
さらに詳しく知るには、テスト レポートの詳細ページで、各テスト ケースのステップごとの視覚的な表現を提供します。
または、 Playwright Trace Viewerを調べて特定のテスト ケースをデバッグしたり、エージェントによって生成されたコードをローカルで実行してステップ デバッグしたりすることもできます。
テスト実行をスケジュールできます。
また、統合または API を介して、CI/CD のデプロイメント後のタスクでオンデマンドでトリガーされます。
4. テスト範囲
ここが面白いところです。エージェントにテストを generate more で依頼するだけで、テストの範囲を広げることができます。
また、新しいテストの提案を取得したり、エージェントにプロンプトを出してカスタム テスト ケースを作成したりすることもできます。
テスト ケースは階層的に配置され、親から子への実行シーケンスを視覚的に表示するとともに、エージェントに新しいテスト ケースのコンテキストを提供します。
5. テストステータスとデバッグ
アクティブは、テスト ステップの設計が期待どおりに機能したことを示します。一方、非アクティブなテスト (オフ) は、エージェントが障害に遭遇し、テスト検証ステップに到達できなかったことを意味します。サイトに問題はありません。エージェントは、テスト戦略の改善に支援を必要としているだけです。「ステップの確認が必要」というラベルが付けられます。
非アクティブなテストを修正するには、さまざまなオプションがあります。
エージェントが生成したプロンプトは、想定していなかった手順を含めるように変更できます。
ロケーター(操作する要素) を調整できます (例: 間違ったボタンがクリックされた場合) 。
アサーションとインタラクションの方法は変更できます (たとえば、正しい要素の状態を検証していない場合など)。
冗長なステップを削除できます。
さらに、テストをローカルで実行してデバッグすることもできます。
テスト手順が修正されたら、「保存して実行」をクリックしてテストを実行し、成功した場合はアクティブなテストに変わります。
これは Octomind の最初から最後までの非常に包括的なツアーです。ぜひ試していただければ幸いです。
ご質問がある場合は、daniel @ octomind.dev までメールを送信するか、Discord コミュニティに参加してください。
Co-founder & CPO
この記事が気に入ったらサポートをしてみませんか？