このトピックでは、Siebel Web クライアントのテストを成功に導くため、共通の陥りやすい問題について説明し、ヒントを提供し、さらにベスト プラクティスを説明します。
読み取り専用トランザクションは、新しいレコードが挿入されない、かつデータが変更されないトランザクションです。読み取り専用トランザクション用に記録されたスクリプトは変更をせずに実行します。
しかし、このようなスクリプトは、値配列の解析関数を含む場合があります。たとえば、解析関数は、テーブルの 3 番目のレコードの値配列を解析するかもしれません。このテーブルの再生時に、レコード数が 3 レコードより少ないと、値配列を解析できずに再生エラーとなる可能性があります。このような状況は、存在する値配列が解析されるように、解析関数の出現パラメータを調整することによって避けることができます。
しかし、よりよい解決策は、データベースの各テーブルに負荷テスト時に十分なレコードが含まれていることを保障することで、問題を完全に回避することです。
書き込みトランザクションは、新しいレコードを挿入したり、既存のレコードの値を変更するトランザクションです。
書き込みトランザクションのスクリプトは、再生の成功を保証するために、最低限のカスタマイズが必要となります。これは、新しいレコードの値配列がサーバー レスポンスから解析されることができるためです。
再生を成功させるために修正が必要な場合、Siebel の多くのテーブルはレコードの重複を許さないためという理由が一般的です。Siebel がレコードが重複しているとみなされる状況は、テーブルによって異なります。ほとんどの場合、レコードがユニークであるとみなすには、レコード フィールドのある組み合わせが Siebel に対して異なっている必要があります。
再生を成功させるために、スクリプトの試行の実行時でさえ、これらのフィールドを変更すべきです。これは、Web Recorder がこれらの値を変数として作成するとき、簡単に行うことができます。
スクリプトの試行の実行では、これらの値をスクリプトで直接手動で変更することで十分です。しかし、テストの場合、各仮想ユーザーがユニークな値の組み合わせでレコードを挿入するように、データ ファイルを準備して、スクリプトをカスタマイズする必要があります。
空のテーブルにレコードを挿入することによって生成された HTTP トラフィックは、すでにレコードが存在するテーブルにレコードを挿入することによって生成された HTTP トラフィックとは明らかに異なります。このため、殻のテーブルにレコードの挿入を記録するスクリプトは、一旦テーブルにレコードが追加されると、後で再生セッション中に使用することはできません。これは逆も同様です。
このような問題を避けるために、切ろうセッション中に空のテーブルにレコードを挿入しないことを保障します。また、負荷テストの前、または最中にテーブルが空にならないように保障します。
次のシナリオはこれらの制約による影響を受けないことにご注意ください。