学ぶ / 用語集
ソフトウェアテスト用語集
QA エンジニアや SDET が日常的に使う用語を、分かりやすい日本語で解説します。各用語に具体例と、関連するレッスン・ラボ・面接質問へのリンクを掲載しています。
77 語 · テストの基礎 26 · テスト設計 5 · UI 自動化 18 · API テスト 8 · CI/CD と DevOps 5 · パフォーマンス 5 · セキュリティ 4 · テストにおける AI 6
テストの基礎
- E2E テスト（エンドツーエンドテスト） End-to-end test 実際に完全デプロイされたシステムで、UI や公開 API からデータベースまでを通しで動かし、ユーザージャーニー全体を検証するテストです。
- コードカバレッジ Code coverage テスト実行中に実行されたソースコード（行、ステートメント、ブランチ、関数）の割合です。何がテストされていないかは分かりますが、十分にテストされているかは分かりません。
- サニティテスト（Sanity Testing） Sanity testing 小さな変更やバグ修正の後に、影響を受けた領域が意図どおり動くことを確認する、範囲を絞った集中的なチェックで、より広いテストに進む前に行います。
- シフトレフトテスト（Shift-Left Testing） Shift-left testing テストや品質活動をデリバリーのライフサイクルの早い段階に移し、欠陥を最も安く直せる時点で防止または検出するアプローチです。
- スモークテスト（Smoke Testing） Smoke testing 新しいビルドの最も重要な機能をすばやく浅く確認し、そもそもより深いテストに進めるほど安定しているかを判断するテストです。
- テストオラクル（Test Oracle） Test oracle 仕様、以前のバージョン、参照モデル、ルールなど、出力が正しいかどうかを判断するためにテストが使う「正解の拠り所」です。
- テストケース（Test Case） Test case システムの 1 つの振る舞いを検証し、合否を明確に判定するための、事前条件・入力データ・手順・期待結果の具体的な組み合わせです。
- テストシナリオ（Test Scenario） Test scenario 「保存済みカードでの決済を検証する」のように、テストすべきユーザーの目的や機能を高いレベルで記述したもので、後からテストケースに分解されます。
- テストダブル（Test Double） Test double ダミー、スタブ、フェイク、スパイ、モックなど、テスト内で本物の依存関係の代わりを務めるオブジェクトの総称で、テスト対象のコードを高速かつ予測可能に動かします。
- テストピラミッド（Test Pyramid） Test pyramid 土台に高速なユニットテストを多数、その上に結合テストを少なめに、頂点に E2E テストを少数置いて、自動テストのバランスを取るためのモデルです。
- テスト計画書（Test Plan） Test plan リリースやプロジェクトのテストについて、範囲、アプローチ、リソース、スケジュール、環境、リスク、開始・終了基準を定義する文書です。
- バグの重要度（Severity） Bug severity 欠陥がシステムやユーザーに与える影響の大きさを示すもので、完全なクラッシュやデータ損失から見た目の問題まであり、通常は QA が設定します。
- バグの優先度 Bug priority 他の作業と比べて欠陥をどれだけ急いで修正すべきかを示すもので、ビジネス上の必要性で決まり、通常はプロダクトオーナーやバグトリアージで設定されます。
- ブラックボックステスト Black-box testing 内部のコードや設計を見ず、それに依存もせずに、入力と出力を要件と照らし合わせてシステムをテストする手法です。
- フレーキーテスト（Flaky Test） Flaky test コードを何も変更していないのに成功したり失敗したりするテストで、主な原因はタイミング、共有状態、実行順序、不安定な環境です。
- ホワイトボックステスト（White-Box Testing） White-box testing 分岐、条件、パスなど内部のコードの知識に基づいてテストを設計し、実装が正しく振る舞うことを確かめるテストです。
- ミューテーションテスト（Mutation Testing） Mutation testing コードに小さな意図的バグ（ミュータント）を埋め込んでテストを再実行し、テストスイートが本当に欠陥を検出できるかを測る手法です。
- ユーザー受け入れテスト（UAT） User acceptance testing 実際のユーザーや業務部門の代表者が、システムがニーズを満たしリリースを受け入れられる状態かを確認する、最終段階のテストです。
- ユニットテスト（単体テスト） Unit test 関数やクラスなどの小さなコード単位を、データベース、ネットワーク、ほかのサービスから切り離して確認する自動テストです。
- リスクベーステスト（Risk-Based Testing） Risk-based testing 故障の発生可能性と影響度を掛け合わせたリスクでテストの労力に優先順位を付け、最もリスクの高い領域を最初に、最も深くテストするアプローチです。
- 回帰テスト（リグレッションテスト） Regression testing 変更後に既存のテストを再実行し、それまで動いていた機能が今も動くこと、修正や新機能がほかを壊していないことを確認するテストです。
- 結合テスト（インテグレーションテスト） Integration test サービスとデータベース、2 つの API など、2 つ以上のコンポーネントが実際のインターフェースを通じて正しく連携するかを確認するテストです。
- 検証と妥当性確認（V&V） Verification and validation 検証は仕様に照らして「製品を正しく作っているか？」を、妥当性確認は実際のユーザーのニーズに照らして「正しい製品を作っているか？」を問います。
- 受け入れ基準（Acceptance Criteria） Acceptance criteria ユーザーストーリーや機能がプロダクトオーナーに完成と認められるために満たすべき、具体的でテスト可能な条件です。
- 探索的テスト Exploratory testing テスターがテストの設計と実行を同時に行い、各結果から得た情報をもとに次に何を試すかを決めていくテスト手法です。
- 要件トレーサビリティマトリクス（RTM） Requirements traceability matrix 各要件を、それを検証するテストケースとその結果に対応づけた表で、カバレッジの抜けや変更の影響範囲を可視化します。
テスト設計
- デシジョンテーブルテスト Decision table testing 条件の組み合わせと、それぞれが引き起こすべきアクションを一覧にするテスト設計技法で、すべてのビジネスルールにテストを用意できます。
- ペアワイズテスト（Pairwise Testing） Pairwise testing パラメーター値のあらゆるペアが少なくとも 1 回は一緒に登場するように、少数のテストケースを選ぶ組み合わせテストの技法です。
- 境界値分析 Boundary value analysis 有効範囲の端とそのすぐ前後の値をテスト入力に選ぶブラックボックスのテスト設計技法で、off-by-one の欠陥が集中する箇所を狙います。
- 状態遷移テスト（State Transition Testing） State transition testing システムを状態と、状態間を移動させるイベントとしてモデル化し、有効な遷移と無効な遷移をテストするテスト設計技法です。
- 同値分割 Equivalence partitioning システムが同じように扱うべき入力をグループ（同値クラス）に分け、各グループから代表値を 1 つずつ選んでテストするテスト設計技法です。
UI 自動化
- CSS セレクター CSS selector タグ、id、クラス、属性、位置で要素にマッチさせる CSS のパターンで、高速で読みやすい UI テストのロケーターとして広く使われます。
- Gherkin（ガーキン） Gherkin BDD のシナリオを .feature ファイルに書くための Given-When-Then 形式のプレーンテキスト構文で、Cucumber などのツールが自動テストとして実行します。
- Selenium Grid WebDriver のセッションをリモートのブラウザーノードに振り分ける Selenium のサーバーで、多数のブラウザー・バージョン・マシンでテストを並列実行できます。
- StaleElementReferenceException 要素を取得した後に DOM ノードが削除・置換された WebElement をテストが使ったときに発生する Selenium のエラーで、典型的には再レンダリング後に起こります。
- Web ファーストアサーション（Web-First Assertion） Web-first assertion ロケーターを受け取り、値を一度だけ確認するのではなく、期待する条件が満たされるかタイムアウトするまでリトライし続ける Playwright のアサーションです。
- XPath XML や HTML 文書のノードを選択するためのクエリ言語で、UI 自動化では構造、属性、テキストによって要素を特定するのに使われます。
- データ駆動テスト Data-driven testing 同じテストロジックを多数の入力と期待結果の組み合わせで実行する手法で、データは各テストにコピーせず表・ファイル・データソースで管理します。
- テストシャーディング（Test Sharding） Test sharding テストスイートをシャードと呼ばれる単位に分割し、別々のマシンで同時に実行することで、長いスイートを数分の一の時間で終わらせる手法です。
- テストの独立性（Test Isolation） Test isolation 各テストが自分で状態を準備し、ほかのテストに依存も影響もせず、どの順序でも並列でも単独で合格できるという性質です。
- テストフィクスチャ（Test Fixture） Test fixture ブラウザーのページ、投入済みのユーザー、データベースなど、テストの実行前に必要な固定の準備と、実行後にそれを片付ける後処理のことです。
- ビジュアルリグレッションテスト（Visual Regression Testing） Visual regression testing UI のスクリーンショットを承認済みのベースライン画像と比較し、レイアウトのずれ、スタイルの欠落、要素の重なりといった意図しない見た目の変化を検出するテストです。
- ビヘイビア駆動開発（BDD） Behavior-Driven Development ビジネス・開発・テストが具体例を通じて振る舞いを合意する協働プラクティスで、多くの場合 Gherkin で記述して自動化します。
- ページオブジェクトモデル（Page Object Model） Page Object Model UI の各ページやコンポーネントをクラスで包み、テストがロケーターを繰り返し書く代わりに意図レベルのメソッドを呼び出せるようにするデザインパターンです。
- ヘッドレスブラウザ Headless browser 画面上にウィンドウを表示せずに動く本物のブラウザエンジンで、ディスプレイのない CI サーバーなどで UI テストを実行するために使われます。
- ロケーター（Locator） Locator UI テストがページ上の要素を見つけるために使うクエリで、ロールと名前、テスト ID、CSS セレクター、XPath 式などがあります。
- 暗黙的待機（Implicit Wait） Implicit wait Selenium のグローバル設定で、すべての findElement 呼び出しが NoSuchElementException を投げる前に、指定時間まで要素をポーリングし続けるようにします。
- 自動待機（Auto-waiting） Auto-waiting 固定のスリープに頼らず、要素が表示・安定・有効化などの操作可能な状態になるまでフレームワークが自動で待ってから操作する機能です。
- 明示的待機（Explicit Wait） Explicit wait 要素がクリック可能になるなど特定の条件を、タイムアウトまでポーリングして待つ待機方法で、Selenium では WebDriverWait で記述します。
API テスト
- HTTP ステータスコード HTTP status code すべての HTTP レスポンスに含まれる 3 桁の数字で、リクエストが成功したか、リダイレクトされたか、クライアントまたはサーバーの原因で失敗したかを示します。
- JSON Schema（JSON スキーマ） JSON Schema 型、必須フィールド、フォーマットなど JSON データの期待される構造を記述するための JSON の語彙で、API レスポンスの検証に使われます。
- JWT（JSON Web Token） JWT JSON Web Token は header.payload.signature 形式のコンパクトな署名付きトークンで、ユーザー ID、有効期限、オーディエンスなどのクレームを運びます。
- OAuth 2.0 パスワードを扱わずに、ユーザーの代理または自身として API を呼び出すための限定的なアクセストークンをアプリが取得できる認可フレームワークです。
- REST API URL で識別されるリソースを中心に設計され、GET・POST・PUT・PATCH・DELETE などの標準メソッドとステートレスなリクエストで操作する HTTP API です。
- レート制限（Rate Limiting） Rate limiting 一定時間内にクライアントが API に送れるリクエスト数に上限を設け、超過分を通常 429 Too Many Requests と Retry-After ヘッダーで拒否する仕組みです。
- 契約テスト（Contract Testing） Contract testing API のプロバイダーとコンシューマーがやり取りするリクエストとレスポンスについて合意できているかを、両者を一緒にデプロイせずに検証するテストです。
- 冪等性（べきとうせい） Idempotency 同じリクエストを 1 回送っても何回送ってもサーバーの状態が同じになる性質です。GET、PUT、DELETE は冪等ですが、POST は冪等ではありません。
CI/CD と DevOps
- Docker コンテナ Docker container アプリやサービスを依存関係ごとパッケージ化した Docker イメージの、隔離された実行中インスタンスで、ノート PC でも CI でも同じように動きます。
- Testcontainers データベース、メッセージブローカー、ブラウザーなどの本物の依存関係を、テストコードから使い捨ての Docker コンテナとして起動し、終了後に削除するライブラリです。
- フィーチャーフラグ Feature flag デプロイせずにコードパスをオン・オフできる実行時のスイッチで、未完成の機能を隠したまま出荷し、段階的に公開し、素早くロールバックできます。
- 継続的インテグレーション（CI） Continuous integration 小さな変更を共有ブランチへ頻繁にマージし、プッシュごとに自動でビルドとテストを実行して、壊れた箇所を数分で検知するプラクティスです。
- 品質ゲート（Quality Gate） Quality gate テストの成功やカバレッジのしきい値など、コードをマージ・リリースする前に満たす必要がある、パイプライン内の自動化された合否チェックです。
パフォーマンス
- ストレステスト（Stress Testing） Stress testing 想定を超える負荷をかけて限界点を見つけ、システムがどのように故障し、その後に復旧できるかを確認する性能テストです。
- スループット（Throughput） Throughput システムが単位時間あたりに処理する仕事量で、通常は 1 秒あたりのリクエスト数やトランザクション数で表し、レイテンシやエラー率とあわせて測定します。
- ソークテスト（耐久テスト） Soak testing 現実的な通常負荷を何時間も維持し、メモリリークのように時間とともに蓄積して初めて現れる問題を明らかにする性能テストです。
- パーセンタイルレイテンシ（p95・p99） Percentile latency p95 や p99 のように、その割合のリクエストが完了した時間を示す応答時間の指標で、平均値では隠れてしまう遅いテールを明らかにします。
- 負荷テスト（Load Testing） Load testing 想定される実際のトラフィックをシステムにかけ、応答時間・エラー率・スループットが合意した目標を満たすかを確認する性能テストです。
セキュリティ
- IDOR（安全でない直接オブジェクト参照） IDOR Insecure Direct Object Reference の略で、リクエスト内の ID を書き換えるだけで他のユーザーのデータを閲覧・変更できてしまうアクセス制御の欠陥です。
- OWASP Top 10 OWASP が公開する、最も重大な Web アプリケーションのセキュリティリスク 10 分類の啓発リストで、セキュリティテストやコードレビューの範囲決めに広く使われています。
- SQL インジェクション（SQL Injection） SQL injection ユーザー入力が SQL クエリに文字列連結される脆弱性で、攻撃者がクエリのロジックを変えてデータを読み取り、改ざん、削除できてしまいます。
- クロスサイトスクリプティング（XSS） Cross-site scripting 信頼できない入力が別のユーザーのブラウザで実行可能なスクリプトとして描画され、攻撃者がそのユーザーになりすまして操作できてしまう脆弱性です。
テストにおける AI
- LLM 評価（Evals） LLM evaluation 出力が毎回変わり完全一致のアサートが合わない LLM 機能の品質を、固定の入力セットと基準に対して体系的に測定することです。
- LLM-as-a-Judge（LLM による評価） LLM-as-judge 記述したルーブリックに基づき言語モデルに別のモデルの出力を採点させる手法で、LLM 評価において人のレビューを拡張可能に代替しますが、バイアスがあります。
- MCP（Model Context Protocol） Model Context Protocol MCP は、AI アシスタントやエージェントをブラウザー、リポジトリ、テスト管理システムなどの外部ツールやデータに接続するためのオープンなプロトコルです。
- ゴールデンデータセット Golden dataset 検証済みの期待出力を持つ、厳選されバージョン管理された入力のセットで、モデル、プロンプト、パイプラインの回帰テストの固定ベンチマークとして使います。
- プロンプトインジェクション（Prompt Injection） Prompt injection ユーザーが直接入力した、あるいは LLM が読み込むコンテンツに隠されたテキストが開発者の指示を上書きし、その振る舞いを変えてしまう攻撃です。
- 自己修復ロケーター（Self-Healing Locator） Self-healing locator ロケーターが一致しなくなったとき、保存済みの属性やモデルをもとにテストツールが代わりの要素を推定し、テストを続行させる仕組みのロケーターです。