客先でしか発生しない不具合で困ってます・・・
エンジニアあるあるの解決法

ユーザーのみなさまから「お客様のところでしか発生しない不具合で困っている」という相談をよく受けます。客先や市場に出した場所で、ひたすら再現確認を繰り返す…。海外に納品した製品の不具合検証のため、いつ帰れるのか先の見えない出張をしなければならない…。すでに自分たちの手を離れ市場に出回っている製品では、不具合再現時の詳細な解析情報を得ること、自社にある環境で不具合を再現させることは、多くの時間を必要とし、たいへん困難な作業となります。

そういうときこそ「動的テストツールDT10」(以下、DT10)が、お客様にとって希望の光となることを我々は知っています。そこで今回は、市場に出した製品に対しても、DT10を適用し簡単に詳細ログを取得する設定方法やドライバのカスタマイズ方法を紹介します。みなさまの想定外の工数・出張経費が削減できることを望みます。

製品の動作ログをカンタンに残せる方法

「ファイル書き出し」で、もしものときのログデータを受け取れるようにする

DT10のファイル書き出しを使用することで、テストポイントの情報がファイルに出力され、納品物(市場に出荷した製品)であってもテストポイントの情報が出力できます。もしも不具合が発生した場合は、お客様からDT10のログファイルを受け取り、DT10がインストールされている手元のPCで不具合時の実行経路や変数値などの解析ができます。

とはいえ、納品物に対してテストポイントを入れることで、パフォーマンスが低下してしまいます。また、ログデータを出力する分だけ余分にROM容量も確保しなければなりません。このあたりも、DT10のテストポイントの設定や出力処理(ドライバ)を工夫することで最小限に抑えることができますので、ご安心ください。

テストポイントの量を調整する

まずは、ターゲットのソースコードに挿入するテストポイントの数を検討する必要があります。ターゲットのパフォーマンスへの影響やログデータのファイルサイズを抑えつつ、必要な情報を取得できる「いい塩梅」を見極めます。難しいポイントですので、ここは実際にやられているユーザー様の例を踏まえ、以下のやり方で検討してみましょう。

まずは1番の方法で絞り込んでみて、同時に2番と3番の方法を使ってテストポイントを絞り込みます。このようにすると不具合時の関数の遷移が見れるため、解析しやすいと思います。変数値に着目する4番の方法を使って、異常値をとっていないかなどの情報を取得し、関連する処理から不具合の解析を進めるという手もあります。

テストポイント出力サイズの選択

ファイル書き出しでは、ひとつのテストポイント当たりのログサイズを4Byteから18Byteまで選択できます。サイズが大きいほど、時間データやスレッド情報などを取得することができますが、それだけファイルサイズが大きくなります。不具合時は実行処理・経路の確認ができれば良いと割り切ってしまえば、最小の4Byteで良いです。

うまく運用するためのドライバのカスタマイズ

「ファイル書き出し」のサンプルドライバでは、常にテストポイントのデータをファイルに書き出していますので、ターゲットが実行されているとどんどんログファイルのサイズが大きくなります。納品物の環境ではこのサンプルドライバをそのまま適用することはできません。ドライバは何かしらカスタマイズ(工夫)が必要になりますが、納品物にも適用できる具体的な方法をいくつか紹介します。

テストポイントのデータをバッファにためておく

あらかじめリングバッファを確保し、「隠しコマンド」などお客様が普段行わない操作も用意します。テストポイント通過時はそのバッファにテストポイント情報を格納するだけですが、不具合が発生したときに「隠しコマンド」を使用してそのバッファの内容をファイルに書き出します。不具合が発生したらお客様にその操作を行ってもらい、DT10のログファイルが出力されるという流れになります。

メモリは消費してしまいますが、ファイルに書き出さない分オーバーヘッドを抑えることができ、不具合解析に必要な情報も残すことができます。一方、バッファの容量が小さすぎると、肝心の不具合のときの情報が取得できませんので、あらかじめ必要なバッファサイズを見極め確保する必要があります。メモリの容量に比較的余裕のあるターゲットに向いています。

テストポイントの出力する／しないを切り替えられるようにする

もうひとつ、「隠しコマンド」により出力のON/OFFを制御できるようにする方法をご紹介します。この方法では「隠しコマンド」のほかに、DT10のドライバで使用するフラグを用意します。正常動作時はフラグをOFFにしておき、「隠しコマンド」操作後はONにするようにします。一方ドライバの方では、OFFのときはテストポイントを通過しても何も処理しないようにしておき、フラグがONのときだけテストポイントのデータがファイルに書き出されるようにします。

不具合が客先で何度も再現することが前提とはなるので、頻度が低い場合はそもそも情報が取得できないリスクもありますが、正常動作時はテストポイントの影響を受けない方法になります。また、バッファを確保する必要もありませんので、オーバーヘッドやメモリ容量の都合上あまりコストをかけられないようなターゲットでも使用できます。

ファイルが一定サイズ以上になったらファイルを上書きする

テストポイントの情報を常にファイルに書き出しますが、同時にログデータファイルのサイズを監視し、一定サイズ以上になったらファイルを上書きする方法です。この方法ではテストポイントのデータを常にファイルに書き出しているため、不具合が発生した場合は、そのままログデータファイルをお客様から受け取ることができます。

テストポイントの出力処理のほかにファイルサイズを取得したり、必要に応じて上書きするなどほかの方法と比べてオーバーヘッドは若干大きくなってしまいますが、「隠しコマンド」やバッファを用意する必要がないため、最もとっつきやすい方法とも言えます。常にファイルに書き出している分、再現頻度が低い不具合にも対応できますので、最もオススメできる方法です。

特定のテストポイントをファイル書き出しの始点・終点にする

ファイルを上書きする上記の方法では、時間のかかる「ファイルを上書きする」という処理が、パフォーマンスが要求される処理の中で発生する危険もあります。そこで、ファイルを上書きするテストポイントをあらかじめ決めておくことで、そういったリスクを避けることができます。

この方法では、そのテストポイントを通過した時点でファイルを上書きします。それだけですと、ファイルのサイズが上限に達してしまう可能性もあるため、ファイルに書き出す始点と終点となるテストポイントを分けた方がよいでしょう。こうすることで、ファイルサイズを監視する処理を省略することができます。

まとめ

客先で発生した不具合は、自社で開発・テストしているときに比べて、原因を特定するための情報がとても少ないため、結果として大きく工数を割くことになってしまいます。そのような状況でも事前にテストポイントの設定やドライバの工夫をすることによって、納品物からでも実行処理や実行経路、変数の遷移を得ることができます。お客様からの指摘の操作などと突き合わせて確認することで、納品物の不具合の解析で大きく工数増加することを防げるのではないでしょうか。

今回ご紹介したドライバを試してみたいという方は、ぜひこちらまでお問い合わせください。