モデルベーステスト

グラフィカルユーザインターフェース（Graphical User Interface）の頭字語。

モデルベースドテストで使用するあらゆるモデル。

ピアレビューの一種。ドキュメントの目視検査により、欠陥を検出する方法。これにより、たとえば、開発標準の違反や、上位レベルドキュメントへの準拠違反が見つかる。最も公式なレビュー技術なので、必ず、文書化された実施基準に従って進める。

間違った結果を生み出す人間の行為。

（モデルから）生成したテストケースを以降のテスト実行のために保存するモデルベースドテストのアプローチ。

（モデルから）生成したテストケースを生成と同時に実行するモデルベースドテストのアプローチ。

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

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

効果や効率を示す高位レベルのメトリック。開発をコントロールし、方向性を決めるために利用する。たとえば、ソフトウェア開発のためのリードタイムの遅れ。

統合されたシステムが、特定の要件を満たすことを実証するためのテスト。

ブラックボックステスト設計技法の一つ。ユースケースのシナリオを実行するテストケースを設計する。

テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。

テストスイートによって遂行されたステートメントのパーセンテージ。

プログラミング言語の実体。実行の最小単位。

予測または特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。

ソフトウェア製品のセキュリティを判定するテストのプロセス。

許可されていない人またはシステムが情報またはデータを読んだり、修正したりすることができないように、および許可された人またはシステムが情報またはデータへのアクセスを拒否されないように、情報またはデータを保護するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

アイテムの品質に影響を与えるフィーチャや特性。

ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。

特定のテスト設計技法を使用している際に、テストベースのサイズが大きくなるにつれて、テストケースの数が過度に増加すること。テストケースの爆発的増加は、テスト設計技法を初めて体系的に適用した際に発生することもある。

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

テストケースを作成したり選択したりするための技法。

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

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

テストに使うデータを選択（データベース内の実データなど）、または、作成、生成、操作、編集をするためのツール。

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

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

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

テスト実行に必要なスタブやドライバからなるテスト環境。

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

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

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

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

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

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

テスト対象のコンポーネントまたはシステムをテストするために使用するテストウェアを規定するモデル。

あるプロセスを公式に完了させるため、ステークホルダが承認した一般・特定条件のセット。終了基準の目的は、未完了部分のあるタスクが、完了とみなされるのを防ぐことにある。あらかじめ計画していた終了基準を、テスト完了時の報告に利用する。

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

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

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

テスト対象となるシステムのことであり、テスト対象の一種。

テストすべきコンポーネントまたはシステム。

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

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

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

テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。

テストを自動化するための環境を提供するツール。通常、テストハーネスとテストライブラリで構成される。

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

達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。

テスト計画書を策定し、更新すること。

概略的なテスト目的を具体的なテスト条件とテストケースに変換するプロセス。

テスト自動化アーキテクチャのレイヤー。抽象レベルのテストスクリプトをSUTのさまざまなコンポーネント、構成、またはインターフェースに適合させるために必要なコードを提供する。

テストケースを適切に生成するために使用する基準、またはテストのサイズを制限するためにテストケースを選択する際に使用する基準。

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

1つ以上のテストケースのセット。

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

ブラックボックステスト設計技法の一つ。デシジョンテーブルにある入力と刺激（原因）の組み合わせを実行するテストケースを設計する。

スクリプト作成技法の1つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、1つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。

2つのエンティティ（たとえば、要件とテストケース）を関係付ける2次元の表。この表を使用すると、エンティティ間の関係を前工程および後工程の双方向に追跡できるので、達成したカバレッジを測定でき、変更点の影響を評価できる。

ドキュメントとソフトウェアの関連事項（たとえば、ある要件と、それを検証するテストケース）を識別する能力。

抽象的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース

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

テストスイートが遂行したパスのパーセンテージ。

コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。

ブラックボックステスト設計技法の一つ。同値分割した領域から代表値を実行するテストケースを設計する。原則として、最低1回各同値分割した領域を実行するように設計する。

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

テストスイートが遂行した条件結果のパーセンテージ。条件カバレッジを100%にするには、各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。

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

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

測定尺度、および、測定手法。

リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。

テストスイートがモデル要素の遂行を計画したか、またはモデル要素をすでに遂行した度合。パーセンテージで表す。

テスト戦略の一つ。テストチームはテストウェアをモデルから生成する。

モデルに基づく、またはモデルを活用するテスト。

変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのコンポーネントやシステムに対して実行するテスト。

プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。

将来、否定的な結果を生む要素。

プロダクトやプロジェクトの状態を評価する手法。計画した結果との違いを分析し、改善を提案する。例として、マネジメントレビュー、非公式レビュー、テクニカルレビュー、インスペクション、ウォークスルーがある。

具体的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース

特定の条件下で、仕様や他の情報から期待できるコンポーネントやシステムの振る舞い。

特定のテストやテスト手順でコンポーネントやシステムを実行する前に満足すべき、環境と状態の条件。

指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。[ISO/IEC 9126] JSTQB 訳注）JIS X 0129-1:2003 より引用

修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、または環境の変化、要求仕様の変更および機能仕様の変更にソフトウェアを適応させることを含めてもよい。JSTQB訳注）JIS X 0129-1:2003より引用

あるアイテム（たとえば、欠陥）に割り当てた（ビジネス上の）重要さのレベル。

コンポーネントが参照する変数。コンポーネント内部または外部に格納されている。

コンポーネントが書き込む変数（コンポーネントの内部、外部に格納される）。

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

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

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

仕様に基づき、コンポーネントやシステムの振る舞いが同じとみなせる入力ドメインや出力ドメインの部分。

テストスイートが遂行した、同値分割した領域のパーセンテージ。

品質マネジメントの一部。品質要件を満たしていることの確信度合に焦点を当てている。

コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。

欠陥の認識、調査、欠陥に対する行動、処置のプロセス。欠陥の記録、分類、および、影響の識別を含む。

ブラックボックステスト設計技法の一つ。境界値に基づいてテストケースを設計する。

同値分割した領域の端、あるいは端のどちらか側で最小の増加的距離にある入力値または出力値。たとえばある範囲の最小値または最大値。

(1)個人やチーム、組織を現在の状態から望ましい状態へと移行させるための構造化されたアプローチ。(2)プロダクトやサービスに対して変更あるいは提案された変更を達成するためのコントロールされた方法。

検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。

コンパイル時にオブジェクトコードに翻訳され、プログラムが走るときに手順に沿って実行されて、データに対して動作を行なうステートメント。

特定の要件を変更する前に、開発ドキュメント、テストドキュメント、コンポーネントの各階層が、変更によりどのような影響を受けるか評価すること。

コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。

定義済みプロセス領域のセット全体において、セット内の全てのゴールが達成されているプロセス改善の度合。

意図する結果を生成する能力。

ブラックボックステストの設計技法の一つ。無効と有効の状態遷移を実行するテストケースを設計する。

客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用

公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)

ソフトウェアが、指定された条件の下で利用されるときに、明示的および暗示的必要性に合致する機能を提供するソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

測定することによって、ある実体の特性に付加した数字や種別。

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

統合したコンポーネントやシステムのインターフェースや相互作用の欠陥を摘出するためのテスト。

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

ユーザが問題解決や目的を達成するために必要な条件や能力。契約、標準、仕様、その他の公式ドキュメントを満足するために、システムやシステムコンポーネントが満たし、保持すべき条件や能力。

修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力。JSTQB訳注）JIS X 0129-1:2003より引用

コンポーネント、システム、人が、適格要件に従っていることを確認するプロセス。たとえば、試験に合格するなど。