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


検索結果:56件

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


dashboard (ダッシュボード)
組織や活動の業務成績の動的な測定結果を、メタファによって表されたメトリクスを用いて表現したもの。ここでいうメタファとは、自動車のダッシュボードに似せた、目にみえるダイヤルやカウンターなどである。これによって、出来事や活動の結果が容易に把握でき、業務上の目標と関連付けることができる。corporate dashboard, scorecardも参照のこと。


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


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


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


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


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


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


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


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


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


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


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


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


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


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


decision (判定)
制御フローとして、二つ以上の選択可能なルートがあるプログラムポイント。分岐を切り分けるため、二つ以上のリンクを持ったノード。


decision condition coverage (判定条件カバレッジ)
テストスイートが遂行した条件と判定のパーセンテージ。100%の判定条件カバレッジは、100%の条件カバレッジと100%のデシジョンカバレッジを意味する。


decision condition testing (判定条件テスト)
ホワイトボックステスト設計技法の一つ。条件と判定の結果を実行するようテストケースを設計する。


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


decision outcome (判定結果)
判定の結果(これにより、どの分岐を選択するかが決まる)。


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


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


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


defect (欠陥)
コンポーネント又はシステムに要求された機能が実現できない原因となる、コンポーネント又はシステムに含まれる不備。たとえば、不正なステートメント又はデータ定義。実行中に欠陥に遭遇した場合、コンポーネント又はシステムの故障を引き起こす。


defect category (欠陥カテゴリ)
defect typeを参照のこと。


defect density (欠陥密度)
コンポーネント又はシステムの中で識別された欠陥の数をコンポーネント又はシステムのサイズで割った値。(サイズを表す標準的な尺度には、コード行数、クラス数、又はファンクションポイント数がある)


Defect Detection Percentage (DDP) (欠陥検出率)
あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。escaped defectsも参照のこと。


defect management (欠陥マネジメント)
認識、調査、行動、及び、欠陥の処置の手順。欠陥の記録、分類、及び、影響の識別を含む。[After IEEE 1044]


defect management committee (欠陥マネジメント委員会)
クロスファンクショナルなステークホルダのチーム。報告された欠陥の初期検出から最終的な解決(欠陥除去、欠陥除去の延期、報告取り消し)に至るまでを管理する。構成管理委員会と同じチームとなることがある。configuration control boardも参照のこと。


defect management tool (欠陥マネジメントツール)
欠陥及び変更の記録と状態追跡を容易にするツール。多くの場合、欠陥の割り振り、訂正、再テストを追跡、コントロールするために、ワークフロー指向の機能を搭載している他に、レポート機能も持っている。incident management toolも参照のこと。


defect masking (欠陥マスキング)
一つの欠陥が他の欠陥の検出を妨げる現象。[After IEEE 610]


defect report (欠陥レポート)
コンポーネント又はシステムに要求された機能が実現できない原因となる、コンポーネント又はシステムに含まれる不備を報告するドキュメント。[After IEEE 829]


defect taxonomy (欠陥分類法)
欠陥の分類を再現しやすくするように設計された(階層的)カテゴリの体系。


defect tracking tool (欠陥追跡ツール)
defect management toolを参照のこと。


defect triage committee (欠陥選別委員会)
defect management committeeを参照のこと。


defect type (欠陥のタイプ)
欠陥を分類する要素。欠陥の分類は、次を含むさまざまな検討事項に基づいて識別できる。(ただし、これだけではない)
・欠陥が作り込まれたフェーズ又は開発活動。たとえば、仕様エラー又はコーディングエラー。
・欠陥の特性。たとえば、「off-by-one」欠陥。
・不正確性。たとえば、不正確な関係演算子、プログラム言語の構文エラー、無効な仮定。
・性能問題。たとえば、過剰な実行時間、不十分な可用性。


defect-based technique (欠陥ベースの技法)
defect-based test design techniqueを参照のこと。


defect-based test design technique (欠陥ベースのテスト設計技法)
一つ以上の欠陥のタイプをターゲットにしたテストケースを導いたり、選び出す技法。テストケースは特定の欠陥のタイプから開発していく。defect taxonomyも参照のこと。


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


deliverable (成果物)
(業務用)プロダクトの開発担当者以外に提供する必要のある、あらゆる(業務用)プロダクト。


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


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


desk checking (机上チェック)
手動の実行シミュレーションによるソフトウェア又は仕様のテスト。static testingも参照のこと。


development testing (開発テスト)
コンポーネントやシステムの実装中に実施する公式又は非公式のテスト。通常は、開発担当者の製品開発環境で実行する。[After IEEE 610]


deviation (逸脱)
incidentを参照のこと。


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


dirty testing (ダーティテスト)
negative testingを参照のこと。


documentation testing (ドキュメンテーションテスト)
ユーザガイドやインストールガイドのようなドキュメントの品質をテストすること。


domain (ドメイン)
データのセット。ここから、有効な入力値や出力値を選ぶ。


domain analysis (ドメイン分析)
ブラックボックステスト設計技法の一つ。複数の変数を同時にテストできる、又はテストする必要がある場合に効率的かつ効果的なテストケースを識別するのに使用される。同値分割法と境界値分析に基づいて構築され、これらを汎用化する。boundary value analysis, equivalence partitioningも参照のこと。


driver (ドライバ)
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。[After TMap]


dynamic analysis (動的解析)
実行中のシステムやコンポーネントの振る舞い(たとえば、メモリの使用効率、CPUの使用状況)を評価するプロセス。[After IEEE 610]


dynamic analysis tool (動的解析ツール)
ソフトウェアコードの状態に関する実行時(ランタイム)情報を提供するツール。未割り当てのポインタの識別、ポインタ計算のチェック、メモリの割り当て・使用・解放のチェック、メモリリークの検出で使うことが多い。


dynamic comparison (動的比較)
(たとえば、テスト実行ツールを使用し)ソフトウェアの実行中に、実行結果と期待結果とを比較すること。


dynamic testing (動的テスト)
コンポーネントやシステムのソフトウェアを実行させて確認するテスト。