自分の体をメンテナンスしているとき オラクルBRM (請求および収益管理) 構成をしばらく続けていると、構成されたエンティティの量が増え続けていることに気付き始めます。この頃には、いくつかのカスタマイズを開発し、追加のソリューションと統合している可能性が非常に高くなります。環境の進化は、複雑に絡み合ったオブジェクトのクラスタにつながります。あなた、あるいはあなたのクライアントが何かを変更することを決定するときが来ます。新しい機能を開発するのは、最初は簡単に思えるかもしれません。しかし実際は、既存の機能と衝突したり、既存の設定の更新が必要になったりする可能性が非常に高いのです。単純な変更と思われたものが、システム全体に影響を及ぼすのです。このような事態を避けることは時に困難ですが、それに対する準備をしておくことで、多くのトラブルを避けることができます。機能テストシナリオとテストの汎用性は、大きな変化をもたらします。
継続的開発の流れ
Tridensでは、継続的な開発フローを確立しています。すべてのBRMコンフィギュレーション、カスタマイズ、その他の統合コンポーネントは適切にバージョン管理され、分散バージョン管理システム(Git)で追跡されています。この実践により、開発者は必要なコンポーネントのバージョンをいつでもチェックアウトし、作業を開始することができます。ここまではすべて順調ですが、新機能が現在のビルドを壊してしまう可能性にどう対処すればよいでしょうか?

私たちはデプロイとテストのフローを設定し、ソースのリモートリポジトリを追跡しています。その結果、開発者が変更をコミットしてバージョン管理にプッシュするたびに、テストプロセスが開始されます。デプロイフローは、ローカル(またはリモート)環境に最新バージョンのすべての関連コンポーネントの docker イメージをビルドし、ビルドが安定していることを確認するために自動テストを実行します。テストが成功して初めて、新バージョンを本番環境にリリースできます。このプロセスは、新機能が既存機能とシームレスに動作することを保証するのに役立ちます。実行されるテストは、私たちが開発したOracle BRM TestToolkitの一部です。BRM TestToolkitには、背景となるグルーコードを持つ定義済みのステップとシナリオがあります。ステップは非常に記述的でユーザーフレンドリーであるため、当社の開発者や他のユーザーが新しいテストシナリオを素早く書くことができます。下の画像でテストシナリオの例をご覧ください。

自動テストのためのBRM TestToolkit
アカウント作成と商品購入のための単純なテストシナリオとして始まったものが、今日、BRM TestToolkitのテストのメインフレームとなっています。明確にするために、私たちは現在、実装された機能を最大限にカバーするために、いくつかの異なるテストケースとフリンジケースのシナリオを持っています。自動化されたテストのおかげで、開発者は手作業によるテストに膨大な時間を費やすことなく、目の前のタスクに集中することができます。もちろん、まだテストシナリオでカバーされていない新機能を開発することもあります。そのような場合、テストステップの定義とその背景となるコードは、その機能の一部として実装されます。
TestToolkitは、異なるコンポーネントと通信できるため、他のシステムでも迅速な調整が可能です。また、BRM TestToolkit の再設計バージョンを他のコンポーネントにも使用しています。私たちが追加した最新の機能の一つはモジュール化で、開発者は異なるテストシナリオをグループの一部としてタグ付けすることができます。各グループにはスクリプトと分離されたロジックがあり、必要に応じて、特定の数のテストだけを一度に並行して実行することができます。さらに、モジュール化により、プリペイド評価テストとポストペイド評価テスト、またはアドオン購入テストとその他購入テストを分離することができます。下の画像にテストの流れを示します。

テストシナリオカバレッジ
BRM TestToolkit は、より複雑な操作を簡素化するために Oracle BRM と統合した API と通信します。また、TestToolkit は BRM RestBridgeこれは、REST API を介して JSON または XML フォーマットを使用できるようにすることで、BRM との通信を容易にします。テスト・ステップ定義は、特に以下の操作をサポートしています:
- アカウントの作成と管理
- ディール購入およびその他のディール業務
- 残高照会とチェック
- トラフィック発生 - 利用イベント
- APIコール
- CDRドロップオフ
- リアルタイムトラフィックツール(diameterプロトコル)
- 格付けチェック
- BRM TestToolkit は、さまざまな使用イベントと購入品を期待値と比較します。
- 異なるプランや商品ごとに独自のレーティングファイルセットを持つことができるため、複雑な商品設定でも汎用性が確保されます。
ユーザーフレンドリーなテストステップを構成することで、各開発者は開発中の機能のシナリオを書くことができます。多くの場合、開発者は機能を開発する前に、テストシナリオを事前に設定することを選択します。事前にシナリオを準備することは、Behaviour Driven Development(BDD)パターンに従います。BDDは基本的に、シナリオが開発の流れを決定し、事前に存在することを意味します。これらのシナリオはシステムがどのように振る舞うべきかを記述し、開発者はこれらのシナリオに適合する方法で新機能を開発しなければなりません。各テストシナリオを個別に実行することができ、その結果、指定された形式のレポートが作成されます。下記はHTMLレポートの例です。

報告する
システムが新しい開発ビルドの一部としてテストシナリオを実行するとき、通常、すべてのテストを含めて、その潜在能力をフルに発揮させます。環境によっては、これには時間がかかりますが、新機能が他の既存の実装にどのような影響を与えたかについて、大まかな情報を得ることができます。BRM TestToolkit がテスト実行の最後に生成するテストレポートから、ビルドの安定性を評価することができます。テストレポートには、各テストシナリオの詳細だけでなく、すべてのテスト全般に関する統計や分析も含まれています。この分析を使用して、ビルド間の差異を見つけたり、ビルドが正しく動作していることを確認したりすることができます。以下にレポートの例を示します。

結論
適切なテストソリューションを持つことは、膨大な時間を節約し、不必要なバグの発生を防ぐことができます。したがって、もしあなたがこの記事で述べたような問題に悩んでいたり、私たちのTesting BRM Toolkitに興味があれば、お気軽に私たちにご連絡ください。私たちのソリューションについて詳しくご説明し、お客様のデプロイとテストフローを改善するための最適なプランをご提案させていただきます。