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


検索結果:33件

回帰回避テスト (regression-averse testing)
ソフトウェアが前の状態に戻ることのリスクをマネジメントするためにさまざまな技法を使用するテスト。たとえば、再利用可能なテストウェアの設計や一つ以上のテストレベルでのテストの大幅な自動化などがある。


回帰テスト (regression testing)
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わる度に実施する。


開始 (IDEAL(initiating (IDEAL)))
IDEALモデルの1フェーズであり、改善活動が成功するための基盤を具体化する。開始フェーズは、活動背景の確認、支援体制及び活動体制の構築によって構成される。IDEALも参照のこと。JSTQB訳注)IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。


開始基準 (entry criteria)
定義したタスク(たとえば、テストフェーズ)の開始を許可するための基準となる一般・特定の条件のセット。この目的は、開始基準を満足させるための労力に比べ、はるかに多くの(無駄な)労力を投入しないとタスクが始まらない状況を防ぐことである。[Gilb and Graham]


開始点 (entry point)
プロセスの開始を意図した実行ステートメント、若しくはポイントとして定義したプロセスステップ。


解析性 (analyzability)
ソフトウェアにある欠陥の診断又は故障原因の追及、及びソフトウェアの修正箇所の識別を行なうためのソフトウェア製品の能力。[ISO/IEC 9126] maintainabilityを参照のこと。 JSTQB訳注)JIS X 0129-1:2003より引用


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


回復性 (recoverability)
故障時に、指定された達成水準を再確立し、直接に影響を受けたデータを回復するソフトウェア製品の能力。[ISO/IEC 9126] reliabilityも参照のこと。JSTQB訳注)JIS X 0129-1:2003より引用


回復性テスト (recoverability testing)
ソフトウェア製品の回復性を判定するテストのプロセス。reliability testingも参照のこと。


回復テスト (recovery testing)
recoverability testingを参照のこと。


改良条件判定カバレッジ (MC/DC(modified condition decision coverage))
判定結果に対して独立に影響する全単一条件結果のうち、テストスイートが遂行した条件結果のパーセンテージ。100%の改良条件判定カバレッジ(MC/DC)は、100%の判定条件カバレッジを意味する。


改良条件判定テスト (modified condition decision testing)
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。


改良複合条件カバレッジ (modified multiple condition coverage)
modified condition decision coverageを参照のこと。


改良複合条件テスト (modified multiple condition testing)
modified condition decision testingを参照のこと。


学習 (IDEAL(learning (IDEAL)))
IDEALモデルの1フェーズであり、経験から学習し、将来の新しいプロセスと技術を適用するために自らの能力を向上させる。学習フェーズは、分析、妥当性確認、及び以降の活動提案によって構成される。IDEALも参照のこと。JSTQB訳注)IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。


拡張性 (scalability)
増加する負荷に応じてソフトウェア製品をアップグレードできる能力。[After Gerrard]


拡張性テスト (scalability testing)
ソフトウェア製品の拡張性を判定するテスト。


確認テスト (confirmation testing)
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。


確立 (IDEAL(establishing (IDEAL)))
IDEALモデルの1フェーズであり、組織が、計画された目標にどのように到達するかを特定する。確立フェーズは、優先順位の決定、アプローチの開発、行動計画の活動によって構成される。IDEALも参照のこと。JSTQB訳注)IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。


カスタムソフトウェア (custom software)
bespoke softwareを参照のこと。


カスタムツール (custom tool)
特定のユーザ又は顧客に特別に開発されたソフトウェアツール。


カバレッジ (coverage)
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。


カバレッジアイテム (coverage item)
テストカバレッジの基礎となる実体や属性。たとえば、同値分割やステートメント。


カバレッジ測定ツール (coverage measurement tool)
coverage toolを参照のこと。


カバレッジツール (coverage tool)
テストスイートが遂行したステートメントや分岐等の構成要素の客観的な測定結果を提供するツール。


カバレッジ分析 (coverage analysis)
特定のカバレッジアイテムのうち、どれだけ実行したかをテスト実行中に計測すること。追加テストが必要か、必要ならどのテストを追加するかの判定用に事前に定めた判定基準に照らして実施する。


可用性 (availability)
使用する際にコンポーネントやシステムが稼動し、利用可能な度合。パーセンテージで表すことが多い。[IEEE 610]


環境適応性 (adaptability)
ソフトウェアにあらかじめ用意された以外の付加的な作業又は手段なしに、指定された異なる環境にソフトウェアを適応させるためのソフトウェア製品の能力。 [ISO/IEC 9126] portabilityを参照のこと。 JSTQB訳注)JIS X 0129-1:2003より引用


頑健性〔堅牢性〕 (robustness)
不正な入力や過負荷の環境条件の中でも、コンポーネント又はシステムが正しく機能できる度合。[IEEE 610] error tolerance, fault toleranceも参照のこと。


監査 (audit)
標準、ガイドライン、仕様、客観的な基準に基づいた手続きに遵守することを確認し、以下の(1)~(3)を規定したドキュメント等を含む、ソフトウェアプロダクトや開発プロセスの独立した評価。
(1)開発するプロダクトの形式や内容
(2)プロダクトの開発プロセス
(3)標準やガイドライン遵守の測定方法 [IEEE 1028]


監査証跡 (audit trail)
プロセスの出力をスタート地点とし、プロセスを遡って、プロセスへの元の入力(たとえば、データ)までたどることができるパス。これにより、欠陥分析が容易になり、プロセス監査を実施できる。[After TMap]


完全テスト (complete testing)
exhaustive testingを参照のこと。


管理図 (control chart)
統計に基づくプロセス管理ツール。プロセスを監視し、統計的に管理されているかどうかを確認する。プロセスの平均値と、上方管理限界及び下方管理限界(最大値及び最小値)を図示する。