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


検索結果:61件

ファンクションポイント法 (Function Point Analysis (FPA)
情報システムの機能規模を測定する手法。FPAでの測定は、対象技術に依存しない。生産性測定、必要リソースの見積り、プロジェクトコントロールのベースとして利用できる。


V字モデル (V-model)
要求仕様からメンテナンスまでのソフトウェア開発ライフサイクル活動を表現したフレームワーク。V字モデルは、ソフトウェア開発ライフサイクルの各フェーズに、各テスト活動がどのように対応しているかどうかを示している。


フィーチャ (feature)
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの特性となる機能群(たとえば、信頼性、使用性、設計上の制約など)。[After IEEE 1008]


フィーチャ駆動開発 (feature-driven development)
クライアントにとっての機能性価値(フィーチャ)の観点で駆動される、イテレーティブかつインクリメンタルなソフトウェア開発プロセス。フィーチャ駆動開発は、ほとんどの場合、アジャイルソフトウェア開発で使用する。agile software developmentも参照のこと。


フィッシュボーンダイアグラム (fishbone diagram)
cause-effect diagramを参照のこと。


フィールドテスト (field testing)
beta testingを参照のこと。


フェイルオーバーテスト (failover testing)
管理されている環境で、故障モードをシミュレーションするか、実際に故障を発生させて行なうテスト。故障の後、フェイルオーバー機能をテストし、データの損失及び破損が発生しておらず、合意されている全てのサービスレベル(機能の可用性、応答時間など)を維持していることを確認する。recoverability testingも参照のこと。


フェーズテスト計画 (phase test plan)
主に、一つのテストフェーズを扱うテスト計画。test planも参照のこと。


フェーズ内阻止 (phase containment)
ソフトウェアライフサイクルの同一フェーズ内における、混入した欠陥数に対する除去された欠陥数のパーセンテージ。


フォールト (fault)
defectを参照のこと。


フォールトインジェクション (fault injection)
システムが欠陥を検出し、欠陥から復旧できることを確認する目的で、意図的に欠陥をシステムに追加するプロセス。フィールドで発生する可能性のある故障を模倣することを目的とする。fault toleranceも参照のこと。


フォールト検出率 (Fault Detection Percentage (FDP))
Defect Detection Percentage(DDP)を参照のこと。


フォールト攻撃 (fault attack)
attackを参照のこと。


フォールトシーディング (fault seeding)
残存欠陥数の見積りや検出、除去の割合を監視する目的でシステムやコンポーネントに欠陥を意図的に加えるプロセス。フォールトシーディングは、通常、開発(プレリリース)テストの一環として実施され、全てのテストレベル(コンポーネント、統合、又はシステム)で実行できる。[After IEEE 610]


フォールトシーディングツール (fault seeding tool)
システムやコンポーネントにフォールトを埋め込む(つまり、意図的に挿入する)ためのツール。


フォールトツリー解析 (Fault Tree Analysis (FTA))
フォールト(欠陥)の原因分析で使用する方法。故障やヒューマンエラーと、(特定の顕在化したフォールトと結びつく)外部イベントとの関係を論理的に視覚化したモデルにする技法。


フォールトマスキング (fault masking)
defect maskingを参照のこと。


フォールト密度 (fault density)
defect densityを参照のこと。


不可分条件 (atomic condition)
これ以上分解できない条件、すなわち、論理演算子(AND、OR、XOR)で結合されている 2 つ以上の単一条件を含まない条件。


複合条件 (compound condition)
論理演算子(AND、OR、又はXOR)によって二つ又はそれ以上の単一条件が結合されたもの。たとえば、「A>B AND C>1000」。


複合条件 (multiple condition)
compound conditionを参照のこと。


複合条件カバレッジ (multiple condition coverage)
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。


複合条件テスト (multiple condition testing)
ホワイトボックステスト設計技法の一つ。(一つのステートメント中の)単一条件結果の組み合わせを実行するテストケースを設計する技法。


複雑度 (complexity)
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。cyclomatic complexityも参照のこと。


不正 (anomaly)
要求仕様、設計ドキュメント、ユーザドキュメント、標準など、又は知見、経験から逸脱するあらゆる状態。レビュー、テスト、分析、コンパイルをする中で検出できるが、それだけにとどまらず、ソフトウェアプロダクトや該当するドキュメントを利用するときに検出できることもある。[IEEE 1044] bug, defect, deviation, error, fault, incident, problemも参照のこと。


不適合 (non-conformity)
特定の要求を満足しないこと。[ISO 9000]


ブラックボックス技法 (black box technique)
black box test design techniqueを参照のこと。


ブラックボックステスト (black box testing)
コンポーネント又はシステムの内部構造を参照せずに行なう、機能的又は非機能的なテスト。


ブラックボックステスト設計技法 (black box test design technique)
コンポーネントやシステムの内部構造を参照することなく、機能仕様や非機能仕様の分析に基づきテストケースを設計、選択する技法。


ブランチ (branch)
基本ブロックの一つ。二つ以上の実行可能なパスから、一つのパスを実行するために、プログラム構造に基づき選択された基本ブロック。たとえば、case、jump、go to、if-then-else。


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


ブランチコンデション (branch condition)
分岐条件。 conditionを参照のこと。


ブランチコンデションカバレッジ (branch condition coverage)
condition coverageを参照のこと。


ブランチコンデション組み合わせカバレッジ (branch condition combination coverage)
multiple condition coverageを参照のこと。


ブランチコンデション組み合わせテスト (branch condition combination testing)
multiple condition testingを参照のこと。


ブランチテスト (branch testing)
ホワイトボックステスト設計技法の一つ。分岐を実行するためのテストケースを設計する。


プランニングポーカー (planning poker)
合意に基づく見積り技法の一つ。アジャイルソフトウェア開発で、ユーザストーリーの作業量又は相対規模を見積るのに使用される。ワイドバンドデルファイ方法の一つの種類で、チームが見積る単位を表す一組のカードを使用する。agile software development, Wide Band Delphiも参照のこと。


振り返りミーティング (retrospective meeting)
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。


PRISMA (PRISMA (Product RISk MAnagement))
リスクベースドテストの体系的なアプローチ。プロダクトリスクの識別と分析を行ない、発生可能性及び影響に基づくプロダクトリスクマトリクスを作成する。


振る舞い (behavior)
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。


プレディケート (predicate)
真偽を評価できるステートメント。後続の判定ロジックの制御フローを決定する場合がある。decisionも参照のこと。


プログラムインスツルメンタ (program instrumenter)
instrumenterを参照のこと。


プログラムテスト (program testing)
component testingを参照のこと。


プロジェクト (project)
開始日及び終了日を持ち、調整され、管理された一連の活動からなり、時間、コスト及び資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。 [ISO 9000] JSTQB訳注)JIS Q 9000:2006より引用


プロジェクト後ミーティング (post-project meeting)
retrospective meetingを参照のこと。


プロジェクトテスト計画 (project test plan)
master test planを参照のこと。


プロジェクトの振り返り (project retrospective)
次のプロジェクト又は次のプロジェクトフェーズを改善するために、教訓を学び、具体的なアクションプランを作成する構造化された方法。


プロジェクトリスク (project risk)
(テスト)プロジェクトのマネジメントとコントロールに関係するリスク。たとえば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。riskも参照のこと。


プロセス (process)
相互関係のある活動のセット。入力を出力に変換する。[ISO/IEC 12207]


プロセスアセスメント (process assessment)
参照モデルを用いた、組織におけるソフトウェアプロセスの統制度合の評価。 [After ISO/IEC 15504]


プロセス改善 (process improvement)
組織のプロセスの成熟度とパフォーマンスを改善するために設計した活動プログラムとその結果。[CMMI]


プロセスサイクルテスト (process cycle test)
ブラックボックステスト設計技法の一つ。ビジネスの手順やプロセスを実行するためのテストケースを設計する。 [TMap] procedure testingも参照のこと。


プロセス参照モデル (process reference model)
プロセスモデルの一つ。ベストプラクティスの汎用的に使用できる部分と、事前に定義された手順を順に実行してプロセスを改善する方法とを提供する。


プロセス準拠性テスト (process-compliant testing)
定義されているプロセスに従って実行するテスト。プロセスは、たとえば、標準化委員会など外部の団体によって定義される。standard-compliant testingも参照のこと


プロセスモデル (process model)
共通の性質を持つプロセスによって全体的に統一されたモデルで表したフレームワーク。たとえば、テスト改善モデル。


プロダクトベースド品質 (product-based quality)
品質に対する考え方の一つ。品質は明確に定義された品質の属性のセットに基づく、というもの。これらの属性は、客観的かつ定量的な方法で測定する必要がある。同じ種類のプロダクト品質の違いは、特定の品質特性を実装した方法に由来する。[After Garvin] manufacturing-based quality, quality attribute, transcendent-based quality, user-based quality, value-based qualityも参照のこと。


プロダクトリスク (product risk)
テスト対象に直接関係するリスク。riskも参照のこと。


プロダクトリスクマネジメント (Product RISk Management)
PRISMAを参照のこと。


ブロックドテストケース (blocked test case)
事前条件を満足できないため、実行不能のテストケース。


プローブ効果 (probe effect)
性能テストツールやモニタなどでコンポーネントやシステムを測定する場合、測定ツールによって埋め込まれる測定のためのコード(インスツルメント)がコンポーネントやシステムに及ぼす影響。たとえば、性能テストツールを使うことによって、性能は若干悪化する。


分析的テスト (analytical testing)
たとえば、製品リスク又は要件の体系的な分析に基づくテスト。