Webアプリのテスト観点を調べてまとめてみた (25選)
最近、Property Based Test という言葉を知りました。 他にどういうテストの種類があるのか気になったので、調べてみました。 本記事は、テストの種類を列挙します。 ※ 使用する技術は、私の都合上、node.js で選んでいます。
テスト観点一覧
Cache Test
Web アプリでは、様々な Cache が使われます。 例えば、ブラウザ Cache、CDN Cache、プロキシ Cache、バックエンド Cache などなどです。 Cache は、便利な反面、使いすぎると、どこがどう Cache しているのか迷子になってしまいます。 Web アプリでも、Cache をテストする必要がありそうです。
Code Size Test
大きなサイズの JS ライブラリを読み込むと、レスポンスタイムが悪化してしまいます。そこで、常にコードサイズを計測する必要があります。
Complexity Test
循環的複雑度(Cyclomatic complexity)は、制御文(if や for)の複雑さを計測します。 複雑なコードは、バグの温床になりがちなので、極力シンプルなコードを心がけたいところです。
Copy&Paste Test
Copy&Paste は、DRY の原則に反するため、特別な理由がない限りは、してはいけません。Copy&Paste を検出するツールがあるみたいです。
Cross Browser/Platform Test
サポートするブラウザや、プラットフォーム(iOS,Android,Desktop など)の動作検証が必要です。 そのため、サポートするブラウザやプラットフォームの環境を準備しなければなりません。 そういう環境を手軽に使えるサービスがあったりします。
E2E Test
Web アプリを、端から端まで (End To End: E2E)を検証します。 例えば、ユーザーが Web アプリを訪れて、クリックや入力するなど、使ってみることです。 このテストは、不安定なテスト(よく失敗する)になりがちなので、安定稼働できるような取り組みが必要です。 例えば、操作する処理の抽象化や、データ固定などです。
Exception Test
正常系、準正常系、異常系などのテストが必要です。 準正常系は、システムが意図的にエラーとしているものです。例えば、フォーム入力値エラーとかです。 異常系は、システムが意図せずエラーとなるものです。例えば、Timeout エラーとかです。
また、Java が得意な人なら知っているであろう、検査例外や非検査例外という例外の扱い方があります。 基本的には検査例外はエラーハンドリングし、非検査例外はエラーハンドリングしない方針が良いです。
Flaky Test
不安定なテストのことを指します。これに対するアプローチ方法の１つに、Google 社の資料があります。
https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45880.pdf日本人がまとめて頂いたものが、次の資料です。 speakerdeck.com
Integration Test
Integration Test は、Unit Test のような単一機能を統合した検証になります。 定義によりますが、私は『Unit Test では発見できないようなもの』かなと思います。 Unit Test でカバーできていなくても、他のテストで検証できていれば、Integration Test は不要になります。
Logging Test
ログ出力が適切なレベルで出力されているか検証する必要があります。 INFO, WARN, ERROR などがルールに基づいて使い分けされているか気になります。 ログを出すことができるかどうかは、ログライブラリの検証になりますので、必要ないかもしれませんが、 意図したタイミングで、意図したログレベルで、意図したメッセージが出力されるかは、テストしても良いと思います。
Monkey Test
お猿さんがランダムにテストするような、モンキーテストです。 テストのパターン網羅が難しい場合や、パターン網羅できているけどダメ押しで、このテストをします。
Multi Tenanct Test
マルチテナントは、企業者（利用者）毎に区別した、同一のシステムを提供する方式です。 これは、企業毎にサブドメインを分けたりするため、その環境毎のテストが必要になります。
Mutation Test
テストを検証するため、突然変異テストというものがあります。 プロダクトコードを破壊することで、テストも壊れるかどうかを検証します。 もし、プロダクトコードを壊しても、テストが成功してしまうと、それは正しくテストできていません。
Chaos Test
障害を注入した際に、どういった動きになるのかを検証するテストです。
Performance Test
パフォーマンスと言っても、 CPU 使用率、メモリ使用率、レスポンスタイム、RPS など様々な指標があります。 これらを計測し、SLO などの基準値を満たせているかを検証しておく必要があります。
Property Based Test
データを半自動生成し、テストをする手法です。
Regression Test
Regression Test は、修正した内容が意図せず他の箇所に影響を及ぼしていないか(デグレーション)を確認するテストです。 このテストは幅広い意味を持つので、ここに内容されるテスト種類は多いと思います。
Robustness Test
Web アプリは、ロバストであるべきです。 何かしら Web アプリ内で障害が発生したとしても、最低限のサービスだけでも提供するのが好まれます。 もちろん、その際の HTTP ステータスを 200 にせず、障害にあったステータスを返しましょう。
Security Test
セキュリティのテストは、どんな Web アプリでも必須になります。 セキュリティの専門家ではないので、どういうテストが必要なのかは、ここでは割愛します。
依存するパッケージ脆弱性検査には、下記のコマンドが有効です。
npm audit fixSEO Test
Web アプリへ流入数を改善するためには、SEO は不可欠です。 lighthouse というツールで SEO スコアを見ることができるみたいです。
Smoke Test
Smoke Test は、Web アプリが最低限動作するために必要なケースを確保する検証です。 例えば、トップページへリクエストしたら、レスポンスが HTTP 200 で返却されるとかです。
この最低限の動作保証がなければ、これ以上の詳細なテストができません。 個人的には、Smoke Test → E2E Test の順で進むのかなと思っています。
Snapshot Test
Web アプリへリクエストし、そのレスポンスである HTML(スナップショット)を保存します。 この HTML が、変更前と比較して変化がないかの検証をするのが、Snapshot test です。 リファクタリングなど、変化がない修正に対して有効です。
jestjs.ioStatic Test
Static Test は、Web アプリを動かさなくても検証できるテストです。 よくあるのが、Linter です。
-
CSS
- JS
- SVG
- Commit
- Docker
これらは、プルリクエストで機械的に指摘する Danger との相性が良いです。
Unit Test
単一機能をテストする Unit Test があります。この Unit Test が全て PASS したら、 他のテストを進めるのが一般的かなと思います。
Code Coverage
Unit テストで、どこをテストできたかのカバレッジを見ることができます。 感覚としては、全体の 8 割を満たしていれば良いかなと思います。
jestjs.io実際に動作している JS や CSS のカバレッジを収集することもできます。
speakerdeck.com
Visual Regression Test
見た目の変化を監視する必要があります。例えば、リンク切れとかがあれば、検出するべきです。
最後に
どういうテストの観点があるのか、調べたり、経験則よりざっと書いてみました。 全てをテストする必要はなく、『どういう動作の品質を担保したいか』を意識して、 取捨選択するのが良いと思います。 最後まで読んでいただき、ありがとございます。
-
シェアする
フォローする
関連する記事
タグ「ブラウザ」の記事
DuckDB WASMとOrigin Private File System (OPFS) を組み合わせ、Google マイアクティビティの履歴をブラウザ内に閉じたまま扱えるようにしたときの設計と学びを整理しました。
こんにちは、@silverbirderです。最近、湖県に移住してWebフロントエンドのお仕事をしています。お仕事をしていると、ユーザー体験を良くするためには、大きな改善をせずとも小さな改善だけでも十分な効果があると思い始めました。本記事では、その小さな改善となる、3つのことについて書きたいと思います。
ブログ記事のOGP画像に、ブログタイトルを入れたい場面があります。その際、タイトルが長い場合は複数行に分けたり、省略したりする必要があります。今回は、試してみてよさそうだった2つの方法を紹介します。
2025-02-06
タグ「テスト」の記事
Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。 flex-shrink の指定を忘れて、要素が押しつぶされてしまった z-index の指定を間違えて、要素が意図せず前面（また
AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。 単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。 興味があれば、参考として読んでもらえると嬉しい
2026-01-09
はじめに Playwright で E2E テストを書く際、playwright codegen や、近年では Playwright MCP を利用して、テストコードの雛形を作成することが多いと思います。 ただし、生成したテストコードが正し
2025-12-26