デバッグ・テスト支援ツールと品質の測り方
デバッグ・テスト支援ツール（静的解析・テストカバレージ分析・トレーサ・アサーションチェック）の役割を見分け、バグ管理図のグラフから品質が安定しているかを判定できるようになる。あわせて、移植性・使用性・保守性などの品質特性を、定義や施策・指標から選べるようになる。
ツール名と説明文を入れ替えた4択や、グラフを読んで品質を判定させる問題が、毎年のように形を変えて出る。実務でも、ベンダーの「テストは順調です」という報告をグラフで確かめるときに、そのまま使える見方。
このレッスンで稽古する（用語チェック・過去問）結論：まず「プログラムを動かすかどうか」で2つに分ける
テスト支援ツールは、プログラムを実行せずに調べる＝静的と、実行して調べる＝動的の2つに分かれる。試験の選択肢の大半は、この2つを入れ替えて作られている。
たとえるなら、静的解析は提出前の契約書を読んで誤字や矛盾を探すことで、動的テストは契約を実際に運用してみて不具合を探すこと。「実行時間」「実行回数」「実行された割合」のように実行という言葉が入った情報は、静的解析では絶対に取れない。
| 分類 | ツール | 何をするか | 見分けるキーワード |
|---|---|---|---|
| 静的（実行しない） | 静的解析ツール | ソースコードを読んで、文法の誤りや論理的な誤りを検出する | 「ソースコードを分析」「実行せずに」 |
| 動的（実行する） | テストカバレージ分析ツール | コードのうち実行された部分の割合（網羅率）を測る | 「網羅率」「実行された割合」「実行されなかった命令」 |
| 動的 | プロファイラ | 呼び出し回数・実行時間・実行回数など、動いているときの特性を測る | 「実行時間」「呼出し回数」 |
| 動的 | トレーサ | 命令が実行された順序と結果の履歴を出力する | 「実行順序」「履歴」 |
| 動的 | アサーションチェック | 「この時点ではこの条件が成り立つはず」という式を埋め込み、実行中に確かめる | 「論理式を埋め込む」「成立する条件」 |
| テストの準備 | テストデータ生成ツール | 条件に合ったテストデータや入力ファイルを作る | 「データを生成」 |
| テストの準備 | ドライバ・スタブ生成ツール | 単体テストで足りない呼び出し元・呼び出し先の代役を作る | 「ドライバ」「スタブ」 |
静的解析ツールで見つかるもの・見つからないもの（最頻出）
静的解析ツールは、コードを読むだけで分かる問題を見つける。たとえば「代入したのに後で一度も使われない変数」は、コードを上から読めば分かるので検出できる（2010年の問題の正解）。
| 静的解析で検出できる | 静的解析で検出できない |
|---|---|
| 文法の誤り | 関数ごとの実行時間（→プロファイラ） |
| 使われない変数への代入 | テストで実行されなかった命令（→カバレージ分析） |
| 初期化していない変数の参照 | 仕様書に書かれた処理の記述漏れ（仕様と照らす必要がある） |
| コーディング規約違反 | 実行中のメモリの中身（→ダンプ・トレーサ） |
「仕様に対応する処理の記述漏れ」はひっかけ。ツールは仕様書を知らないので、レビューやテストで見つけるしかない。
テストカバレージ分析・トレーサ・アサーションチェック
テストカバレージ分析ツールは、ホワイトボックステスト（中身のコードを見ながら行うテスト）で、コードのどれだけが実行されたかを％で出す。「割合」「網羅率」とあればこれ。
トレーサは、命令がどの順で実行され、どんな結果になったかの履歴を出す、飛行機のフライトレコーダーのような道具。似た名前のダンプ（中身の書き出し）と混同させられる。
| 道具 | 出すもの | いつ出すか |
|---|---|---|
| トレーサ | 実行順序・実行結果の履歴 | 実行中ずっと |
| メモリダンプ | メモリの内容 | エラーで止まったとき |
| スナップショットダンプ | 指定したメモリの内容 | 指定した命令を実行するたび |
| ファイルダンプ | ファイルの内容 | 必要なとき |
アサーションチェックは、「ここでは必ず x > 0 のはず」という論理式（表明）をプログラムに埋め込み、実行中に破れていないかを確かめる手法。
バグ管理図：S字で頭打ちなら「安定」（グラフ問題の山場）
バグ管理図（信頼度成長曲線ともいう）は、横軸にテスト項目の消化件数、縦軸に累積バグ件数をとったグラフ。テストを進めるとバグが見つかり、やがて新しいバグが出なくなって曲線が**頭打ち（水平）**になる。
| グラフの形 | 意味 | 判定 |
|---|---|---|
| S字で上の方が水平に近づく | テストしても新しいバグがほぼ出ない | 品質が安定しつつある |
| 右上がりの直線 | 同じペースでバグが出続けている | 未安定 |
| 下に凸（だんだん急になる） | バグの出方が増えている | まだ多くのバグが潜んでいる |
| 右下がり | 累積件数は減らないので、この形はありえない | 論外 |
大事なのは目標件数に届いたかではなく、曲線が寝てきたか。急な上り坂のまま目標値に届いても、「目標達成＝品質良好」とは言えない。
なお、テストの進捗そのものは「計画したテスト項目のうち、何件消化したか」で管理する。テストデータの作成量や修正量は進捗の指標にならない。
ソフトウェア品質特性：言葉の意味と測り方を結びつける
品質特性は、ソフトウェアの良さを観点別に分けたもの（現行は JIS X 25010、古い問題は旧規格の用語）。定義だけでなく、「どの施策や指標が、どの特性に効くか」の形でも問われる。
| 品質特性 | ひとことで | 施策・指標の例 |
|---|---|---|
| 移植性 | 別の環境（別アーキテクチャのコンピュータ）へ持っていきやすい | 変更が必要な行数 ÷ 移植する行数 |
| 使用性 | 利用者が分かりやすく、覚えやすく、使いやすい | オンラインヘルプを充実させる |
| 保守性 | 修正や変更がしやすい（旧規格の「変更性」はこの一部） | 修正時間の合計 ÷ 修正件数（平均修正時間） |
| 信頼性 | 壊れにくく、壊れても困らない | 成果物の誤り件数 ÷ 成果物の量、データの複製を分散配置 |
| 相互運用性（現行は互換性に含む） | 他のシステムとつながりやすい | 外部インタフェースを見直して連携先を増やす |
| 機能適合性 | 必要な機能がそろっている | 機能を追加して利用範囲を広げる |
見分け方は、「別の環境へ移す」なら移植性、「直す」なら保守性、「他とつながる」なら相互運用性。
バグ管理図で「品質が安定しつつある」グラフを選ぶ
ア [図] 横軸テスト項目消化件数，縦軸累積バグ件数。原点付近から緩やかに立ち上がり，上に凸でなく下に凸（加速的に増加）の曲線。
イ [図] 横軸テスト項目消化件数，縦軸累積バグ件数。左上の高い位置から右下へ減少し，0 に近づく下に凸の減衰曲線。
ウ [図] 横軸テスト項目消化件数，縦軸累積バグ件数。原点から右上がりの直線。
エ [図] 横軸テスト項目消化件数，縦軸累積バグ件数。原点から S 字（ロジスティック）状に増加し，上方で頭打ちになって水平に近づく曲線。
解き方と答えを見る
- 軸を確認する：横軸＝テスト項目の消化件数、縦軸＝累積バグ件数。累積なので、値が減ることはない。
- イ（右下がり）を消す：累積件数は減らないので、この形はありえない。
- ウ（直線）を判定する：テストを進めても同じペースでバグが出続けているので、まだ安定していない。
- ア（下に凸・だんだん急になる）を判定する：バグの出方がむしろ増えているので、最も危ない状態。
- エ（S字で上が水平に近づく）を判定する：テストを消化しても新しいバグがほとんど出なくなっているので、収束に向かっている。
答え：エ。累積バグ曲線が頭打ちになっていることが、品質安定の目安になる。
目標件数に届いたグラフの状況を判定する
ア テスト工程が順調に終了したことを示す。
イ テスト前段階での机上チェックやシミュレーションが十分にされていることを示す。
ウ まだ多くのバグが内在している可能性があることを示す。
エ 目標のバグ累積件数が達成されたので，出荷後にバグが発生する確率が低いことを示す。
解き方と答えを見る
- 曲線の形を見る：下に凸で、右へ行くほど傾きが急になっている。
- 傾きの意味を考える：傾き＝テスト1件あたりに見つかるバグの数。それが増え続けている。
- 目標値に到達したことの意味を考える：目標の件数に届いても、曲線が寝ていない（頭打ちになっていない）ので、収束していない。
- 選択肢を照らす：ア「順調に終了」、エ「出荷後のバグが少ない」は、収束していないので誤り。イ「事前チェックが十分」なら、もっと早くバグが減っているはずなので誤り。
答え：ウ。まだ多くのバグが潜んでいる可能性がある。
要点（試験直前に読む）
- 静的解析は「実行しない」。分かるのは文法の誤りや、使われない変数への代入など。実行時間・網羅率・仕様の漏れは分からない。
- 「実行された割合（網羅率）」はテストカバレージ分析、「実行時間・回数」はプロファイラ、「実行順序の履歴」はトレーサ。
- アサーションチェックは、成り立つべき条件の論理式をプログラムに埋め込み、実行中に確かめる手法。
- バグ管理図は、S字で頭打ちなら品質が安定。直線や急な上り坂は、目標件数に届いていても未安定。進捗はテスト項目の消化件数で測る。
- 品質特性は、別の環境へ移すなら移植性、使いやすさなら使用性（ヘルプを充実）、直しやすさなら保守性（平均修正時間）。
ひっかけ
- 静的解析の問題で、ア＝テストデータ生成、イ＝網羅率計測、エ＝実行特性の計測が並ぶ。「ソースコードを分析」と書かれた選択肢だけが静的解析。
- 「仕様に対応する処理の記述漏れ」はツールで検出できそうに見えるが、ツールは仕様書を知らないので静的解析の答えにならない。
- トレーサの問題では、ファイルダンプ・メモリダンプ（エラー時）・スナップショットダンプ（指定命令ごと）が並ぶ。「履歴」「実行順序」がトレーサ。
- バグ管理図で「目標値に到達＝順調・出荷後も安心」は罠。曲線がまだ急に上っていれば、バグが残っている。
- 品質特性の施策・指標の問題では、信頼性（データの分散配置・誤り密度）、相互運用性（連携先を増やす）、機能適合性（機能を追加）がひっかけとして並ぶ。
用語（17）
プログラムを実行せずにソースコードを読み、文法の誤りや使われない変数などの論理的な問題を見つける道具。
⚠ テストカバレージ分析やプロファイラは実行してから測る動的な道具。「実行時間」「実行された」とあれば静的ではない。
プログラムを動かさずに調べるのが静的テスト、実際に動かして調べるのが動的テスト。
⚠ 選択肢の文に「実行」「計測」が入っていたら動的と見る。
テストでコードのどれだけの部分が実行されたかを、網羅率として測る道具。
⚠ 静的コード解析は実行しない。「割合」「網羅率」とあればカバレージ分析。
テストで実行された命令や分岐が、全体の何％にあたるかを表す数値。
プログラムの内部の構造（命令や分岐）を見ながら、それが正しく通るかを確かめるテスト。
⚠ ブラックボックステストは、中身を見ずに入力と出力だけで確かめる。
モジュールの呼び出し回数や実行時間など、動いているときの特性を測る道具。
⚠ 網羅率を測るのはカバレージ分析ツール。時間や回数を測るのがプロファイラ。
単体テストで、まだ無い呼び出し元の代役がドライバ、呼び出し先の代役がスタブ。
⚠ これらを生成する道具は、テストの準備を支援するもので、静的解析ではない。
命令が実行された順序と実行結果の履歴を出力するデバッグ用の道具。
⚠ ダンプは「ある時点のメモリやファイルの中身」を出すもの。順序の「履歴」を出すのがトレーサ。
エラーでプログラムが止まったときに、メモリの内容を書き出すこと。
⚠ スナップショットダンプは、エラーとは関係なく、指定した命令を実行するたびに書き出す。
プログラムの指定した命令を実行するたびに、指定したメモリの内容を書き出すこと。
⚠ メモリダンプはエラーで止まったときに出す。実行の履歴を出すのはトレーサ。
ある時点で成り立つべき条件を論理式としてプログラムに埋め込み、実行中に正しさを確かめる手法。
⚠ 「論理式を埋め込む」とあればこれ。網羅率を測るのはカバレージ分析。
テスト項目の消化件数に対して累積バグ件数を描いたグラフで、頭打ちになれば品質が安定してきたと判断する。
⚠ 目標件数に届いたかではなく、曲線が水平に近づいたかで判断する。
計画したテスト項目のうち、実施を終えた件数で、テストの進捗管理に使う。
⚠ テストデータの作成量やプログラムの修正量は、進捗の指標ではない。
別のアーキテクチャのコンピュータなど、異なる環境でも動くようにしやすい度合い。
⚠ 相互運用性は他システムとつながりやすいこと。変更性（保守性の一部）は直しやすいこと。
利用者が理解しやすく、覚えやすく、使いやすい度合い。
⚠ 連携先を増やすのは相互運用性、機能を増やすのは機能適合性、データを分散配置するのは信頼性の施策。
修正や変更がしやすい度合いで、平均修正時間（修正時間の合計÷修正件数）などで測る。
⚠ 誤り件数÷成果物の量は信頼性の指標。変更行数÷移植行数は移植性の指標。
他のシステムと情報をやり取りして連携しやすい度合い。
⚠ 別の環境に持っていくのは移植性。
このレッスンの過去問
- 静的解析ツールで検出できる事項平成31年度 春期 基本情報技術者試験 午前 問48
- テストカバレージ分析ツールの役割平成25年度 春期 基本情報技術者試験 午前 問22
- トレーサ(デバッグツール)の機能基本情報技術者試験 科目A免除 修了試験 20170611 実施分 問20
- アサーションチェックの定義平成25年度 秋期 基本情報技術者試験 午前 問49
- バグ管理図によるテスト進捗・品質判断平成29年度 春期 基本情報技術者試験 午前 問53
- ソフトウェア品質特性の定義(移植性等)平成22年度 春期 基本情報技術者試験 午前 問52