メニュー

長寿試験とは何ですか？顧客がそれを見つける前にバグをキャッチする方法

what is longevity testing

問題を排除するために楽器を試してください

この記事では、「 寿命試験 」と、システムまたは製品の安定性を評価し、お客様が発見した欠陥を減らすのにどのように役立つか。 「」 顧客がバグを見つける前に、社内でバグをキャッチします 」。

この記事の終わりまでに、QAマネージャー、リード、およびテスターは、以下についての公正な知識を持つようになります。

  • 長寿試験とは何ですか？
  • なぜ寿命試験が必要なのですか？
  • 寿命テストの計画と実行
  • 長寿テストの長所と短所は何ですか？

寿命試験

C ++のフレンド関数

学習内容：

長寿試験とは何ですか？

長寿テストはテスト活動です：

  • リアルタイムのトラフィックとアプリケーションを使用して、適切な負荷とストレスの状態に対して、システムまたは製品の安定性と保守性の機能を長期間にわたって検証する
  • お客様のサイトで表面化する欠陥の発生を減らすため

お客様から報告された問題の処理のフロー図（図1）

長寿試験とは

長寿試験の背景

＃1） 通常、製品展開の最初の数週間、またはお客様のサイトで最新のソフトウェアリリースにアップグレードした後は、すべてが正常に実行されます。ただし、数週間にわたって、顧客は問題の報告を開始します。

＃二） 問題の多くは、お客様から報告され、社内で簡単に再現できないため、単純な機能である可能性があります。彼らは多くの時間とスペクトル全体の専門家チームによる注意深い分析を必要とします。 ヒント：時間= $$$ !!!

＃3） 顧客が欠陥を見つけた場合、次の1つ以上が発生します（図1）

  • 欠陥の重大度 お客様のビジネスに直接的な影響を及ぼします。つまり、$$$
  • テクニカルサポートセンターへのサービスリクエストは、製品エンジニアリング組織に$$$の費用がかかります
  • お客様が提起した問題がフロントエンドテクニカルサポートチームによって解決されることはめったにありません
  • このようなリクエストまたはチケットは、エスカレーションサポートチームにエスカレーションされます
  • 顧客チケットのエスカレーションは、組織にとってより多くの$$$の費用がかかります
  • エスカレーションチームが問題を解決できない場合は、エンジニアリングチーム（開発およびQA）を関与させる必要があります。
  • 今では、問題を解決するための$$$のコストも大幅に上昇しているでしょう
  • 欠陥の解決が長ければ長いほど、不満を持った顧客が繰り返し注文しない可能性が高くなります。最悪のシナリオは、顧客が適切なタイミングで競合他社のソリューションに移行することを決定した場合です。ただし、どちらの場合も、製品エンジニアリング組織にとっては収益の損失になります。

4） お客様から報告されたこのような問題の割合が高いのは、お客様のトポロジ、インフラストラクチャ、トラフィック、およびアプリケーション固有と組み合わせた、一般的なシステムまたは製品の安定性に関連しています。

なぜ寿命試験が必要なのですか？

1） お客様から報告された「欠陥」は、通常、テストエスケープです。

二） このような欠陥は、顧客と、顧客にソリューションとサービスを提供するエンジニアリング組織に最終的な$$$の費用がかかります。

3） 通常のシナリオでは、問題の複雑さに応じて、テストチームの1人以上のテスターに​​よる回帰テストを含むさまざまなテストサイクル中に、内部で欠陥に気付くはずです。

4） 最も重要なことは、顧客から報告された問題から生じるこのような欠陥は、適切なテストシナリオまたはテストケースがテスト計画の実行時に見逃されていることも示しています。

5） テスターの多くは、特定の機能が顧客サイトで失敗しているが、次のようなさまざまなテストベッドで社内を通過していることを経験している必要があります。

  • 特徴
  • 回帰
  • 負荷
  • ストレス
  • パフォーマンス
  • システム
  • 解決
  • アルファ
  • ベータ

6）考慮すべき重要な所見 -

  • ソフトウェアリリースサイクル中、すべてのテストベッドのテスト対象システム（SUT）またはテスト対象デバイス（DUT）は、新しいコードドロップのロード、バグ検証などのために、頻繁にソフトまたはハードリブートされます。
  • 自動回帰テストスイートでさえ、通常、特定のテストケーススクリプトまたは一連のテストケーススクリプトの実行後にSUTまたはDUTを再起動またはリセットします。
  • したがって、SUTまたはDUTは、ソフトまたはハードの再起動なしでは十分に長く実行されていません。
  • 一方、お客様のサイトでは状況がまったく異なります。お客様はシステムを頻繁に再起動し続ける余裕がないため、生産性が低下します
  • お客様は、対象となる対象者に適切なメンテナンスウィンドウを発表してから、ソフトウェアのアップグレードやハードウェアの交換などを実行するという実証済みの慣行に従います。
  • このようなメンテナンスウィンドウは、お客様の組織の内部ガイドラインと手順に応じて、四半期ごとから年ごとの特定の期間にすることができます
  • 実際には、顧客サイトでのシステムまたは製品の実際の状態は、製品エンジニアリング組織の特定のソフトウェアリリースサイクル中のテストベッドの状態とはまったく異なります。
  • 多くの顧客は、特定の垂直モデルテスト、特に金融、ヘルスケア、連邦垂直モデルに合格した認定品質のドキュメントも探しています。

上記のようにいくつかのテストギャップを考慮する=>

経験豊富なデータステージインタビューの質問と回答
  • システムまたは製品は、顧客サイトまたは垂直市場を模倣したエンドツーエンドのシナリオで、より長い期間のテストまたは寿命テストを受ける必要があることは明らかです。
  • より長い期間は72〜720時間になる可能性があります。 （3-30日）またはに基づく適切な期間 EFD または CFD データと特定の顧客事例
  • QAマネージャー、リード、テスターに​​は、特定のソフトウェアリリースサイクルで個別のアクティビティとして寿命テストを実行することをお勧めします。
  • Net-Net、Longevity Testingは、組織の最終的な$$$と直接的な関係があるため、システムまたは製品の安定性に非常に関連しています。

寿命テストの計画と実行

QAマネージャー、リード、およびテスターは、その一部として寿命テストを含めることが重要です。 全体的なテスト戦略 。

計画

寿命テストの計画と実行

  • エンジニアリング組織は、社内でテストエスケープ分析を実行します（ お茶 ）多くの製品（ハードウェアおよびソフトウェア）に対して時々演習を行います。中には、通常「外部で見つかった欠陥（ EFD ）」または「お客様が見つけた欠陥（ CFD ） ’はサポートエスカレーションチームによって記録されました
  • EFDまたはCFDは、インフラストラクチャだけでなく、エンドユーザーのデバイス、アプリケーション、トラフィックパターンも含めて、エンドツーエンドの観点からお客様のライブ展開に関連して慎重に分析する必要があります。

顧客の業種を理解する：

顧客は通常、以下の幅広い業種のいずれかに分類されます。

  • 健康管理
  • 小売
  • ファイナンス
  • 教育
  • 交通
  • 製造
  • エンジニアリング
  • 連邦（政府）

活動

＃1） 寿命テスト用に個別のテスト計画とテストケースを作成します。これは、テストの実行、バグのログ記録、および検証の追跡にも役立ちます

＃二） テストエスケープ分析の入力に基づいてテストケースを特定します–通常はEFDまたはCFDのバグスクラブです

＃3） QAチームが、組織の業種に応じて1つ以上の業種のテストベッドを模倣し、業種の数を増やすことが非常に重要です。

＃4）専用のテストベッドが必要です

  • 目的の垂直市場または複数の垂直市場と同様のネットワークトポロジ
  • 同様のスイッチ、ルーター、バックエンドサーバー、ファイアウォールなどを備えたインフラストラクチャ
  • 特定の業種で最も頻繁に使用されるアプリケーションサーバー
  • 特定の業種で最も頻繁に使用されるエンドユーザーガジェット

＃5） 負荷、ストレス、リアルタイムのトラフィックを生成するための適切なツール

＃6） 手動実行リソースを特定する

＃ 7） より速く繰り返し実行するための自動化リソース/戦略を特定する

＃8） 特定のリリースの寿命テストの開始と終了を特定する

長寿試験の開始と終了の2つのアプローチ：

I）アプローチ1：

  • ソフトウェアコードまたはハードウェアは安定した状態である必要があります
  • FEATUREテスト完了の最後に開始
  • コードフリーズの前に終了

II）アプローチ2：

  • 少し不安定なコードを許可してマイナーヒットを取ります
  • FEATUREテストサイクルの70％完了時に開始します
  • コードフリーズの前に終了

＃9） 解決された欠陥のバグ検証

Javaコーディングインタビューの質問はコードを書く

＃10） 後続の回帰テストのために、寿命テストを回帰に移動します

実行

  • 1つ以上の顧客バーティカルを模倣するようにテストベッドを設定します
  • フレーバーを含むすべてのバックエンドインフラストラクチャ、アプリケーション、およびデータベースがお客様のものと類似していることを確認してください
  • テスト計画の実行中に、エンドユーザーのデバイスがお客様の使用と同様のものが利用可能で使用されていることを確認します
  • システムまたは製品に中程度のストレスと負荷を発生させるための適切なツールが利用可能であることを確認します
  • SUTまたはDUT、バックエンドサーバー、別のインフラ関連デバイスをソフトまたはハードに再起動せずに、Longevityテスト計画からテストスイート全体を実行します。
  • テストの複数の実行は、スロット72〜720時間から定義されたノンストップ期間、上記の方法で実行する必要があります。
  • 結果を記録する
  • 識別されたすべてのバグをログに記録する
  • すべてのバグを確認する

長寿テストの長所と短所は何ですか？

長所

  • 助けます 重大なバグを特定する 顧客がそれを見つける前に
  • お客様の生産性とビジネスに不可欠なサービス可能な機能のために、システムまたは製品を安定させるのに役立ちます
  • 顧客満足度の向上に役立ちます
  • 組織に$$$の多くのコストを節約します–節約されたお金は稼いだお金です!!!
  • 寿命テストレポートは、さまざまな業種に対応する品質認証の証明に変えることもできます

短所

  • 特定のリリースおよび回帰アクティビティの一部として寿命テストとその関連アクティビティを含めるための初期コスト
  • に最適 ウォーターフォールモデル
  • アジャイル/スクラムモデルでは、期間とカバレッジを微調整する必要があります

結論

お客様から報告された問題から発生する「欠陥」の多くは、主にテストエスケープが原因です。これは、次に、テスト計画の開発、レビュー、適用範囲、実行などの多くの質問を求めます。

外部で見つかった欠陥（EFD）または顧客で見つかった欠陥（CFD）は、顧客と製品組織にビジネス（$$$）の影響を及ぼします。

寿命テストは独自のものであり、顧客が欠陥を見つける前に欠陥を特定して解決することにより、製品組織が顧客満足度を向上させるのに役立つはずです。寿命テストは、安定性の向上にも役立ち、堅牢な品質のシステムまたは製品を実現します。

著者について： この記事はSTHの作者Vinayakによって書かれました。彼はフォーチュン500企業で12年間のQA /テストの経験があります。

この記事について質問や提案があればお知らせください。

推奨読書

^