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


検索結果:95件

S.M.A.R.T. goal methodology (S.M.A.R.T. ゴール方法論)
目標を、汎用的ではなく、非常に具体的に定義する方法論。SMARTは、定義される目標の属性を表すSpecific(具体的な)、Measurable(測定可能な)、Attainable(達成可能な)、Relevant(妥当な)、及びTimely (タイムリーな)からの頭字語である。


safety (安全性)
利用者が指定された利用の状況で、人、事業、ソフトウェア、財産又は環境への害に対して、容認できるリスクの水準を達成するためのソフトウェア製品の能力。[ISO/IEC 9126] JSTQB訳注)JIS X 0129-1:2003 より引用


safety critical system (セーフティクリティカルシステム)
故障や誤動作が人命や人々への深刻な損害、若しくは機器へのダメージや環境被害となる可能性のあるシステム。


safety testing (安全性テスト)
ソフトウェア製品の安全性を判定するテスト。


sanity test (サニティテスト)
smoke testを参照のこと。


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


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


scenario testing (シナリオテスト)
use case testingを参照のこと。


scorecard (スコアカード)
長期的なゴールに向けた実行の進捗状況を表す要約されたパフォーマンス測定の表現。スコアカードは、定義された間隔中、若しくはその間隔の終了時に静的なパフォーマンス測定を提供する。balanced scorecard, dashboardも参照のこと。


scribe (書記)
レビューミーティングで指摘された欠陥や、改善の提案を、所定の書式に記録する人。書記は、記録が読みやすく、理解しやすくなるように留意しなくてはならない。


scripted testing (スクリプトテスト)
すでに記述されているテスト順序通りに実行するテスト方法。


scripting language (スクリプト言語)
実行可能テストスクリプトとして書かれ、テスト実行ツール(たとえば、キャプチャ・プレイバックツール)で使われるプログラミング言語。


SCRUM (スクラム)
アジャイルソフトウェア開発におけるプロジェクト管理のためのイテレーティブインクリメンタル型フレームワーク。agile software developmentも参照のこと。


security (セキュリティ)
許可されていない人又はシステムが情報又はデータを読んだり、修正したりすることができないように、及び許可された人又はシステムが情報又はデータへのアクセスを拒否されないように、情報又はデータを保護するソフトウェア製品の能力。[ISO/IEC 9126] functionalityも参照のこと。 JSTQB訳注)JIS X 0129-1:2003より引用


security testing (セキュリティテスト)
ソフトウェア製品のセキュリティを判定するテスト。functionality testingも参照のこと。


security testing tool (セキュリティテストツール)
セキュリティの特性と脆弱性をテストするための支援をするツール。


security tool (セキュリティツール)
セキュリティの運用を支援するツール。


serviceability testing (保守性テスト)
maintainability testingを参照のこと。


session-based test management (セッションベースのテストマネジメント)
セッションベースドテストの測定と管理の手法。たとえば、exploratory testing


session-based testing (セッションベースドテスト)
テスト設計と実行を行なう連続するセッションとして計画されたテスト活動を行なうテストアプローチ。多くの場合、探索的テストにおいて使用される。


severity (重要度)
コンポーネントやシステムの開発、また運用に対し欠陥が与える影響の度合。[After IEEE 610]


Shewhart chart (シューハート管理図)
control chartを参照のこと。


short-circuiting (短絡評価)
複合条件を評価するためのプログラミング言語/インタープリタの技法。論理演算子の片方が最終結果を決定するのに十分である場合に、他方は評価されないことがある。


simulation (シミュレーション)
物理的なシステム、あるいは、抽象的なシステムの代表的な動作特性を他のシステムで模倣すること。[ISO/IEC 2382/1]


simulator (シミュレータ)
テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。[After IEEE 610, DO178b] emulatorも参照のこと。


site acceptance testing (サイト受け入れテスト)
ユーザや顧客が自分のサイトで実施する受け入れテスト。コンポーネントやシステムが、ユーザや顧客のニーズを満たしているかどうか、ユーザや顧客のビジネスプロセスに適合するかを判定するために実施する。通常、ソフトウェアだけでなく、ハードウェアも含める。


smoke test (スモークテスト)
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。日次のビルドやスモークテストは、(ソフトウェア)業界において最も効率的・効果的な実践方法の一つ。intake testも参照のこと。


software (ソフトウェア)
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。


software attack (ソフトウェア攻撃)
attackを参照のこと。


Software Failure Mode and Effect Analysis (SFMEA) (ソフトウェア・故障モード影響解析)
Failure Mode and Effect Analysis (FMEA)を参照のこと。


Software Failure Mode, Effects, and Criticality Analysis (SFMECA) (ソフトウェア・故障モード影響・致命度解析)
Failure Mode, Effects, and Criticality Analysis (FMECA) を参照のこと。


software Fault Tree analysis (SFTA) (ソフトウェア・フォールトツリー解析)
Fault Tree Analysis (FTA)を参照のこと。


software feature (ソフトウェアフィーチャ)
featureを参照のこと。


software integrity level (ソフトウェア完全性レベル)
ステークホルダが選択したソフトウェアやソフトウェアベースのシステム特性にソフトウェアが準拠する、又は準拠する必要のある度合。一連のシステム特性は、たとえば、ソフトウェアの複雑性、リスクアセスメント、安全レベル、セキュリティレベル、期待される性能、信頼性、又はコストで構成され、ステークホルダにとってのソフトウェアの重要度を反映するように定義される。


software lifecycle (ソフトウェアライフサイクル)
ソフトウェアプロダクトの最初から最後、つまり企画段階から利用終了までの期間。ソフトウェアライフサイクルは通常、コンセプトフェーズ、要件フェーズ、設計フェーズ、実装フェーズ、テストフェーズ、インストールとチェックアウトフェーズ、運用と保守フェーズを含み、ときに除去フェーズを含むこともある。注)これらのフェーズは重複することもあるし、反復することもある。


Software Process Improvement (ソフトウェアプロセス改善)
組織のソフトウェアプロセスとその結果のパフォーマンス及び成熟度を改善する活動プログラム。[After CMMI]


software product characteristic (ソフトウェア製品特性)
quality attributeを参照のこと。


software quality (ソフトウェア品質)
ソフトウェア製品の全体として、機能とフィーチャが、明示的、暗示的なニーズを満たしている能力。[After ISO/IEC 9126] qualityも参照のこと。


software quality characteristic (ソフトウェア品質特性)
quality attributeを参照のこと。


software test incident (ソフトウェアテストインシデント)
incidentを参照のこと。


software test incident report (ソフトウェアテストインシデントレポート)
incident reportを参照のこと。


Software Usability Measurement Inventory (SUMI) (ソフトウェア使用性測定一覧表)
エンドユーザの視点からソフトウェア品質を測定するための、アンケートに基づいた使用性テストの技法。[Veenendaal04]


source statement (ソースステートメント)
statementを参照のこと。


specification (仕様)
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を(理想としては完全で的確、かつ検証可能な方法で)詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。 [After IEEE 610]


specification-based technique (仕様ベースの技法)
black box test design techniqueを参照のこと。


specification-based test design technique (仕様ベースドテスト設計技法)
black box test design techniqueを参照のこと。


specification-based testing (仕様ベースドテスト)
black box testingを参照のこと。


specified input (スペシファイドインプット)
仕様から結果を予測した入力。


SPI (SPI)
Software Process Improvementを参照のこと。


stability (安定性)
ソフトウェアの修正による、予期せぬ影響を避けるソフトウェア製品の能力。[ISO/IEC 9126] maintainabilityも参照のこと。 JSTQB訳注)JIS X 0129-1:2003より引用


staged representation (段階表現)
成熟度レベルとして確立したプロセスエリアのゴールに達したかをみるモデル構造であり、各レベルは次のレベルの土台となるよう組み立てられている。[CMMI]


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


standard software (標準ソフトウェア)
off-the-shelf softwareを参照のこと。


standard-compliant testing (標準準拠テスト)
標準により定義されている一連の要件に準拠していることを確認するテスト。たとえば、業界のテスト標準又はセーフティクリティカルシステムのテスト標準などがある。process-compliant testingも参照のこと。


standards testing (標準テスト)
compliance testingを参照のこと。


state diagram (状態遷移図)
コンポーネント又はシステムが取りうる状態を示し、ある状態から他への状態の変化の原因となる、(又は)その結果として生ずる、イベントや状況を表すダイアグラム。[IEEE 610]


state table (状態遷移表)
発生する可能性のあるイベントと状態の組み合わせから、生じる結果を示す遷移のテーブル。無効な遷移と、有効な遷移の両方を示す。


state transition (状態遷移)
コンポーネントやシステムにおいて、二つの状態の間を遷移すること。


state transition testing (状態遷移テスト)
ブラックボックステストの設計技法の一つ。無効と有効の状態遷移を実行するテストケースを設計する。N-switch testingも参照のこと。


statement (ステートメント)
プログラミング言語の実体。実行の最小単位。


statement coverage (ステートメントカバレッジ)
テストスイートによって遂行されたステートメントのパーセンテージ。


statement testing (ステートメントテスト)
ホワイトボックステスト設計技法の一つ。ステートメントを実行するテストケースを設計する。


static analysis (静的解析)
(たとえば、要件又はコードなどの)ソフトウェア開発の成果物を実行せずに解析すること。静的解析は通常、支援ツールを用いて実施する。


static analysis tool (静的解析ツール)
static analyzerを参照のこと。


static analyzer (静的アナライザ)
静的解析を行なうツール。


static code analysis (静的コード解析)
ソフトウェアを実行せずにソースコードを解析すること。


static code analyzer (静的コードアナライザ)
静的コード解析を実施するツール。ソースコードをチェックし、コーディング基準や品質メトリクスへの準拠度合、データフローの不整合などを検出する。


static testing (静的テスト)
ソフトウェア開発の成果物(要件、設計、又は、コードなど)の実行をせずに実施する成果物のテスト。たとえば、レビュー、静的解析など。


statistical testing (統計的テスト)
入力の統計的な分散モデルを使い、代表的なテストケースを作成するテスト設計技法。operational profile testingも参照のこと。


status accounting (ステータスアカウンティング)
構成管理の要素で、構成を効果的に管理する場合に必要となる情報を記録、報告すること。必要情報には、承認済み構成識別表、承認済み構成に対する変更提案の状態表、承認済み変更の実施状態の一覧表などがある。[IEEE 610]


STEP (STEP)
Systematic Test and Evaluation Processを参照のこと。


STEP(Systematic Test and Evaluation Process) (体系的テストと評価プロセス)
体系的なテスト方法論。テストプロセス改善のためにコンテンツベースドモデルとしても使用される。STEPによる改善は、順序には依存しない。content-based modelも参照のこと。


storage (ストレージ)
resource utilizationを参照のこと。


storage testing (ストレージテスト)
resource utilization testingを参照のこと。


stress testing (ストレステスト)
予測又は特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、又は、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。[After IEEE 610] performance testing, load testingも参照のこと。


stress testing tool (ストレステストツール)
ストレステストを支援するツール。


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


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


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


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


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


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


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


stub (スタブ)
特定のコンポーネント(仮にAと呼ぶ)をテストするため、Aに呼び出される(特定目的のための最小限度の)コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。[After IEEE 610]


subpath (サブパス)
コンポーネント内の一連の実行可能なステートメント。


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


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


SUMI (SUMI)
Software Usability Measurement Inventoryを参照のこと。


suspension criteria (中止基準)
テストアイテムに関わる全て、又は、一部のテストの活動を(一時的に)止める場合に参照する基準。[After IEEE 829]


syntax testing (シンタックステスト〔構文テスト〕)
ブラックボックステスト設計技法の一つ。入力ドメインと出力ドメインの定義を基にテストケースを設計する。


system (システム)
特定の機能や、機能の組み合わせを実現するために組織化したコンポーネントのセット。[IEEE 610]


system integration testing (システム統合テスト)
システムやパッケージを統合して行なうテスト。外部機構とのインターフェース(たとえば、電子データ交換やインターネット)をテストすること。


system of systems (システムオブシステムズ)
相互接続したドメインと複数レベルのネットワークに組み込まれた複数の分散システムや異機種環境のこと。通常、共通的な管理構造を持たずに、広範囲に専門領域間をまたがる共通の問題や目的に対処する。


system testing (システムテスト)
統合されたシステムが、特定の要件を満たすことを実証するためのテストのプロセス。[Hetzel]


system under test (テスト対象システム)
test objectを参照のこと。