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


検索結果:53件

高位レベルテストケース (high level test case)
具体的な(実行レベルの)入力値や予測結果を使わないテストケース。論理演算子は使用するが、値のインスタンスは未定義や使用不可であるといった状態にある。low level test caseも参照のこと。


合格/失敗基準 (pass/fail criteria)
テストアイテム(機能)やフィーチャが、テストに合格したか失敗したかを判定するための判定規則。[IEEE 829]


攻撃 (attack)
品質を評価するために、直接的に焦点を定めて行なう試み。特定の故障が発生するような強制を試みることによって、テスト対象の品質、特に信頼性を評価する。negative testingも参照のこと。


攻撃ベースドテスト (attack-based testing)
経験ベースのテスト技法で、ソフトウェア攻撃を使用して、故障、特にセキュリティ関連の故障を引き起こさせる。attackも参照のこと。


公式レビュー (formal review)
文書化された手順と要件に特徴付けられるレビュー。たとえば、インスペクション。


工場受け入れテスト (factory acceptance testing)
コンポーネント又はシステムが要件を満たすかどうかを確認するために、製品開発の場所で供給者組織の従業員により実行される受け入れテスト。要件には、ソフトウェア要件だけでなく、ハードウェア要件も含む。alpha testingも参照のこと。


構成 (configuration)
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。


構成アイテム (configuration item)
ハードウェア、ソフトウェア、又は、両方の集合体。構成管理の対象であり、構成管理プロセスでは、一つの実体として扱う。[IEEE 610]


構成監査 (configuration auditing)
構成アイテムのライブラリの内容をチェックする役割。たとえば、標準適合性をチェックするなど。[IEEE 610]


構成管理 (configuration management)
技術的かつ管理的な指示と監視を適用する規範。この規範の目的は
・構成アイテムの特性を機能的、物理的に識別・文書化すること
・特性に対する変更をコントロールすること
・処理の変更と実装の状況を記録し、報告すること
・特定の要求への整合を実証すること
である。[IEEE 610]


構成管理ツール (configuration management tool)
構成アイテムの識別やコントロール(変更やバージョンの状態や構成アイテムをまとめたベースラインのリリース)を支援するツール。


構成コントロール (configuration control)
構成管理の一つの要素。構成アイテムを公式に定義後、構成アイテムに対する変更を、評価、調整、承認・否認、実施すること。[IEEE 610]


構成コントロール委員会 (configuration control board (CCB))
構成アイテムに対する変更提案を評価、承認・否認することに責任を持つグループ。承認した変更の実施にも責任を負う。[IEEE 610]


構成識別 (configuration identification)
構成管理の一つの要素。システムの構成アイテムを選択し、構成アイテムの機能的、物理的特性を技術ドキュメントに記録する。[IEEE 610]


構成テスト (configuration testing)
portability testingを参照のこと。


構造化ウォークスルー (structured walkthrough)
walkthroughを参照のこと。


構造カバレッジ (structural coverage)
コンポーネント又はシステムの内部構造に基づいたカバレッジの測定値。


構造テスト (structural testing)
white-box testingを参照のこと。


構造テスト設計技法 (structural test design technique)
white-box test design techniqueを参照のこと。


構造ベースドテスト (structure-based testing)
white-box testingを参照のこと。


構造ベースの技法 (structure-based technique)
white-box test design techniqueを参照のこと。


構造ベースのテスト設計技法 (structure-based test design technique)
white-box test design techniqueを参照のこと。


行動 (IDEAL) (acting (IDEAL))
IDEALモデルの1フェーズであり、改善を展開し、実践し、組織全体に導入する。行動フェーズでは、解決策の創造、試行/試験的導入、改良、実行の活動によって構成される。IDEALも参照のこと。JSTQB訳注)IDEALのフェーズ名称は「CMMI V1.2 モデル - 開発のための - 公式日本語翻訳版」の定義を使用。


合目的性 (suitability)
指定された作業及び利用者の具体目標に対して適切な機能の集合を提供するソフトウェア製品の能力。[ISO/IEC 9126] functionalityも参照のこと。 JSTQB訳注)JIS X 0129-1:2003より引用


合目的性テスト (suitability testing)
ソフトウェア製品の合目的性を判定するためのテストのプロセス。


効率性 (efficiency)
(1)明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力。[ISO/IEC 9126]
  JSTQB訳注)JISX0129-1:2003より引用"
(2)使用するリソースの量に対比して、意図した結果を生成するプロセスの能力。


効率性テスト (efficiency testing)
ソフトウェア製品の効率を測定するテストのプロセス。


交流分析 (transactional analysis)
人と人の心の内の交流分析。交流は刺激とその反応により定義される。交流は、人と人の間と、人の心の中にある自我の状態(個性の部分)の間に発生する。


互換性テスト (compatibility testing)
interoperability testingを参照のこと。


故障 (failure)
コンポーネントやシステムが、期待した機能、サービス、結果から逸脱すること。[After Fenton]


故障モード (failure mode)
物理的又は機能的な故障の兆候。たとえば、故障モードのシステムは、遅い運用、間違った出力、又は実行の完全な打ち切りなどで特徴付けられる。[IEEE 610]


故障モード影響解析 (Failure Mode and Effect Analysis (FMEA))
リスクの識別と分析(故障モードの識別と、発生防止策の試み)を行なう体系的なアプローチ。Failure Mode, Effects, and Criticality Analysis (FMECA)も参照のこと。


故障モード影響・致命度解析 (Failure Mode, Effects, and Criticality Analysis (FMECA))
基本的なFMEAに加え、致命度解析を含んで拡張したもの。結果の重要性に対して、故障モードの発生確率を図で表現したものを使用する。これにより、他と比べて高い発生確率と、結果の重要性を持った故障モードが強調されるため、最大の価値を生み出す方向に向かう改善活動ができる。Failure Mode and Effect Analysis (FMEA)も参照のこと。


故障率 (failure rate)
測定単位に発生したあるカテゴリの故障数の率。たとえば、単位時間あたりの故障数、トランザクション数あたりの故障数、コンピュータの運用回数あたりの故障数。[IEEE 610]


COTS (COTS)
Commercial Off-The-Shelf software(市販ソフトウェア)の頭字語。off-the-shelf softwareを参照のこと。


コード (code)
プログラミング言語、又は機械語、コンパイラやその他の変換装置によってアウトプットされたコンピュータ命令とデータ定義を表現したもの。[IEEE 610]


コードアナライザ (code analyzer)
static code analyzerを参照のこと。


コードカバレッジ (code coverage)
テストスイートが、ソフトウェアのどの部分を実行(カバー)し、どの部分が未実行かを判定する分析手法。たとえば、ステートメントカバレッジ、デシジョンカバレッジ、条件カバレッジ。


コードベースドテスト (code-based testing)
white-box testingを参照のこと。


コーポレートダッシュボード (corporate dashboard)
企業業績の状況に関するダッシュボードスタイルの表現。balanced scorecard, dashboardも参照のこと。


ゴールクエスチョンメトリック (Goal Question Metric)
三つのレベル、すなわち、概念的なレベル(ゴール)、運用上のレベル(クエスチョン)、定量的なレベル(メトリック)のモデルを用いたソフトウェア測定のアプローチ。


コールグラフ (call graph)
プログラムにおけるサブルーチン間の呼び出し関係の抽象的表現。


コンサルテーションベースのテスト (consultative testing)
外部テストチームの適切な専門家(テクノロジ専門家又はビジネスドメインの専門家)のアドバイス及びガイダンスに基づいて実行されるテスト。


コンテンツ参照モデル (content reference model)
content-based modelを参照のこと。


コンテンツベースドモデル (content-based model)
優れたエンジニアリングプラクティス(たとえば、テストプラクティス)に関する詳細な説明を提供するプロセスモデル。


コンパイラ (compiler)
高度な命令語で表現されたプログラムを、等価の機械語に翻訳するソフトウェアツール。[IEEE 610]


コンフィデンステスト (confidence test)
smoke testを参照のこと。


コンポーネント (component)
独立してテストできるソフトウェアの最小単位。


コンポーネント仕様 (component specification)
コンポーネントに関する機能(特定の条件下で、特定の入力値に対する出力値を観点としたもの)、及び、要求される非機能的な振る舞い(たとえば、資源効率性)の記述。


コンポーネントテスト (component testing)
個々のソフトウェアコンポーネントのテスト。[After IEEE 610]


コンポーネント統合テスト (component integration testing)
統合したコンポーネント間のインターフェースや相互作用の欠陥を検出するためのテスト。


根本原因 (root cause)
欠陥の発生源のことで、根本原因が除去されると、欠陥が削減又は除去される。[CMMI]


根本原因分析 (root cause analysis)
欠陥の根本原因の識別を目的とした分析技法。根本原因に是正を行なうことで、欠陥再発を最小化する事が期待できる。