Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

114 vues

Publié le

ソフトウェア基礎講座資料

Publié dans : Formation
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

  1. 1. 第7回「デバッグ」 2011年7月22日(金) 服部 健太 ソフトウェア・テスト入門
  2. 2. デバッグの過程  テストケースに成功した(テストケースによって エラーが発見された)後に行う仕事  2つの部分からなる: 1. プログラム内で疑わしいエラーの正確な性質とあ り場所を決める 2. エラーを修正すること 2011/7/222 ソフトウェア・テスト入門7
  3. 3. プログラマがいやがる理由  「エゴのないプログラミング」を実践していない 人は,心理的に困難を感じる  すべてのソフトウェア開発のなかで,もっとも精 神的に負担のかかる仕事  プログラムのどの部分にもエラーが存在しうる  デバッグに関する研究・論文・指導書は少ない. 2011/7/223 ソフトウェア・テスト入門7
  4. 4. 力ずくのデバッグ  何も考えないデバッグ  もっとも効率がわるく,うまくいかないことが多 い  記憶域ダンプによるデバッグ  printfをちりばめるデバッグ  デバッガによるデバッグ  他のすべての方法がうまくいかなかったとき  あるいは他の思考過程の補助として用いる 2011/7/224 ソフトウェア・テスト入門7
  5. 5. 帰納法によるデバッグ 2011/7/22ソフトウェア・テスト入門75  糸口から出発し,それらの糸口間 の関係をみつけることによって, エラーへたどりつけることが多い 適切な データを 見つける データを 組織化す る 関係を調 べる 仮説をた てる 仮説を証 明する エラーを なおす できる できる できない できない
  6. 6. 帰納法によるデバッグ(2) 2011/7/22ソフトウェア・テスト入門76 1. 適切なデータを見つける  プログラムが正しくおこなったことと誤っておこなっ たことをについてわかっていることをすべて列挙する  似ているが異なるテストケースで,その兆候を「しめ さない」もの 2. データを組織化する  パターンと矛盾をみつけるためにデータを構造化する ? である ではない 何が どこで いつ どこまでの範囲か
  7. 7. 帰納法によるデバッグ(3) 2011/7/22ソフトウェア・テスト入門77 3. 仮説をたてる  糸口間の関係をしらべてエラーの原因なる1つ以 上の仮説を案出する(パターンをつかう)  もし仮説がたてられなければ,追加のテストケー スを実行して,さらにデータを得る 4. 仮説を証明する  仮説が妥当であることを証明することが重要 (焦ってこの段階を飛ばしてはいけない)  もとの糸口やデータと比較し,この仮説が完全に 糸口の存在を説明できることを確認すればよい.  そうでなければ,仮説が間違っているか,不完全 なのか,複数のエラーがあるかのどれか
  8. 8. 試験採点プログラムのデバッグ例 2011/7/22ソフトウェア・テスト入門78  報告されたエラー:  中央値が全部ではないが,一部まちがっている  あるテストケースでは,51人の学生の成績で,平均点は73.2 と正しく印字されているが,中央値は予想値の82ではなく26 と印字されている ? である ではない 何が レポート3に印字されている 中央値は正しくない 平均または標準偏差の計算 どこで レポート3のみ 他のレポート上.学生成績は 正しく計算されているようだ いつ 51人の学生をつかったテスト でおきた 2人と200人の学生のテストで はおきなかった どこまで の範囲か 印字された中央値は26である. 1学生をつかったテストでも おきた.この場合,中央値と して1が印字された
  9. 9. 試験採点プログラムのデバッグ例(2) 2011/7/22ソフトウェア・テスト入門79  エラーについての仮説をたてる(パターンと矛盾を みつける)  学生数が奇数のときのテストケースだけエラーが起きて いる  計算された中央値がいつも学生数に等しいかより小さい  もう一度51人の学生のテストケースをまえとちがった成 績を与えて実行してみる  もし,この結果も26だったら,さらに貴重な糸口が得られる  「このプログラムは学生の成績ではなく,真ん中に位置 する学生の番号を印字しているのではないか?」  たてた仮説を証明する  追加的なテストケースを実行する  コーディングを調べる
  10. 10. 推定によるデバッグ 2011/7/22ソフトウェア・テスト入門710  一般的な見解や前提からはじめて,消去や改善の 過程をつかうことによって,結論にたどりつく 可能な原 因を列挙 する 消去過程 をつかう 残ってい る仮説を 改善する 残ってい る仮説を 証明する エラーを なおす もっと データを 集める できない できる 残って いない
  11. 11. 推定によるデバッグ(2) 2011/7/22ソフトウェア・テスト入門711 1. 可能な原因や仮説を列挙する  エラーについてすべての考えうる原因のリストを作成する 2. データをつかって可能な原因を消去する  データを注意ぶかく分析し,矛盾をさがして,可能な原因 のなかから1つを残してすべてを消去するように努力する  すべてが消去されるようなら新しい説をたてるために別の 追加のデータが必要となる  1つより多い原因が残った場合は,もっとも可能性の高い原 因,重要な仮説をまず選択する 3. 残っている仮説を改善する  この仮説を,より限定されたものに明確化するための可能 な糸口を探す 4. 残った仮説を証明する
  12. 12. dumpコマンドのデバッグ例 2011/7/22ソフトウェア・テスト入門712  テストケース  最初のテストケースに関して,可能な原因を列挙する 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
  13. 13. dumpコマンドのデバッグ例(2) 2011/7/22ソフトウェア・テスト入門713  原因を消去する  2番目のテストケースから仮説1の可能性を消える  3番目のテストケースから仮説2,3も消える  残っている4番目の仮説を改善する  このプログラムは16進数表現が認識できないのではないか?  そもそも4番目のテストケースではなぜ存在しない番地のデー タを表示できたのか?  オペランドを10進数の値として扱っているのかもしれない?  3番目のテストケースがこの仮説を裏付けている  改善された仮説「入力オペランドのバイト数と記憶域番地, および,出力上の記憶域番地を10進数の値として扱ってい る」  仮説を証明する  4番目のテストケースの結果を説明できる  2番目のテストケースの結果も説明できる
  14. 14. 逆もどりデバッグ 2011/7/22ソフトウェア・テスト入門714  小さなプログラムに対して有効  プログラムの論理をとおして正しくない結果につい て逆もどりし,その論理があやまっている点を発見 できるまでつづける  思考過程の例:  正しくない結果が生まれた場所から出発  この地点で観察された出力からこのプログラムの変数がもたな ければならない値は何かを推定する  「もしこの地点でプログラムの状態がこれであったら, ここより前の地点ではプログラムの状態がこうでなけれ ばならない」という過程を繰り返し使う  期待どおりである点と最初に期待どおりでなくなった点 との間にエラーがある
  15. 15. テストによるデバッグ 2011/7/22ソフトウェア・テスト入門715  疑わしいエラーの位置を示すのに役立つ情報を得る ことを目的にテスト・ケースを作る  あやしいエラーの兆候が発見されたら,その位置を 示すのにこの方法を使う  もともとのテスト・ケースから派生されたものを書くこ とによって行う  単独でつかわれるよりも,むしろ,帰納法や演繹法 とむすびつけてつかう  仮説をたてたり仮説を証明するのに必要な情報を得るた め,うがった原因を消去するため,仮説を改善したり仮 説を証明するため,etc.
  16. 16. エラー位置発見の原則 2011/7/22ソフトウェア・テスト入門716  考えよ  デバッグは問題解決型の過程である  エラーの兆候と関係ある情報を頭のなかで分析する  いきづまったときは,明日までのばそう  適当な時間内(小さなプログラムで30分,大きな もので2~3時間)にエラーをみつけられないとき は,なにかほかのことをやりなさい  いきづまったときはその問題を他人に説明しよう  単にその問題を良い聞き手に説明するだけで,聞き 手からの助言なしに突然解答を得ることがよくある
  17. 17. エラー位置発見の原則(2) 2011/7/22ソフトウェア・テスト入門717  デバッガは2番目の手段として使おう  思考のかわりではなく補助としてそれを使いなさい  実験を避けよう.実験は最後の手段である  プログラムを実験的に変更して問題を解決しようと してはならない  プログラムに新しいエラーが加わって問題を複雑に することが多い.
  18. 18. エラー修正の原則 2011/7/22ソフトウェア・テスト入門718  1つのバグがあるところには,別のエラーもある可能性が 高い  エラーはかたまって存在する  エラーを修正するとき,ほかにも怪しいところがないかその 付近をしらべてみよう  エラーの兆候ではなく,エラーそのものをなおそう  エラーの表面的な現象だけを修正しないこと.  修正が正しいという確率は100%ではない  エラー修正はもとのプログラムの場合よりもっと厳密にテス トしなければならない  修正が正しい確率は,プログラムが大きいほど落ちる  ひろくつかわれているある大きなプログラムで,新しく発見 されるエラー6個のうちの1つは,まえにプログラムを修正し たときのエラーである
  19. 19. エラー修正の原則(2) 2011/7/22ソフトウェア・テスト入門719  エラー修正は新しいエラーを生む可能性があることに注意 しよう  正しいと思われる修正でも,新たなエラーを導くような場合 がある  修正したあとで,新しいエラーが生まれてないかどうかを判 定するための「回帰テスト」もしなければならない  エラー修正のとき,しばらく設計段階にもどってみよう  設計過程でつかわれている手順・手法・公式化をエラー修正 過程にも応用すべきである  例えば,エラーを修正したあとでもコード検査をすることが 重要  オブジェクトコードではなくソースコードを修正しよう  プログラムをコンパイルしなおしたときエラーが再発する
  20. 20. エラー分析 2011/7/22ソフトウェア・テスト入門720  発見されたエラーを詳細に分析することで,プログ ラマや組織はおおいに成長できる.  分析の例: 1. いつエラーがおきたのか 2. だれがエラーをつくったのか 3. 何が誤っておこなわれたのか 4. どうすればそのエラーを防げたか 5. なぜそのエラーは早期に発見されなかったか 6. どうすれば,このエラーはもっと早く発見できたか 7. どのようにしてそのエラーが発見されたか
  21. 21. 次回予定(最終回)  日にち  2011年7月29日(金)  時間  10:30~12:00  場所  LB/2FA  内容  テスト道具とその他の手法 2011/7/2221 ソフトウェア・テスト入門7

×