Product Design, Manufacturing & Innovation Resources
» 静的検証と動的検証(IT)

静的検証と動的検証(IT)

1970
Software engineer performing static verification using code analysis tools in Computer Science.

(画像はイメージです)

Verification 検証手法は大きく静的検証と動的検証に分類されます。静的検証(または静的解析)は、システムを実行せずにコードや設計を検証します。例としては、コードレビュー、検査、自動静的解析ツールなどがあります。動的検証(またはテスト)は、一連の入力を用いてシステムを実行し、その動作を観察して欠陥を見つけます。どちらも包括的な品質保証のために相互補完的な役割を果たします。

静的検証と動的検証は、欠陥を見つけるための補完的なアプローチです。静的検証は開発サイクルの早い段階、多くの場合、コードのコンパイル前に実行されます。コードベース全体を分析して、構文エラー、型の不一致、ヌルポインタの逆参照、コーディング規約違反などの問題を特定できます。実行を必要としないため、テストでは到達しにくいコードパスの問題も発見できます。自動化された静的解析ツールは、現代の開発ワークフローの標準的な一部となっており、統合開発環境(IDE)内で開発者に即座にフィードバックを提供します。

動的検証(一般的にはテストと呼ばれる)は、ソフトウェアの実行時動作に焦点を当てます。これは、特定の入力でプログラムを実行し、実際の出力と期待される出力を比較することによって行われます。パフォーマンスのボトルネック、時間経過とともに発生するメモリリーク、複雑なユーザー操作の不適切な処理など、特定の種類のエラーを検出するには、この方法しかありません。動的検証には、個々のコンポーネントをチェックする単体テストから、アプリケーション全体を検証するシステムテストまで、さまざまなレベルのテストが含まれます。動的テストは強力ですが、本質的に不完全です。テスト対象の入力に対してバグが存在することを証明できるだけで、考えられるすべての入力に対してバグが存在しないことを証明することはできません。

包括的な検証戦略では、両方の手法が活用されます。静的解析は、特定の種類のエラーを低コストかつ早期に検出する一方、動的テストは、実行中のシステムの機能的および非機能的な動作を検証し、運用条件下で期待どおりに動作することを保証します。

UNESCO Nomenclature: 1203
コンピュータサイエンス

タイプ

抽象システム

混乱

実質的な

使用法

広く普及している

前駆物質

  • compiler theory (for parsing and semantic analysis)
  • 初期のデバッグ手法(例:print文)
  • 形式論理
  • コードのウォークスルーと検査プロセス

アプリケーション

  • IDEに搭載されている静的解析ツール(例:lint、findbugs)
  • 単体テストフレームワーク(例:JUnit、PyTest)
  • コード検査およびピアレビュープロセス
  • パフォーマンスおよび負荷テスト
  • セキュリティ侵入テスト

特許:

NA

潜在的なイノベーションのアイデア

ボットによるトラフィック(現在1日あたり4万件以上)を排除するため、このコンテンツはコミュニティメンバー限定となっています。
> ログイン < または > 登録 < (100%無料)でこれにアクセスできます。他のすべての制限付きコンテンツとツールも同様です。

関連キーワード:静的解析、動的解析、テスト、検証、ソフトウェア品質、コードレビュー、単体テスト、リンティング。

歴史的背景

静的検証と動的検証(IT)

1960
1960
1967
1970
1970
1970
1970
1956
1960
1967
1967
1970
1970
1970
1970-01-01

(日付が不明または関連性がない場合、例えば「流体力学」などでは、その注目すべき出現時期の概算値が提示されます。)

関連する発明、革新、および技術原理

フルサイズの画像とダウンロードは、登録会員のみが100%無料で利用できます。