いま求められるソフトウェア静的解析・動的解析 第2回：「根拠ある作業」のため「ソフトウェア解析」ができること：いま求められるソフトウェア静的解析・動的解析 第2回（2/4 ページ）

動的解析の種類

　それでは、動的解析にはどのような手法があるのでしょうか？そしてそれを支えるツールにはどのようなものがあるのでしょうか？ 筆者になじみ深いLinuxのツールを例に上げながら具体的な説明をしていきます。

• メモリ使用量測定

　メモリ使用量は、設計時にある程度の予測を立てることは可能なものの、動的にメモリを確保・解放するソフトウェアを作製した場合、実行時にどれくらいメモリを使用しているかをあらかじめ想定することは非常に難しい課題です。

　そのため、実際に対象となるソフトウェアを動作させることにより、ヒープ使用量の推移、GC^＊1の動作状況、空きメモリのフラグメンテーションの状況などを測定することで、設計の妥当性を確認する必要があります。Linuxでは「valgrind」がメモリ使用量測定ツールとして有名です。

＊1 Javaにおけるガベージコレクション。自動的にヒープメモリを確保・解放する仕組み

• 並列処理に関連した問題の検出

　スレッドの並行処理には、デッドロックやタイミングに依存する不具合がつきものです。実行タイミング次第で発生するような不具合は、原因の特定とデバッグが非常に困難です。

　並行処理に関する問題は、デバッガ・ICEを使用したデバッグで解決することが主流ですが、実行時の各タスクやスレッドの実行状況や切り替わり状況を監視するトレースツールも解析・デバッグに有効なツールとなります。Linuxでは「ftrace/strace」がトレースツールとして有名です。また、「gdb/kgdb」が事実上Linuxの標準デバッガとして存在します。

• 速度性能測定

Linuxのプロファイリングビュワーツールの1つ、「kcachegrind」の解析結果画面

　速度性能に関しても、設計時にあらかじめ課題を特定・解決することが難しいことの1つです。みなさんもソフトウェアを動作させて初めて、速度性能の問題が顕在化した経験はお有りだと思います。

　どの関数がどのくらい呼びだされているのか、また、各関数がどのくらいの処理時間を専有しているのか、各種IOのためにウェイトしている時間は全体のどの程度を占めているのか、そのような各種解析を行うためのツールが存在します。Linuxではこれも「valgrind」が有名です。他に「oprofile」などが存在します。

• カバレッジの測定

　カバレッジ計測は、主に単体テストのテストケースの妥当性を確認する上で、あらかじめ設計されたテストケースが、対象となるソフトウェアのどれくらいのソースコードを実行対象としているかを測定するために用いられます。

　テストケースによるソフトウェアの動作を慎重にトレースすることでカバレッジを机上で計測することも可能ですが、ミスが起きやすく、また、膨大な作業量となります。そのため、通常は動的解析ツールを用いて、テストケースが意図した通りのカバレッジを達成しているかどうかの測定を行います。

　Linuxではgcovがカバレッジ測定ツールとして有名です。