このレポートには Go2Group synapseRT のパフォーマンス ベンチマークの結果が記載されます。レポートにはテスト環境、テスト シナリオ、テスト データ、テスト結果などの情報が含まれます。

 目的

テストを実行することで製品のパフォーマンス上のボトルネックを見つけ、パフォーマンス結果を得ることで次のバージョンと比較するためのベンチマークとして使用すること。

対象読者

  • synapseRT製品チーム
  • synapseRT ユーザー

テスト環境

ハードウェアおよびシステム

OS

Windows 10 Pro 64 ビット

プロセッサ

Intel(R) Xeon(R) CPU E3-1231 v3 @3.40GHz

CPU コア

4

メモリ

32.0 GB

ソフトウェア

JIRA Server

JIRA Core 7.2.3

synapseRT

V8.5.1

データベース

Oracle12c

ブラウザー

Firefox 47.02

テスト データ

Testing_Data_JIRA7.2.3_v8.4.3.1_0104(3000TCs&1000REQs&100TPs_REQHierarchyDone_TC&REQLinkageDone).zip

テスト シナリオ

JIRA は Web ベースのサーバーであるため、パフォーマンス テストは大量のデータを使用したページの読み込み時間に焦点を合わせたものになっています。

大量のデータが用意されている以下のページを開き、ページの読み込み時間を記録します。

  1. [要件 (Requirements)] ページに移動します。
  2. [テスト スイート (Test Suites)] ページに移動します。
  3. [テスト計画 (Test Plans)] ページに移動します。
  4. [トレーサビリティ (Traceability)] ページに移動します。
  5. [synapseRT レポート (synapseRT Reports)] ページに移動します。
  6. 大量のテスト ケースがあるテスト計画にテスト サイクルを追加します。
  7. 大量のデータがあるテスト計画課題を開きます。
  8. 大量のテスト ケースがあるテスト サイクル ページを開きます。
  9. 大量のテスト ケースがあるテスト サイクルを開始します。
  10. 大量のテスト ケースで "一括操作" を開始します。
  11. [テスト計画 (Test Plans)]ページ  ([未解決計画 (Unresolved Plans)] タブ内) でテスト計画を展開します。
  12. 大量のテスト ケースをテスト スイートにリンクします。
  13. [テスト サイクル (Test Cycle)] ページを更新するためにテスト実行ダイアログ ボックスを閉じます。
  14. ガジェット : [ガジェットの編集 (Edit Gadget)] ページでテスト サイクルを読み込むためのテスト計画を選択します。
  15. 引き続き JIRA プロジェクトにテスト ケースをインポートします。
  16. 要件階層セットアップおよびテスト ケースの関連付けのある [要件 (Requirements)] ページから要件階層を展開します。

テスト結果

弊社ではこのベンチマーク テストを数回実行しました。各テストの結果はほぼ同じものでした。結果の一例を以下に示します。

テスト シナリオ

テスト データ

平均ページ読み込み時間

[要件 (Requirements)] ページに移動する

  • 要件の件数 : 1000
  • レベル 1 の要件の数 : 21
  • レベル 2 の要件の数 : 20 (L1 要件)*5+1(L1 要件)*79 = 179
  • レベル 3 の要件の数 : 16 (L1 要件)*5(L2 要件)*10(L3 要件) = 800
  • テスト ケースの数 : 300 (L3 要件) * 10 (テスト ケース) = 3000
  • テスト計画の数 : 5 (4 テスト サイクル、3000 テスト ケース)

4.64 秒

[テスト スイート (Test Suites)] ページに移動する

  • 合計 5 件のテスト スイート
  • 各テスト スイートには 600 件のテスト ケースが関連付けられている

2.27 秒

[テスト計画 (Test Plans)] ページに移動する

  • テスト計画の件数 : 100
  • テスト計画の件数 : 5
  • 各テスト計画に 3000 件のテスト ケースが追加されている (上記 5 件のテスト計画)
  • 各テスト計画に 4 件のテスト サイクル (上記 5 件のテスト計画) が作成され、"アクティブ" ステータスになっている
  • 残りの 95 件のテスト計画について、テスト ケースおよびテスト サイクルは追加されない

13.22 秒

[トレーサビリティ (Traceability)] ページに移動する

プロジェクト サイド バーから [トレーサビリティ (Traceability)] メニューをクリックする

1.43 秒

[synapseRT レポート (synapseRT Reports)] ページに移動する


1.22 秒

大量のテスト ケースがあるテスト計画にテスト サイクルを追加する

PTA-8100

  • テスト ケースの件数 : 3000

18 秒

大量のデータがあるテスト計画課題を開く

PTA-8100

  • テスト ケースの件数 : 3000
  • テスト サイクルの件数 : 4 (すべて "アクティブ" ステータス)
  • 網羅されている要件 : 3000

5.78 秒

大量のテスト ケースがあるテスト サイクル ページを開く

PTA-8100/テスト サイクル 1 (3000 テスト ケース)

  • テスト ケースの件数 : 3000

19.18 秒

大量のテスト ケースがあるテスト サイクルを開始する

PTA-8100/テスト サイクル 1 (3000 テスト ケース)

  • テスト ケースの件数 : 3000

50 秒

大量のテスト ケースで "一括操作" を開始する

PTA-8100/テスト サイクル 1 (3000 テスト ケース)

  • 単一の JIRA ユーザーに 3000 件のテスト ケースをすべて割り当てる

8 秒

[テスト計画 (Test Plans)]ページ  ([未解決計画 (Unresolved Plans)] タブ内) でテスト計画を展開する

PTA-8100

  • テスト ケースの件数 : 3000
  • テスト サイクルの件数 : 5 (すべて "アクティブ" ステータス)

5.76 秒

大量のテスト ケースをテスト スイートにリンクする

[パフォーマンス テスト] テスト スイート 8 (リンク)

  • テスト ケースの件数 : 600

12 秒

[テスト サイクル (Test Cycle)] ページを更新するためにテスト実行ダイアログ ボックスを閉じる

PTA-8100/テスト サイクル 1 (3000 テスト ケース)

  • 3000 テスト ケースを持つテスト サイクル

1 秒未満

ガジェット : [ガジェットの編集 (Edit Gadget)] ページでテスト サイクルを読み込むためのテスト計画を選択する

PTA-8100

  • テスト ケースの件数 : 3000
  • テスト サイクルの件数 : 3 (すべて "アクティブ" ステータス)

1 秒未満

引き続き JIRA プロジェクトにテスト ケースをインポートする

  • 1.) 1 回目、600 テスト ケース
  • 2.) 2 回目、600 テスト ケース
  • 3.) 3 回目、600 テスト ケース

1.) 2 分 50 秒

2.) 3 分 10 秒

3.) 該当なし

要件階層セットアップおよびテスト ケースの関連付けのある [要件 (Requirements)] ページから要件階層を展開する

  • 要件数の合計 : 1000
  • 一覧内の最初の 20 件の要件 (レベル 1 要件) について (既定で要件ページに表示されるもの) :
    • 各レベル 1 要件の直下に 5 件の子要件がある (レベル 2 要件)
    • 各レベル 2 要件の直下に 10 件の子要件がある (レベル 
    •  3 要件)
    • 各レベル 3 要件には 10 件のテスト ケースが関連付けられている

1.) [要件 (Requirements)] ページを開く :

4.44 秒

2.) レベル 2 要件を展開する :

434 ミリ秒

テストの結論

  1. 上記のデータは 1 回のテストを実行した結果に基づいています。弊社では複数回テストを実行しましたが、結果はほぼ同じであり、結果を立証したものとなっています。
  2. 次のステップ : 今後は同じ環境とスクリプトでテストを再実行し、次のバージョンとの比較のためにこのデータを使用します。
  3. 上記のデータを考慮すると、大量のテスト ケースのインポートには時間がかかっており、今後のリリースではこの面での製品パフォーマンスの改善の必要を感じています。ただし、データの負荷 (大量のデータ) を考えると平均データ負荷を超えており、待機時間はユーザーにとって許容範囲であると思われます。