synapseRT for Jira パフォーマンス レポート

2019-09-25 (Wed)  •  By 伊藤  •  ドキュメント  •  synapseRT

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

目次

  1. 目的
  2. 対象読者
  3. テスト環境
    • ハードウェアおよびシステム
    • ソフトウェア
    • テスト データ
  4. テスト シナリオ
  5. テスト結果
  6. テストの結論

目的

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

対象読者

テスト環境

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

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 for Jira V8.5.1
データベース Oracle12c
Web ブラウザー Firefox 47.02

テスト データ

テスト シナリオ

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. 上記のデータを考慮すると、大量のテスト ケースのインポートには時間がかかっており、今後のリリースではこの面での製品パフォーマンスの改善の必要を感じています。ただし、データの負荷 (大量のデータ) を考えると平均データ負荷を超えており、待機時間はユーザーにとって許容範囲であると思われます。
  Previous

関連記事