software testing terms complete glossary
さまざまなソフトウェアテスト用語のあいまいさを回避するために、私は ソフトウェアテスト用語集 ここに。
すべてのソフトウェアテスト用語は、この用語集に含まれています。ここに記載されているよりも用語の定義をよく知っていると感じた場合は、これを使用できます お問い合わせフォーム 定義を送ってください。レビュー時に、これらをこの用語集リストに含めます。
ソフトウェアテストと品質保証の基本的な定義を知るために、これはによって編集された最高の用語集です。 Erik van Veenendaal 。また、各定義について、括弧内に記載されているIEEEまたはISOの参照があります。
に
合否基準： コンポーネントまたはシステムが満たすために満たさなければならない終了基準ユーザー、顧客、またはその他の承認されたエンティティによって受け入れられます。 (IEEE 610)
受け入れ試験： システムが受け入れ基準を満たしているかどうかを判断し、ユーザー、顧客、またはその他の承認されたエンティティがシステムを受け入れるかどうかを判断できるようにするために実施される、ユーザーのニーズ、要件、およびビジネスプロセスに関する正式なテスト。 (IEEE610以降)
アクセシビリティテスト： 障害を持つユーザーがコンポーネントまたはシステムを簡単に使用できるかどうかを判断するためのテスト。 (ジェラード)
休憩とSOAPWebサービスのインタビューの質問
正確さ： 必要な精度で正しいまたは合意された結果または効果を提供するソフトウェア製品の機能。 (ISO9126)機能テストも参照してください。
実結果： コンポーネントまたはシステムがテストされたときに生成/観察された動作。
アドホックテスト： 非公式に実施されたテスト。正式なテスト準備は行われず、認められたテスト設計手法は使用されません。結果に対する期待はなく、ランダム性がテスト実行アクティビティをガイドします。
適応性： 検討対象のソフトウェアに対してこの目的のために提供されたもの以外のアクションまたは手段を適用することなく、さまざまな指定された環境に適応するソフトウェア製品の機能。 (ISO9126)移植性テストも参照してください。
アジャイルテスト： エクストリームプログラミング（XP）などのアジャイル手法を使用し、開発をテストの顧客として扱い、テストファーストの設計パラダイムを強調するプロジェクトのテストの実践。
アルファテスト： 潜在的なユーザー/顧客または開発者のサイトでの独立したテストチームによる、ただし開発組織外でのシミュレーションまたは実際の運用テスト。アルファテストは、内部受け入れテストの一形態としてよく使用されます。
分析可能性： ソフトウェアの欠陥または障害の原因について診断されるソフトウェア製品の機能、または識別のために変更される部品。 (ISO9126)保守性テストも参照してください。
異常： 要件仕様、設計ドキュメント、ユーザードキュメント、標準などに基づく期待から、または誰かの認識や経験から逸脱する条件。異常は、ソフトウェア製品または該当するドキュメントのレビュー、テスト、分析、コンパイル、または使用中に発見される場合がありますが、これらに限定されません。 (IEEE 1044)欠陥、逸脱、エラー、障害、障害、インシデント、問題も参照してください。
魅力： ユーザーにとって魅力的なソフトウェア製品の機能。 (ISO 9126)
監査： 以下を指定する文書を含む客観的な基準に基づいて、標準、ガイドライン、仕様、および/または手順への準拠を確認するためのソフトウェア製品またはプロセスの独立した評価。
（1）生産される製品の形態または内容
（2）製品の製造プロセス
（3）基準またはガイドラインへの準拠をどのように測定するか。 (IEEE 1028)
監査証跡： プロセスへの元の入力（データなど）をプロセス全体にさかのぼって、プロセス出力を開始点として使用できるパス。これにより、欠陥分析が容易になり、プロセス監査を実行できます。 【TMap後】
自動テストウェア： ツールスクリプトなど、自動テストで使用されるテストウェア。
可用性： コンポーネントまたはシステムが動作可能であり、使用が必要なときにアクセスできる程度。多くの場合、パーセンテージで表されます。 (IEEE 610)
B
連続テスト： コンポーネントまたはシステムの2つ以上のバリアントが同じ入力で実行され、出力が比較され、不一致の場合に分析されるテスト。 (IEEE 610)
ベースライン： 正式にレビューまたは合意され、その後のさらなる開発の基礎として機能し、正式な変更管理プロセスを通じてのみ変更できる仕様またはソフトウェア製品。 (IEEE610以降)
基本ブロック： ブランチを含まない1つ以上の連続する実行可能ステートメントのシーケンス。
基本テストセット： 指定されたカバレッジ基準の100％が達成されることを保証するために、内部構造または仕様から派生した一連のテストケース。
動作： 入力値と前提条件のセットに対するコンポーネントまたはシステムの応答。
ベンチマークテスト： （1）測定または比較を行うことができる基準。 （2）コンポーネントまたはシステムを相互にまたは（1）のように標準と比較するために使用されるテスト。 (IEEE610以降)
特注ソフトウェア： 一連のユーザーまたは顧客向けに特別に開発されたソフトウェア。反対は既製のソフトウェアです。
ベストプラクティス： 特定のコンテキストで組織のパフォーマンスの向上に貢献する優れた方法または革新的な手法。通常、他のピア組織によって「最良」と認識されます。
ベータテスト： コンポーネントまたはシステムがユーザー/顧客のニーズを満たし、ビジネスプロセスに適合しているかどうかを判断するための、開発者が関与していない外部サイトでの潜在的および/または既存のユーザー/顧客による運用テスト。ベータテストは、市場からフィードバックを取得するために、外部の受け入れテストの形式としてよく使用されます。
ビッグバンテスト： ソフトウェア要素、ハードウェア要素、またはその両方を段階的にではなく、コンポーネントまたはシステム全体に一度に組み合わせる統合テストの一種。 (IEEE610以降)統合テストも参照してください。
ブラックボックステスト： コンポーネントまたはシステムの内部構造を参照せずに、機能的または非機能的にテストします。
ブラックボックステストの設計手法： 内部構造を参照せずに、コンポーネントまたはシステムの機能的または非機能的な仕様の分析に基づいてテストケースを導き出し、選択するための文書化された手順。
ブロックされたテストケース： 実行の前提条件が満たされていないために実行できないテストケース。
ボトムアップテスト： 最も低いレベルのコンポーネントが最初にテストされ、次により高いレベルのコンポーネントのテストを容易にするために使用される統合テストへの増分アプローチ。このプロセスは、階層の最上位にあるコンポーネントがテストされるまで繰り返されます。統合テストも参照してください。
境界値： 等価パーティションのエッジ上、またはエッジの両側の最小増分距離にある入力値または出力値。たとえば、範囲の最小値または最大値。
境界値分析： テストケースが境界値に基づいて設計されるブラックボックステスト設計手法。
境界値の範囲： テストスイートによって実行された境界値のパーセンテージ。
ブランチ： 2つ以上の代替プログラムパスの1つが使用可能なプログラム構成に基づいて実行用に選択できる基本ブロック。場合は、ジャンプして、に移動します。
ブランチカバレッジ： テストスイートによって実行されたブランチの割合。 100％のブランチカバレッジは、100％の意思決定カバレッジと100％のステートメントカバレッジの両方を意味します。
ブランチテスト： テストケースがブランチを実行するように設計されているホワイトボックステスト設計手法。
ビジネスプロセスベースのテスト： ビジネスプロセスの説明や知識に基づいてテストケースを設計する、テストへのアプローチ。
C
機能成熟度モデル（CMM）： 効果的なソフトウェアプロセスの重要な要素を説明する5レベルの段階的フレームワーク。機能成熟度モデルは、ソフトウェアの開発と保守を計画、エンジニアリング、および管理するためのプラクティスをカバーしています。 (CMM)
能力成熟度モデル統合（CMMI）： 効果的な製品開発および保守プロセスの重要な要素を説明するフレームワーク。能力成熟度モデル統合は、製品の開発と保守を計画、エンジニアリング、および管理するためのプラクティスをカバーしています。 CMMIはCMMの後継者として指定されています。 (CMMI)
キャプチャ/再生ツール： 後で実行（つまり再生）できる自動テストスクリプトを生成するために、手動テスト中に入力が記録されるテスト実行ツールの一種。これらのツールは、自動回帰テストをサポートするためによく使用されます。
場合： Computer Aided SoftwareEngineeringの頭字語。
キャスト： Computer Aided SoftwareTestingの頭字語。テスト自動化も参照してください。
因果関係グラフ： テストケースの設計に使用できる、入力および/または刺激（原因）とそれに関連する出力（効果）のグラフィック表現。
因果関係のグラフ化： テストケースが因果関係グラフから設計されるブラックボックステスト設計手法。 (BS 7925/2)
認証： コンポーネント、システム、または人が指定された要件に準拠していることを確認するプロセス。試験に合格することによって。
変更可能性： 指定された変更を実装できるようにするソフトウェア製品の機能。 (ISO9126)保守性も参照してください。
分類ツリー法： 分類ツリーによって記述されたテストケースが、入力ドメインおよび/または出力ドメインの代表の組み合わせを実行するように設計されるブラックボックステスト設計手法。 (グロヒトマン)
コードカバレッジ： ソフトウェアのどの部分がテストスイートによって実行（カバー）され、どの部分が実行されていないかを判断する分析方法。ステートメントカバレッジ、決定カバレッジ、または条件カバレッジ。
共存： 共通のリソースを共有する共通の環境で他の独立したソフトウェアと共存するソフトウェア製品の機能。 (ISO9126)移植性テストを参照してください。
複雑： コンポーネントまたはシステムが、理解、維持、および検証が困難な設計および/または内部構造を持っている程度。循環的複雑度も参照してください。
コンプライアンス： 法律および同様の処方箋の標準、規則、または規制に準拠するソフトウェア製品の機能。 (ISO 9126)
コンプライアンステスト ： コンポーネントまたはシステムのコンプライアンスを判断するためのテストプロセス。
成分： 単独でテストできる最小限のソフトウェアアイテム。
コンポーネント統合テスト： インターフェースの欠陥と統合コンポーネント間の相互作用を明らかにするために実行されたテスト。
コンポーネント仕様： 指定された条件下での指定された入力値の出力値、および必要な非機能動作（リソース使用率など）に関するコンポーネントの機能の説明。
コンポーネントテスト： 個々のソフトウェアコンポーネントのテスト。 (IEEE610以降)
複合条件： 論理演算子（AND、OR、またはXOR）によって結合された2つ以上の単一条件。 「A> B AND C> 1000」。
同時実行テスト： アクティビティのインターリーブまたは同時実行のいずれかによって達成された、同じ時間間隔内での2つ以上のアクティビティの発生が、コンポーネントまたはシステムによってどのように処理されるかを判別するためのテスト。 (IEEE610以降)
調子： TrueまたはFalseとして評価できる論理式。例： A> B。テスト条件も参照してください。
条件カバレッジ： テストスイートによって実行された状態の結果のパーセンテージ。 100％の条件カバレッジでは、すべての決定ステートメントの各単一条件をTrueおよびFalseとしてテストする必要があります。
状態判定カバレッジ： テストケーススイートによって実行された決定結果に独立して影響を与えるすべての単一条件の結果のパーセンテージ。 100％の条件決定カバレッジは、100％の決定条件カバレッジを意味します。
状態判定テスト： 意思決定の結果に独立して影響を与える単一の条件の結果を実行するようにテストケースが設計されるホワイトボックステスト設計手法。
状態テスト： テストケースが条件の結果を実行するように設計されるホワイトボックステスト設計手法。
状態の結果： 条件のTrueまたはFalseへの評価。
構成： 構成部品の数、性質、および相互接続によって定義されるコンポーネントまたはシステムの構成。
構成監査： 構成アイテムのライブラリの内容をチェックする機能。標準への準拠。 (IEEE 610)
構成制御： 構成IDの正式な確立後の構成アイテムの評価、調整、承認または不承認、および変更の実装で構成される構成管理の要素。 (IEEE
610)
構成の識別： システムの構成アイテムを選択し、それらの機能的および物理的特性を技術文書に記録することで構成される構成管理の要素。 (IEEE 610)
構成項目： 構成管理用に指定され、構成管理プロセスで単一のエンティティとして扱われるハードウェア、ソフトウェア、またはその両方の集合体。 (IEEE 610)
構成管理： 技術的および管理的な指示と監視を適用して、構成アイテムの機能的および物理的特性を識別および文書化し、それらの特性への変更を制御し、変更の処理と実装ステータスを記録および報告し、指定された要件への準拠を検証する分野。 (IEEE 610)
一貫性： コンポーネントまたはシステムのドキュメントまたはパーツ間の統一性、標準化、および矛盾のない程度。 (IEEE 610)
制御フロー： コンポーネントまたはシステムを介した実行で発生する可能性のあるすべてのイベント（パス）の抽象表現。
変換テスト： 交換システムで使用するために既存のシステムからデータを変換するために使用されるソフトウェアのテスト。
ベビーベッド： 商用オフザシェルフソフトウェアの頭字語。
カバレッジ： 指定されたカバレッジ項目がテストスイートによって実行された度合い。パーセンテージで表されます。
カバレッジ分析： 追加のテストが必要かどうか、必要な場合はどのテストケースが必要かを判断するための所定の基準を参照して、テスト実行中に指定されたカバレッジ項目に対して達成されたカバレッジの測定。
取材項目： テストカバレッジの基礎として使用されるエンティティまたはプロパティ。等価パーティションまたはコードステートメント。
カバレッジツール： どの構造要素の客観的な測定値を提供するツール。ステートメント、ブランチはテストスイートによって実行されました。
循環的複雑度： プログラムを通る独立したパスの数。循環的複雑度は次のように定義されます：L – N + 2P、ここで–L =グラフ内のエッジ/リンクの数–N =グラフ内のノードの数– P =グラフの切断された部分の数（例：呼び出しグラフとサブルーチン）。 【マッケイブ後】
D
データ定義： 変数に値が割り当てられる実行可能ステートメント。
データ駆動型テスト： 1つの制御スクリプトでテーブル内のすべてのテストを実行できるように、テスト入力と期待される結果をテーブルまたはスプレッドシートに保存するスクリプト手法。データ駆動型テストは、キャプチャ/再生ツールなどのテスト実行ツールのアプリケーションをサポートするためによく使用されます。 (Fewster andGraham)キーワード駆動型テストも参照してください。
データフロー： シーケンスの抽象表現とデータオブジェクトの状態の可能な変更。オブジェクトの状態は次のいずれかです。：作成、使用、または破壊。 【バイザー】
データフロー分析： 変数の定義と使用法に基づく静的分析の形式。
データフローカバレッジ： テストケーススイートによって実行された定義と使用のペアの割合。
データフローテスト： 定義を実行し、変数のペアを使用するようにテストケースを設計するホワイトボックステスト設計手法。
デバッグ： ソフトウェアの障害の原因を見つけ、分析し、取り除くプロセス。
デバッグツール： プログラマーが障害を再現し、プログラムの状態を調査し、対応する欠陥を見つけるために使用するツール。デバッガーを使用すると、プログラマーはプログラムを段階的に実行したり、任意のプログラムステートメントでプログラムを停止したり、プログラム変数を設定および検査したりできます。
決定： 制御フローに2つ以上の代替ルートがあるプログラムポイント。別々のブランチへの2つ以上のリンクを持つノード。
決定条件の適用範囲： テストスイートによって実行されたすべての条件の結果と決定の結果のパーセンテージ。 100％の決定条件カバレッジは、100％の条件カバレッジと100％の決定カバレッジの両方を意味します。
決定条件テスト： テストケースが条件の結果と決定の結果を実行するように設計されているホワイトボックステスト設計手法。
決定範囲： テストスイートによって実行された決定結果のパーセンテージ。 100％の意思決定カバレッジは、100％のブランチカバレッジと100％のステートメントカバレッジの両方を意味します。
デシジョンテーブル： テストケースの設計に使用できる、入力および/または刺激（原因）とそれに関連する出力および/またはアクション（効果）の組み合わせを示す表。
デシジョンテーブルテスト： デシジョンテーブルに示されている入力および/または刺激（原因）の組み合わせを実行するようにテストケースが設計されるブラックボックステスト設計手法。 (ヴィーネンダール)
意思決定テスト： 意思決定の結果を実行するようにテストケースを設計するホワイトボックステスト設計手法。
決定結果： 決定の結果（したがって、実行するブランチが決定されます）。
欠陥： コンポーネントまたはシステムが必要な機能を実行できなくなる可能性のあるコンポーネントまたはシステムの欠陥。誤ったステートメントまたはデータ定義。実行中に欠陥が発生した場合、コンポーネントまたはシステムの障害が発生する可能性があります。
欠陥密度： コンポーネントまたはシステムで識別された欠陥の数をコンポーネントまたはシステムのサイズで割ったもの（コードの行数、クラスまたはファンクションポイントなどの標準的な測定用語で表されます）。
欠陥検出率（DDP）： テストフェーズで検出された欠陥の数を、そのテストフェーズおよびその後のその他の手段で検出された数で割ったもの。
欠陥レポート： コンポーネントまたはシステムが必要な機能の実行に失敗する原因となる可能性のあるコンポーネントまたはシステムの欠陥について報告するドキュメント。 (IEEE829以降)
欠陥管理： 欠陥を認識し、調査し、行動を起こし、処分するプロセス。これには、欠陥の記録、分類、および影響の特定が含まれます。 (IEEE1044以降)
欠陥マスキング： ある欠陥が別の欠陥の検出を妨げる発生。 (IEEE610以降)
定義と使用のペア： 変数の定義とその変数の使用との関連付け。変数の使用には、計算（乗算など）またはパスの実行を指示する（「述語」の使用）が含まれます。
成果物： （作業）製品の作成者以外の誰かに配信する必要がある（作業）製品。
設計ベースのテスト： コンポーネントまたはシステムのアーキテクチャおよび/または詳細設計に基づいてテストケースが設計されるテストへのアプローチ（コンポーネントまたはシステム間のインターフェイスのテストなど）。
デスクチェック： 実行の手動シミュレーションによるソフトウェアまたは仕様のテスト。
開発テスト： コンポーネントまたはシステムの実装中に、通常は開発者が開発環境で実施する公式または非公式のテスト。 (IEEE610以降)
ドキュメントテスト： ドキュメントの品質をテストします。ユーザーガイドまたはインストールガイド。
ドメイン： 有効な入力値および/または出力値を選択できるセット。
運転者： コンポーネントまたはシステムの制御および/または呼び出しを処理するコンポーネントを置き換えるソフトウェアコンポーネントまたはテストツール。 【TMap後】
動的分析： 行動を評価するプロセス、例えば実行中のシステムまたはコンポーネントのメモリパフォーマンス、CPU使用率。 (IEEE610以降)
動的比較： たとえばテスト実行ツールによってソフトウェアが実行されている間に実行された、実際の結果と期待される結果の比較。
動的テスト： コンポーネントまたはシステムのソフトウェアの実行を伴うテスト。
IS
効率： 指定された条件下で使用されるリソースの量に関連して、適切なパフォーマンスを提供するソフトウェア製品の機能。 (ISO 9126)
効率テスト： ソフトウェア製品の効率を判断するためのテストのプロセス。
基本比較テスト： 条件決定カバレッジの概念を使用して入力の組み合わせを実行するようにテストケースが設計されるブラックボックステスト設計手法。 (TMap)
エミュレータ： 特定のシステムと同じ入力を受け入れ、同じ出力を生成するデバイス、コンピュータープログラム、またはシステム。 (IEEE610)シミュレータも参照してください。
エントリー基準： プロセスが定義されたタスクを進めることを許可するための一般的で特定の条件のセット。テストフェーズ。エントリー基準の目的は、失敗したエントリー基準を削除するために必要な労力と比較して、より多くの（無駄な）労力を伴うタスクの開始を防ぐことです。 (ギルブとグラハム)
エントリーポイント： コンポーネント内の最初の実行可能ステートメント。
等価パーティション： 仕様に基づいて、コンポーネントまたはシステムの動作が同じであると想定される入力ドメインまたは出力ドメインの一部。
等価パーティションカバレッジ： テストスイートによって実行された等価パーティションの割合。
等価分割： 同等のパーティションから代表を実行するようにテストケースが設計されるブラックボックステスト設計手法。原則として、テストケースは各パーティションを少なくとも1回カバーするように設計されています。
エラー： 誤った結果を生み出す人間の行動。 (IEEE610以降)
エラー推測： テスターの経験を使用して、エラーが発生した結果としてテスト対象のコンポーネントまたはシステムにどのような欠陥が存在するかを予測し、それらを明らかにするためのテストを設計するテスト設計手法。
エラーシード： 検出と除去の速度を監視し、残っている欠陥の数を推定する目的で、コンポーネントまたはシステムにすでに存在する欠陥に既知の欠陥を意図的に追加するプロセス。 (IEEE 610)
エラー許容度： 誤った入力が存在する場合でも、システムまたはコンポーネントが通常の操作を継続する機能。 (IEEE610以降)。
例外処理： 人間のユーザーまたは別のコンポーネントまたはシステムからの誤った入力、または内部障害に応じたコンポーネントまたはシステムの動作。
実行可能ステートメント： コンパイル時にオブジェクトコードに変換され、プログラムの実行時に手続き的に実行され、データに対してアクションを実行する可能性のあるステートメント。
行使： プログラム要素は、入力値がステートメント、決定、または他の構造要素などの要素の実行を引き起こすときに、テストケースによって実行されると言われます。
徹底的なテスト： テストスイートが入力値と前提条件のすべての組み合わせで構成されるテストアプローチ。
終了基準： プロセスを正式に完了することを許可するための、利害関係者と合意した一連の一般的および特定の条件。終了基準の目的は、タスクの未完了部分がまだ完了していない場合に、タスクが完了したと見なされないようにすることです。終了基準は、テストによってレポートを作成し、テストをいつ停止するかを計画するために使用されます。 (ギルブとグラハムの後)
出口点： コンポーネント内の最後の実行可能ステートメント。
期待される結果： 指定された条件下でのコンポーネントまたはシステムの仕様または別のソースによって予測された動作。
探索的テスト： テスターがテストの実行時にテストの設計を積極的に制御し、テスト中に取得した情報を使用して、新しくより優れたテストを設計するテスト。 【バッハ】
F
不合格： 実際の結果が期待される結果と一致しない場合、テストは失敗したと見なされます。
失敗： コンポーネントまたはシステムの予想される配信、サービス、または結果からの実際の逸脱。 【フェントン後】
故障モード： 障害の物理的または機能的な兆候。たとえば、障害モードのシステムは、動作が遅い、出力が正しくない、または実行が完全に終了することを特徴とする場合があります。
故障モードおよび影響分析（FMEA）： リスクの特定と、考えられる障害のモードを特定し、それらの発生を防止しようとする分析への体系的なアプローチ。
故障率： 特定の測定単位に対する特定のカテゴリの失敗数の比率。単位時間あたりの障害、トランザクション数あたりの障害、コンピューター実行数あたりの障害。 (IEEE 610)
フォールトトレランス： ソフトウェアの障害（欠陥）または指定されたインターフェイスの侵害の場合に、指定されたレベルのパフォーマンスを維持するソフトウェア製品の機能。 (ISO9126)信頼性も参照してください。
フォールトツリー分析： 障害（欠陥）の原因を分析するために使用される方法。
実行可能なパス： 入力値と前提条件のセットが存在し、それが実行されるパス。
特徴： 要件ドキュメントによって指定または暗示されるコンポーネントまたはシステムの属性（信頼性、使いやすさ、設計上の制約など）。 (IEEE1008以降)
有限状態マシン： 有限数の状態とそれらの状態間の遷移で構成される計算モデル。場合によってはアクションが伴います。 (IEEE 610)
正式なレビュー： 文書化された手順と要件を特徴とするレビュー。検査。
凍結試験基準： 正式な変更管理プロセスによってのみ修正できるテストベースのドキュメント。ベースラインも参照してください。
ファンクションポイント分析（FPA）： 情報システムの機能の大きさを測定することを目的とした方法。測定はテクノロジーに依存しません。この測定値は、生産性の測定、必要なリソースの見積もり、およびプロジェクト管理の基礎として使用できます。
機能統合： 基本的な機能を早期に機能させるために、コンポーネントまたはシステムを組み合わせる統合アプローチ。統合テストも参照してください。
機能要件： コンポーネントまたはシステムが実行する必要のある機能を指定する要件。 (IEEE 610)
機能テスト設計手法： 内部構造を参照せずに、コンポーネントまたはシステムの機能の仕様の分析に基づいてテストケースを導出および選択するための文書化された手順。ブラックボックステストの設計手法も参照してください。
機能テスト： コンポーネントまたはシステムの機能の仕様の分析に基づくテスト。ブラックボックステストも参照してください。
機能： ソフトウェアが特定の条件下で使用された場合に、明示的および黙示的なニーズを満たす機能を提供するソフトウェア製品の機能。 (ISO 9126)
機能テスト： ソフトウェア製品の機能を決定するためのテストのプロセス。
G
ガラスボックステスト： ホワイトボックステストを参照してください。
H
ヒューリスティック評価： ユーザーインターフェイスが認識されているユーザビリティの原則（いわゆる「ヒューリスティック」）に準拠しているかどうかを判断するための静的なユーザビリティテスト手法。
高レベルのテストケース： 入力データと期待される結果の具体的な（実装レベル）値のないテストケース。
水平トレーサビリティ： テスト文書のレイヤー（テスト計画、テスト設計仕様、テストケース仕様、テスト手順仕様など）を介したテストレベルの要件のトレース。
私
影響分析： 指定された要件に特定の変更を実装するための、開発ドキュメント、テストドキュメント、およびコンポーネントのレイヤーへの変更の評価。
増分開発モデル： プロジェクトが一連の増分に分割される開発ライフサイクル。各増分は、プロジェクト全体の要件の機能の一部を提供します。要件に優先順位が付けられ、適切な増分で優先順位に従って提供されます。このライフサイクルモデルの一部（すべてではない）のバージョンでは、各サブプロジェクトは、独自の設計、コーディング、およびテストのフェーズを備えた「ミニVモデル」に従います。
インクリメンタルテスト： すべてのコンポーネントまたはシステムが統合されてテストされるまで、コンポーネントまたはシステムが統合されて一度に1つまたはいくつかがテストされるテスト。
インシデント： テスト中に発生し、調査が必要なイベント。 (IEEE1008以降)
事故管理： インシデントを認識、調査、アクションを実行し、処理するプロセス。これには、インシデントの記録、分類、および影響の特定が含まれます。 (IEEE1044以降)
インシデント管理ツール： テスト中に見つかったインシデントの記録とステータス追跡を容易にするツール。多くの場合、インシデントの割り当て、修正、再テストを追跡および制御し、レポート機能を提供するワークフロー指向の機能があります。
事故報告書： 調査が必要なテスト中に発生したイベントについて報告するドキュメント。 (IEEE829以降)
独立： 客観的テストの達成を促進する責任の分離。 (DO-178b後)
実行不可能なパス： 可能な入力値のセットでは実行できないパス。
非公式レビュー： 正式な（文書化された）手順に基づかないレビュー。
入力： コンポーネントによって読み取られる変数（コンポーネント内またはコンポーネント外に格納されているかどうか）。
入力ドメイン： 有効な入力値を選択できるセット。ドメインも参照してください。
入力値： 入力のインスタンス。入力も参照してください。
検査： 欠陥を検出するために文書の視覚的検査に依存する一種のレビュー。開発基準の違反およびより高いレベルの文書への不適合。最も正式なレビュー手法であるため、常に文書化された手順に基づいています。 (IEEE 610、IEEE1028以降)
インストール可能性： 指定された環境にインストールされるソフトウェア製品の機能(ISO9126)。移植性も参照してください。
インストール可能性テスト： ソフトウェア製品のインストール可能性をテストするプロセス。移植性テストも参照してください。
インストールガイド： インストーラーがインストールプロセスをガイドする、適切なメディアで提供される手順。これは、手動ガイド、ステップバイステップの手順、インストールウィザード、またはその他の同様のプロセスの説明である可能性があります。
インストールウィザード： 適切なメディアで提供されるソフトウェア。これにより、インストーラーがインストールプロセスを実行します。通常、インストールプロセスを実行し、インストール結果に関するフィードバックを提供し、オプションの入力を求めます。
計装： 実行中のプログラムの動作に関する情報を収集するための、プログラムへの追加コードの挿入。
楽器： インストルメンテーションを実行するために使用されるソフトウェアツール。
摂取テスト： コンポーネントまたはシステムが詳細なさらなるテストの準備ができているかどうかを判断するためのスモークテストの特別なインスタンス。摂取テストは通常、テスト実行フェーズの開始時に実行されます。
統合： コンポーネントまたはシステムをより大きなアセンブリに結合するプロセス。
統合テスト： インターフェースおよび統合されたコンポーネントまたはシステム間の相互作用の欠陥を明らかにするために実行されるテスト。コンポーネント統合テスト、システム統合テストも参照してください。
インターフェイステスト： コンポーネントまたはシステム間のインターフェースのテストに関係する統合テストタイプ。
相互運用性： 1つ以上の指定されたコンポーネントまたはシステムと相互作用するソフトウェア製品の機能。 (ISO9126以降)機能も参照してください。
相互運用性テスト： ソフトウェア製品の相互運用性を判断するためのテストプロセス。機能テストも参照してください。
無効なテスト： コンポーネントまたはシステムによって拒否されるべき入力値を使用したテスト。許容誤差も参照してください。
分離テスト： 必要に応じて、周囲のコンポーネントをスタブとドライバーによってシミュレートして、周囲のコンポーネントから分離した個々のコンポーネントのテスト。
に
キーワード駆動テスト： データファイルを使用して、テストデータと期待される結果だけでなく、テスト対象のアプリケーションに関連するキーワードも含めるスクリプト手法。キーワードは、テストの制御スクリプトによって呼び出される特別なサポートスクリプトによって解釈されます。データ駆動型テストも参照してください。
L
LCSAJ： 線形コードシーケンスとジャンプ。次の3つの項目で構成されます（通常、ソースコードリストの行番号で識別されます）：実行可能ステートメントの線形シーケンスの開始、線形シーケンスの終了、および制御対象のターゲット行フローは線形シーケンスの最後に転送されます。
LCSAJカバレッジ： テストスイートによって実行されたコンポーネントのLCSAJの割合。 100％LCSAJカバレッジは、100％決定カバレッジを意味します。
LCSAJテスト： テストケースがLCSAJを実行するように設計されているホワイトボックステスト設計手法。
学習可能性： ユーザーがそのアプリケーションを学習できるようにするソフトウェア製品の機能。 (ISO9126)ユーザビリティも参照してください。
負荷テスト： 負荷の増加に伴うコンポーネントまたはシステムの動作の測定に関係するテストタイプ。コンポーネントまたはシステムで処理できる負荷を決定するための並列ユーザーの数および/またはトランザクションの数。
低レベルのテストケース： 入力データと期待される結果の具体的な（実装レベル）値を使用したテストケース。
M
メンテナンス： 欠陥を修正するため、パフォーマンスやその他の属性を改善するため、または製品を変更された環境に適合させるための、配信後のソフトウェア製品の変更。 (IEEE 1219)
メンテナンステスト： 運用システムへの変更または変更された環境の運用システムへの影響をテストします。
保守性： ソフトウェア製品を簡単に変更して欠陥を修正したり、新しい要件を満たすように変更したり、将来のメンテナンスを容易にするために変更したり、変更された環境に適応させたりすることができます。 (ISO 9126)
保守性テスト： ソフトウェア製品の保守性を判断するためのテストプロセス。
マネジメントレビュー： ソフトウェアの取得、供給、開発、運用、または保守プロセスの体系的な評価。管理者によって、または管理者に代わって実行され、進捗状況を監視し、計画とスケジュールのステータスを決定し、要件と継承システムの割り当てを確認し、管理アプローチの有効性を評価します。目的への適合性を達成するため。 (IEEE 610、IEEE1028以降)
成熟： （1）プロセスと作業慣行の有効性と効率性に関する組織の能力。機能成熟度モデル、テスト成熟度モデルも参照してください。 （2）ソフトウェアの欠陥の結果としての障害を回避するソフトウェア製品の機能。 (ISO9126)信頼性も参照してください。
対策： 測定を行うことによってエンティティの属性に割り当てられた番号またはカテゴリ(ISO14598)。
測定： エンティティに番号またはカテゴリを割り当てて、そのエンティティの属性を記述するプロセス。 (ISO 14598)
測定尺度： 実行できるデータ分析のタイプを制約するスケール。 (ISO 14598)
メモリーリーク： プログラムの動的ストア割り当てロジックの欠陥で、使用終了後にメモリの再利用に失敗し、最終的にはメモリ不足のためにプログラムが失敗します。
メトリック： 測定尺度と測定に使用される方法。 (ISO 14598)
マイルストーン： プロジェクト内の、定義された（中間の）成果物と結果は準備ができているはずです。
モデレータ： 検査またはその他のレビュープロセスを担当するリーダーおよび主要人物。
モニター： テスト対象のコンポーネントまたはシステムと同時に実行され、コンポーネントまたはシステムの動作を監視、記録、および/または分析するソフトウェアツールまたはハードウェアデバイス。 (IEEE610以降)
複数の条件の適用範囲： すべての単一条件の組み合わせの割合テストスイートによって実行された1つのステートメント内の結果。 100％倍数条件カバレッジは、100％の条件決定カバレッジを意味します。
複数の条件のテスト： テストケースが単一の条件の結果の組み合わせを実行するように設計されているホワイトボックステスト設計手法（1つのステートメント内）。
突然変異分析： テストスイートがプログラムをプログラムのわずかなバリアント（ミュータント）から区別できる程度を測定することにより、テストスイートの完全性を判断する方法。
N
Nスイッチカバレッジ： テストスイートによって実行されたN + 1遷移のシーケンスのパーセンテージ。 【チャウチャウ】
Nスイッチテスト： テストケースがN + 1遷移のすべての有効なシーケンスを実行するように設計されている状態遷移テストの形式。 (チャウ)状態遷移テストも参照してください。
ネガティブテスト： コンポーネントまたはシステムが機能しないことを示すことを目的としたテスト。ネガティブテストは、特定のテストアプローチやテスト設計手法ではなく、テスターの態度に関連しています。 (バイザー後)。
不適合： 指定された要件を満たしていない。 (ISO 9000)
非機能要件： 機能性ではなく、信頼性、効率性、使いやすさ、保守性、移植性などの属性に関連する要件。
非機能テスト： 機能に関係のないコンポーネントまたはシステムの属性をテストします。信頼性、効率性、使いやすさ、保守性、移植性。
非機能的なテスト設計手法： 非機能テストのテストを設計または選択するために使用される方法。
または
既製のソフトウェア： 一般市場向けに開発された、つまり多数の顧客向けに開発され、同じ形式で多くの顧客に配信されるソフトウェア製品。
操作性： ユーザーがソフトウェア製品を操作および制御できるようにするソフトウェア製品の機能。 (ISO9126)ユーザビリティも参照してください。
運用環境： テスト対象のコンポーネントまたはシステムが使用されるユーザーまたは顧客のサイトにインストールされたハードウェアおよびソフトウェア製品。ソフトウェアには、オペレーティングシステム、データベース管理システム、およびその他のアプリケーションが含まれる場合があります。
運用プロファイルテスト： システム操作（短期間のタスク）のモデルとそれらの典型的な使用の確率を使用した統計的検定。 【ムサ】
運用テスト： 運用環境でコンポーネントまたはシステムを評価するために実施されるテスト。 (IEEE 610)
出力： コンポーネントによって書き込まれる変数（コンポーネント内またはコンポーネント外に格納されているかどうか）。
出力ドメイン： 有効な出力値を選択できるセット。ドメインも参照してください。
出力値： 出力のインスタンス。出力も参照してください。
P
ペアプログラミング： コンポーネントのコード行（本番および/またはテスト）が、1台のコンピューターに座っている2人のプログラマーによって記述されるソフトウェア開発アプローチ。これは暗黙的に、進行中のリアルタイムコードレビューが実行されることを意味します。
ペアテスト： 2人のテスターが協力して欠陥を見つけます。通常、彼らは1台のコンピューターを共有し、テスト中にそのコンピューターの制御を交換します。
パス： 実際の結果が期待される結果と一致する場合、テストは合格と見なされます。
合格/不合格基準： テスト項目（機能）または機能がテストに合格したか失敗したかを判断するために使用される決定ルール。 (IEEE 829)
道： 一連のイベント、例：エントリポイントからエグジットポイントまでのコンポーネントまたはシステムの実行可能ステートメント。
パスカバレッジ： テストスイートによって実行されたパスの割合。 100％のパスカバレッジは、100％のLCSAJカバレッジを意味します。
epsファイルとは何ですか？
パス増感： 指定されたパスの実行を強制するための入力値のセットの選択。
パステスト： テストケースがパスを実行するように設計されているホワイトボックステスト設計手法。
パフォーマンス： システムまたはコンポーネントが、処理時間とスループット率に関する特定の制約内で指定された機能を実行する程度。 (IEEE610以降)効率を参照してください。
パフォーマンス指標： 進歩的な開発を導き、制御するために使用される有効性および/または効率の高レベルのメトリック。テスト用の欠陥検出率（DDP）。 (CMMI)
性能試験： ソフトウェア製品のパフォーマンスを判断するためのテストのプロセス。効率テストを参照してください。
パフォーマンステストツール： パフォーマンステストをサポートするツールで、通常、負荷の生成とテストトランザクションの測定という2つの主要な機能があります。負荷生成では、複数のユーザーまたは大量の入力データをシミュレートできます。実行中に、選択したトランザクションから応答時間の測定値が取得され、これらがログに記録されます。パフォーマンステストツールは通常、テストログと応答時間に対する負荷のグラフに基づいてレポートを提供します。
フェーズテスト計画： 通常、1つのテストレベルに対応するテスト計画。
移植性： ソフトウェア製品をあるハードウェアまたはソフトウェア環境から別の環境に簡単に転送できます。 (ISO 9126)
移植性テスト： ソフトウェア製品の移植性を判断するためのテストプロセス。
事後条件： テストまたはテスト手順の実行後に満たす必要のある環境および状態の条件。
実行後の比較： ソフトウェアの実行が終了した後に実行された、実際の結果と期待される結果の比較。
前提条件： コンポーネントまたはシステムを特定のテストまたはテスト手順で実行する前に満たす必要のある環境および状態の条件。
優先度： アイテムに割り当てられた（ビジネス）重要度のレベル。欠陥。
プロセスサイクルテスト： テストケースがビジネス手順とプロセスを実行するように設計されるブラックボックステスト設計手法。 (TMap)
処理する： 入力を出力に変換する、相互に関連する一連のアクティビティ。 (ISO 12207)
事業： プロジェクトは、時間、コスト、リソースの制約など、特定の要件に準拠した目的で開始日と終了日が設定された、調整および制御された独自のアクティビティのセットです。 (ISO 9000)
プロジェクトテスト計画： 通常、複数のテストレベルに対応するテスト計画。
疑似ランダム： ランダムに見えるが、実際には事前に準備されたシーケンスに従って生成されるシリーズ。
Q
品質： コンポーネント、システム、またはプロセスが指定された要件および/またはユーザー/顧客のニーズと期待をどの程度満たしているか。 (IEEE610以降)
品質保証： 品質管理の一部は、品質要件が満たされるという確信を提供することに焦点を合わせました。 (ISO 9000)
品質属性： アイテムの品質に影響を与える機能または特性。 (IEEE 610)
品質管理： 品質に関して組織を指揮および管理するための調整された活動。品質に関する方向性と管理には、一般に、品質方針と品質目標の確立、品質計画、品質管理、品質保証、品質改善が含まれます。 (ISO 9000)
R
ランダムテスト： おそらく疑似ランダム生成アルゴリズムを使用して、運用プロファイルに一致するようにテストケースが選択されるブラックボックステスト設計手法。この手法は、信頼性やパフォーマンスなどの非機能属性をテストするために使用できます。
回復可能性： 指定されたレベルのパフォーマンスを再確立し、障害が発生した場合に直接影響を受けるデータを回復するソフトウェア製品の機能。 (ISO9126)信頼性も参照してください。
回復可能性テスト： ソフトウェア製品の回復可能性を判断するためのテストのプロセス。信頼性テストも参照してください。
回帰試験： 変更後の以前にテストされたプログラムをテストして、変更の結果としてソフトウェアの変更されていない領域に欠陥が導入または発見されていないことを確認します。ソフトウェアまたはその環境が変更されたときに実行されます。
リリースノート： テスト実行フェーズの開始時に、テストアイテム、それらの構成、現在のステータス、および開発によってテストに配信されるその他の配信情報、および場合によってはその他の利害関係者を識別するドキュメント。 (IEEE829以降)
信頼性： 指定された期間、または指定された数の操作に対して、指定された条件下で必要な機能を実行するソフトウェア製品の機能。 (ISO 9126)
信頼性テスト： ソフトウェア製品の信頼性を判断するためのテストプロセス。
交換可能性： 同じ環境で同じ目的のために、別の指定されたソフトウェア製品の代わりに使用されるソフトウェア製品の機能。 (ISO9126)移植性も参照してください。
要件： 契約、標準、仕様、またはその他の正式に課された文書を満たすために、システムまたはシステムコンポーネントが満たすか、所有する必要がある問題を解決する、または目的を達成するためにユーザーが必要とする条件または機能。 (IEEE610以降)
要件ベースのテスト： テストケースが要件から導き出されたテスト目的とテスト条件に基づいて設計されるテストへのアプローチ。特定の機能を実行するテスト、または信頼性や使いやすさなどの非機能属性を調査するテスト。
要件管理ツール： 要件、要件属性（優先度、責任のある知識など）、および注釈の記録をサポートし、要件のレイヤーおよび要件変更管理を通じてトレーサビリティを促進するツール。一部の要件管理ツールは、整合性チェックや事前定義された要件ルールへの違反など、静的分析の機能も提供します。
要件フェーズ： ソフトウェア製品の機器が定義および文書化される、ソフトウェアライフサイクルの期間。 (IEEE 610)
リソースの活用： ソフトウェアが指定された条件下で機能を実行するときに、プログラムが使用するメインメモリとセカンダリメモリの量、必要な一時ファイルまたはオーバーフローファイルのサイズなど、適切な量と種類のリソースを使用するソフトウェア製品の機能。 (ISO9126以降)効率も参照してください。
リソース使用率テスト： ソフトウェア製品のリソース使用率を決定するためのテストのプロセス。
結果： テストの実行の結果/結果。これには、画面への出力、データの変更、レポート、および送信される通信メッセージが含まれます。実際の結果、期待される結果も参照してください。
再開基準： 一時停止後にテストを再開するときに繰り返す必要のあるテストアクティビティ。 (IEEE829以降)
再テスト： 修正措置の成功を検証するために、最後に実行されたときに失敗したテストケースを実行するテスト。
レビュー： 計画された結果からの不一致を確認し、改善を推奨するための製品またはプロジェクトのステータスの評価。例としては、管理レビュー、非公式レビュー、技術レビュー、検査、ウォークスルーなどがあります。 (IEEE1028以降)
レビュアー： レビュー中の製品またはプロジェクトの異常を特定して説明する、レビューに関与する人。レビューアは、レビュープロセスにおけるさまざまな視点と役割を表すように選択できます。
危険： 将来の悪影響をもたらす可能性のある要因。通常、影響と可能性として表されます。
リスク分析： 特定されたリスクを評価して、その影響と発生の可能性（可能性）を推定するプロセス。
リスクベーステスト： 製品のリスクに関する情報の調査と提供を目的としたテスト。 【ジェラード後】
リスク管理： 特定のレベルまでのリスクを軽減する、またはリスクを維持するための決定に到達し、保護措置を実施するプロセス。
リスクの特定： ブレーンストーミング、チェックリスト、障害履歴などの手法を使用してリスクを特定するプロセス。
危機管理： リスクの特定、分析、優先順位付け、および管理のタスクへの手順と実践の体系的な適用。
堅牢性： 無効な入力またはストレスの多い環境条件が存在する場合に、コンポーネントまたはシステムが正しく機能できる程度。 (IEEE 610)エラートレランス、フォールトトレランスも参照してください。
根本的な原因： 不適合の原因となった根本的な要因は、プロセスの改善を通じて永久に排除する必要があります。
S
安全性： 特定の使用状況において、人、ビジネス、ソフトウェア、資産、または環境に害を及ぼす許容レベルのリスクを達成するためのソフトウェア製品の機能。 (ISO 9126)
安全性試験： ソフトウェア製品の安全性を判断するためのテストプロセス。
スケーラビリティ： 増加した負荷に対応するためにアップグレードされるソフトウェア製品の機能。 【ジェラード後】
スケーラビリティテスト： ソフトウェア製品のスケーラビリティを判断するためのテスト。
筆記者： 言及された各欠陥とレビュー会議中の改善のための提案をログフォームに記録する必要がある人。筆記者は、ロギングフォームが読みやすく理解しやすいものであることを確認する必要があります。
スクリプト言語： 実行可能なテストスクリプトが記述され、テスト実行ツール（キャプチャ/再生ツールなど）によって使用されるプログラミング言語。
セキュリティ： プログラムおよびデータへの偶発的または故意の不正アクセスを防止する能力に関係するソフトウェア製品の属性。 (ISO 9126)
セキュリティテスト： ソフトウェア製品のセキュリティを判断するためのテスト。
重大度： 欠陥がコンポーネントまたはシステムの開発または運用に与える影響の程度。 (IEEE610以降)
シミュレーション： 別のシステムによる、ある物理システムまたは抽象システムの選択された動作特性の表現。 (ISO 2382/1)
シミュレーター： テスト中に使用されるデバイス、コンピュータープログラム、またはシステム。制御された入力のセットが提供されると、特定のシステムのように動作または動作します。 (IEEE 610、DO178b以降)エミュレータも参照してください。
スモークテスト： コンポーネントまたはシステムの主な機能をカバーするすべての定義済み/計画済みテストケースのサブセット。プログラムの最も重要な機能が機能することを確認しますが、詳細に煩わされることはありません。デイリービルドとスモークテストは、業界のベストプラクティスの1つです。摂取テストも参照してください。
ソフトウェアの品質： 明示的または黙示的なニーズを満たす能力に関係するソフトウェア製品の機能と特徴の全体。 (ISO9126以降)
仕様： コンポーネントまたはシステムの要件、設計、動作、またはその他の特性、および多くの場合、これらの規定が満たされているかどうかを判断するための手順を、理想的には完全で正確かつ検証可能な方法で指定するドキュメント。 (IEEE610以降)
仕様ベースのテスト設計手法： ブラックボックステストの設計手法を参照してください。
指定された入力： 仕様が結果を予測する入力。
安定： ソフトウェアの変更による予期しない影響を回避するソフトウェア製品の機能。 (ISO9126)保守性も参照してください。
状態図： コンポーネントまたはシステムが想定できる状態を示し、ある状態から別の状態への変化を引き起こす、および/またはその結果として生じるイベントまたは状況を示す図。 (IEEE 610)
状態テーブル： 有効な遷移と無効な遷移の両方を示す、可能な各イベントと組み合わされた各状態の結果の遷移を示すグリッド。
状態遷移： コンポーネントまたはシステムの2つの状態間の遷移。
状態遷移テスト： 有効な状態遷移と無効な状態遷移を実行するようにテストケースを設計するブラックボックステスト設計手法。 Nスイッチテストも参照してください。
ステートメント： プログラミング言語のエンティティ。通常、分割できない最小の実行単位です。
ステートメントカバレッジ： テストスイートによって実行された実行可能ステートメントの割合。
ステートメントテスト： テストケースがステートメントを実行するように設計されているホワイトボックステスト設計手法。
静的分析： ソフトウェア成果物の分析（例：これらのソフトウェア成果物を実行せずに実行される要件またはコード。
静的アナライザー： 静的解析を実行するツール。
静的コード分析： そのソフトウェアを実行せずに実行されたプログラムソースコードの分析。
静的コードアナライザー： 静的コード分析を実行するツール。このツールは、コーディング標準への準拠、品質メトリック、データフローの異常など、特定のプロパティについてソースコードをチェックします。
静的テスト： そのソフトウェアを実行せずに、仕様または実装レベルでコンポーネントまたはシステムをテストします。レビューまたは静的コード分析。
統計的検定： 入力の統計的分布のモデルを使用して代表的なテストケースを構築するテスト設計手法。運用プロファイルのテストも参照してください。
ステータスアカウンティング： 構成を効果的に管理するために必要な情報の記録と報告で構成される、構成管理の要素。この情報には、承認された構成IDのリスト、構成に対する提案された変更のステータス、および承認された変更の実装ステータスが含まれます。 (IEEE 610)
ストレステスト： 指定された要件の制限以上でシステムまたはコンポーネントを評価するために実施されるテスト。 (IEEE 610)
構造カバレッジ： コンポーネントの内部構造に基づいたカバレッジ測定。
構造試験設計手法： ホワイトボックステストの設計手法を参照してください。
スタブ： ソフトウェアコンポーネントの骨格的または特別な目的の実装。コンポーネントを呼び出すか、コンポーネントに依存するコンポーネントを開発またはテストするために使用されます。呼び出されたコンポーネントを置き換えます。 (IEEE610以降)
サブパス： コンポーネント内の一連の実行可能ステートメント。
停止基準： テスト項目のテストアクティビティのすべてまたは一部を（一時的に）停止するために使用される基準。 (IEEE829以降)
適合性： 特定のタスクおよびユーザーの目的に適した一連の機能を提供するソフトウェア製品の機能。 (ISO9126)機能も参照してください。
ソフトウェアユーザビリティ測定インベントリ（SUMI）： ユーザビリティを評価するためのアンケートベースのユーザビリティテスト手法。コンポーネントまたはシステムのユーザー満足度。 (ヴィーネンダール)
構文テスト： 入力ドメインおよび/または出力ドメインの定義に基づいてテストケースが設計されるブラックボックステスト設計手法。
システム： 特定の機能または一連の機能を実行するために編成されたコンポーネントのコレクション。 (IEEE 610)
システム統合テスト： システムとパッケージの統合をテストします。外部組織（電子データ交換、インターネットなど）へのインターフェースのテスト。
システムテスト： 統合システムをテストして、指定された要件を満たしていることを確認するプロセス。 【ヘッツェル】
T
テクニカルレビュー： 取るべき技術的アプローチに関するコンセンサスの達成に焦点を当てたピアグループディスカッション活動。テクニカルレビューは、ピアレビューとも呼ばれます。 (Gilb and Graham、IEEE 1028)
テストアプローチ： 特定のプロジェクトのテスト戦略の実装。これには通常、（テスト）プロジェクトの目標と実行されるリスク評価、テストプロセスに関する開始点、適用されるテスト設計手法、終了基準、および実行されるテストタイプに基づいて行われる決定が含まれます。
テスト自動化： テスト活動を実行またはサポートするためのソフトウェアの使用。テスト管理、テスト設計、テスト実行、結果チェック。
テストベース： コンポーネントまたはシステムの要件を推測できるすべてのドキュメント。テストケースの基礎となるドキュメント。正式な修正手続きによってのみ文書を修正できる場合、テスト基準は凍結テスト基準と呼ばれます。 【TMap後】
テストケース： 特定のプログラムパスを実行したり、特定の要件への準拠を確認したりするためなど、特定の目的またはテスト条件用に開発された一連の入力値、実行前提条件、期待される結果、および実行事後条件。 (IEEE610以降)
テストケースの仕様： テスト項目の一連のテストケース（目的、入力、テストアクション、期待される結果、および実行の前提条件）を指定するドキュメント。 (IEEE829以降)
テスト憲章： テストの目的、および場合によってはテストのアイデアのステートメント。テストチャーターは、とりわけ探索的テストで使用されます。探索的テストも参照してください。
テストコンパレータ： 自動テスト比較を実行するためのテストツール。
テスト比較： テスト対象のコンポーネントまたはシステムによって生成された実際の結果と、テストで期待される結果との違いを特定するプロセス。テスト比較は、テスト実行中（動的比較）またはテスト実行後に実行できます。
試験条件： 1つ以上のテストケースで検証できるコンポーネントまたはシステムのアイテムまたはイベント。関数、トランザクション、品質属性、または構造要素。
テストデータ： テストが実行される前に（データベースなどに）存在し、テスト対象のコンポーネントまたはシステムに影響を与える、または影響を受けるデータ。
テストデータ準備ツール： テストで使用するために、既存のデータベースからデータを選択したり、作成、生成、操作、編集したりできるテストツールの一種。
テスト設計仕様： テスト項目のテスト条件（カバレッジ項目）、詳細なテストアプローチ、および関連する高レベルのテストケースの特定を指定するドキュメント。 (IEEE829以降)
テスト設計ツール： CASEツールリポジトリに保持される可能性のある仕様からテスト入力を生成することにより、テスト設計アクティビティをサポートするツール。要件管理ツール、またはツール自体に保持されている指定されたテスト条件から。
テスト設計手法： テストケースを導出または選択するために使用される方法。
テスト環境： テストの実施に必要なハードウェア、計測器、シミュレーター、ソフトウェアツール、およびその他のサポート要素を含む環境。 (IEEE610以降)
テスト評価レポート： テストプロセスの最後に作成された、すべてのテストアクティビティと結果を要約したドキュメント。また、テストプロセスの評価と学んだ教訓も含まれています。
テストの実行： テスト対象のコンポーネントまたはシステムによってテストを実行し、実際の結果を生成するプロセス。
テスト実行の自動化： ソフトウェアの使用、例えばテストの実行、実際の結果と期待される結果の比較、テストの前提条件の設定、およびその他のテスト制御およびレポート機能を制御するためのキャプチャ/再生ツール。
テスト実行フェーズ： ソフトウェア製品のコンポーネントが実行され、ソフトウェア製品が評価されて要件が満たされているかどうかを判断する、ソフトウェア開発ライフサイクルの期間。 (IEEE 610)
テスト実行スケジュール： テスト手順を実行するためのスキーム。テスト手順は、そのコンテキストで、実行される順序でテスト実行スケジュールに含まれています。
テスト実行テクニック： 実際のテスト実行を実行するために使用される方法、手動または自動のいずれか。
テスト実行ツール： 自動テストスクリプトを使用して他のソフトウェアを実行できるテストツールの一種。キャプチャ/再生。 (フュースターとグラハム)
テストハーネス： テストの実施に必要なスタブとドライバーで構成されるテスト環境。
テストインフラストラクチャ： テスト環境、テストツール、オフィス環境、および手順で構成される、テストを実行するために必要な組織の成果物。
テスト項目： テストする個々の要素。通常、1つのテストオブジェクトと多くのテスト項目があります。テストオブジェクトも参照してください。
テストレベル： 一緒に編成および管理されるテストアクティビティのグループ。テストレベルは、プロジェクトの責任にリンクされています。テストレベルの例としては、コンポーネントテスト、統合テスト、システムテスト、および受け入れテストがあります。 【TMap後】
テストログ： テストの実行に関する詳細の時系列の記録。 (IEEE 829)
テストロギング： 実行されたテストに関する情報をテストログに記録するプロセス。
実行可能なjarファイルを実行する方法
テストマネージャー： テストオブジェクトのテストと評価の責任者。計画を指揮、管理、管理し、テストオブジェクトの評価を規制する個人。
テスト管理： テスト活動の計画、見積もり、監視、および制御。通常、テストマネージャーによって実行されます。
テスト成熟度モデル（TMM）： 効果的なテストプロセスの主要な要素を説明する機能成熟度モデル（CMM）に関連する、テストプロセス改善のための5レベルの段階的フレームワーク。
テストプロセス改善（TPI）： 特にシステムテストと受け入れテストを対象とした、効果的なテストプロセスの重要な要素を説明するテストプロセス改善のための継続的なフレームワーク。
テストオブジェクト： テストするコンポーネントまたはシステム。テスト項目も参照してください。
テストの目的： テストを設計および実行する理由または目的。
オラクルのテスト： テスト対象のソフトウェアの実際の結果と比較するための期待される結果を決定するためのソース。オラクルは、既存のシステム（ベンチマーク用）、ユーザーマニュアル、または個人の専門知識である可能性がありますが、コードであってはなりません。 【アドリオン後】
テストパフォーマンス指標： 特定の目標値または基準がどの程度満たされているかを示す、一般に高レベルのメトリック。多くの場合、テストプロセスの改善目標に関連しています。欠陥検出率（DDP）。
テストフェーズ： プロジェクトの管理可能なフェーズに収集された一連の個別のテストアクティビティ。テストレベルの実行アクティビティ。 【ジェラード後】
テスト計画： 対象となるテスト活動の範囲、アプローチ、リソース、およびスケジュールを説明するドキュメント。特に、テスト項目、テストする機能、各タスクを実行するテストタスク、テスターの独立性の程度、テスト環境、使用するテスト設計手法とテスト測定手法、およびそれらを選択する理由を特定します。 、および緊急時対応計画を必要とするリスク。これは、テスト計画プロセスの記録です(IEEE829以降)
テスト計画： テスト計画を確立または更新するアクティビティ。
テストポリシー： テストに関する組織の原則、アプローチ、および主な目的を説明する高レベルのドキュメント。
テストポイント分析（TPA）： ファンクションポイント分析に基づく式ベースのテスト推定方法。 (TMap)
テスト手順： テスト手順の仕様を参照してください。
テスト手順の仕様： テストを実行するための一連のアクションを指定するドキュメント。テストスクリプトまたは手動テストスクリプトとも呼ばれます。 (IEEE829以降)
テストプロセス： 基本的なテストプロセスは、計画、仕様、実行、記録、および完了の確認で構成されます。 (BS 7925/2)
テストの再現性： テストが実行されるたびに同じ結果が生成されるかどうかを示すテストの属性。
テスト走行： テストオブジェクトの特定のバージョンでのテストの実行。
テストスクリプト： テスト手順の仕様、特に自動化された仕様を指すために一般的に使用されます。
テスト仕様： テスト設計仕様、テストケース仕様、および/またはテスト手順仕様で構成されるドキュメント。
テスト戦略： 実行するテストレベルと、プログラム（1つ以上のプロジェクト）のそれらのレベル内でのテストを定義する高レベルのドキュメント。
テストスイート： テスト対象のコンポーネントまたはシステムのいくつかのテストケースのセット。1つのテストの事後条件が次のテストの前提条件として使用されることがよくあります。
テスト要約レポート： テスト活動と結果を要約した文書。また、終了基準に対する対応するテスト項目の評価も含まれています。(IEEE829以降)
テストターゲット： 終了基準のセット。
テストツール： 計画と制御、仕様、初期ファイルとデータの構築、テストの実行、テストの分析など、1つ以上のテストアクティビティをサポートするソフトウェア製品。 (TMap) CASTも参照してください。
テストタイプ： 1つ以上の相互に関連する品質属性に関してコンポーネントまたはシステムをテストすることを目的としたテストアクティビティのグループ。テストタイプは、特定のテスト目的、つまり信頼性テスト、ユーザビリティテスト、回帰テストなどに焦点を当てており、1つ以上のテストレベルまたはテストフェーズで実行できます。 【TMap後】
テスト容易性： 変更されたソフトウェアをテストできるようにするソフトウェア製品の機能。 (ISO9126)保守性も参照してください。
テスト容易性レビュー： テスト基準がテストプロセスの入力ドキュメントとして機能するのに十分な品質レベルにあるかどうかを判断するための、テスト基準の詳細なチェック。 【TMap後】
テスト可能な要件： 要件が満たされているかどうかを判断するためのテスト設計（およびその後のテストケース）の確立とテストの実行を可能にする用語で要件が記述されている程度。 (IEEE610以降)
テスター： コンポーネントまたはシステムのテストに携わる技術的に熟練した専門家。
テスト： ソフトウェア製品および関連する作業成果物の計画、準備、評価に関係する、静的および動的のすべてのライフサイクルアクティビティで構成されるプロセス。指定された要件を満たしているかどうかを判断し、目的に適合していることを示し、欠陥を検出します。
テストウェア： ドキュメント、スクリプト、入力、期待される結果、セットアップとクリーンアップの手順、ファイル、データベース、環境、およびで使用される追加のソフトウェアやユーティリティなど、テストの計画、設計、実行に必要なテストプロセス中に生成されたアーティファクトテスト。 (フュースターとグラハムの後)
スレッドテスト： 階層のレベルによるコンポーネントの統合とは対照的に、コンポーネントのプログレッシブ統合が要件のサブセットの実装に従うコンポーネント統合テストのバージョン。
トレーサビリティ： 次のようなドキュメントやソフトウェアの関連アイテムを識別する機能関連するテストの要件。水平トレーサビリティ、垂直トレーサビリティも参照してください。
トップダウンテスト： コンポーネント階層の最上位にあるコンポーネントが最初にテストされ、下位レベルのコンポーネントがスタブによってシミュレートされる統合テストへの増分アプローチ。次に、テストされたコンポーネントを使用して、下位レベルのコンポーネントをテストします。このプロセスは、最低レベルのコンポーネントがテストされるまで繰り返されます。
U
理解しやすさ： ソフトウェアが適切であるかどうか、および特定のタスクと使用条件にどのように使用できるかをユーザーが理解できるようにするソフトウェア製品の機能。 (ISO9126)ユーザビリティも参照してください。
到達不能なコード： 到達できないため実行できないコード。
使いやすさ： 特定の条件下で使用されたときに、理解され、学習され、使用され、ユーザーにとって魅力的なソフトウェアの機能。 (ISO 9126)
ユーザビリティテスト： ソフトウェア製品がどの程度理解され、習得しやすく、操作しやすく、特定の条件下でユーザーにとって魅力的であるかを判断するためのテスト。 (ISO9126以降)
ユースケーステスト： ユーザーシナリオを実行するようにテストケースを設計するブラックボックステスト設計手法。
ユーザーテスト： コンポーネントまたはシステムのユーザビリティを評価するために実際のユーザーが関与するテスト。
V
Vモデル： 要件仕様から保守までのソフトウェア開発ライフサイクル活動を記述するためのフレームワーク。 Vモデルは、テストアクティビティをソフトウェア開発ライフサイクルの各フェーズに統合する方法を示しています。
検証： 検査および特定の使用目的または用途の要件が満たされていることの客観的証拠の提供による確認。 (ISO 9000)
変数： ソフトウェアプログラムが名前で参照することによりアクセスできる、コンピューター内のストレージの要素。
検証： 審査および特定の要件が満たされていることの客観的証拠の提供による確認。 (ISO 9000)
垂直トレーサビリティ： 開発ドキュメントのレイヤーからコンポーネントまでの要件のトレース。
ボリュームテスト： システムが大量のデータにさらされる場所でのテスト。リソース使用率テストも参照してください。
に
ウォークスルー： 情報を収集し、その内容の共通の理解を確立するために、ドキュメントの作成者による段階的なプレゼンテーション。 (フリードマンとWeinberg、IEEE 1028)
ホワイトボックステストの設計手法： コンポーネントまたはシステムの内部構造の分析に基づいてテストケースを導き出し、選択するための文書化された手順。
ホワイトボックステスト： コンポーネントまたはシステムの内部構造の分析に基づくテスト。
ワイドバンドデルファイ： チームメンバーの集合的な知恵を使用して正確な見積もりを行うことを目的とした専門家ベースのテスト見積もり手法。
私に連絡して この用語集にさらに定義を追加したい場合。
参照：http：//www.istqb.org/downloads/glossary-1.0.pdf
推奨読書
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- ソフトウェアテストQAアシスタントジョブ
- ソフトウェアテストコース：どのソフトウェアテスト機関に参加する必要がありますか？
- キャリアとしてのソフトウェアテストの選択
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- QAアウトソーシングガイド：ソフトウェアテストアウトソーシング会社
- いくつかの興味深いソフトウェアテストのインタビューの質問
- ソフトウェアテストコースのフィードバックとレビュー