test execution software testing
正確なプロセスと実際の例を使用してテストケースを実行する計画。
バブルソートアルゴリズムc ++
今日、私たちの ソフトウェアテストミニトレーニングコース 、私たちはSTLCの最終段階に進んでいます。 テストの実行 。
このページで、この無料のQAトレーニングシリーズに投稿されているすべてのチュートリアルのリストを確認できます。 ライブプロジェクトでのエンドツーエンドのソフトウェアテストトレーニング。
テストの実行は、間違いなく、最も重要で「起こっている」フェーズです。 STLC また、開発ライフサイクル全体。 その理由は、すべてのチーム/チームメンバーの貢献と作業がここで検証されるためです。
- ビジネスアナリストは要件を正しく解釈しましたか？
- 開発チームは、ビジネス要件を機能要件に変換し、最終的には正しくコーディングしましたか？
- データアーキテクトとDBAは適切なバックエンドシステムを設計しましたか？
さて、テストの実行は、これらの質問に対するすべての答えが見つかる場所です。それは私たちを作ります、QAソフトウェア構築プロセス全体のヒーローですよね？ :)
テストの実行は、SDLCの「テスト」部分でもあります。
テストケースが作成され、BAおよび開発チームと共有され、レビューされると、変更がQAチーム（存在する場合）に通知され、QAチームが必要な修正を行います-テスト設計フェーズが完了します。テストケースの準備ができたからといって、テストの実行を開始できるわけではありません。とりわけ、アプリケーションを準備する必要があります。
学習内容：
テスト実行ガイドライン
ここで、テスト実行フェーズを理解するために重要なすべてのもののリストを作成しましょう。
＃1） ザ・ ビルド （開発チームによって作成されたコードは、ビルドと呼ばれるものにパッケージ化されています。これは、QA環境にデプロイする準備ができているインストール可能なソフトウェア（AUT）にすぎません。）デプロイされている（つまり、インストールされている） QA環境で利用できるようにすることは、テスト実行を開始するために必要な最も重要な側面の1つです。
＃二） テストの実行は、 QA環境 。コードに関する開発チームの作業が、QAチームがテストしている場所と同じ場所にないことを確認するために、一般的な方法は、専用の開発およびQA環境を用意することです。 （ライブアプリケーションをホストするための実稼働環境もあります）。
これは基本的に、SDLCライフサイクルのさまざまな段階でアプリケーションの整合性を維持するためです。それ以外の場合、理想的には、3つの環境すべてが本質的に同一です。
＃3） テストチームのサイズ プロジェクトの最初から一定ではありません。テスト計画が開始されると、チームはチームリーダーを持っている可能性があります。テスト設計段階では、数人のテスターが参加します。テストの実行は、チームが最大サイズになっているフェーズです。
＃4） テストの実行は、 少なくとも2サイクル （一部のプロジェクトでは3つ）。通常、各サイクルで、すべてのテストケース（テストスイート全体）が実行されます。最初のサイクルの目的は、ブロッキング、重大な欠陥、およびほとんどの高欠陥を特定することです。
2番目のサイクルの目的は、残りの高および中程度の欠陥を特定し、スクリプトのギャップを修正して結果を取得することです。
＃5） テスト実行フェーズは、次のもので構成されます。 テストスクリプトの実行+テストスクリプトのメンテナンス（スクリプトのギャップの修正）+レポート（欠陥、ステータス、メトリックなど） したがって、このフェーズを計画するときは、 努力を見積もる必要があります スクリプトの実行だけでなく、これらすべての側面を考慮に入れます。
＃6） テストスクリプトが実行され、AUTが展開された後、テストの実行が開始される前に、中間ステップがあります。これは、 「テスト準備レビュー（TRR）」 。これは一種の移行ステップであり、テストの設計フェーズを終了し、テストの実行を容易にします。
C ++幅優先探索
この手順と「テスト準備レビューチェックリスト」のサンプルについては、次のリンクを確認してください。 ソフトウェアテストチェックリスト
＃ 7） TRRに加えて、テスト実行のためにQA環境にデプロイされている現在のビルドを受け入れることができることを確認する前に、追加のチェックがいくつかあります。
それらは 煙と健全性テスト 。これらが何であるかに関する詳細情報は次のとおりです。 煙と健全性テストとは何ですか？
＃8） TRR、煙、および健全性テストが正常に完了すると、テストサイクルが正式に開始されます。
＃9） 探索的テスト ビルドがテストの準備ができたら実行されます。このテストの目的は、次のレベルのテストを開始する前に、重大な欠陥が除去されていることを確認することです。この探索的テストは、テストスクリプトやドキュメントなしでアプリケーションで実行されます。また、AUTに慣れるのにも役立ちます。
＃10） STLCの他のフェーズと同様に、テスト実行フェーズでも作業はチームメンバー間で分割されます。分割は、モジュールごと、テストケース数ごと、またはその他の意味のあるものに基づいている場合があります。
＃十一） テスト実行フェーズの主な結果は、主にレポートの形式です。つまり、欠陥レポートとテスト実行ステータスレポートです。報告の詳細なプロセスは、次の場所にあります。 テスト実行レポート。
テストケースドキュメントの新しい列
テストケースドキュメントは、次の2つの列で展開されます– 現状と実績 。
（（ 注意 ：ライブプロジェクトのテスト実行については、以下のダウンロード用に提供されているテストケーススプレッドシートのテスト実行結果でこれらの列を追加および更新しました）
＃1）ステータス列
テストの実行は、AUTのテスト手順を使用して、テストデータ（テストケースドキュメントで識別される）を提供し、AUTの動作を観察して、期待される結果を満たしているかどうかを確認することに他なりません。
期待した結果が得られない場合は、欠陥と見なすことができます。そして、テストケースのステータスは「Fail」になり、期待される結果が満たされた場合、ステータスは「Pass」になります。何らかの理由（既存の欠陥またはサポートされていない環境）のためにテストケースを実行できない場合、ステータスは「ブロック済み」になります。
まだ実行されていないテストケースのステータスは、(実行なし/未実行)に設定するか、空のままにすることができます。
- 複数のステップがあるテストケースの場合、特定のステップ（テストケースステップの途中）の期待される結果が満たされない場合、テストケースのステータスをその場で「失敗」に設定でき、次のステップを実行する必要はありません。
- すぐに注意を引きたい場合は、ステータス「失敗」を赤色で表示できます。
＃2）実績欄
これは、テスターが期待される結果の偏差を記録できるスペースです。期待される結果（またはステータスが「合格」のテストケース）が満たされた場合、このフィールドは空のままにすることができます。なぜなら、期待される結果が満たされる場合、それは実際の結果=期待される結果を意味します。つまり、実際の結果列にそれを書き換えると、繰り返しと冗長性が発生します。
問題が何であるかをより明確にするために、偏差のスクリーンショットをこの列に添付できます。
OrangeHRMライブプロジェクトのテスト実行結果
OrangeHRMを入手して、上記のガイドラインに基づいてテストを実行してみましょう。
注意すべき点がいくつかあります。
- 拡張テストケーステンプレート。
- 示されている探索的テストは、テストスクリプトなしで実行されます。したがって、必要に応じて、アプリケーションを並行してテストしてください。
- 読み取り可能なコンテンツの形式でライブプロジェクトを提示する際の制限により、サンプルのテスト実行テンプレートには、限られた量のOrangeHRMアプリケーションのテストケース/機能のみが表示されます。繰り返しになりますが、最も実用的な体験のためにもっと努力してください。
- SanityおよびSmokeテストスイートもドキュメントに追加され、これらの段階でどのような種類のテストケースが考慮されるかについてのアイデアを提供します。
- 一部のテストケースのステータスが「失敗」に設定されていても、欠陥はまだログに記録されていません。これは、欠陥をログに記録することが、テスターとしての私たちの生活の側面で次に重要/一般的に取り組んでいるためです。それで、次の記事でそれを詳細に扱いたいと思います。
実行結果のあるテストケース：
=> テストケース実行ドキュメントをダウンロードするには、ここをクリックしてください。
を含む –テストケースの実行結果、スモークテスト、健全性テスト、探索的テスト–スプレッドシート
最後に、テスト管理ツールを使用してテストケースを作成および保守した場合は、同じものをテストの実行にも使用できます。ツールを使用するとレポートが簡単になりますが、それ以外の点では、テストケースを実行するプロセスは同じです。のアイデアを得るためにこの記事をチェックしてください テストケースの実行にHPALMを使用する方法 。
IPを無料でddosする方法
（画像をクリックすると拡大表示されます）
これで、テストプロセスの別の興味深いセグメントが終了します。これの次のそして最後の記事で 無料のオンラインソフトウェアテストQAトレーニングミニコース 、欠陥を詳細に調べます。 「テストをいつ停止するか」、メトリクス、QAサインオフなどのトピックをまとめます。
=> QAトレーニング6日目： バグ追跡、テストメトリック、およびテストサインオフ
現在の状況をお知らせください。次の記事にご期待ください。