ソフトウェア・テスト入門7

第7回「デバッグ」
2011年7月22日（金）
服部健太
ソフトウェア・テスト入門

デバッグの過程
 テストケースに成功した（テストケースによって
エラーが発見された）後に行う仕事
 ２つの部分からなる：
1. プログラム内で疑わしいエラーの正確な性質とあ
り場所を決める
2. エラーを修正すること
2011/7/222 ソフトウェア・テスト入門７

プログラマがいやがる理由
 「エゴのないプログラミング」を実践していない
人は，心理的に困難を感じる
 すべてのソフトウェア開発のなかで，もっとも精
神的に負担のかかる仕事
 プログラムのどの部分にもエラーが存在しうる
 デバッグに関する研究・論文・指導書は少ない．

力ずくのデバッグ
 何も考えないデバッグ
 もっとも効率がわるく，うまくいかないことが多
い
 記憶域ダンプによるデバッグ
 printfをちりばめるデバッグ
 デバッガによるデバッグ
 他のすべての方法がうまくいかなかったとき
 あるいは他の思考過程の補助として用いる

帰納法によるデバッグ
2011/7/22ソフトウェア・テスト入門７5
 糸口から出発し，それらの糸口間
の関係をみつけることによって，
エラーへたどりつけることが多い
適切な
データを
見つける
データを
組織化す
る
関係を調
べる
仮説をた
てる
仮説を証
明する
エラーを
なおす
できる
できる
できない
できない

帰納法によるデバッグ(2)
1. 適切なデータを見つける
 プログラムが正しくおこなったことと誤っておこなっ
たことをについてわかっていることをすべて列挙する
 似ているが異なるテストケースで，その兆候を「しめ
さない」もの
2. データを組織化する
 パターンと矛盾をみつけるためにデータを構造化する
？であるではない
何が
どこで
いつ
どこまでの範囲か

帰納法によるデバッグ(3)
3. 仮説をたてる
 糸口間の関係をしらべてエラーの原因なる1つ以
上の仮説を案出する（パターンをつかう）
 もし仮説がたてられなければ，追加のテストケー
スを実行して，さらにデータを得る
4. 仮説を証明する
 仮説が妥当であることを証明することが重要
（焦ってこの段階を飛ばしてはいけない）
 もとの糸口やデータと比較し，この仮説が完全に
糸口の存在を説明できることを確認すればよい．
 そうでなければ，仮説が間違っているか，不完全
なのか，複数のエラーがあるかのどれか

試験採点プログラムのデバッグ例
 報告されたエラー：
 中央値が全部ではないが，一部まちがっている
 あるテストケースでは，51人の学生の成績で，平均点は73.2
と正しく印字されているが，中央値は予想値の82ではなく26
と印字されている
？であるではない
何がレポート3に印字されている
中央値は正しくない
平均または標準偏差の計算
どこでレポート3のみ他のレポート上．学生成績は
正しく計算されているようだ
いつ 51人の学生をつかったテスト
でおきた
2人と200人の学生のテストで
はおきなかった
どこまで
の範囲か
印字された中央値は26である．
1学生をつかったテストでも
おきた．この場合，中央値と
して1が印字された

試験採点プログラムのデバッグ例(2)
 エラーについての仮説をたてる（パターンと矛盾を
みつける）
 学生数が奇数のときのテストケースだけエラーが起きて
いる
 計算された中央値がいつも学生数に等しいかより小さい
 もう一度51人の学生のテストケースをまえとちがった成
績を与えて実行してみる
 もし，この結果も26だったら，さらに貴重な糸口が得られる
 「このプログラムは学生の成績ではなく，真ん中に位置
する学生の番号を印字しているのではないか？」
 たてた仮説を証明する
 追加的なテストケースを実行する
 コーディングを調べる

推定によるデバッグ
 一般的な見解や前提からはじめて，消去や改善の
過程をつかうことによって，結論にたどりつく
可能な原
因を列挙
する
消去過程
をつかう
残ってい
る仮説を
改善する
残ってい
る仮説を
証明する
エラーを
なおす
もっと
データを
集める
できない
できる
残って
いない

推定によるデバッグ(2)
1. 可能な原因や仮説を列挙する
 エラーについてすべての考えうる原因のリストを作成する
2. データをつかって可能な原因を消去する
 データを注意ぶかく分析し，矛盾をさがして，可能な原因
のなかから1つを残してすべてを消去するように努力する
 すべてが消去されるようなら新しい説をたてるために別の
追加のデータが必要となる
 1つより多い原因が残った場合は，もっとも可能性の高い原
因，重要な仮説をまず選択する
3. 残っている仮説を改善する
 この仮説を，より限定されたものに明確化するための可能
な糸口を探す
4. 残った仮説を証明する

dumpコマンドのデバッグ例
 テストケース
 最初のテストケースに関して，可能な原因を列挙する
1. このプログラムはdumpを受け入れない
2. このプログラムはピリオドを受け入れない
3. このプログラムはデフォルトとして第1オペランドをとりあ
げていない
4. このプログラムは，Eを有効なバイト数とみなさない
テストケース入力予想出力実際の出力
dump .E 000000=0000 4444 8888
CCCC
M1: 無効のコマンド構文
dump 21-29 000020=0000 4444 8888
CCCC
000020=4444 8888 CCCC
0000
dump .11 000000=0000 4444 8888
CCCC
000010=0000 4444 8888
CCCC
000000=0000 4444 8888
CCCC
dump 8000-END M2:必要な記憶域が実際の記
憶域限界をこえている
008000=0000 4444 8888
CCCC

dumpコマンドのデバッグ例(2)
 原因を消去する
 2番目のテストケースから仮説1の可能性を消える
 3番目のテストケースから仮説2,3も消える
 残っている4番目の仮説を改善する
 このプログラムは16進数表現が認識できないのではないか？
 そもそも4番目のテストケースではなぜ存在しない番地のデー
タを表示できたのか？
 オペランドを10進数の値として扱っているのかもしれない？
 3番目のテストケースがこの仮説を裏付けている
 改善された仮説「入力オペランドのバイト数と記憶域番地，
および，出力上の記憶域番地を10進数の値として扱ってい
る」
 仮説を証明する
 4番目のテストケースの結果を説明できる
 2番目のテストケースの結果も説明できる

逆もどりデバッグ
 小さなプログラムに対して有効
 プログラムの論理をとおして正しくない結果につい
て逆もどりし，その論理があやまっている点を発見
できるまでつづける
 思考過程の例：
 正しくない結果が生まれた場所から出発
 この地点で観察された出力からこのプログラムの変数がもたな
ければならない値は何かを推定する
 「もしこの地点でプログラムの状態がこれであったら，
ここより前の地点ではプログラムの状態がこうでなけれ
ばならない」という過程を繰り返し使う
 期待どおりである点と最初に期待どおりでなくなった点
との間にエラーがある

テストによるデバッグ
 疑わしいエラーの位置を示すのに役立つ情報を得る
ことを目的にテスト・ケースを作る
 あやしいエラーの兆候が発見されたら，その位置を
示すのにこの方法を使う
 もともとのテスト・ケースから派生されたものを書くこ
とによって行う
 単独でつかわれるよりも，むしろ，帰納法や演繹法
とむすびつけてつかう
 仮説をたてたり仮説を証明するのに必要な情報を得るた
め，うがった原因を消去するため，仮説を改善したり仮
説を証明するため，etc.

エラー位置発見の原則
 考えよ
 デバッグは問題解決型の過程である
 エラーの兆候と関係ある情報を頭のなかで分析する
 いきづまったときは，明日までのばそう
 適当な時間内（小さなプログラムで30分，大きな
もので2～3時間）にエラーをみつけられないとき
は，なにかほかのことをやりなさい
 いきづまったときはその問題を他人に説明しよう
 単にその問題を良い聞き手に説明するだけで，聞き
手からの助言なしに突然解答を得ることがよくある

エラー位置発見の原則(2)
 デバッガは2番目の手段として使おう
 思考のかわりではなく補助としてそれを使いなさい
 実験を避けよう．実験は最後の手段である
 プログラムを実験的に変更して問題を解決しようと
してはならない
 プログラムに新しいエラーが加わって問題を複雑に
することが多い．

エラー修正の原則
 1つのバグがあるところには，別のエラーもある可能性が
高い
 エラーはかたまって存在する
 エラーを修正するとき，ほかにも怪しいところがないかその
付近をしらべてみよう
 エラーの兆候ではなく，エラーそのものをなおそう
 エラーの表面的な現象だけを修正しないこと．
 修正が正しいという確率は100％ではない
 エラー修正はもとのプログラムの場合よりもっと厳密にテス
トしなければならない
 修正が正しい確率は，プログラムが大きいほど落ちる
 ひろくつかわれているある大きなプログラムで，新しく発見
されるエラー6個のうちの1つは，まえにプログラムを修正し
たときのエラーである

エラー修正の原則(2)
 エラー修正は新しいエラーを生む可能性があることに注意
しよう
 正しいと思われる修正でも，新たなエラーを導くような場合
がある
 修正したあとで，新しいエラーが生まれてないかどうかを判
定するための「回帰テスト」もしなければならない
 エラー修正のとき，しばらく設計段階にもどってみよう
 設計過程でつかわれている手順・手法・公式化をエラー修正
過程にも応用すべきである
 例えば，エラーを修正したあとでもコード検査をすることが
重要
 オブジェクトコードではなくソースコードを修正しよう
 プログラムをコンパイルしなおしたときエラーが再発する

エラー分析
 発見されたエラーを詳細に分析することで，プログ
ラマや組織はおおいに成長できる．
 分析の例：
1. いつエラーがおきたのか
2. だれがエラーをつくったのか
3. 何が誤っておこなわれたのか
4. どうすればそのエラーを防げたか
5. なぜそのエラーは早期に発見されなかったか
6. どうすれば，このエラーはもっと早く発見できたか
7. どのようにしてそのエラーが発見されたか

次回予定（最終回）
 日にち
 ２０１１年７月２９日（金）
 時間
 １０：３０～１２：００
 場所
 ＬＢ／２ＦＡ
 内容
 テスト道具とその他の手法

ソフトウェア・テスト入門7

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to ソフトウェア・テスト入門7

Similar to ソフトウェア・テスト入門7 (20)

More from Kenta Hattori

More from Kenta Hattori (20)

Recently uploaded

Recently uploaded (8)

ソフトウェア・テスト入門7