現場で役立つ 実践デバッグ手法
すべての開発者が避けては通れない「デバッグ」。
HW/SWに依存しないデバッグ手法について、日ごろデバッグで心掛けていること、経験上のノウハウをまとめて紹介します。
トラブルが発生したら
「基板に電源をいれたら全く動かない。」「プログラムを実行したら誤った動作をしている。」など、トラブルが発生した瞬間は「えっ、そんなはずはない」「ちゃんと見直しもしたし、正しく動くはず。なんでなんで・・・どこにバグ(問題)あったの?」っと、あせってしまい頭が真っ白になってしまいます。
みなさんならこんな時どうしますか? まずは上司、チームリーダに報告?
トラブル発生
まずは落ち着く
先ほどの例のように「○○がおかしい。」「○○が動いていない。」など、曖昧な報告は避けてください。曖昧な報告で作業を進めてしまうと、その後の確認事項のやり取りや想像での作業が増えて、余計に時間がかかってしまうことがあります。
バグ(問題)が見つかったことを早く報告したいという気持ちもわかりますが、あせってもいいことはないので、まずは深呼吸をして落ち着いてから、デバッグ(問題解決)プランを考えていきましょう。
・まさに今デバッグを行っていて、この記事を読んでいる人
・ここまでの記事を読んで、昔の記憶がよみがえった人
心を落ち着けるために、一度深く深呼吸してからこの後の記事に進んでみましょう。
正確な情報を集める
上司も確認していましたが、的確な報告を行うには、まずバグ(問題)の発生状況について以下の確認が必要です。外部に確認依頼を出すにしても、最低限これらの具体的な情報が必要です。
- どの作業で起きたか。
- どういった手順で起きたか。(再現手順を確立する)
- 正常(期待する)動作はなにか。(本来の正しい動作を理解する)
- 正常動作と何が違うのか。(本当に問題の動作なのか再確認する)
- どの環境(基板)で起きたのか。(正しい環境なのか再確認する)
- 別の環境(基板)でも起きるのか。(単発なのか潜在的問題の可能性があるのか)
- 個体/全体の発生頻度はどのくらいか。(どの程度の影響範囲なのか)
これらの情報はあって困ることはないので、これ以外にも必要だと思ったものは積極的に確認を行ってください。ここまでまとめられたら報告を行いましょう。
電源ICでトラブルがあった場合の例ですが、当社では以下のような確認を行っています。
情報の再確認(裏付け)をする
報告が終わってひと段落したら、今度はその情報を再確認します。いきなり問題点に踏み込んでいくのではなく、すぐにわかることから調査を始めましょう。下記は確認項目の一例ですが、確認項目の洗い出しには、「もし○○という問題だったとしたら・・・」と仮説を立てて、進めていくとアプローチ方法がいろいろと出てきます。
- バグ(問題)の再現
- 確実に再現する方法を探る
- 基板の見直し
- 電源を確認する
- クロックを確認する
- 基板の設定の確認(ディップスイッチなど)
- 回路図の見直し
- ICの設定
- 抵抗・コンデンサなどのIC周辺の定数の確認。
特にデータシートに指定定数があるものは再度、正しいかどうか確認
この確認時は「何を・何回やって・どういう結果になったのか」を必ず記録につけましょう。記録方法は「星取表」を使うと、確認回数や確認項目漏れを防ぐことが出来て便利です。
この記録は作業の整理や発生頻度の再確認に役立ちます。
仮説を立てて検証をする
ここまでくるとある程度、問題の再現方法やその時に発生する現象がしぼれてきますので、ここからはその現象が発生する原因の仮説とその確認方法を考えてみましょう。
ここでは“LCDが映らない”問題を例に考えてみましょう。
事象:機器に電源を入れてもLCDが表示されない。映ってもノイズがのる。
よくある間違いはこれまでに電源やクロックをチェックしているので、もうHWは大丈夫と判断してしまい、いきなり表示用のデバイスの設定をチェックし始めることです。
そうしてしまうと表示用のデバイスとLCDパネル間に問題があった場合には、ほぼ見つけることは不可能でどんどんデバッグの深みにはまってしまいます。
この項目でのポイントは問題が起きているところから順に現象(信号)を逆に追っていくことです。
仮説①:LCDパネルが壊れているかもしれない。
仮説②:本体とLCDパネル間のケーブルが断線しているかもしれない。
仮説③:LCDモジュールに入力している映像信号がおかしいのかもしれない。
仮説④:表示用のデバイスが出力している映像信号がおかしいのかもしれない。
仮説⑤:表示用のデバイスの設定がおかしいのかもしれない。
なかなかバグ(問題)が見つからないときは
いろいろと仮説を立てて検証を行っても、なかなかバグ(問題)が見つからないときは、次のことを試してみてください。
- 関係者に説明(相談)する。
- これまでの経緯・確認内容・結果を誰かに話してみてください。相談者からヒントをもらえるかもしれません。ただ、それ以上に役に立つのは説明を行うための「内容の整理・理解」です。
この作業の中から今まで気づかなかった新たなアイデア・テスト方法を思いつくことがあります。
- これまでの経緯・確認内容・結果を誰かに話してみてください。相談者からヒントをもらえるかもしれません。ただ、それ以上に役に立つのは説明を行うための「内容の整理・理解」です。
- 最初から手順をやり直してみる。
- 2枚以上の基板をつなげてテストを行っている場合は、基板を組み立てなおす。
- 基板に電源を入れっぱなしでデバッグ作業を行っている場合、一度電源を切って、本当の初期状態からテストをやり直すことで挙動が変わり、糸口が見つかることがあります。
- この時の経験上のポイントとしては、ACアダプタなどの電源を元から切ることと、電源を切って一定以上(30分ぐらい)の時間をあけてからテストを再開することです。
- わざと失敗してみる。
- テスト手順を1つ飛ばしてみる。確認作業をランダムにやってみるなど、通常とは違った方法を試すことで挙動が変わり、糸口が見つかることがあります。
- この際は再現手順がわからなくならないように、どのテストを飛ばしたのか、どの順番でやったのかは必ず記録に取りましょう。
- 思い込みをすてる。
- 先の説明で「仮説を立てて確認をする」と言いましたが、一度これらの仮説・思い込みをすてて違った目線でテストをすることも重要です。
それでもバグ(問題)が見つからないときは
デバッグに行き詰ったときの最終手段です。
「一度、リフレッシュしましょう。」
ここまでやってもなかなか成果が出ない場合は、リフレッシュすることで新しい気持ちで最初からデバッグに取り掛かれます。そのことで新たな発見の手助けにもなります。
ただし、本当に休んでしまう前に最後にもうひと踏ん張りして、次にスムーズにデバッグを開始できるように準備をしておきましょう。
- もう一度、設定・環境を見直す。
- 本日の記録を整理・保存する。
- 作業スペースを確保する。(ラボルームの予約)
- 作業機材を確保する。(機材の予約)
- その他の予定がないか確認する。
担当エンジニアからの一言
今回はみなさんが一度は経験したことがあるデバッグのあれこれについて紹介しました。バグ(問題)が見つかった時、そのデバックに行き詰った時にどうすればいいか。意外にそういう時の考え方、デバッグの方法って知られてないよね。ということで記事にしてみましたが、我々の社内のエンジニアのノウハウが、少しでも皆さんのお役に立てればうれしく思います。