Opera受け入れテスト (OAT) の例

何ですか Opera受け入れテスト?

Opera受け入れテスト (OAT) 運用受入テストは、ソフトウェアアプリケーションを本番環境にリリースする前に、その運用準備状況を評価するソフトウェアテスト手法です。運用受入テストの目的は、システムとコンポーネントが標準規格に準拠し、システムがスムーズに動作することを保証することです。 Opera環境（SOE）。

Opera国家受入試験は、 Opera国家準備テスト（ORT）、あるいはより簡潔に言えば運用テスト。これら3つの名称はすべて同じチェックを指します。ソフトウェアは既にビジネス側の要求を満たしているかもしれませんが、稼働開始後に実際に使用する担当者が、インストール、バックアップ、再起動、監視、復旧を問題なく行えるこ​​とをまだ誰も証明していないのです。

その特徴により、OATは 非機能テスト これは、機能が正しい答えを返すかどうかではなく、実際の運用条件下でシステムがどのように動作するかを問うものです。

の種類 Opera試験

Opera国家試験は包括的な活動です。以下の各項目はそれぞれ独立したチェック項目であり、独自の実施条件と証拠が必要です。OATの全サイクルでは、通常、これらの項目のほとんどが網羅されます。

• インストールテスト — 提供されたドキュメントを使用して、対象環境にビルドをインストール、アップグレード、およびロールバックできることを確認します。
• 負荷とパフォーマンスのテスト Opera生産 — システムが本番環境と同等の負荷の下で、期待されるスループットと応答時間を維持していることを確認します。参照 性能試験 (NAIST) と 負荷テスト 基礎となる技術について。
• バックアップと復元のテスト ―バックアップが単にディスクに書き込まれるだけでなく、実際にスケジュール通りに取得され、正常に動作する状態に復元できることを証明する。
• セキュリティテスト — 運用環境におけるアクセス制御、認証情報、証明書、およびセキュリティ強化を検証します。参照先 セキュリティテスト 詳細な手順については、こちらをご覧ください。
• Code 分析 納品されたコードと構成を、保守性や既知の脆弱性パターンについて静的にレビューし、それが誰かの運用上の負担となる前に検証する。
• フェイルオーバーテスト ノード、サービス、またはサイトを強制的に障害状態にし、スタンバイが合意された時間内に引き継ぐかどうかを監視します。
• 回復テスト ―システムがクラッシュ後にどれだけ完全に、どれだけ迅速に復旧するかを測定する。 回復テスト その技術を詳細に解説しています。
• End-to-End テスト環境 Opera試験 — サーバー、ネットワーク、ジョブ、インターフェースのチェーン全体を単一の動作単位として操作します。
• Operaドキュメント RevIEW — 実行マニュアル、サービス図、再起動手順、エスカレーションパスが、実際に構築されたシステムと一致していることを確認します。

以下の図は、これらのチェック項目をリリース前後にグループ化しており、運用テストがアプリケーションが本番環境に入る前の最後の段階であることを示しています。

Why Opera試験

Opera国家テストが存在するのは、すべての機能要件を満たすリリースであっても、実行が不可能な場合があるためです。

• OAT（運用承認試験）の期間中、ソフトウェア構成と運用サポートコンポーネントが初めて統合されます。
• これは、ソフトウェアまたはサービスに対する機能的または構造的な変更の実装を、機能環境または非機能環境でテストするものです。
• このテストは、アプリケーションがITインフラストラクチャライブラリ（ITIL）標準に準拠してネットワーク上に展開できるかどうかを判断するものです。
• これは、ソフトウェアがビジネスプロセスを阻害することなく、設計どおりに動作するかどうかを示すものです。
• OATは主にソフトウェア製品の以下の側面に焦点を当てています。
  • 回復力
  • 回復能力
  • 管理性とサポート性
  • Integrity

誰が演じるのか Opera全国的なテストと

OATの所有権はこれまでのどのテストレベルとも異なり、その違いが結果の大部分を説明している。OATを運営しているのは、午前3時に呼び出されるような人たちなのだ。

• システム管理者およびインフラストラクチャエンジニア ―対象環境に対して、インストール、フェイルオーバー、再起動の各ケースを実行します。
• Opera支援チーム — 各アラートで参照されているアラート、しきい値、エスカレーション経路、および解決ドキュメントを検証する。
• データベースおよびバックアップ管理者 バックアップの取得と復元（セカンドサイトへの復元を含む）。
• セキュリティおよびコンプライアンス担当者 ―本番環境に近い環境で、セキュリティ強化、アクセス制御、監査ログの有効性を確認する。
• テストマネージャー ―証拠を収集し、運用開始決定パックにまとめる。

ソフトウェアテストのライフサイクル運用テストは、まさに最後に位置づけられる。 システムテスト 組み立てられた製品が正しく動作することを確認するテスト、ビジネス部門が製品を受け入れることを確認するユーザー受け入れテスト、そして組織が製品を運用できることを確認する運用受け入れテスト（OAT）があります。OATは本番環境に近い環境を必要とするため、通常はリリース候補版が確定した後に実施されます。それ以降にコードが変更されると、サイクルは最初からやり直しになります。

テストケースの例 Opera試験または OAT

以下は、OAT（運用評価テスト）を実施するための便利なチェックリストです。各項目は、結果が合格か不合格かの明確な判定となるように記述されており、これは本番稼働審査委員会が必要とするものです。

1. あるサイトで取得したバックアップは、同じサイトに復元できます。
2. あるサイトで取得したバックアップは、別のサイトに復元できます。
3. 新機能を本番環境に導入しても、既存の本番サービスの整合性に悪影響を与えることはありません。
4. 有効なドキュメントを使用すれば、実装プロセスを再現できます。
5. 各コンポーネントは、合意された時間枠内で正常にシャットダウンおよび起動できる。
6. アラートに関しては、すべての重大なアラートはTECに報告し、適切な解決文書を参照する必要があります。
7. アラートが設定されており、合意されたしきい値を超えた場合に発令されます。
8. サービス図を含む、作成または変更された復旧関連文書はすべて有効です。これらの文書は、関係するサポート部門に提出してください。
9. 障害の影響を受けたコンポーネントには、推奨される再起動順序、完了までの時間、および関連する依存関係が表示されます。

このリストに加えるべき実用的な項目として、否定的なケースが挙げられます。つまり、意図的に依存関係を一つ破壊し、アラートが発報され、実行ブックが見つかり、文書化された再起動手順によってサービスが復旧することを確認するのです。成功のみを記録するチェックリストでは、操作を全くテストしたことになりません。

Opera国家テストとユーザー受け入れテスト

OATと ユーザー受け入れテスト どちらも承認手続きであり、どちらも予定より遅れるため、よく混同されます。しかし、それぞれ異なる質問に回答し、異なる担当者が承認を行います。

この2つは代替関係ではなく、相互補完的な関係にある。UAT（ユーザー受け入れテスト）に合格し、OAT（運用受け入れテスト）に不合格となったリリースは、最初の障害が発生するまで正しく機能するリリースである。

の利点と課題 Opera試験

OATを導入するチームは、概して同じ利点を挙げ、同じ障害に直面する。

優位性

• 顧客が実際にそれらに依存する前に、復旧およびフェイルオーバーの手順がテストされるため、システム停止のリスクは低下します。
• サポートチームは、設計図に基づいて作成されたものではなく、実際のシステムで検証済みのドキュメントを引き継ぐことになる。
• 導入時の予期せぬ問題は、稼働開始当日ではなく、管理された期間内に明らかになる。
• コンプライアンスおよび監査に関する証拠は、チェックリストの副産物として生成される。

チャレンジ

• 本番環境に近い環境を構築するには費用がかかり、規模を縮小したコピーでは、OATがまさに検出しようとしている不具合が隠されてしまう。
• このサイクルはリリースと同じカレンダー上のスペースを競合するため、リリース日が遅れると最初に削減される活動となる。
• フェイルオーバーやリストアといった破壊的な操作には、承認や静かな作業期間が必要であり、それらを得るのは困難である。
• 結果は、現在稼働中のサービスを同時に運用している運用スタッフの能力に左右されます。

一般的な対策は、小規模から始めることです。まず、バックアップ/リストアと再起動のケースを自動化します。これらはリリースごとに繰り返され、最も明確な合否のシグナルが得られるためです。そこから、チェックリストはサイクルごとに拡大でき、ランブックへの変更はすべて、 回帰試験 次回のリリースで。

よくあるご質問