第４章 問題の再現
デバッグするには、まず問題の再現が必要ってことを、３章より掘り下げて書いた章ですね。
目次
4.1 デバッグの最初の作業
4.2 問題環境の再現
4.3 プログラム実行の再現
4.3.1 データの再現
4.3.2 ユーザの対話操作の再現
4.3.3 コミュニケーションの再現
4.3.4 時刻の再現
4.3.5 乱数の再現
4.3.6 動作環境の再現
4.3.7 スケジューリングの再現
4.3.8 物理現象の影響
4.3.9 デバッグツールの影響
4.4 システムとの対話の再現
4.5 ユニットに注目する
4.5.1 コントロール層の構成
4.5.2 制御の例
4.5.3 モックオブジェクト
4.5.4 さらなるユニット間の対話の制御
4.6 クラッシュの再現
4.7 本章のまとめ
4.8 ツール
4.9 さらに詳しく学ぶ
練習問題
まず大事なのが、問題の再現を、以下２つに分けて考えること。混合しないこと。
- 環境の再現
- 実行の再現
環境の再現は意外と面倒なのだけど、以下の観点で行えとのこと。
まーそれはそうですよね。OSのレベル変えたりとか、出来ればしたくないですしね。。
あと、一気に変えるより徐々に変えた方が、問題の原因を判明しやすいですね。
- (以前の障害報告から推測した結果)最も問題の発生に関係すると考えられるもの、かつ
- 簡単に変更できるもの(そして元に戻せるもの)
実行の再現に関しては、コントロール層を導入して、入力機能の呼び出しを補足しろって話。具体的に補足対象となるのは、以下。
- データ
- ユーザ入力
- コミュニケーション
- 時刻
- 乱数
- 動作環境
- プロセススケジューリング
(意図しない影響をプログラムに与える可能性のあるもの)
- 物理現象
- デバッグツール
この辺、いまいちこの本だとまとまってなくて分かりづらいんだけど、
例えばLinuxであればstraceを使ってシステムコールを監視しろとかみたいな話。
straceの出力使って、再生も行えるって書いてあるんだけど、
出力結果のシステムコールをCとかに書いて実行しろってことかな？多分。
ちなみにAIX等のUNIXだとtrussですね。
その辺は、以下がよくまとまってます。
http://yourpalm.jubenoum.com/archives/468
どのユニットで問題が発生してるかまで絞り込めているのであれば、
クラスの継承使ってコントロール層作れって話が4.5節。
メソッドをオーバーライドして、トレースログ吐き出すようにしろって話。
Cみたいなクラス機能がない言語だと、直接ソースコード書き換えるしかないですがね。。。
記録結果からモックオブジェクト作れば、再現テスト可能ですねって話。
あとはユーザーとのやり取りはあんましいいツールが無いとか。
一応紹介されてるのはHP社製のWinrunnerとか。
私は使ったことないんだけど、有名なんですかね？
最後にプログラムがクラッシュした時について。
この場合は、通常はクラッシュした時点で呼ばれてた関数がログとして残るのだけど、
クラッシュ前のステータスは記録しないので、工夫が必要って話。
使ったことないから分からないけど、JavaだとReCrashってツールを使うのかな？
この章はちょっといまいち。
部分的にツールの紹介とかもしてるんだけど、十分に踏み込めていない感じ。
体系的な説明にするか、具体的な説明にするか、どっちつかずになっちゃってる。
大学のテキストとして使うなら、こっから発展学習するにはいいのかな？
あんまし深くやってると時間ばかりかかるので、とりあえず先進みます〜。
