<Insert Picture Here>




 アナタのアプリ性能改善の秘訣、オラクルが教えます!

日本オラクル株式会社
システム事業統括本部 System & Application Management ビジネス推進本部
セールスデ...
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。
また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは
できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン
ト(確約)する...
品質管理から始めるコスト削減
  品質コスト(予防コスト+評価コスト+失敗コスト)
        についてお考えですか?




                                                        ...
テスト工数の肥大化


• 開発の効率化が進む中
 – 開発プロセスの効率化
 – 開発資産の再利用
 – 標準化


• テスト工数は、増加し続けている。
 – 1%のプログラム修正でも、テストは100%行う必要がある。
 – テスト工数は、...
ソフトウェアの品質維持に赤信号

• 開発資産の共有化により、開発は短縮できたが
 – テストが複雑になる
 – 開発初期段階のテストを維持できず
 – アプリケーションを継続発展させ、品質維持は困難




                 ...
コスト削減は、テストにあり

• 今から、注視するべきはテストにあり

 – テスト管理による品質向上 +コスト削減 (予防コスト)

 – 自動化によるコスト削減 +品質維持 (評価コスト)

 – 性能管理による、サービス向上+コスト削減 ...
なぜ性能障害は恐ろしいのか

• とにかくコストがかかる
 – 実運用では再現が難しい
 – 修正コストが他の不具合の100倍のケースも
 – 開発スケジュールの混乱
   • 要件定義から見直しが必要な場合も
 – 突然のシステムダウン
  ...
負荷テストの重要性

• 事前見積もりと、実際の性能が異なる
 – ブラックボックス
    • 使用技術全ての把握は困難
    • 積算があてにならない
 – 機能性能要因の存在
    • 表示機能の一部追加によって大幅に性能劣化
 – ...
負荷テストとは

 • Webアプリケーションに対して大量のアクセスを発生させ、アプリケーション
   やハードウェア(インフラ)の機能が期待通りの性能を満たしているかを検証
   するテスト




                   ルー...
性能テスト

 • 目標スループットの負荷を与えた時のパフォーマンス、システムの振る舞い
   を評価し、限界値(限界ポイント)までテストを続け、限界値を見極める
 • 一般的な「負荷テスト」は性能テストのこと
                ...
どのシステムがボトルネックと考えられますか?
                                      AP
                            Web                          D...
ボトルネックを判断するためのマクロ情報

クライアント   ネットワーク機器            Webサーバ                         APサーバ    DBサーバ
 (ユーザ)




               ...
ボトルネックの現象・要因・対策
             性能限界時に顕著に
                                               主な劣化要因                        対策
   ...
性能テストを行なわないリスク

• 総合テスト段階で性能問題が発生すると、運用に入れなかった
  り、不安要素を抱えたままの運用開始に直面
      開発フェーズ

 要件                         単体        ...
開発の初期段階から性能テストを計画


     開発フェーズ

要件                         単体                 結合               総合    運用
                 ...
性能要件の策定

• 性能要件で考慮する項目
 – システムを使用する人数
 – 同時アクセス数
 – 受託開発かパッケージアプリケーションか


• 性能目標の確立
     最大同時アクセスユーザ数
 –
     最大処理ページ数/秒
 ...
システム設計での考慮点

• 性能要件を反映させる
 – サーバ構成
   • サイジングを行なう
 – ネットワーク構成
   • 性能目標と矛盾がないか確認
 – パラメータ値
   • 最大コネクション数
   • JVMヒープサイズ
 ...
システム設計での考慮点

• サーバ構成と性能要件
 – CPUとスループット
    • 目標 2,000PV/秒
    • 1台あたりの目標処理数 200PV/秒

 – メモリと同時アクセスユーザ数
    • 目標 同時1,000ユー...
詳細設計での考慮点

• 応答時間のブレークダウン
 – 単体レベルでの性能目標
   • サーブレットの処理時間など

 – プロファイラーの選定
    • 測定方法の明確化

 ✍重要なトランザクションは明確な指標を策定する




  ...
単体テストフェーズでの性能テスト

• 単体レベルで性能テストを行なわないリスク
 – 性能要件を満たさないシステム構築が行なわれる
   • GCでは解決できないメモリリーク
   • パフォーマンスの悪いSQL
   • CPUを大量に占有...
結合テストフェーズでの性能テスト

• スケジュール
 – 性能テストで考慮すべき工数
   • スクリプト作成                                  1日~1週間
   • データ準備               ...
結合テストフェーズでの性能テスト

• チーム構成
 – テスト担当者
    • システム構成をよく理解している
    • システムアーキテクトを理解している
    • テストツールの操作が行える
    • 基本的な結果グラフを見て問題...
結合テストフェーズでの性能テスト

• テストの準備
 – 負荷テストツールを理解する
   • 仮想ユーザのスクリプト作成
      – フリーツールでは十分なシミュレーションができない
      – プログラミング必要だと準備工数増加
...
結合テストフェーズでの性能テスト

• テストの準備
 – テスト用データの作成
    • ログインを個別に行える
    • 十分な検索が行える
    • 繰り返しテストが行える




                         ...
結合テストフェーズでの性能テスト

• テストの実施
 – テストを始める前に、低負荷での接続確認
 – 1つのテストは30~60分
 – 段階的にユーザ数を上げる
    • 100ユーザー最大のテストを行う場合は、10ユーザー毎ぐらいで増加...
結合テストフェーズでの性能テスト

• 結果の分析
 – ボトルネック検出のための情報収集
   • 応答時間とスループットの情報分析が基本
   • 各サーバからリソース情報を収集する
 – ボトルネックを明確にするには様々の追加試験が必要と...
総合テストフェーズでの性能テスト

• 目的
 – 本番と同等のデータを使用して実環境でテストする
 – バックエンドの機能も稼働させる
    • バッチ
    • メール配信
    • ファイル転送など


• 結合テストがうまくいって...
ソフトウェアテストは未知の世界

• Webアプリケーションの発展はここ数十年
 – 未熟なエリア
 – いつか当然となるソフトウェア品質


• 性能向上の鍵は負荷テスト
                              負荷テスト...
<Insert Picture Here>




Oracle Application Testingのご紹介




                                                             ...
エンピレックスからオラクルへ

• 高い実績と強力なノウハウの継承
     2008年6月 オラクルに統合
 –
     エンピレックスは、Web負荷テストの国内でのトップベンダー
 –
     年間60件以上のテストコンサルティングの実...
テスト・プロセス管理の簡素化
   ~ Oracle Test Manager for Web Applications ~

ソフトウェアやハードウェアの品質に関わる情報を一元管理することにより、テスト資産の活用、組織
ソフトウェアやハードウ...
Webアプリケーションに対する負荷テスト
    ~ Oracle Load Testing for Web Applications ~

多数のユーザからのアクセスを擬似しWebアプリケーションの性能検証を実現。運用を開始する前に、
多数の...
機能・回帰テストの自動化を実現
    ~ Oracle Functional Testing for Web Applications ~

WebアプリケーションやWebサービスの品質を確保する最短の方法として、テストプロセスの自動化を
W...
データベースの構成変更時のテストを効率化
        ~ Oracle Real Application Testing ~

システム変更に影響する評価タスクを、数ヶ月かかる複雑な本番環境であっても、数日単位にまで削
システム変更に影響す...
プライバシー・ポリシーに準拠したデータの共有
   ~ Oracle Enterprise Manager 10g Data Masking Pack ~

開発環境、テスト環境およびステージング環境で機密情報をマスキングすることによって、組織...
Oracle Load Testingがさらに求めやすく
 3月24日から新価格に

                                        FW/LB                  Web           AP...
「Oracle Application Testing Suite」性能検証支援サービス
~オラクル・コンサルティングによるテスティング・サービス~

 カットオーバー後の障害抑止と検証コスト削減を目的として、「Oracle Applicati...
Oracle Application Testing Suite対応研修コース
             Oracle Application Testing Suite: 基礎コース(2日間)
   機能テスト、負荷テストの基礎編      ...
<Insert Picture Here>




              「招待コード = 5384」をご利用ください
40
Copyright© 2009, Oracle. All rights reserved.
Upcoming SlideShare
Loading in …5
×

【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!

3,022 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,022
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
105
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

【13-D-4】 アナタのアプリ性能改善の秘訣、オラクルが教えます!

  1. 1. <Insert Picture Here> アナタのアプリ性能改善の秘訣、オラクルが教えます! 日本オラクル株式会社 システム事業統括本部 System & Application Management ビジネス推進本部 セールスディレクター 山岡 英明
  2. 2. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン ト(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さ い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい ては、弊社の裁量により決定されます。 * Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標で す。その他のブランドまたは製品は、それぞれを保有する各社の商標または登録商標です。 2 Copyright© 2009, Oracle. All rights reserved.
  3. 3. 品質管理から始めるコスト削減 品質コスト(予防コスト+評価コスト+失敗コスト) についてお考えですか? 3 Copyright© 2009, Oracle. All rights reserved.
  4. 4. テスト工数の肥大化 • 開発の効率化が進む中 – 開発プロセスの効率化 – 開発資産の再利用 – 標準化 • テスト工数は、増加し続けている。 – 1%のプログラム修正でも、テストは100%行う必要がある。 – テスト工数は、開発初期段階の何十倍にもなる。 4 Copyright© 2009, Oracle. All rights reserved.
  5. 5. ソフトウェアの品質維持に赤信号 • 開発資産の共有化により、開発は短縮できたが – テストが複雑になる – 開発初期段階のテストを維持できず – アプリケーションを継続発展させ、品質維持は困難 5 Copyright© 2009, Oracle. All rights reserved.
  6. 6. コスト削減は、テストにあり • 今から、注視するべきはテストにあり – テスト管理による品質向上 +コスト削減 (予防コスト) – 自動化によるコスト削減 +品質維持 (評価コスト) – 性能管理による、サービス向上+コスト削減 (失敗コスト) 6 Copyright© 2009, Oracle. All rights reserved.
  7. 7. なぜ性能障害は恐ろしいのか • とにかくコストがかかる – 実運用では再現が難しい – 修正コストが他の不具合の100倍のケースも – 開発スケジュールの混乱 • 要件定義から見直しが必要な場合も – 突然のシステムダウン • 予想外のユーザアクセスがもたらす性能障害 7 Copyright© 2009, Oracle. All rights reserved.
  8. 8. 負荷テストの重要性 • 事前見積もりと、実際の性能が異なる – ブラックボックス • 使用技術全ての把握は困難 • 積算があてにならない – 機能性能要因の存在 • 表示機能の一部追加によって大幅に性能劣化 – 品質性能要因の存在 • アウトソーシングしていたモジュールに性能問題 8 Copyright© 2009, Oracle. All rights reserved.
  9. 9. 負荷テストとは • Webアプリケーションに対して大量のアクセスを発生させ、アプリケーション やハードウェア(インフラ)の機能が期待通りの性能を満たしているかを検証 するテスト ルーター ファイア ロード 外部 クラアント端末 DB サーバ ウォール バランサー ネットワーク網 Web AP サーバ サーバ 大量のアクセスを発生 大量のアクセスを発生 例:ロードバランスされたWebサーバ/バックエンドで稼動する 例:ロードバランスされたWebサーバ/バックエンドで稼動する DB、さらには様々なアプリケーション/DBのテーブル構造など DB、さらには様々なアプリケーション/DBのテーブル構造など 複雑化したシステム全体のパフォーマンスは、計ってみること 複雑化したシステム全体のパフォーマンスは、計ってみること で初めてわかる で初めてわかる 9 Copyright© 2009, Oracle. All rights reserved.
  10. 10. 性能テスト • 目標スループットの負荷を与えた時のパフォーマンス、システムの振る舞い を評価し、限界値(限界ポイント)までテストを続け、限界値を見極める • 一般的な「負荷テスト」は性能テストのこと 性能限界値 性能限界値 応答時間/スループット(page数/秒) スループット スループット page数/秒) page数/秒) 応答時間 応答時間 ボトルネック ボトルネック 同時接続ユーザ数 0 増加する 10 Copyright© 2009, Oracle. All rights reserved.
  11. 11. どのシステムがボトルネックと考えられますか? AP Web DB Client Network Device DBサーバで処理されるページ 応答時間の遅延が発生 応答時間 → APサーバで処理されるページ ボトルネック Webサーバで処理されるページ ユーザ数 → 11 Copyright© 2009, Oracle. All rights reserved.
  12. 12. ボトルネックを判断するためのマクロ情報 クライアント ネットワーク機器 Webサーバ APサーバ DBサーバ (ユーザ) ◆CPU使用率 ◆CPU使用率 ◆応答時間 ◆スループット ◆スループット ◆CPU使用率 ◆CPU使用率 ◆メモリ ◆メモリ ◆ディスクI/O ◆メモリ 12 Copyright© 2009, Oracle. All rights reserved.
  13. 13. ボトルネックの現象・要因・対策 性能限界時に顕著に 主な劣化要因 対策 分かる現象 物理ボードの処理能力限界 ネットワーク機器 CPU使用率100% システムバスの処理上限 より高いスペックの機器に 入れ替え 単純なCPU処理限界 (FW,LB,IDS,etc) 帯域使用率100% バッファメモリ不足 CPU使用率100% サーバの増設 OSの応答処理能力を超えている サーバのCPU強化 Webサーバ NIC帯域使用率 H/Wのスループット上限 NIC帯域容量増加等 100% 非効率なプログラム・アプリ設計 プログラムや設計の見直し 不適切なヒープ配分 APサーバ CPU使用率100% ヒープとスレッドのチューニング 不適切なスレッド数定義 メモリ不足 H/Wの強化 DBへの接続 非効率なクエリ SQLクエリの見直し 不適切なインデックス設定 適切なインデックス設定 CPU使用率100% 非効率なテーブル設計 DBサーバ テーブル設計の見直し 不適切なバッファ・キャッシュの配 DiskI/O増加 バッファ・キャッシュのチューニング 分 H/Wの強化 メモリ不足 13 Copyright© 2009, Oracle. All rights reserved.
  14. 14. 性能テストを行なわないリスク • 総合テスト段階で性能問題が発生すると、運用に入れなかった り、不安要素を抱えたままの運用開始に直面 開発フェーズ 要件 単体 結合 総合 運用 単体 要件 結合 総合 設計 開発 設計 開発 定義 テスト テスト テスト テスト 定義 テスト 性能不具合 テスト 発見! アーキテクチャの変更が必要なことも・・・ 14 Copyright© 2009, Oracle. All rights reserved.
  15. 15. 開発の初期段階から性能テストを計画 開発フェーズ 要件 単体 結合 総合 運用 単体 要件 結合 総合 設計 開発 設計 開発 定義 テスト テスト テスト テスト 定義 テスト テスト マクロな視点での マクロな視点での 性能テスト 性能テスト テスト 性能 性能 テスト 性能 性能 計画 要件 監視 計画 要件 監視 ミクロな視点での ミクロな視点での 性能テスト 性能テスト 性能問題を開発プロセス全体で考える 15 Copyright© 2009, Oracle. All rights reserved.
  16. 16. 性能要件の策定 • 性能要件で考慮する項目 – システムを使用する人数 – 同時アクセス数 – 受託開発かパッケージアプリケーションか • 性能目標の確立 最大同時アクセスユーザ数 – 最大処理ページ数/秒 – 主要なページの平均応答時間 – 高負荷時に許容されるエラー率 – システムの性能限界値 – 16 Copyright© 2009, Oracle. All rights reserved.
  17. 17. システム設計での考慮点 • 性能要件を反映させる – サーバ構成 • サイジングを行なう – ネットワーク構成 • 性能目標と矛盾がないか確認 – パラメータ値 • 最大コネクション数 • JVMヒープサイズ • ほか – 性能テストを考慮した設計 • テスト環境 • 必要のないセッション管理 • ほか 17 Copyright© 2009, Oracle. All rights reserved.
  18. 18. システム設計での考慮点 • サーバ構成と性能要件 – CPUとスループット • 目標 2,000PV/秒 • 1台あたりの目標処理数 200PV/秒 – メモリと同時アクセスユーザ数 • 目標 同時1,000ユーザ • 1セッションあたりのメモリ消費量 – サーバ台数とページの応答時間 • 目標 平均8秒以内 • 処理能力 平均2秒以内 6秒の調整時間 18 Copyright© 2009, Oracle. All rights reserved.
  19. 19. 詳細設計での考慮点 • 応答時間のブレークダウン – 単体レベルでの性能目標 • サーブレットの処理時間など – プロファイラーの選定 • 測定方法の明確化 ✍重要なトランザクションは明確な指標を策定する 19 Copyright© 2009, Oracle. All rights reserved.
  20. 20. 単体テストフェーズでの性能テスト • 単体レベルで性能テストを行なわないリスク – 性能要件を満たさないシステム構築が行なわれる • GCでは解決できないメモリリーク • パフォーマンスの悪いSQL • CPUを大量に占有するプログラム – 後工程で問題が露見して、手戻りが生じる • 連続処理のシーケンスの不具合 • 並列操作の不具合 • 高負荷時に実行される例外処理が正しく動作しない ☹共通機能で発生したら致命的 20 Copyright© 2009, Oracle. All rights reserved.
  21. 21. 結合テストフェーズでの性能テスト • スケジュール – 性能テストで考慮すべき工数 • スクリプト作成 1日~1週間 • データ準備 1日~3日 • 負荷テストツールのセットアップ 半日 • サーバリソースの取得準備 半日 • 負荷テスト実施 半日~1日 • チューニング/不具合改修 数日 ✍性能テストで最低2週間は必要 21 Copyright© 2009, Oracle. All rights reserved.
  22. 22. 結合テストフェーズでの性能テスト • チーム構成 – テスト担当者 • システム構成をよく理解している • システムアーキテクトを理解している • テストツールの操作が行える • 基本的な結果グラフを見て問題点が指摘できる – アプリケーション開発者 – DBA – ネットワーク管理者 – システム管理者 – ユーザー(オペレータ) 22 Copyright© 2009, Oracle. All rights reserved.
  23. 23. 結合テストフェーズでの性能テスト • テストの準備 – 負荷テストツールを理解する • 仮想ユーザのスクリプト作成 – フリーツールでは十分なシミュレーションができない – プログラミング必要だと準備工数増加 • 正確な負荷の生成 – その同時ユーザーアクセスは正確? – ユーザー操作の遅延時間は考慮されている? • エラーチェック – HTTPリクエストを単純にシミュレーションしているだけ? – HTTP 200/OKでもエラー • 分析データの内容 – ボトルネックが特定できる? 23 Copyright© 2009, Oracle. All rights reserved.
  24. 24. 結合テストフェーズでの性能テスト • テストの準備 – テスト用データの作成 • ログインを個別に行える • 十分な検索が行える • 繰り返しテストが行える 24 Copyright© 2009, Oracle. All rights reserved.
  25. 25. 結合テストフェーズでの性能テスト • テストの実施 – テストを始める前に、低負荷での接続確認 – 1つのテストは30~60分 – 段階的にユーザ数を上げる • 100ユーザー最大のテストを行う場合は、10ユーザー毎ぐらいで増加 させながら、結果情報を収集すると良い。 • 一度に100ユーザーを接続させるテストを行う場合は、事前に段階的 にテストをして、状況を確認する必要がある。 – ログインの方法 • 毎回? • 最初に1回だけ? ✍遅延時間はしっかりと考慮する 25 Copyright© 2009, Oracle. All rights reserved.
  26. 26. 結合テストフェーズでの性能テスト • 結果の分析 – ボトルネック検出のための情報収集 • 応答時間とスループットの情報分析が基本 • 各サーバからリソース情報を収集する – ボトルネックを明確にするには様々の追加試験が必要となる場合もある 26 Copyright© 2009, Oracle. All rights reserved.
  27. 27. 総合テストフェーズでの性能テスト • 目的 – 本番と同等のデータを使用して実環境でテストする – バックエンドの機能も稼働させる • バッチ • メール配信 • ファイル転送など • 結合テストがうまくいっても安心しない – 本番環境になると新たな問題が発生する場合もある • ネットワーク • DB (データ件数、インデックス、実行計画) 27 Copyright© 2009, Oracle. All rights reserved.
  28. 28. ソフトウェアテストは未知の世界 • Webアプリケーションの発展はここ数十年 – 未熟なエリア – いつか当然となるソフトウェア品質 • 性能向上の鍵は負荷テスト 負荷テスト ボトルネック 実行 発生の確認 負荷テスト計画 負荷テスト 準備 ボトルネック 要因の推測 再試験の 仮説に基づく 環境準備 チューニング 28 Copyright© 2009, Oracle. All rights reserved.
  29. 29. <Insert Picture Here> Oracle Application Testingのご紹介 29 Copyright© 2009, Oracle. All rights reserved.
  30. 30. エンピレックスからオラクルへ • 高い実績と強力なノウハウの継承 2008年6月 オラクルに統合 – エンピレックスは、Web負荷テストの国内でのトップベンダー – 年間60件以上のテストコンサルティングの実績 – テストツールe-Loadは過去5年間国内販売数トップシェア – e-TEST suite + Empirix ノウハウ Oracle 30 Copyright© 2009, Oracle. All rights reserved.
  31. 31. テスト・プロセス管理の簡素化 ~ Oracle Test Manager for Web Applications ~ ソフトウェアやハードウェアの品質に関わる情報を一元管理することにより、テスト資産の活用、組織 ソフトウェアやハードウェアの品質に関わる情報を一元管理することにより、テスト資産の活用、組織 間の効果的な情報共有を実現します。 間の効果的な情報共有を実現します。 [包括的なテスト管理] プロジェクト管理者 テスター 品質・進捗管理 テスト実施 テスト資産 テスト定義 不具合改修 製品の特徴 開発担当者 品質管理者 ・ブラウザアクセスにより 主な用途 複数拠点からの利用が容易 ・分散しているプロジェクトチームでテスト資産を共有したい。 ・カスタマイズ可能な ・常に最新のテスト状況を確認したい。 データスキーマを提供 ・機能変更時に影響を受ける他の要件やテストを把握したい。 ・OFTや3rd Partyの ・不具合の多い要件やテストケースを調べたい。 自動化ツールと同期可能 ・チーム全体がテストプロセスを確認できるよう可視性を高めたい。 ・メールによるイベント通知 ・自動化ツールと連動しテスト効率を向上したい。 ・豊富なレポート OFT … Oracle Functional Testing for Web Applications 31 Copyright© 2009, Oracle. All rights reserved.
  32. 32. Webアプリケーションに対する負荷テスト ~ Oracle Load Testing for Web Applications ~ 多数のユーザからのアクセスを擬似しWebアプリケーションの性能検証を実現。運用を開始する前に、 多数のユーザからのアクセスを擬似しWebアプリケーションの性能検証を実現。運用を開始する前に、 アプリケーションの性能問題をあぶりだし、Quality of Experienceの向上を支援します。 アプリケーションの性能問題をあぶりだし、Quality of Experienceの向上を支援します。 [負荷テストの実施] 仮想ユーザ QoEの計測 FW/LB Web AP DB サーバ性能の計測 製品の特徴 ・GUIによる簡単なスクリプト作成 主な用途 ・CookieやHTML内のセッション ・開発の早い段階から手軽に負荷テストを実施したい。 データも自動パラメータ化 ・応答時間の遅延の原因となるサーバを特定したい。 ・ユーザ視点のエラーチェック ・想定していないエラー画面を見落としたくない。 ・OS/AP/Network等の性能 ・PCだけでなく携帯や専用端末のアプリケーションもテストしたい。 データをエージェントレスで収集 ・サーバにモジュールを導入することなく性能を計測したい。 ・見やすい分析グラフ ・機能テストで作成したスクリプトを活用したい ・HTTP(S)/SOAPに対応 32 Copyright© 2009, Oracle. All rights reserved.
  33. 33. 機能・回帰テストの自動化を実現 ~ Oracle Functional Testing for Web Applications ~ WebアプリケーションやWebサービスの品質を確保する最短の方法として、テストプロセスの自動化を WebアプリケーションやWebサービスの品質を確保する最短の方法として、テストプロセスの自動化を 実現する、使いやすい機能・回帰テストツールです。 実現する、使いやすい機能・回帰テストツールです。 [機能・回帰テストの実施] “1つ”のテストスクリプトを 使用してテストを実施 リリースごと 入力値ごと プラットフォームごと 製品の特徴 ブラックボックス Ver1.0 Ver1.1 Ver2.0 Windows Linux Solaris ・プログラミング不要なスクリプト 主な用途 ・入出力データをCSVとして ・リリースのたびに行う定型化されたテストを自動化したい。 定義するデータ駆動型テスト ・ブラックボックステストにおける入力値のパターンを増やしたい。 ・豊富なユーザ定義テストを提供 ・プラットフォームごとに行うテストを省力化したい。 ・SiebelやPeopleSoftなどの ・ページ内のリンクや画像が正しく存在しているかチェックしたい。 Oracleアプリケーションに対応 ・テストスクリプトの開発ではなく、テストに集中したい。 ・.NETやWebサービスにも対応 ・負荷テストとスクリプトを共有してテストの準備工数を削減したい ・OLT/OTMでスクリプトを共用 OLT…Oracle Load Testing for Web Applications | OTM … Oracle Test Manager for Web Applications 33 Copyright© 2009, Oracle. All rights reserved.
  34. 34. データベースの構成変更時のテストを効率化 ~ Oracle Real Application Testing ~ システム変更に影響する評価タスクを、数ヶ月かかる複雑な本番環境であっても、数日単位にまで削 システム変更に影響する評価タスクを、数ヶ月かかる複雑な本番環境であっても、数日単位にまで削 減できます。Database ReplayおよびSQL Performance Analyzerの二つの機能から構成されます。 減できます。Database ReplayおよびSQL Performance Analyzerの二つの機能から構成されます。 [データベースの負荷テスト] 本番環境 検証環境 AP Database Replay 本番環境のDB負荷を再現 (ワークロード) ワークロード/SQLを取得 SQL Performance Analyzer 製品の特徴 SQLの単体テストを実施 (SQL) -Database Replay- ・本番環境で取得した 主な用途 ワークロードを忠実に再現 ・データベースに焦点をあてた負荷テストを実施したい。 ・環境の変更による性能差異や ・ハードウェアなどの構成変更に対する影響度を検証したい。 エラー発生の有無を確認 ・データベースのアップグレード、パッチ、初期化パラメータの -SQL Performance Analyzer- 変更によるSQL実行計画や統計情報の違いを確認したい ・本番環境のSQLを再評価 ※ 次のOracle Database管理製品と併せてより高度な分析が行えます ・構成変更による実行計画の ・Oracle Diagnostics Pack 違いと性能への影響を確認 ・Oracle Tuning Pack 34 Copyright© 2009, Oracle. All rights reserved.
  35. 35. プライバシー・ポリシーに準拠したデータの共有 ~ Oracle Enterprise Manager 10g Data Masking Pack ~ 開発環境、テスト環境およびステージング環境で機密情報をマスキングすることによって、組織がプラ 開発環境、テスト環境およびステージング環境で機密情報をマスキングすることによって、組織がプラ イバシおよび機密保護法を順守できるように支援します。 イバシおよび機密保護法を順守できるように支援します。 [表データの置換] ID CARDNUMBER マスキング 1 7488-2984-1736-7400 2 4033-6177-0089-6401 ID CARDNUMBER 3 6141-5126-0475-8802 1 5870-2967-9149-5700 4 1139-4145-6222-3703 2 9634-7334-4874-2301 5 8337-6263-1608-0104 3 8430-8214-6445-1102 : : 4 1573-9537-1503-5503 5 0606-3321-6271-8304 製品の特徴 : : ・主キー/一意/参照整合性制約に 主な用途 違反することなくデータを置換 ・もっと簡単にテストデータを準備したい ・置換の定義情報を残し、同じ ・新システム開発時に、既存システムと同等のデータを利用したい マスク処理を繰り返し実行可能 ・負荷テストなどに本番データを使用したい ・マスキングはXML形式で ・サブシステム追加時に、既存システムへの影響を知りたい エクスポート/インポート可能 ・障害調査を行うために開発会社で本番データが必要だが、 ・マスキング・フォーマットの充実 個人情報が多く含まれるため提供できない ・高パフォーマンス 35 Copyright© 2009, Oracle. All rights reserved.
  36. 36. Oracle Load Testingがさらに求めやすく 3月24日から新価格に FW/LB Web AP DB Load Testing for Web Applications Controller 200 同時ユーザー Controller (CPU 1枚) のテスト 1 CPU = ¥760,900 (仮想ユーザー) Load Testing for Web Applications 1 NUP = ¥10、900 ライセンス価格の計算 (200 NUP から導入可能) 1 CPU x ¥760,900 = ¥760,900 + 合計 ¥2,940,900 200 NUP x ¥10,900 = ¥2,180,000 36 Copyright© 2009, Oracle. All rights reserved.
  37. 37. 「Oracle Application Testing Suite」性能検証支援サービス ~オラクル・コンサルティングによるテスティング・サービス~ カットオーバー後の障害抑止と検証コスト削減を目的として、「Oracle Application Testing Suite」を使っ たテスト方針の策定と標準化、および、実施をリードします テスティング・サービス基本パッケージの例 価格 200万円~ 想定サービス提供期間 10営業日~ 基本パッケージの想定範囲 テストシナリオ:各10ページのシナリオ、3本以下をサービス開始時に決定 計測サーバー:10台以下のサーバーをOS情報のみ取得 分析対象の処理の決定、性能要件確認をサービス開始時に実施 1つの契約につき、2回のテストショットを想定 ご提供する成果物 テスト計画書 (試験実施の事前打ち合わせに基づき作成) シナリオスクリプト (事前打ち合わせ、計画書に基づき作成) 報告書 (最大2回の負荷テスト実施よりボトルネックを分析し、報告書作成) 本サービスの適用条件 オラクルのサポート・サービスの契約者を前提としております 基本パッケージの対象外のタスク データベース/アプリケーションの内部動作に関わる詳細解析 パフォーマンス・チューニング作業 改善案や適用効果の数値的な予測分析 ※上記の「基本パッケージの対象外のタスク」や、Webアプリケーション以外の負荷テストについても、実際の 工数に基づいた金額で支援サービスを提供しておりますので、ご相談下さい。 37 Copyright© 2009, Oracle. All rights reserved.
  38. 38. Oracle Application Testing Suite対応研修コース Oracle Application Testing Suite: 基礎コース(2日間) 機能テスト、負荷テストの基礎編 ■Load Testing基礎 Webアプリケーションの機能テスト(Functional Testing)と負荷テスト(Load Testing ■負荷テスト実施計画の基礎 コース )に関するツール操作を中心に学習して頂けます。また、負荷テスト(Load Testing) ■サーバーリソースのモニタリング方法(ServerStats 内容 については、負荷テスト実施計画から負荷テスト実施全般に関して学習して頂けます の使い方) 。Functional Testingによるスクリプトの作成と機能/リグレッションテストや、Load ■スクリプトを組み合わせた負荷テスト Testingを使用した負荷/拡張性テストの詳しい内容、ServerStatsを使用したアプリケ ーションのボトルネックの発見について説明いたします。 定価¥138,600(税込) 受講料 Oracle Application Testing Suite: アドバンスコース(1日) スクリプト編集の応用編 ■Load Testingのアドバンスト技術の習得 ■Webサイトのスクリプトの対応方法の理解 ブラウザ操作によって記録されたスクリプトの編集方法について学習していただけま コース す。HTTPリクエストの解析とナビゲーション・エディタの全般的な機能およびスクリプ ■HTTPリクエストの基礎 内容 ト編集について、効果的に学習します。 ■失敗しているナビゲーションの見つけ方 ナビゲーション・エディタの使用方法ならびにプロキシーレコーダ機能を解説し、実際 ■proxy機能 にいくつかのWebサイトを使用してどのようにスクリプトを作成するのか習得します。 定価¥69,300(税込) 受講料 Oracle Application Testing Suite: ボトルネック検出コース(1日) テスト結果分析の実践編 ■ボトルネック検出に必要な監視項目とその見方 負荷テスト(Load Testing) の結果からボトルネックを検出する着眼点について学習 ■ボトルネックの検出に必要な分析ポイント コース していただけます。結果グラフをどのように読み取るか、また実機を使った負荷テスト ■各種テスト結果グラフからのボトルネック読取り の実施によって効果的にボトルネック特定に必要な方法について学習します。エンジ 内容 ■Load TestingによるWebアプリの負荷テスト ニアが現場でよく遭遇する代表的なアプリケーションボトルネックについて解説いたし ■代表的なアプリケーションボトルネックの理解 ます。負荷テストの実行とボトルネック検出について実際のマシンで負荷および測定 を実演し、システムの負荷テスト方法をマスターして頂けます。 定価¥69,300(税込) 受講料 38 Copyright© 2009, Oracle. All rights reserved.
  39. 39. <Insert Picture Here> 「招待コード = 5384」をご利用ください
  40. 40. 40 Copyright© 2009, Oracle. All rights reserved.

×