9.6 KiB
source_url, ingested, sha256, discovered_from
| source_url | ingested | sha256 | discovered_from | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| https://zenn.dev/knowledgework/articles/e2e-coverage | 2026-06-30 | bc474fcb26a91f713653fc731abdd4a8ef889cf53b521e7a7577e015305ec942 |
|
E2E テストのカバレッジ指標に「ページ網羅率」と「RPC(API) 網羅率」を導入する
Author: jinjor / 株式会社ナレッジワーク Published: 2026-06-30T08:48:10.551+09:00
こんにちは。ナレッジワークの torii (https://twitter.com/jinjor) です。
Playwright で実施している E2E テストに新しいカバレッジ指標「ページ網羅率」と「RPC 網羅率」を導入したので紹介します！
背景: 手動によるカバレッジ管理の信頼性低下
ナレッジワークでは、プロダクトの継続的な品質保証のために E2E テストがどこにどれだけ書かれているかを管理しています。また、カバレッジを次のように定義して追ってきました。
E2E テストのカバレッジ = 書かれているテストケースの数 / 書くべきテストケースの数 この定義自体は妥当なものでしたが、運用する中で次のような問題が出てきました。
-
「書くべきテストケース」の一覧を手で管理する必要があり、更新が漏れると最新の状態と乖離する
-
機能追加時に更新しないと分母が増えず、カバレッジの数字が信頼できなくなる
-
テストケースの粒度に関する統一見解がなく、書き方によって数字がブレる
ナレッジワークでは同じ E2E テストの基盤を複数の開発チームで共有していますが、運用は各チームに委ねられています。そのため、開発チームによって E2E テストにかけるコストが違ったり、メンテナンスできるメンバーがいるかどうかによって更新にバラつきが出ます。
そこで「実際にどれだけのテストが網羅的に書かれているのか、属人的な努力に頼らなくても客観的に測定できる指標」が必要になりました。
解決策: 「ページ網羅率」と「RPC 網羅率」の導入
解決策として、新たに次の指標を導入しました。
-
ページ網羅率: プロダクトの全ページのうち E2E テストで訪問したページの割合
-
RPC 網羅率: プロダクトの全 RPC のうち E2E テストで呼び出した RPC の割合
-
Service 単位, Method 単位それぞれの網羅率を算出
!
ナレッジワークでは API に Connect（gRPC/Protocol Buffers）を使っているので、ここでの「API」は .proto ファイルで定義された RPC（Service/Method）の単位になります。REST/OpenAPI なら「エンドポイント」に読み替えてください。
従来のカバレッジがテストケースの網羅率であるのに対し、こちらは実装の網羅率です。コードカバレッジの E2E テスト版と言ってもいいかもしれません。
この方式のメリットは「機械的に収集できる客観的な指標である」ことです。人間がメンテナンスしなくても、機能追加のためにページや RPC を増やせば自動的に分母が増え、最新の状況がカバレッジに反映されます。
![想定から漏れた機能の存在を示唆]
従来のテストケース管理では「書くべきテストケース」と人間が想定したリストが本当に全ての機能を網羅しているのか確証がありませんでした。しかし、到達していないページや呼び出していない RPC があれば、機能が網羅されていないことはすぐに分かります。
例えば「作成」「更新」「削除」のテストケースで十分だと思っていたところ、FileUpload という RPC が網羅されていないことから「ファイル添付」の機能のテストが足りていなかったということが分かる、といった具合です。
つまりは、機能追加の時にリストを更新しなかったり、テスト担当者が見逃した機能があったということをすぐに検出できます。
重要: 実装の網羅率は「十分性」を担保できない
ここで、注意点として強調しておくべきことがあります。
「ページ網羅率」や「RPC 網羅率」が見ているのは実装の網羅率であり、これらがカバーされたとしても十分なテストケースが存在するということは言えません。実装の網羅が示してくれるのは、少なくとも「明らかな不足がない」という必要条件を満たしていることです。
E2E テストで網羅すべきはユーザー視点でのシナリオです。ページや RPC を一通り網羅しても、担保すべき全てのシナリオを網羅するためには同じページや RPC を何度も踏む必要があるかもしれません。どのようなシナリオが存在すれば十分なのかはやはり人間が考えないといけません。
あくまでユーザー中心のシナリオをベースにテストケースを作り、結果として想定通りページや RPC を網羅しているか、という順番で考えるのが良いと思います。
実装方法
ここからは実装方法について、具体的なコードよりもアーキテクチャや考え方を中心に紹介します。ナレッジワーク独自の事情に依存している部分もありますが、同じ要領で他社でも実装できるはずです。
全ページと全 RPC の抽出
カバレッジの分母となる全ページと全 RPC は全てソースコードから取得します。ナレッジワークのプロダクトでは以下を情報源として利用することができました。
-
全ページ: Next.js の pages/ 以下のディレクトリに存在するファイルからページとパス構造を取得
-
全 RPC: .proto ファイルから Service / Method 情報をパース
テスト実行時に網羅したページと RPC の抽出
Playwright の trace (https://playwright.dev/docs/trace-viewer) が出力する .network エントリを使います。
ナレッジワークのプロダクトでは、ページ・RPC をそれぞれ以下のように取得することができました。
-
ページ: ページ毎に Google Analytics が
/_gtm/g/collectに送信するpage_viewイベントに含まれるページのパス -
RPC:
/_apiなど特定のプレフィックスを持つリクエストのパス
ここで１つの難所は、ページのパスに含まれる変数をうまく正規化する必要があることです。
例えば /foo/123/bar のようなパスは /foo/:id/bar と正規化できそうですが、実は bar も変数で /foo/:id/:kind が正しい可能性もあります。このような曖昧さを避けるため、実際の実装では上で取得した全ページの情報と突き合わせて確実な正規化を行なっています。
注意点として、このログを得るためには playwright.config.ts で use: { trace: 'on' } を指定する必要があります（doc (https://playwright.dev/docs/api/class-testoptions#test-options-trace)）。今回の目的では成功時のログも必要なので retain-on-failure などではなく on を指定しているのですが、ログのサイズが余裕で GB 単位になります。CI でレポート用にログを保存する場合は、カバレッジ計測の後に成功時のログを削ってスリムにした方が良いです。
メトリクスの収集とカバレッジの集計
上記の方法で必要な情報が揃い、カバレッジを集計することが出来るようになります。しかし、その場でカバレッジを集計するのではなく、生データを一度 DB に保存しておくと多角的な分析に役立ちます（履歴から推移を見るなど）。
今回は社内のデータ基盤 (https://zenn.dev/knowledgework/articles/knowledgework-data-platform-20250905) を使い、GCS にアップロードしたデータを BigQuery から取得、という流れで集計を行いました。カバレッジを集計するのはクエリ側です。
![メトリクスの収集とカバレッジの集計]
こうすることで以下のメリットがあります。
-
生データが保存されているため、後から違う集計方法に変えられる
-
集計・通知のタイミングをテスト実行と独立にできる
-
Redash/Lightdash などのダッシュボードと連携できる
Slack チャンネルへのレポート通知
いくらカバレッジを取っても、誰も見ない場所に眠っていては意味がありません。ナレッジワークの開発運用の中に自然と溶け込むように、毎日テスト結果と一緒に Slack チャンネルに通知するようにしました。新しい仕組みを導入してからまだ日が浅いですが、早速「テストを追加すると数字が増えていって楽しい」という声が聞かれるようになりました。
まとめ
E2E テストで「ページ網羅」「RPC 網羅」を計測するメリットと実装方法を紹介しました。もし「うちでも導入したい」という方がいらっしゃれば、是非この記事の URL を Claude Code や Codex に食べさせていただければと思います！