アプリケーションのプログラミングインターフェースを直接使用し、テスト対象のソフトウェアにコマンドを発行して行うテスト。
コンポーネントまたはシステムに含まれる、定義された形式の構造で情報を交換するインターフェースの1つ。Application Programming Interface の頭字語。
ISO 26262のアイテムまたは要素の必要要件と、不合理な残余リスクを回避するための安全方策を、4つのレベルで指定する。
Computer Aided Software Engineering（コンピュータ支援ソフトウェア開発）の頭字語。
電気/電子（E/E）システムの誤動作によって危険な状況が引き起こされるという不合理なリスクが存在しないこと。
グラフィカルユーザインターフェース（Graphical User Interface）の頭字語。
最初は有益で一般的に使用できるように思われるが、実際には効果がない、または逆効果である反復的な活動、プロセス、構造、または再利用可能なソリューション。
インストールプロセス中、インストールを誘導するソフトウェア。いろいろな形態の媒体で提供される。インストールを実行し、インストール実施結果情報を出力し、オプション機能のガイダンスを表示するものが多い。
ある特定のシステムと同じ入力を受け入れ、同じ出力を作り出す装置、コンピュータプログラム、またはシステム。
システムやコンポーネントにフォールトを埋め込む（つまり、意図的に挿入する）ためのツール。
誤ったデータを入力しても、通常運用を続けられるコンポーネントやシステムの能力。
脆弱性の一つ。悪意のあるコードを安全なWebサイトへ感染させるために攻撃者が悪用することを可能にする。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
プログラムにおけるサブルーチン間の呼び出し関係の抽象的表現。
セキュリティ攻撃方法の一つ。サービスできない正当なリクエストなどを大量に送りつけてシステムを過負荷状態にする。
物理的なシステム、あるいは、抽象的なシステムの代表的な動作特性を他のシステムで模倣すること。
テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。
特定のコンポーネント（仮にAと呼ぶ）をテストするため、Aに呼び出される（特定目的のための最小限度の）コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
予測または特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。
ソフトウェア製品の資源効率性を判定するためのテストのプロセス。
ソフトウェア製品のセキュリティを判定するテストのプロセス。
組織にとってのセキュリティに関わる原理原則、アプローチ、主要な目的を記述する高位レベルのドキュメント。
システムまたはコンポーネント、リソース、情報への不正なアクセスを成功させようとする試み。またはシステムの完全性を侵害しようとする試み。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。
テスト環境、テストツール、オフィス環境、処理手続きからなるテストの実施に必要な構造的なもの。
テスト実行中の連続した一区切りの時間。探索的テストでは、各テストセッションは一つのチャータに焦点を当ててテストを行なう。しかし、セッション中にテスト担当者は新しい気づきや問題に対してもまた探索することもある。テスト担当者はその場で作成して実行し、進捗を記録する。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト実行中にテスト対象が外部ソースから受け取ったデータ。外部ソースは、ハードウェア、ソフトウェア、人の場合がある。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
たとえばキャプチャ/プレイバックツールのようなソフトウェアを使用して、テストの実行、実行結果と期待結果の比較、テスト事前条件の設定、その他のテストコントロールやレポート機能を(自動)制御すること。
テスト対象となるシステムのことであり、テスト対象の一種。
テストの実行に必要なハードウェア、インスツルメンテーション、シミュレータ、ソフトウェアツール、その他の支援要素を含む環境。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
テスト自動化アーキテクチャの設計、実装、および保守を担当する人。作成したテスト自動化ソリューションを技術的に進化させる役割も担う。
テストを自動化するための環境を提供するツール。通常、テストハーネスとテストライブラリで構成される。
達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。
故障を再現して、プログラムの状態を調査し、対応した欠陥を見つけるために、プログラマが使用するツール。デバッガは、プログラムの変数をセットし検査するために、どのプログラムステートメントの場所でもプログラムを停止したり、プログラムを１ステップずつ実行したりできる。
故障を再現して、プログラムの状態を調査し、対応した欠陥を見つけるために、プログラマが使用するツール。デバッガは、プログラムの変数をセットし検査するために、どのプログラムステートメントの場所でもプログラムを停止したり、プログラムを１ステップずつ実行したりできる。
ホワイトボックステスト設計技法の一つ。変数の「定義と使用」の組を実行するようにテストケースを設計する。
データオブジェクトの順序と、起こり得る状態の変化を抽象的に表現したもの。オブジェクトの状態は、発生、使用、消滅のいずれかになる。
別のコンポーネントを置き換え、テストアイテムを単独で制御または呼び出す、一時的なコンポーネントまたはツール。
Webサイト上に切断されたハイパーリンクが存在しないことを確認するために使用されるツール。
ウェブページで、他のウェブページへ導くためのポインタ。
抽象的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性（たとえば、信頼性、使用性、設計上の制約など）。
管理されている環境で、故障モードをシミュレーションするか、実際に故障を発生させて行なうテスト。故障の後、フェイルオーバー機能をテストし、データの損失および破損が発生しておらず、合意されている全てのサービスレベル（機能の可用性、応答時間など）を維持していることを確認する。
システムが欠陥を検出し、欠陥から復旧できることを確認する目的で、意図的に欠陥をシステムに追加するプロセス。フィールドで発生する可能性のある故障を模倣することを目的とする。
システムやコンポーネントにフォールトを埋め込む（つまり、意図的に挿入する）ためのツール。
テストスイートが遂行した条件結果のパーセンテージ。条件カバレッジを100%にするには、各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
真または偽として評価することのできる論理的表現。たとえば、A>B。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注）JIS Q 9000:2006より引用
相互関係のある活動のセット。入力を出力に変換する。
他のデータアイテムのロケーションを指定するデータアイテム。たとえば、処理される次の従業員レコードアドレスを指定したデータアイテム。
運用システム自体の変更や、稼動環境の変更が運用システムに与える影響をテストすること。
リリース後のコンポーネントやシステムを変更するプロセス。欠陥の修正、品質特性の改善、変更した環境への適合を目的とする。
システムで特定のタスクを達成するために、ユーザに情報を提供し、ユーザによる制御を可能にするシステムのすべてのコンポーネント。
ソフトウェア製品を実際に使用した後、または使用することが予想される場合のユーザの認識および反応。
変更により引き起こされた、コンポーネントやシステムの品質の悪化。
テストされるコンポーネントやシステムが稼動中にユーザが行なうであろう活動内容を記した仕様書。ロードプロファイルは、特定の時間内に所定の運用プロファイルに準じ決められたトランザクションを処理する仮想ユーザを複数指定して構成する。
範囲外、若しくは、存在しない位置を参照しているポインタ。
コンポーネントやシステムが他のコンポーネントやシステムと情報を交換できる度合、および／もしくは、同じハードウェアまたはソフトウェア環境を共有しながら、必要な機能を実行できる度合。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を（理想としては完全で的確、かつ検証可能な方法で）詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
ソフトウェア製品の保守性を判定するテストのプロセス。
ソフトウェア製品の保守性を判定するテストのプロセス。
ソフトウェア製品の信頼性を判定するテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
たとえば、プロダクトリスクまたは要件のような体系的な分析に基づくテスト。
コンポーネントやシステムで、開始点から終了点へ至るイベント（たとえば、実行ステートメント）の順列。
システムを受け入れる判断に焦点を当てたテストレベル
コンポーネントやシステムが、正しく機能しないことを証明するためのテスト。否定テストは、特定のテストアプローチやテスト設計技法ではなく、テスト担当者の意向を反映したもの。たとえば、無効入力値や例外値を用いたテスト。
一つ以上のインシデントを引き起こしている未解明の原因。
ソフトウェア製品の回復性を判定するテストのプロセス。
ソフトウェア製品の回復性を判定するテストのプロセス。
ソフトウェアプログラムから名前を参照することでアクセスできるコンピュータ中のストレージの要素。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること。
コンパイル時にオブジェクトコードに翻訳され、プログラムが走るときに手順に沿って実行されて、データに対して動作を行なうステートメント。
システムが故障から回復するまでに要する平均時間。これには一般的に欠陥が解決されていることを保証するテストが含まれる。
システムにおける故障から次の故障までの平均時間。MTBFは、通常、欠陥修正プロセスの一部として、障害が発生したシステムを直ちに修復することを想定した信頼度成長モデルの一部である。
定義されたプロセスに従うレビュー。形式に則った文書の作成を伴う。
テストツールの種類の1つ。定義したテストアイテム用の負荷を生成する。また、テストの実行中に、性能を計測・記録する。
コンポーネントやシステムが、定義した機能を達成するために使用する時間、リソース、容量の度合。
リソースにアクセスすることを可能にする、人、またはプロセスに付与される権限。
ソフトウェア製品の拡張性を判定するテスト。JSTQB訳注）この「テスト」は実行とそのための一連の活動を意味している。
増加する負荷に応じてソフトウェア製品をアップグレードできる能力。
入力値や事前条件のセットに対する、コンポーネントやシステムの反応。
ランダムであるようにみえるが、実際にはいくつか事前に決められた順序に従って生成される一揃いのもの。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
物理的または機能的な故障の兆候。たとえば、故障モードのシステムは、遅い運用、間違った出力、または実行の完全な打ち切りなどで特徴付けられる。
情報をエンコードするプロセス。認可されたもののみが一般的には特定の復号化キーまたは復号化プロセスを使用して元の情報を読み取れるようにする。
計算モデルの一つ。有限個数の状態と、それらの状態間遷移から構成される。状態遷移に対応する動作も記述できる。
テストスイートが遂行した条件結果のパーセンテージ。条件カバレッジを100%にするには、各判定ステートメントの全ての単一条件に対し、真と偽をテストする必要がある。
ホワイトボックステスト設計技法の一つ。判定結果に対して独立に影響する単一条件結果を実行するテストケースを設計する。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
真または偽として評価することのできる論理的表現。たとえば、A>B。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注）JIS Q 9000:2006より引用
ソフトウェア製品の移植性を判定するテストのプロセス。
コンポーネントやシステムの構成要素の数、性質、相互連結によって定義される構成。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
システム統合法のアプローチの一つ。早い時期に、基本機能を動作させるために、コンポーネントやシステムを結合すること。
コンポーネントやシステムが、特定の条件の下で使用される場合に、定義または示唆されているニーズを満たす機能を備えている度合。
測定することによって、ある実体の特性に付加した数字や種別。
ある実体の特性を表すため、数字や種別を付加する手順。
重要な懸念、問題、または機会を特定する評価の結果。
複合条件を評価するためのプログラミング言語/インタープリタの技法。論理演算子の片方が最終結果を決定するのに十分である場合に、他方は評価されないことがある。
ソフトウェア製品の移植性を判定するテストのプロセス。
コンポーネントやシステムを組み合わせ、さらに大きな集合体を作るプロセス。
ソフトウェア開発手順のひとつ。自動化したプロセス内ですべての変更をコミットすると、それらをすぐにマージ、統合、テストする。
テストスイートが遂行した一つのステートメントの中にある全ての単一条件結果の組み合わせのパーセンテージ。100%の複合条件カバレッジは、100%の改良条件判定カバレッジを意味する。
コンポーネントやシステムの設計・内部構造において、理解、保守、検証することが難しい度合。
コンポーネント、システム、人が、適格要件に従っていることを確認するプロセス。たとえば、試験に合格するなど。
性能テストの一種。さまざまな負荷でのコンポーネントやシステムの振る舞いを評価するために使用する。負荷については、予測される使用量の低、標準、ピークを一般的に使用する。
ソフトウェア製品の資源効率性を判定するためのテストのプロセス。
真偽を評価できるステートメント。後続の判定ロジックの制御フローを決定する場合がある。
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。
プロセスの開始を意図した実行ステートメント、若しくはポイントとして定義したプロセスステップ。
不正な入力や過負荷の環境条件の中でも、コンポーネントまたはシステムが正しく機能できる度合。