用語集
TOP >  用語集
JSTQBに準拠したソフトウェアテストに関する用語集ページです。
フリーキーワード検索と五十音索引で簡単に調べることができます。
(出典:ソフトウェアテスト標準用語集 V2.3.J02)
用語検索


検索結果:143件

低位レベルテストケース (low level test case)
入力データと期待結果が具体的(実装レベル)なテストケース。高位レベルのテストケースからの論理演算子は、論理演算子に相当する実際の値に置き換えられる。high level test caseも参照のこと。


TMMi (TMMi)
Test Maturity Model integrationを参照のこと。


定義使用ペア (definition-use pair)
変数の定義と、その変数の以降での使用とを結合したもの。変数の使用の例として、計算(たとえば、乗算)、パス実行の制御(述語的使用)がある。


TQM (TQM)
Total Quality Managementを参照のこと。


TDD (TDD)
test-driven developmentを参照のこと。


D-Dパス (dd-path)
アルゴリズムの二つの判定間のパス。又は他の判定を含まない対応するグラフの二つの判定ノード間のパス。pathも参照のこと。


TPI Next (TPI Next)
テストプロセスを改善するための、継続するビジネス駆動のフレームワーク。効果的で効率的なテストプロセスの主要な要素を定義する。


TPG (TPG)
Test Process Groupを参照のこと。


デイリービルド (daily build)
システム全体を毎日(多くの場合、夜間)、コンパイル、リンクして作成する開発の活動。これにより、最新の変更を反映した一貫性のあるシステム、アプリケーションにいつでもアクセスできるようになる。


デヴィエーションレポート(逸脱報告) (deviation report)
incident reportを参照のこと。


適合テスト (conformance testing)
compliance testingを参照のこと。


テクニカルレビュー (technical review)
どのような技術的アプローチをとるかで意見を一致させることを目的とした、ピアグループによるディスカッション。[Gilb and Graham], [IEEE 1028] peer reviewも参照のこと。


デザインベースドテスト (design-based testing)
テストに対するアプローチ法の一つ。コンポーネントやシステムの構造や詳細設計に基づいたテストケースを設計するもの(たとえば、コンポーネントやシステム間のインターフェースのテスト)。


デシジョンカバレッジ (decision coverage)
テストスイートによって遂行された、判定結果のパーセンテージ。100%のデシジョンカバレッジは、100%のbranch coverage(ブランチカバレッジ)と100%のstatement coverage(ステートメントカバレッジ)の両方を意味する。


デシジョンテスト (decision testing)
ホワイトボックステスト設計技法の一つ。判定を実行するテストケースを設計する。


デシジョンテーブル (decision table)
入力と刺激(原因)、及び、対応する出力と処理(結果)の組み合わせを示す表。テストケースの設計に利用できる。


デシジョンテーブルテスト (decision table testing)
ブラックボックステスト設計技法の一つ。デシジョンテーブルにある入力と刺激(原因)の組み合わせを実行するテストケースを設計する。[Veenendaal04] decision tableも参照のこと。


テスト (test)
一つ以上のテストケースのセット。[IEEE 829]


テスト (testing)
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。


テストアイテム (test item)
テストを実施する個々の要素。通常、一つのテスト対象に対し、多数のテストアイテムがある。test objectも参照のこと。


テストアイテム送付レポート (test item transmittal report)
release noteを参照のこと。


テストアーキテクト (test architect)
(1)テスト組織に対して、テスト組織と他の分野との関連について、ガイダンスと戦略的指針を提供する人。
(2)特定のシステム用にテストを構造化する方法を定義する人。テストツールやテストデータのマネジメントなどのトピックも定義する。


テストアプローチ (test approach)
特定のプロジェクトのためのテスト戦略を実現化したもの。この中には、(テスト実施)プロジェクトのゴールと評価済みリスクに基づいて決めた決定事項、テストプロセスの開始ポイント、適用するテスト設計技法、テスト終了基準、実施するテストタイプを含む。


テストインシデント (test incident)
incidentを参照のこと。


テストインシデントレポート (test incident report)
incident reportを参照のこと。


テストインフラ (test infrastructure)
テスト環境、テストツール、オフィス環境、処理手続きからなるテストの実施に必要な構造的なもの。


テストウェア (testware)
テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、セットアップとクリーンアップの処理手順、ファイル、データベース、環境、その他、テストで使用する付加的なソフトウェアやユーティリティなど。[After Fewster and Graham]


テストオラクル (test oracle)
テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する(ベンチマーク用の)システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。[After Adrion]


テスト改善計画 (test improvement plan)
組織のテストプロセスとテストプロセスの資産について、長所と短所を徹底的に理解し、組織的にテストプロセス改善を達成することをベースとした計画。[After CMMI]


テストカバレッジ (test coverage)
coverageを参照のこと。


テスト環境 (test environment)
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。[After IEEE 610]


テスト完了基準 (test completion criteria)
exit criteriaを参照のこと。


テスト技法 (test technique)
test design techniqueを参照のこと。


テスト駆動開発 (test driven development)
本体のソフトウェアを開発する前に、テストケースを開発(場合によると自動化)するソフトウェア開発手法。


テスト計画 (test plan)
計画されたテスト活動の狙い、アプローチ、リソース、スケジュールを記述するドキュメント。テストアイテム、テストすべきフィーチャ、タスク、各タスク担当者、テスト担当者の独立の度合、テスト環境、用いるテスト設計技法と開始・終了基準、それらの選択の理論的根拠、それに代替計画を必要とするあらゆるリスクを識別する。これはテスト計画プロセスの記録である。[After IEEE 829]


テスト計画作業 (test planning)
テスト計画を策定し、更新すること。


テストケース (test case)
入力値、実行事前条件、期待結果、そして、実行事後条件のセットで、特定のプログラムパスを用いることや特定の要件が満たされていることを検証することのような、特定の目的又はテスト条件のために開発されたもの。[After IEEE 610]


テストケース仕様 (test case specification)
テストアイテム用のテストケースのセット(目的、入力値、テスト実行、期待結果、実行事前条件)を規定するドキュメント。[After IEEE 829] test specificationも参照のこと。


テストケーススイート (test case suite)
test suiteを参照のこと。


テストケース設計技法 (test case design technique)
test design techniqueを参照のこと。


テスト結果 (test outcome)
resultを参照のこと。


テスト結果 (test result)
resultを参照のこと。


テスト結果記録 (test log)
テスト実行の詳細を時系列的に記録したもの。[IEEE 829]


テスト結果記録作業 (test logging)
テスト実行の情報を記録するプロセス。


テスト結果比較 (test comparison)
テスト対象のコンポーネントやシステムの実行結果と期待結果の違いを識別するプロセス。テスト結果比較は、テスト実行中(動的比較)、又は、テスト実行後に実施することができる。


テストコントロール (test control)
監視中に計画から逸脱していることを検出した場合に、テストプロジェクトを軌道修正するための対策を考えたり適用したりするテストマネジメントタスクの一つ。test managementも参照のこと。


テストサイクル (test cycle)
識別可能な単一のテスト対象のリリースに対し、テストプロセスを実行すること。


テスト再現性 (test reproducibility)
テストを実行する度に、同じ結果を出力できるかどうかを示す特性。


テストサマリレポート (test summary report)
テスト活動と結果を要約したドキュメント。テストアイテムがテスト終了基準を満足しているかどうかの評価も含む。[After IEEE 829]


テストジェネレータ (test generator)
test data preparation toolを参照のこと。


テストシチュエーション (test situation)
test conditionを参照のこと。


テスト実行 (test execution)
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。


テスト実行技法 (test execution technique)
実際のテストを、手動又は自動で実行する技法。


テスト実行自動化 (test execution automation)
たとえばキャプチャ/プレイバックツールのようなソフトウェアを使用して、テストの実行、実行結果と期待結果の比較、テスト条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること。


テスト実行スケジュール (test execution schedule)
テスト手順を実行していくための計画。注)テスト実行スケジュールには、テスト手順書の実際に実行する内容とその実行順を記述する。


テスト実行ツール (test execution tool)
テストツールの一種。キャプチャ/プレイバックのような自動化テストスクリプトを使い、他のソフトウェアを実行できる。[Fewster and Graham]


テスト実行フェーズ (test execution phase)
ソフトウェア開発ライフサイクル中で、ソフトウェアプロダクトのコンポーネントを実行し、要件を満たしているかどうか判定する期間。[IEEE 610]


テスト実装 (test implementation)
テストデータを考え出し、テスト手順の開発及び優先度付けを行なうプロセス。テストハーネスの準備や自動テストスクリプト記述を含むこともある。


テスト失敗 (test fail)
failを参照のこと。


テスト自動化 (test automation)
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。


テストシナリオ (test scenario)
test procedure specificationを参照のこと。


テスト使命 (test mission)
組織にとってのテストの目的で、多くの場合、テストポリシーの一部として文書化される。test policyも参照のこと。


テスト終了作業 (test closure)
テストプロセスに含まれるテスト終了作業フェーズの間、経験、テストウェア、事実、数字をまとめるために、データを完了した活動から収集する。テスト終了作業フェーズはテストウェアの仕上げ、保管とテスト評価レポートの準備を含むテストプロセスの評価からなる。test processも参照のこと。


テスト仕様化技法 (test specification technique)
test design techniqueを参照のこと。


テスト条件 (test condition)
コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質特性、構造要素など。


テスト仕様書 (test specification)
テスト設計仕様、テストケース仕様、テスト手順仕様からなるドキュメント。


テスト進捗レポート (test progress report)
定期的に作成するテストの活動と結果をまとめたドキュメント。テスト活動の進捗がベースライン(当初のテスト計画など)に沿っているかどうか報告するため、かつリスクや決定が必要な代替案をマネジメント層へ伝えるために作成する。


テストスイート (test suite)
テスト対象のコンポーネント又はシステムのためのいくつかのテストケースのセット。一つのテストの実行事後条件は、次のテストの実行事前条件としてよく利用される。


テストスクリプト (test script)
一般的にテスト手順仕様を指して用いられる。特に自動化時のスクリプトを指す。


テストスケジュール (test schedule)
活動、タスク、又はテストプロセスのイベントに関して、開始/終了日、時間、依存関係を識別できるリスト。


テストステージ (test stage)
test levelを参照のこと。


テスト成果物 (test deliverable)
テストプロダクト作成者以外に提供する必要のある、あらゆるテスト(作業)プロダクト。deliverableも参照のこと。


テスト成熟度モデル統合 (Test Maturity Model integration (TMMi))
能力成熟度モデル統合(CMMI)と関連させた5段階からなるテストプロセス改善のためのフレームワークであり、効果的なテストプロセスのための重要要素を記述している。


テスト設計 (test design)
(1) test design specificationを参照のこと。
(2) 概略的なテスト目的を具体的なテスト条件とテストケースに変換するプロセス。


テスト設計技法 (test design technique)
テストケースを作成したり選択したりするための技法。


テスト設計仕様 (test design specification)
テストアイテムのテスト条件(カバレッジアイテム)、詳細なテストアプローチ、及び、関連する高位レベルテストケースを記述したドキュメント。[After IEEE 829] test specificationも参照のこと。


テスト設計ツール (test design tool)
テスト入力を生成することでテスト設計を支援するツール。テスト入力の生成は、CASEツールのリポジトリ(たとえば要件マネジメントツール)に格納している仕様、ツールの中に保存してある特定のテスト条件、又はコードから行なわれる。


テストセッション (test session)
テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場でテストケースを考えて実行し、進捗を記録する。 exploratory testingも参照のこと。


テストセット (test set)
test suiteを参照のこと。


テスト戦略 (test strategy)
組織や(一つ若しくは複数プロジェクトの)プログラムで実施するテストレベルと各テストレベルでのテスト内容を高位レベルで説明したもの。


テスト対象 (test object)
テストすべきコンポーネント又はシステム。test itemも参照のこと。


テスト対象システム (system under test)
test objectを参照のこと。


テストタイプ (test type)
コンポーネント又はシステムをテストするためのテスト活動をまとめたものであり、たとえば機能テスト、使用性テスト、回帰テストなどのように特定のテスト目的に焦点を当てている。テストタイプは一つ又は複数のテストレベル又はテストフェーズで行なわれる。[After TMap]


テストターゲット (test target)
テスト終了基準のセット。


テスト担当者 (tester)
コンポーネントやシステムのテストを実施する熟練した専門家。


テストチャータ (test charter)
テスト目的を明記したもの。テスト実施法のアイデアを含む場合もある。探索的テストにて使用する。exploratory testingも参照のこと。


テストツール (test tool)
一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。 [TMap] CASTも参照のこと。


テストディレクタ (test director)
テストマネージャをマネジメントする上級マネージャ。test managerも参照のこと。


テスト手順 (test procedure)
test procedure specificationを参照のこと。


テスト手順仕様 (test procedure specification)
テストの実行のために、一連の手順を定めたドキュメント。テストスクリプト、又は、手動テストスクリプトとしても知られる。[After IEEE 829] test specificationも参照のこと。


テストデータ (test data)
テスト実行前に実在する(たとえば、データベースの中にある)データであり、テスト対象のコンポーネントやシステムに影響を与えたり、影響を受けたりするもの。


テストデータ準備ツール (test data preparation tool)
テストに使うデータを選択(データベース内の実データなど)、又は、作成、生成、操作、編集をするためのツール。


テストデータマネジメント (test data management)
テストデータ要件の分析、テストデータ構造の設計、テストデータの作成と保守を行なうプロセス。


テストドライバ (test driver)
driverを参照のこと。


テスト入力 (test input)
テスト実行中にテスト対象が外部ソースから受け取ったデータ。外部ソースは、ハードウェア、ソフトウェア、人の場合がある。


テストの独立性 (independence of testing)
責任を分離すること。これにより、客観的なテストを促進できる。[After DO-178b]


テストパス (test pass)
passを参照のこと。


テストハーネス (test harness)
テスト実行に必要なスタブやドライバからなるテスト環境。


テストパフォーマンスインジケータ (test performance indicator)
テストの開発をよい方向へ導きコントロールするために利用する有効性と効率の高位レベルなメトリック。たとえば、欠陥検出率(DDP)。


テスト比較ツール (test comparator)
テスト実行時の実行結果と期待結果との比較を自動的に実施するテストツール。


テスト評価レポート (test evaluation report)
全てのテスト活動と結果を要約した、テストプロセスの最後にまとめるドキュメント。テストプロセスの評価や、学んだ教訓を含むこともある。


テストフェーズ (test phase)
テスト活動をプロジェクト中で管理(マネジメント)しやすいフェーズにまとめたセット。たとえば、あるテストレベルの実行活動。[After Gerrard]


テストプロセス (test process)
基本的なテストプロセスは、テストの計画とコントロール、テストの分析と設計、テストの実装と実行、終了基準の評価と報告、テスト終了作業によって構成される。


テストプロセス改善マニフェスト (test process improvement manifesto)
アジャイルマニフェストにより表明された声明で、テストプロセスを改善するための価値を定義している。ここでいう価値とは以下のようなものである。
・プロセスの詳細化よりも柔軟性
・テンプレート(ひな形)よりもベストプラクティス
・プロセス志向よりも展開志向
・品質保証(部門)よりもピアレビュー
・モデル駆動よりもビジネス駆動
[Veenendaal08]


テストプロセスグループ (Test Process Group)
(テスト)専門家の集団。組織が使用するテストプロセスの定義、改善や保守を促進する。 [After CMMI]


テストプロセス担当 (test process improver)
テスト改善計画に基づきテストプロセス改善を実行する人。


テスト分析 (test analysis)
テストベースとテスト目的の定義を分析するプロセス。


テストベース (test basis)
コンポーネント要件やシステム要件を推測できる全てのドキュメント。これらのドキュメントがテストケースのベースとなる。公式な改訂手順を経ないとドキュメントの改訂ができない場合、そのテストベースを「凍結テストベース」と呼ぶ。[After TMap]


テストベッド (test bed)
test environmentを参照のこと。


テストポイント分析 (Test Point Analysis (TPA))
ファンクションポイント分析に基づき、数式でテストの必要リソースを見積る手法。[TMap]


テストポリシー (test policy)
組織にとってのテストに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。


テストマネジメント (test management)
テスト活動の計画、見積り、監視、コントロール。主としてテストマネージャによって実施される。


テストマネジメントツール (test management tool)
テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。


テストマネージャ (test manager)
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。


テスト見積り (test estimation)
テストのさまざまな局面に紐付けられた概算結果(たとえば、工数(effort spent), 完了日(completion date),コスト(costs involved), テストケース数(number of test cases), など)。ただし、入力情報が不完全、又は不確か、若しくは余計な情報を含んでいても実施できる。


テスト目的 (test objective)
テストを設計、実行する理由や目的。


テストモニタリング (test monitoring)
テストプロジェクトの状態の周期的なチェックに関連した活動を扱うテスト管理タスク。実際の活動と計画した活動とを比較した報告が準備される。test managementも参照のこと。


テスト容易化要件 (testable requirement)
要件を満たしているかどうかを判断できるテストの設計(後に続くテストケースの作成を含む)と実行を可能にする観点から記述されている要件。[After IEEE 610]


テスト要件 (test requirement)
test conditionを参照のこと。


テストラン (test run)
テスト対象の特定のバージョンでテストを実行すること。


テストランログ (test run log)
test logを参照のこと。


テストリグ (test rig)
test environmentを参照のこと。


テストリーダ (test leader)
test managerを参照のこと。


テストレコーディング〔テスト結果記録作業〕 (test recording)
test loggingを参照のこと。


テストレコード〔テスト結果記録〕 (test record)
test logを参照のこと。


テストレベル (test level)
系統的にまとめ、管理していくテストの活動のグループ。各テストレベルはプロジェクトの特定の責務と対応付けができる。テストレベルの例には、コンポーネントテスト、統合テスト、システムテスト、受け入れテストがある。[After TMap]


テストレポート (test report)
test summary report, test progress reportを参照のこと。


テストレポート作業 (test reporting)
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。test processも参照のこと。


データ完全性テスト (data integrity testing)
database integrity testingを参照のこと。


データ駆動テスト (data-driven testing)
スクリプト作成技術の一つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、一つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。[Fewster and Graham] keyword-driven testingも参照のこと。


データ定義 (data definition)
変数に値を割り当てる実行ステートメント。


データ品質 (data quality)
データの属性の一つ。事前に定義した基準(たとえば、ビジネス期待度、データ完全性の要件、データ一貫性など)に関する正確さを示す。


データフロー (data flow)
データオブジェクトの順序と、起こり得る状態の変化を抽象的に表現したもの。オブジェクトの状態は、発生、使用、消滅のいずれかになる。[Beizer]


データフロー解析 (data flow analysis)
変数の「定義と使用」に基づく静的解析の一つ。


データフローカバレッジ (data flow coverage)
変数の「定義と使用」を1組とし、テストスイートによってどれだけ遂行されたかをパーセンテージで表したもの。


データフローテスト (data flow testing)
ホワイトボックステスト設計技法の一つ。変数の「定義と使用」の組を実行するようにテストケースを設計する。


データベース完全性テスト (database integrity testing)
データ(ベース)をアクセス・管理する方法や手順をテストすること。アクセス方法、手順、データルールが期待通りに動作すること、データベースへのアクセス中にデータが破壊されたり、期待に反して削除、更新、生成されたりしないことを確認する。


手続きテスト (procedure testing)
コンポーネントやシステムが、新規、若しくは現行利用者のビジネス手順、又は運用手順と共に運用できることの確認を目的にしたテスト。


デッドコード (dead code)
unreachable codeを参照のこと。


デバッガ (debugger)
debugging toolを参照のこと。


デバッグ (debugging)
ソフトウェアの故障の原因を見つけて、分析して、取り除くプロセス。


デバッグツール (debugging tool)
故障を再現して、プログラムの状態を調査し、対応した欠陥を見つけるために、プログラマが使用するツール。デバッガは、プログラムの変数をセットし検査するために、どのプログラムステートメントの場所でもプログラムを停止したり、プログラムを1ステップずつ実行したりできる。


デミングサイクル (Deming cycle)
反復的な四つのステップからなる問題解決のプロセス(計画-実施-評価-改善)。特にプロセス改善において用いられる。[After Deming]