how effectively prepare test bed
テストベッド/テスト環境のセットアップの課題とベストプラクティス：
テスターは、環境問題のために欠陥が拒否されたり、同様の理由で欠陥を絶えず複製していることに気付く場合があります。最も多くの欠陥を開くことは、確かにすべてのテスターの個人的なベンチマークの1つである必要がありますが、ほとんどのテスターは、最も多くの有効な欠陥があることも強調する必要があります。
これはどのように達成されますか？
さまざまなテストシナリオの計画や広告申込情報の完全な理解などの他の側面とは別に、 テストベッドまたはテスト環境のセットアップには、かなりの時間を費やす必要があります 。第二に、テストケース計画の見積もり額があるにもかかわらず、テスターは 彼らのエネルギーを集中する 効果的なテストデータの作成 。
個人的には、監査プロセスの一環として、テストベッドまたはテスト環境を正しい方法で作成するために多大な労力を費やし、テスターが徹底的に調査した場合に、最も多くの有効な欠陥が見つかることを確認しました。必要な環境の種類の理解。
また、テスト環境に提供されるテストデータの種類によって、テスト対象のコード/機能に非常に深刻な欠陥が発生し、製品の品質に深刻な影響を与える可能性があります。
この記事では、テストベッドの正確な内容について説明します。これは、テスト環境のセットアップとテストデータのセットアップの2段階のプロセスです。
パート1） 記事の前半では、 テスト環境のセットアップの一般的なプロセス 、これらの課題の代わりにテストベッドを作成する際に留意すべきテストとポインタが直面する最も一般的に直面するセットアップの問題。
パート2） この記事でまとめてテストベッドに関して多くのことを述べたので、いくつかの光を当てる価値がありました テスト環境のメンテナンス 側面も。記事の後半では、テストベッドのセットアップの2番目の部分について説明します。これには、テストデータをセットアップするためのアプローチと、いくつかの効果的なものが含まれます。 テストデータ管理手法 。
ソフトウェアの開発とテストには常に「ビッグバン」があり、品質保証プロセス全体を透過的、効率的、適切にするためにさまざまな方法論を採用することにますます大きな焦点が当てられています。
組織全体でさまざまな品質監査が実施され、テストチームのパフォーマンスを適切に評価でき、テストサイクルの初期化時に特定されたメトリックで測定可能な結果が得られることを確認します。これらの結果により、テストするソフトウェアの最適な品質を確保するという観点から、特定のチームがどこに立っているかを特定できます。
これらのレポートは、監査中に行われた観察に基づいて、チームが改善の機会を理解するのにも役立ちます。
言うまでもなく、テストチームにとって非常に明白な指標は、開かれた欠陥の総数と 有効な欠陥の数 。したがって、明らかに浮かび上がる質問の1つは、欠陥を発見しようとする根拠は何ですか。別の言い方をすれば、欠陥を見つけることができる基盤は何ですか？
答えは全会一致です–テストベッドおよび/またはテスト環境のセットアップ。チーム内で設定された品質ベンチマークがあります 拒否された欠陥を減らす テストセットアップエラー/ユーザーエラー、無効な構成、または場合によっては、使用できない構成、テストされていない構成が原因で特定のチームから脱出することで発生する欠陥として。
まず、テストベッドまたはテスト環境とは何かを定義する方法を詳しく見ていきましょう。
学習内容：
テストベッドとテスト環境とは何ですか？
非常に一般的な意味で、テストベッドは一種の開発環境として定義できます。これにより、コードまたはモジュールの実装者は、テストチームからの妨害を受けることなく、完全に制限された状態でモジュールを自由にテストできます。
ただし、テストベッドは開発チームに固有のものだけではありません。テストチームまたはテスターの観点からは、テストベッドはソフトウェア/製品テスト用に識別されたプラットフォームにすぎないため、同じ意味でテスト環境とも呼ばれます。
テストベッドまたはテスト環境は、テスト対象のアプリケーション/製品/ソフトウェアに対して特定されたテスト目標を満たすように構成する必要があります。特定の状況では、テストベッドはテスト環境とそれが動作するテストデータの照合です。
テスト環境のコンポーネント
すべてのテストには特定のテスト環境要件がありますが、非常に広い意味で、テストベッド/テスト環境は、特定のテストを実行および実行するために最低限必要な構成をサポートするハードウェア、ソフトウェア、およびネットワーク要素で構成されます。 。
テスターの時間が環境問題によってかなりの時間が費やされ、それが生産性とテストスケジュールに影響を与えることはよく知られている事実です。課題の種類はテストチームごとに異なりますが、一般的なものもあります。
一般的に直面するいくつかの重要な課題は次のとおりです。
＃1）リモート環境
テスト資産またはテスト環境は、ほとんどの場合、チームから離れた場所に地理的に配置されています。これは、ハードウェア、ファームウェア、ソフトウェア、ネットワークなどに関連して発生する可能性のある問題の場合のように、テストチームにとって最も一般的に直面する課題の1つです。
資産を消費するチームは、資産が存在する場所のサポートチームに大きく依存する必要があります。
同じように、一部のアセットでファームウェアのアップグレードまたはビルドのアップグレードが必要な場合も、テストチームは、サポートチケットを開いて、環境を所有するサポートチームのサポートを必要とする場合があります。これはまた、特にタイムゾーンの違いの場合に、かなりのテスト時間と遅延スケジュールを浪費する可能性があります。
＃2）チーム間の併用
ほとんどの場合、開発チームとテストチームは同じ環境資産を使用します。一般的な基準では、開発、テスト、および実稼働環境を分離する必要があると定義されていますが、実際には、この理想的なシナリオが実現されることはめったにありません。組織がチームごとに個別のリソースを調達することは、非常にコストがかかりにくくなります。
したがって、ほとんどの組織は、開発とテストの間で環境の一般的な使用法を義務付けています。これに加えて、開発リソースとテストリソースが同じアセットの使用を同時に争うと、メンバー内で混乱や意見の不一致が発生します。
＃3）統合のためのリソース使用の非効率的な計画
場合によっては、 エンドツーエンドのテスト これにより、2つ以上のコンポーネントが統合されて一緒に機能するため、テストチーム間でリソースを共通に使用する必要がある場合があります。使用法に関する効果のない計画は、チーム間の対立に加えて、環境が不安定になる大きな要因です。
これの最も明白な効果は、特定の1回または2回に気付いた問題が、同じシナリオの次の実行で完全に異なる動作を生成する可能性があることです。このためにすでに欠陥が開かれている場合、修正の有効な候補として開発によって受け入れられない可能性が高くなります。
＃4）複雑なテスト構成
テストベッドまたはテスト環境の構成が複雑すぎる場合があります。テストチームは必要な構成を理解するために必要なスキルを必要とするため、これにはいくつかの課題があります。テスターが必要な構成を考え出すために利用できる知識ベースが不足している場合があります。
このような場合、テスター自身がテストベッドを誤って構成することにより、テストベッドでエラーを引き起こす可能性があります。これは、テストケースとそれが生成する結果に大きな影響を与えます。
＃5）手の込んだセットアップ時間
また、テストケースごとに、特定されたテストケースごとにテストの設定が複雑すぎる場合もあります。これは、統合テストの場合に、一緒に結合する必要がある、または複数のコンポーネントを一緒に機能させる必要がある、多種多様な共存テクノロジーが原因である可能性があります。
このような場合、1つのコンポーネントが次のコンポーネントへの入力を形成する可能性があるため、一貫した結果を保証するには、各コンポーネントが完全に機能している必要があります。
テスト環境を設定するためのベストプラクティス
テストの実行前または開始中にテスターが直面する課題の概要を確認しました。私たちのほとんどは、プロジェクトのマイルストーンのある時点で、これらの問題の1つ以上に直面しています。これらの課題は存在しており、理想的な状況が存在しないため、さまざまな程度で存在し続ける可能性があります。
セットアップの課題はテスターの仕事の一部であり、避けられないことを考えると、テスト用にセットアップを効果的に準備する方法に関するいくつかの提案があります。これは、セットアップの問題に起因する可能性のある欠陥を最小限に抑えるのに役立ちます。
ヒント＃1） 理解する 要件を徹底的にテストする 自分自身を教育します
マージソートソースコードc ++
常に基本から始め、最も明白なものから始めましょう！仕様書またはユースケース文書が開発チームによって展開される場合、テストチームの不変のステップは、ラインアイテムの要件を理解してから、テストケースの詳細を示すテストケース文書を準備することです。
テスト計画が実行されている間、それは 最高の テストケースドキュメントに詳細なテスト環境情報も含めるように練習してください。その後、テスターが必要なテスト環境とそれに応じて必要な構成の分析に時間を費やすという事実を推測することはできません。
これは、優れた知識ベースを構築するために開発チーム/アーキテクトと話し合うことで達成できます。これにより、実行サイクルの時間が節約されるだけでなく、テスターが単純なテストと複雑なテストの間で実行時間を効果的に割り当てることができます。
個人的には、これの良い結果は、サイクルの最初の段階でセットアップの問題（本質的に一貫したテストの実行を妨げる）を発見したことです。これにより、これらの問題を修正するために必要なヘルプをチャネル化して取得する時間ができました。許容できない期間を超えてテストサイクルを延長しない。
これがもたらすもう1つのプラスの影響は、これによりテストチームの知識が大幅に向上し、不要な欠陥が防止されることです。このプラクティスは、上記のテストセットアップの課題に対処するために本質的に必要なほぼすべてのプラクティスをまとめたものですが、それでも他のヒントについて言及する価値があります。
ヒント＃2） 接続の確認
もう1つの最も重要なチェックポイントは、テストに使用する予定のリソースまたはアセットが到達可能であることを確認することです。システムを他のマシンと統合して実行する必要がある場合は、pingまたはtelnetを使用して相互の接続を確認してください。
また、システムが相互に対話する必要があり、ファイアウォールの背後にある場合は、基本セキュリティオプション（BSO）を使用してこれらのファイアウォールを介して認証できることを確認し、プロキシも確認してください。一部のマシンに到達できない、またはBSO認証が必要であることに気付いた場合は、サポートチームへの要件を満たすために、適切なサービスリクエストを発行できます。
これは、環境が遠隔地にある場合に特に役立ち、マシンやシステムに関するエスカレーションも回避します。テストチームがリソースまたはリポジトリへのアクセスを必要とする場合、これはプロアクティブに同じものを決定するのに役立ちます。
ヒント＃3）ネットワークやストレージの確認
これは前のヒントのほとんどの拡張であり、技術的な深さを増した他の特定のチェックが必要になります。必要なテストに必要な帯域幅があること、およびテストにインターネット接続が必要かどうかを確認してください。また、システムとリソース間のネットワークトポロジが正しいことを確認する方法を見つけてください。
次に、テストの目標がストレージの必要性を示唆している場合は、ストレージとネットワーク接続があることを確認してください。ほとんどの場合、これを実施するのは管理者の責任ですが、同じことに関する実用的および機能的な知識を持っていることも大きな付加価値です。
ヒント＃4） 必要なハードウェアとソフトウェア、ライセンスを確認してください
多くの場合、テスターは必要なハードウェアとソフトウェアをチェックせずにシステムで実行を開始します。これが何度も行われた結果、テスターは、テストサイクルのほぼ間に、特定の機能がより高いレベルのハードウェアまたはソフトウェア/ファームウェアでのみ利用可能であることに気付きます。
その時点で、テスターはテスト作業でブロッカーにフラグを立て、かなりのテスト時間を消費します。したがって、事前に必要なハードウェアとソフトウェアを記録するためのチェックポイントを用意することは、貴重な慣行です。
多くの場合、ハードウェア/ソフトウェアのアップグレードに伴うダウンタイムが発生する可能性があります。 ヒント1 テスターがハードウェアに関する事前計画に関与する必要がある場合。一部のソフトウェアには、法務チームからの承認とアクションが必要なライセンスが必要な場合があります。これはプロセス主導のアクションであるため、実行されるまでに数日かかる場合があり、計画する必要があります。
ヒント＃5）ブラウザとバージョン
あなたが行うテストはミラーリングする必要があります エンドユーザーが実行する内容 。彼は、すべてのブラウザーの最新バージョンの特定のブラウザーでテストしている可能性があります。したがって、テストに使用されるさまざまな種類のブラウザを特定し、それらを独自のローカルテストセットアップにインストールする必要があります。
次に、テストに使用する必要のあるブラウザのバージョンも特定します。下位バージョンのブラウザから始めて、下位互換性を確保してから、最新バージョンにアップグレードすることをお勧めします。
ヒント＃6）テスト環境の使用を計画します。
テストチームが独自のテストリソース、システム、および資産を所有する状況になることは決してないという事実を考えると、テストリソースを効果的に使用することは、テスト計画の主要なマイルストーンの1つです。
イーサネットのデフォルトゲートウェイは利用できません
これは、2つ以上のコンポーネントが連携して動作するエンドツーエンドのシナリオ、またはテストセットアップが複雑すぎて複製できない状況のために、複数のチームが同じリソースセットにアクセスする必要がある場合に特に必要です。非常に簡単で、同じチーム内に複数のメンバーが同じセットアップでテストオウンゴールを持っている可能性があります。
特定のチームまたは人が前半にそれを使用し、残りの人が後半にそれを使用するタイムシェアリングアプローチを考案することをお勧めします。その間には、それぞれが他のテストを妨げない独立したテストを実行できることが一般的である場合があります。
これを行うことで、メンバー内の混乱や対立を減らすだけでなく、環境の行動の安定性を長期間確保することもできます。
ヒント＃7）自動化ツールとその構成
ご存知のように、テストのすべての項目には、自動化する必要がある回帰サイクルの一部となるいくつかの反復テストがあります。テストチームは、実行したい自動化の種類とそれに必要なツールを特定する必要があります。
これは環境準備の一部である必要はありませんが、自動化ツールを特定してそれに応じて構成するためのベストプラクティスとしてこれをリストします。これは、テストの準備を確実にするための必須の要素ではないため、このアクティビティを実行する場合は、テスターの裁量に完全に依存します。
結論
これらのヒントとコツは、テスト環境のテスト準備を確実にするための適切な尺度とフットプリントを形成することができます。間違いなく、各チームは独自の一連の課題に直面しており、上記のヒントは、それぞれのニーズに合わせて調整およびカスタマイズできます。
実際、このヒントの骨組み全体を書き留めるソースは、非常に複雑なセットアップの問題に直面し、テストを開始するのにほぼ1年かかった私の割り当ての1つから来ています！
テスト環境の制限は私の手に負えませんでしたが、これらのヒントを適用していれば、これらの問題の多くが以前に報告された可能性があると感じました。それ以来、私はこれをすべての課題に適用してきました。このスケルトンは、セットアップの問題を積極的に見つけ、それらを解決するための努力をチャネル化するのに大いに役立ちました。
著者について： この記事はSnehaNadigによって書かれました。彼女は、手動および自動化テストプロジェクトで7年以上の経験を持つテストリーダーとして働いています。
この記事のパート2では、テスト環境のセットアップとメンテナンスのプロセス、およびテストデータの準備と管理のヒントについて説明します。 その間、コメントであなたのテストベッド準備質問を投稿してください。