🧠 概要：
概要
この記事では、ローカルで動作するLLM（大規模言語モデル）を使用して、自然言語のテストランナー「Aethr」を実行する試みについて詳しく述べています。特に、環境構築の手順やテスト実行時の結果の考察が中心となっています。
要約
-
環境構築:
- WSL上でOllamaをインストールし、必要なモデルをダウンロード。
- 環境変数を設定し、テストケースの記述ファイルを作成。
-
コマンド実行:
npx -y aethr run <テストケース>でテストを実行。
-
実行結果と考察:
- テスト結果に安定性がないことが確認された。
- いくつかのパターンで結果が異なることが観察された:
- パターン1: 指定した手順を全て実行し、正確な結果が得られた。
- パターン2: 中途で実行が止まり、その時点での結果だけで評価された。
- パターン3: 生成されたコードが期待通りにブラウザを操作できなかった。
- パターン4: 期待とは異なる結果が報告された。
-
まとめ:
- LLMを使用した自動テストは、時には期待通りに動作するが、そうでないことも多い。
- テストケースの意図を正確に反映するためには、慎重な設計が必要。
-
今後の期待:
- AethrからリモートのLLMサーバへ接続可能になることが望ましいとした。
- ハマったポイント:
- Node.jsのバージョンの不一致や、環境変数の設定ミスなど、いくつかのトラブルがあった。
この記事全体として、ローカルLLMを用いた自動テストの実用性と課題が鮮明に描かれています。
前回に引き続き、ローカルLLMで自動テストを動かすチャレンジをしてみました。
前回の記事はこちら
環境構築
WSLでのOllamaのインストールおよびモデルのダウンロード
Ollama の公式の案内どおりにコマンドを実行。
curl -fsSL https:ollama pull <使用したいモデル>環境変数の設定
Ollamaを使うための以下設定を.envファイルに記述。
OLLAMA_MODEL=phi4-mini※小サイズでツールが利用できてそこそこの性能を期待できる、となるとphi4-miniが無難でしょうか
テストケース記述ファイルの作成
私は以下サイトから拝借しました
https://qiita.com/two_pack/items/715ca1ce9364f0d900e4
コマンド実行
npx -y aethr run <テストケース記述ファイル>結果と考察
ファイルを読み込んでのテスト実行はできたものの、結果が安定しませんでした。
何回か動かして確認できたパターンは以下のとおりです。
パターン1：手順を最後まで実行、検証結果が正確
これは一番うれしいパターン。軽量なローカルLLMで動くならとてもよいのでは！…と思いきや、期待どおりに動かない場合も多々ありました。
以降、期待どおりでない結果をご紹介いたします。
パターン2：手順を途中まで実行、実行したところまでで結果判定される
例：参考ページのシナリオ1「織田信長でログインできる」
複数ある手順のうち「Webページ表示」でシナリオ実行が止まり、「Webページ表示」の結果でシナリオがPASS判定されました。
パターン3：一連の手順はコード生成されているが、ブラウザを期待どおり操作できない
例：参考ページのシナリオ2「徳川慶喜はログインできない」
どうやら、生成したテストコードでは対象ページを正しく操作できなかったようです。
INFO: LLM start: 1:llm:ChatOllama {"messagesLength":2}playwright__browser_type(element="ユーザー名", ref="", text=tokugawa)playwright__browser_click(ref="")playwright__browser_type(element="パスワード", ref="", text=yoshinobu)playwright__browser_click(ref="")playwright__browser_type("ログイン", element, expected=true)assertion_result: 検証結果 - 期待される文言が表示されている (against=page) failed.エラーメッセージ："ユーザー名またはパスワードが正しくありません" は、ページに存在しない。パターン4a：手順を最後まで実行、検証結果が不正確(本来の動作結果とLLMが認識している動作結果が一致しない)
例：参考ページのシナリオ3「豊臣秀吉でログインしたのに、徳川家康でログインされる」
INFO: LLM start: 1:llm:ChatOllama {"messagesLength":2}1. playwright__browser_navigate {"url": "https://v0-todo-app-for-testing.vercel.app/"}2. playwright__text_input {"element": "//input[@id='username']", "ref": "", "slowly": false, "submit": true, "text": "toyotomi"}3. playwright__text_input {"element": "//input[@id='password']", "ref": "", "slowly": false, "submit": true, "text": "hideyoshi"}4. playwright__click {"element": "//button[@id='login']", "ref": ""}5. playwright__assert_contain_text {"against": "page", "expected": "徳川家康のToDo"}.ログを見た感じ、テストコードは期待どおり生成されている模様。
しかし、LLMの出力がおかしい…
INFO: LLM start: 1:llm:ChatOllama {"messagesLength":2}{"summary":"ログイン時に、ユーザー名がtoyotomiでパスワードがhideyoshiと入力したところ、正しくエラーメッセージは表示されず、ページには 徳川家康のToDoというテキストが表示された。これは、実際には登録されていないアカウントや不正なログインを示しているため、不具合です。" ,"result": "PASS" }テストコードは正しいものの、結果判定がおかしいです(手順どおり操作すると「豊臣秀吉のToDo」が表示されるはず)。
実際の操作結果取得や結果の解釈に問題があるのかもしれません。
パターン4b：手順を最後まで実行、検証結果が不正確(検証のポイントがずれている)
例：参考ページのシナリオ2「徳川慶喜はログインできない」
INFO: LLM start: 1:llm:ChatOllama {"messagesLength":2}{"summary":"Navigating to the URL and performing login actions with incorrect credentials.","result": "FAIL"}ログインに失敗したことを根拠にFAILしているようです。
実際のシナリオは「ログインできないこと」を確認するものなので、検証のポイントが当初想定からずれています。
まとめ
WSLを使って、ローカルLLMでAthrによる自動テストをやってみました。LLMにphi4-miniを使ってログインテストを実行したところ、期待どおり動くこともあればそうでないこともしばしば。体感的には、「～できないこと」の確認や「テストケース名・手順・期待結果の一貫性が乏しい」場合(参考ページのシナリオ2、3)にLLMの解釈がテストシナリオ作成者の意図から外れやすいように思えます。しかし、OpenWebUIとPlaywright-MCPを連携させたときよりも期待に近い動きをしていたので、OpenWebUIでなんと動かそうとシステムプロンプトやModelfileをこねくり回すよりは実行確度が高いです。
https://.com/vntaro2/n/ndead4f374d72
※とはいっても、そもそもローカルLLMでのツール呼び出しは十分な結果が得られないとも言われていますし、前回・今回の結果については性能限界なのかもしれません
前回の結果も踏まえると、ローカルLLMを使った自動テストは手動テストの当たりを付けるためのツールとして「(自動テストは精度の低いスモークテストと割り切って)同じシナリオを繰り返し実行→FAILが極端に多いテストは手動で確認」といった具合で使うのがよいのかもしれません。
今後の期待
今回の検証環境構築の中で、AethrとLLMは同一マシンに存在する必要があることがわかりました(詳細後述)。今後、AethrからリモートのLLMサーバも参照できるようになると良いと思いました。
※外部接続に厳しい環境でも、LLMサーバとクライアントを分けて配置する構成は需要があると思うのですが…
ハマったポイント
最後に、環境構築時にいくつかやらかしていたので書き残しておきます。
Node.jsのバージョン間違い
私の環境だと、はじめにインストールされているNode.jsのバージョンが18.20.8でした。
そのため以下の問題が発生。
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string.Aethrとしてはv22以上をサポートしているようなので、
nvm install v22で当該バージョンをインストール。
環境変数の設定ミス
私はOllamaを使うつもりだったのですが、間違って
OPENAI_MODEL=xxxという指定をしたため、AethrがOpenAI側にアクセスしようとして「APIキーが間違っている」と怒られました。
Ollamaを使う場合には
OLLAMA_MODEL=xxxという指定が正しいですね。
WSLにOllamaが入っていない
当初、Ollamaはホストマシン(Windows)で動かしAethrからアクセスさせる想定でした。
そのため.envには
OLLAMA_HOST=http:APENAI_BASE_URL=http:など書いたものの、fetch error が発生しテストを動かせず。
結局、WSLにOllamaをインストールすることでエラー解消に至りました。
curl -fsSL https:ollama pull <使用したいモデル>参考
Views: 0
