業務で回ってくるWebアプリの画面テスト、毎回Excelでテスト仕様書をゼロから作成し、手動で画面操作と確認をしていませんか?
本記事は、この 「テスト観点をゼロから考える工程」 と 「手間のかかる境界値テスト」 を、 Playwright + LLM で置き換える具体的な方法を解説します。
はじめに:人力画面テストの問題点
他チームが作成したWebアプリなど、仕様が不明確なシステムの画面テストは、毎回以下のような「考える工程」から始まります:
- ソースコードをざっと眺める
- URLや画面遷移を推測する
- 「たぶんここが重要だろう」と当たりをつける
- 境界値・入力・遷移の観点を洗い出す
- Excelにテスト仕様書を書く
- 実際に画面を操作して確認する
工数がかかる本質は、 画面操作そのものではなく、「テスト観点を毎回ゼロから合わせに行くこと」 にあります。これは創造的に見えて、実は かなりパターン化されている のです。
LLMの役割:「思考の自動化」
LLMは、人間の初動である 「よく分からないけど、とりあえず当たりを付ける」 という部分を代替できます。
- アンノウンなソースコードをざっと読む
- ルーティングを抽出する
- 画面数・遷移の可能性を推測する
- 一般的なWebテスト観点に当てはめる
これにより、人間は 判断とレビュー に集中できるようになります。
Playwrightの役割:「実在確認と証跡取得」
Playwrightは 実ブラウザを操作する ツールです。その最大の強みは、 実装言語やフレームワークに依存しない ことです。
家の中身を知らなくても、窓の外から中を確認できる
URLとHTMLがあれば成立するため、テスト対象のリポジトリにコミットする必要もありません。
全体構成
LLMが推測した観点に基づき、Playwrightが画面を巡回し、実在確認と証跡取得を行います。
境界値テストを含むサンプル構成
実務で重要な「境界値テスト」を含んだ具体的なテストサンプルを見てみましょう。この手法により、人力テストで手間のかかる境界値の確認を自動化し、スクリーンショットをそのまま証跡として活用できます。
フォルダ構成
playwright-testing/
├─ .venv/
├─ main.py # テスト対象アプリ
├─ domain.py # ドメインクラス
├─ test_playwright.py # Playwrightテスト
├─ screenshots/
ドメインクラス(業務ルール)
数値の入力値が $0$ から $100$ の範囲内であるかをチェックする業務ルールを定義します。
from dataclasses import dataclass
@dataclass
class Percentage:
value: int
def is_valid(self) -> bool:
# 0 <= value <= 100 を正とする
return 0 <= self.value <= 100
テスト対象アプリ(FastAPI)
入力された数値を受け取り、ドメインクラス(Percentage)で判定した結果(OK/NG)を表示するシンプルなWebアプリです。
from fastapi import FastAPI, Form
from fastapi.responses import HTMLResponse
from domain import Percentage
app = FastAPI()
@app.get("/", response_class=HTMLResponse)
def index():
return """
<h1>Percentage Check</h1>
<form method="post">
<input type="number" name="value" />
<button type="submit">Send</button>
</form>
"""
@app.post("/", response_class=HTMLResponse)
def check(value: int = Form(...)):
p = Percentage(value)
if p.is_valid():
return f"<h2>OK: {value}</h2>"
else:
return f"<h2>NG: {value}</h2>"
Playwright テスト(境界値)
$0$ と $100$ の前後($-1, 0, 1, 99, 100, 101$)を網羅したテストケースを定義し、自動で画面操作と結果検証、そして証跡のスクリーンショットを生成します。
from playwright.sync_api import Page, expect
from datetime import datetime
import os
def ts():
return datetime.now().strftime("%Y%m%d_%H%M%S")
# 境界値テストケースの定義
TEST_CASES = [
(-1, "NG"), # 最小値の下限
(0, "OK"), # 最小値
(1, "OK"),
(99, "OK"),
(100, "OK"), # 最大値
(101, "NG"), # 最大値の上限
]
# pytest-playwrightがpage: Pageフィクスチャを提供
def test_percentage_boundary(page: Page):
os.makedirs("screenshots", exist_ok=True)
stamp = ts()
for i, (value, expected) in enumerate(TEST_CASES):
print(f"【観点】値={value} は {expected} になること")
# 画面操作
page.goto("http://localhost:8000")
page.fill("input[name=value]", str(value))
page.click("button")
# 結果検証
expect(page.locator("h2")).to_contain_text(expected)
# 証跡取得
page.screenshot(
path=f"screenshots/{stamp}_{i}_{value}.png"
)
実行手順
1. 環境構築と依存関係のインストール
プロジェクトフォルダ(playwright-testing)に入り、仮想環境をアクティベートした後、すべての必要なライブラリをコマンドラインでインストールします。
-
仮想環境のアクティベート
(既にアクティベート済みの場合はスキップ).\.venv\Scripts\Activate -
必要なライブラリの一括インストール
FastAPIのフォーム処理のため
python-multipart、Playwrightのテスト実行のためpytest-playwrightが必要です。pip install fastapi "uvicorn[standard]" pytest pytest-playwright python-multipart -
Playwrightのブラウザ依存関係をインストール
playwright install
補足:Playwrightは二段階インストールが必要です
Playwrightは
pipの世界だけでは完結しません。
pip install playwright(↑のコマンドに含まれています)で、Pythonから操作するための ライブラリ本体(操縦席) をインストールします。playwright installコマンドで、実際にブラウザの動きを再現するための ブラウザエンジン(Chromium, Firefox, WebKit)の実行ファイル を別途ダウンロード・インストールしています。
この二段階の構成により、Python以外の環境に依存しない安定した自動テストが可能になっています。
2. アプリケーションサーバーの起動
ターミナルA を開き、FastAPIアプリケーションを起動します。 python -m を付けることで、仮想環境内のUvicornを確実に実行します。
# 仮想環境がアクティベートされていることを確認してから実行
python -m uvicorn main:app
3. Playwrightテストの実行
ターミナルB を開き、サーバーが起動した状態のまま、pytest-playwrightプラグインを使用してテストを実行します。
# 仮想環境がアクティベートされていることを確認してから実行
# pytest-playwrightプラグインがpageフィクスチャを提供します
pytest
テストが成功すると、screenshotsフォルダ内に境界値テストの証跡PNGファイルが自動で生成されます。
何が変わるか
| 項目 | 従来のExcel人力テスト | Playwright + LLM |
|---|---|---|
| テスト観点 | 人がゼロから思考し、Excelに書く | LLMが推測し、初動を自動化する |
| 境界値確認 | 人が手動で値を入力し、結果を目視確認する | Playwrightが自動で全ケースを実行・検証する |
| 証跡作成 | 手動で画面キャプチャを撮り、Excelに貼り付ける | Playwrightが自動でスクリーンショットを保存する |
| 人の役割 | 思考・操作・記録(=作業) | 判断とレビュー(=価値) |
Excelを捨てるのではなく、 Excelを書く前の思考を自動化する のです。これにより、人力テスト工数を削減し、再現性のある自動テストに置き換えられます。
締めくくり
この手法は、
- ブラックボックスな画面テスト
- 他チーム開発物の受け入れ
- Excelによる人力テスト工数削減
に非常に有効です。
画面テストは、 人が操作する仕事ではなくなりつつあります。LLMとPlaywrightを組み合わせることで、より早く、より正確に、実務に役立つテストを実現しましょう。
発展:デプロイ済み環境での実行(さらなる効果)
本記事で構築したPlaywrightテストは、ローカルのFastAPI(main.py)に対して実行しましたが、このテスト環境は、Webアプリが デプロイされた本番・ステージング環境に対してもそのまま適用できます。
開発コードの削除とテストの独立性
デプロイ済みのアプリケーションをテストする場合、ローカルで実行していた以下のファイルは不要になります。
| ファイル | 理由 |
|---|---|
main.py |
テスト対象のFastAPIコード。デプロイ先サーバーで既に動作している。 |
domain.py |
業務ロジック。main.pyに組み込まれているため不要。 |
残るのは test_playwright.py と .venv のみです。
実行コードの変更点
test_playwright.py 内で、アクセス先URLをデプロイ先のURLに変更するだけで、テスト環境の独立性が完全に保たれます。
例えば、https://production.example.com/ にデプロイした場合、test_playwright.py のこの行を変更します。
# 画面操作
- page.goto("http://localhost:8000")
+ page.goto("[https://production.example.com/](https://production.example.com/)")
page.fill("input[name=value]", str(value))
これにより、テストコードは アプリケーションの内部実装に一切依存せず、外部からのブラウザ操作のみで、デプロイ後の品質を担保できるようになります。