もし私たちが、自分たちの オラクルBRM ソフトウェアを開発するには、開発プロセスに関するいくつかの要件を満たす必要があります。特に、優れたテストとデバッグの技術を開発プロセスに組み込むことが重要です。
テストとは、ソフトウェア製品のバグやエラーを発見するプロセスのことで、テスターが手作業で行うこともあれば、自動化することもあります。
デバッグ とは、コンピュータ・ソフトウェアやシステムの正しい動作を妨げる、コンピュータ・プログラム内の欠陥や問題を発見し、解決するプロセスのことです。基本的には、テスト段階で見つかったバグを修正するプロセスです。プログラマーまたは開発者がデバッグの責任を負い、自動化することはできません。
Oracle BRMポリシーオプコードカスタムコードのデバッグ
でポリシーオプコードをカスタマイズする場合 オラクルBRM コードをデバッグして潜在的なバグを見つけたり、コードの動作を解析したりすることがよくあります。いくつかの基本的な解析は、デバッグメッセージのロギングやログの解析で行うことができますが、より高度で強力な方法は、別のツールであるデバッガを使用することです。この記事では、オープンソースのデバッガ GDB を使用して、カスタムコードも実行する Oracle BRM cm プロセスをデバッグする方法を見ていきます（下の図を参照）。
ジーデービー はオープンソースのデバッガで、コードの解析とデバッグのために多くの高度で強力なツールを提供します。GDBの基本的な機能には、ブレークポイント（条件付き/無条件）、ウォッチ、バックトレース、インクリメンタルコード実行などがあります。もちろん、変数の値を見たり変更したり、さまざまな関数を呼び出したりすることもできます。では、実際にcmプロセスでGDBをどのように使うかを見てみましょう。
デバッグの実際
まず、CMプロセスのPIDを取得します：
psx
CMプロセスのPIDを見つけ、それを使ってGDBでそのプロセスに接続します：
gdb cm
GDBシェルが開き、GDBがサポートする様々なコマンドを実行することができます。CMへの新しい接続が確立されるたびに、親CMから新しい子CMプロセスが生成されます。GDB はこのような子プロセスも追跡します。GDBシェルで以下のコマンドを実行します：
(gdb) set follow-fork-mode child
ニーズによっては、detach-on-forkコマンドやattachコマンドも試してみるとよいでしょう。では、次の例のように、ポリシーのオペコード実装にブレークポイントを設定してみましょう：
(gdb) break fm_act_pol_post_reauthorize.c:192
今、ポリシー・オプコードの実行をトリガーすると、ブレークポイントによって中断されます（あるいは、それ以前に、新しい子プロセスが生成されたことが通知されます）。次に、next (abbr. n) や step コマンドを使って、コードの流れをステップ・バイ・ステップで追うことができます。変数の値に興味があれば、next(abbr. n)やstepを使って出力することができます：
を印刷します。
GDBのドキュメントや統合ヘルプに詳しく説明されています。それらがどのようにあなたの役に立つか、ぜひ調べてみてください。
