Vietnamese
English静的テストの基本
テストとは一般的に、ソフトウェアを実行してその結果を確認するものと考えられがちですが、実際には要件やユーザーストーリー、ソースコードなどの成果物をレビューしたり、ソースコードを静的解析する作業も含まれます。
これらを明確に区別するために、ソフトウェアを実行して結果を確認する通常のテストを「動的テスト」、一方でレビューや静的解析を「静的テスト」と呼ぶことがあります。
ここでは、静的テストについて基本的な説明を行います。静的テストは、動的テストとは異なり、コードを実行したり動作を確認する必要がありません。具体的には、成果物の内容を人が確認する「レビュー」と、ツールを活用してコードや成果物を分析・評価する「静的解析」があります。どちらも、実際に動作させることなく評価を行える点が特徴です。
こうした静的テストは、社会インフラや交通、医療といった安全性が求められるシステムだけでなく、広くさまざまな分野で利用されています。例えば、ソフトウェア開発に限らず、日常生活においても「対象を動かさずに確認する」静的なアプローチは、意外と身近に存在しています。
その身近な例として、引っ越しの準備が挙げられます。引っ越しでは、転居に伴う役所の手続きやライフラインの変更手続き、引っ越し業者の手配など、事前にさまざまな準備が必要です。この際、チェックリストを活用すれば、やるべきことに漏れがないか確認できます。さらに、引っ越し作業に詳しい人にアドバイスをもらいながらリストを作成すれば、より効果的に準備を進めることができるでしょう。
静的テストで検査可能な作業成果物
ソフトウェア開発におけるあらゆる成果物は、静的テスト（レビューや静的解析、またはその両方）の対象となります。
静的テストの対象例としては、以下のようなものが挙げられます。
・仕様書（ビジネス要件、機能要件、セキュリティ要件など）
・エピック、ユーザーストーリー、受け入れ基準
・アーキテクチャや設計仕様
・ソースコード
・テスト関連資料（テスト計画、テストケース、テスト手順、自動化テストスクリプトなど）
・ユーザーガイド
・Webページ
・プロジェクト計画書、スケジュール、予算書
上記のように、人が読んで理解したり、ツールが解析して矛盾や欠陥を発見可能な成果物はすべて静的テストの対象となります。
レビューでは、人が理解可能な成果物全般が対象となります。一方、静的解析では、コードやモデルのように形式的な構造を持つ成果物を対象に、ツールを活用して効率的に評価を行います。たとえば、静的解析の一例として、コーディング規約を用いてコードをチェックすることで、欠陥を減らすことができます。また、設計書など自然言語で書かれた資料についても、言語認識や構文解析を用いることで、誤字脱字、文法エラー、曖昧な表現を検出することが可能です。
さらに、静的解析はセキュアなソフトウェアを開発するための評価手段として、その利用範囲が広がっています。
静的テストの利点
静的テストは、ソフトウェア開発ライフサイクルのさまざまな段階で実施可能です。特に、動的テストの前に行われるレビューや静的解析は、初期段階で欠陥を特定できるため、非常に効果的です。この段階で発見された欠陥は、修正の方法を容易に検討でき、低コストで対応できる場合が多いのが特徴です。一方、ライフサイクルの後半で動的テストによって発見される故障は、複雑な条件下で発生することが多く、欠陥の特定や修正の難易度が高まります。さらに、動的テストにはテスト環境の構築や対象コンポーネントのデプロイが必要であるため、静的テストに比べて準備に手間がかかります。静的テストは、コードの実行を伴わず、文書化された成果物があれば早期に欠陥を特定できる利点があります。
静的テストの主な利点は以下の通りです。
・動的テストの前段階で効率的に欠陥を検出・修正できる
・動的テストでは発見しにくい欠陥を特定可能
・要件の不整合や曖昧性、矛盾、欠落、不正確性、冗長性を明らかにし、設計やコーディング時の欠陥混入を防止
・設計や保守性の向上を通じて開発生産性を向上
・開発コストと時間の削減
・テストにかかる時間とコストの削減
・ライフサイクル後半やリリース後に発見される欠陥を減少させ、ソフトウェア全体の品質コストを削減
・レビューを通じてチームメンバー間のコミュニケーションが向上
効果的なレビューを行うためには、ソフトウェアの内部構造を理解することが重要であり、それによってさらに多くの欠陥を特定できる可能性があります。ただし、レビューの成果は、参加者の知識や利用するチェックリストなどのノウハウに依存します。レビューの効率を高めるためには、経験豊富なレビューアーを選任したり、ナレッジベースを活用したチェックリストを準備することが効果的です。
静的テストと動的テストの違い
静的テストと動的テストはどちらも「作業成果物の品質評価」と「欠陥の早期識別」を目的としていますが、それぞれ異なるタイプの欠陥を発見できるため、相互に補完し合うことで効果が最大化されます。その違いを理解するために、例を挙げてみましょう。
精密機械の設計では、歯車の間に「バックラッシュ」と呼ばれる隙間（遊び）が必要です。この知識がない設計者が図面を作成すると、隙間がないために動かない機械ができてしまいます。しかし、図面を確認する段階でバックラッシュを知っている人がいれば、その欠陥を指摘できます。これが静的テストによる欠陥識別の例です。一方、適切なバックラッシュの量は実際に機械を動作させて確認しないと分からない場合もあります。これが動的テストによる故障の発見に該当します。
静的テストの特徴として、直接的に欠陥を識別できることが挙げられます。一方、動的テストは、欠陥が引き起こす故障を検出するのが主な役割です。また、静的テストは動的テストよりもはるかに低コストで欠陥を発見することができます。特定の条件下でしか実行されないコードに潜む欠陥を動的テストで見つけるには、多数のテストケースを用意し、条件が一致した場合にのみ検出可能です。
静的テストと動的テストの得意分野は以下の通りです。
・静的テスト
▫ 要件や設計の整合性、不整合、内部品質の確認に適している
▫ コードの効率性やセキュリティ脆弱性の特定に効果的
▫ 低コストで欠陥を早期に発見可能
・動的テスト
▫ パフォーマンスやユーザビリティ（使用感）の確認に向いている
▫ 実際の動作を通じて振る舞いを外部から検証
静的テストで発見しやすい欠陥の例
・要件の欠陥：不整合、曖昧性、矛盾、欠落、不正確性、冗長性
・設計の欠陥：非効率なアルゴリズム、高結合度、低凝集度
・コードの欠陥：未定義または未使用の変数、到達不能コード、コードの重複
・標準からの逸脱：コーディング規約の違反
・インターフェースの誤り：システム間で異なる単位が使用されている
・セキュリティの脆弱性：バッファオーバーフローなど
・テストベースの不備：受け入れ基準に対するテストケースの不足
これらの欠陥は、静的テストを通じて早期に発見できるため、開発後期や本番環境での修正コストを大幅に削減できます。また、ソフトウェアの再利用時や保守性向上においても、静的テストが有効です。モジュール化の適切性や再利用時に新たな欠陥が混入していないかを確認する作業は、静的テストが主に担います。
静的テストと動的テストを組み合わせることで、ソフトウェアの品質向上とコスト削減を両立することが可能です。
※練習問題：