2022/4/11
製品
カテゴリー
タグ
2201 Views
評価部隊とDT+Trace環境を共有し効率的に不具合解析を行う方法
リリース後に指摘のあった不具合では、取得できる情報が少なかったり開発者の手元での再現作業が難航したりと、解析が困難になるケースが多い傾向になります。また「突然リブートする」「処理が想定より時間がかかる」といった、現象だけでは関連するコードが特定しにくいものが多いことも特徴です。
例えばそのような状況で評価部隊から不具合の現象とともにDT+Traceのログが送付されることで、開発者の解析作業をスムーズに行えるようになります。このFAQでは、SQAなどの評価部隊とDT+Trace環境を共有しDT+Traceのログを活用する方法について説明します。
Contents
運用イメージ
テストポイントが挿入された状態のソフトウェアを評価部隊と共有します。DT+Traceのファイル書き出しを利用すれば、この状態で評価部隊が操作した際に実行された処理などのログが残ります。さらに開発者はそのログを受け取りDT+Traceで解析することで、不具合発生時の処理や実行経路、変数値といった情報が見えるようになります。
まとめると、以下の図のようなイメージになります。
またファイル書き出しではテストポイントが実行されるたびに、DT+Traceのドライバでfwrite関数を実行しログをファイルに書き出していますが、今回の方法ではテストポイント通過時にはログをいったんドライバ内で確保したバッファに書き込み、特定の操作を行った後にfwrite関数が実行されバッファの内容がファイル化される形となります。
このようにすることで、異常動作時のみログをファイル化できるようになります。
見込める効果
開発者の不具合解析にかかる時間の短縮
DT+Traceで取得した情報があることで、「実行されてはいけない処理が実行されている」「特定の関数の呼び出し回数が想定より多い」「意図しないタイミングで処理が割り込んでいる」といった情報が取得できますので、どの処理を解析するべきかが明確になります。
関連メンバーの拘束時間の減少
現象が複雑であればあるほど、再現させた評価部隊のメンバだけでなく様々なモジュールの担当者への確認が必要となり、そのためのMTGやバグ管理ツールでのやり取りが増えます。そして解析期間が長引くほどそのような拘束時間が増えてしまいますが、DT+Traceで現象発生時のログがあることで要因となる処理の絞り込みを効率化できますので、そのような関連メンバの工数を減らすことができます。
評価部隊が操作を行う際にDT+Traceの操作は必要ないため、新たにツールの操作を覚える必要がないことも特長です。
セットアップ
以下の手順で行っていきます。詳細はそれぞれの節で説明します。
[事前準備]ログをファイル化するための操作の用意
「運用イメージ」のとおり、ドライバ内で格納されたデータをファイル化するトリガーとなる操作を予め決めておきます。ターゲット機器に応じてボタンやスイッチを使用してください。なお、誤って操作しないよう正常時にあまり行わない操作の方が好ましいです。
[事前準備]ファイルのやり取りを行う場所(手順)の準備
現象が再現した際に、評価部隊から開発者へDT+Traceのログファイルを共有する必要がありますので、そのための場所や手順を取り決めておくとやり取りがスムーズです。バグ管理ツールをご使用の場合は対応するチケットなどは発生した現象と対応するログを一緒に管理でき、なおかつ関係者が誰でも閲覧できるため便利です。
DT+Traceアプリケーションの設定
-
接続方式を「ファイル書き出し」に設定
DT+Traceの「プロジェクト設定」画面から、「接続方式」が「ファイル書き出し」となっていることを確認します。
-
テストポイントの調整
ドライバ内で確保できるバッファサイズは限りがありますので、テストポイントが多すぎると現象発生時に見たい箇所のログが存在しなかったり、少なすぎると現象の把握ができない、といったことが考えられます。
例えば以下のような調整方法があります。
-
関数の入り口と出口
関数単位で処理の遷移・実行時間や周期時間は計測可能な状態
-
タスクやスレッドの切り替え位置(イベントID出力ポイント：OSのコード内)
タスク・スレッドの割り込みのタイミング
以下は、Linuxのカーネルコード(コンテキストの切り替え位置:sched.cもしくはcore.c)に挿入した例です。
-
関連する変数値(変数値出力テストポイント)
現象から類推される、関連のある変数をモニタリングできます。
-
-
ファイル書き出しのフォーマット設定
「ファイル」メニューの「インポート」から「ファイル書き出しで取得したレポートデータ」を選択し、設定画面を開きます。
ファイル書き出しでは、ひとつのテストポイントの出力データを4Byte / 8Byte / 16Byte /18Byteのいずれかで指定できます。これは、「設定画面」の「データフォーマット」を選択すると設定が可能です。
サイズが小さいほどバッファに格納できるテストポイントの個数は増えますが、サイズが大きいもののようにコア情報やタスク／スレッドの情報は格納できません。上記のテストポイントの調整と合わせ、検討してください。
※なお、変数値出力テストポイント使用時は8Byte以上を、タスクやスレッドの情報、コア情報を取得する場合は18Byteを指定する必要があります。
テストポイント用ドライバの調整
サンプルドライバのダウンロード
| 対応OS | 接続方式 | 言語 | イベントID出力方式 | ダウンロード |
|---|---|---|---|---|
| Windows | ファイル書き出し | C/C++ | ダウンロード |
サンプルドライバではテストポイントの情報をバッファに格納するためのアルゴリズムが用意されていますが、上記の「ファイル書き出しのフォーマット設定」を変更した場合は、ドライバの調整が必要になります。
以下を参考にして、_TP_BusOut関数内の該当箇所を調整してください。
またドライバ内にある_TP_BufOut関数は、バッファに格納したデータをファイル化するための関数で、ターゲット機器側の処理で呼び出す必要があります。
「1．[事前準備]ログをファイル化するための操作の用意」で用意した操作のハンドラなどで、この関数を呼び出してください。
その他
テストポイントを挿入した状態でリリースする是非について
この手順では、評価部隊にテストポイントを挿入した状態でリリースすることが前提となっています。「テストポイントを入れた状態のものでリリースして良いのか」についてはお客様からよくある質問のひとつですが、
- 解析に時間がかかる(と推測される)不具合の発生時のみテストポイントを挿入した状態でリリースする
- 常にテストポイントを入れてリリースし、実動作でのカバレッジの取得に使用している(不具合解析以外にも活用している)
といった形で、お客様によって対応が分かれる部分でもあります。
いずれにしても、このFAQのような手法を確立しておくことで予期せぬ不具合が発生したときの解析手段を持っておくことが重要です。