what is system testing ultimate beginner s guide
ソフトウェアテストにおけるシステムテストとは何ですか?
システムテストとは、システム全体をテストすることを意味します。システムが期待どおりに機能するかどうかを確認するために、すべてのモジュール/コンポーネントが統合されています。
システムテストは、統合テストの後に行われます。これは、高品質の製品を提供する上で重要な役割を果たします。
チュートリアルのリスト:
統合されたハードウェアおよびソフトウェアシステムをテストして、システムが指定された要件を満たしていることを確認するプロセス。
検証 :特定の要件が満たされていることの調査と客観的証拠の提供による確認。
アプリケーションに3つのモジュールA、B、およびCがある場合、モジュールAとB、モジュールBとC、またはモジュールAとCを組み合わせて実行されるテストは、統合テストと呼ばれます。 3つのモジュールすべてを統合し、それを完全なシステムとしてテストすることを、システムテストと呼びます。
学習内容:
- 私の経験
- アプローチ
- なぜシステムテストなのか?
- これはホワイトボックステストですか、それともブラックボックステストですか?
- システムテストを実行する方法は?
- 利点
- 入退場基準
- システムテスト計画
- システムテストケースを作成する手順
- システムテストケース
- システムテストの種類
- システム統合テストとは何ですか?
- システムテストと検収テストの違い
- システムテストを実行するためのヒント
- 結論
- 推奨読書
私の経験
それで…あなたは本当にテストするのにその膨大な時間がかかると思いますか、あなたはそれを呼んでいます システムテスト 、統合テストに多くの努力を費やした後でも?
私たちが最近プロジェクトのためにアプローチしたクライアントは、私たちが各テスト作業に対して提供した見積もりについて確信していませんでした。
私は例を挙げてチャイムを鳴らさなければなりませんでした:
マイク、私たちの取り組みとシステムテストの重要性について例を挙げて詳しく説明したいと思います。
シュート、彼は答えた。
システムテストの例
自動車メーカーは、自動車全体を製造しているわけではありません。シート、ステアリング、ミラー、ブレーキ、ケーブル、エンジン、車のフレーム、ホイールなど、車の各コンポーネントは個別に製造されています。
各アイテムを製造した後、それが想定どおりに機能しているかどうかを個別にテストします。これを単体テストと呼びます。
Visual Studio Team Foundation Server2015チュートリアル
これで、各パーツを別のパーツと組み立てるときに、組み立てによって各コンポーネントの機能に悪影響がないかどうか、および両方のコンポーネントが期待どおりに機能しているかどうかがチェックされます。これは統合テストと呼ばれます。
すべての部品が組み立てられ、車の準備ができたら、実際には準備ができていません。
車がスムーズに運転できるか、ブレーキ、ギア、その他の機能が適切に機能しているか、2500マイル連続で運転した後、車に疲労の兆候が見られないか、色など、定義された要件に従って、車全体をさまざまな側面でチェックする必要があります。車は一般的に受け入れられ、好まれています。車は滑らかで荒い、ずさんな、まっすぐな道路など、あらゆる種類の道路を走行できます。このテスト作業全体はシステムテストと呼ばれ、統合テストとは関係ありません。
この例は期待どおりに機能し、クライアントはシステムテストに必要な作業について確信していました。
このテストの重要性を奨励するために、ここで例をナレーションしました。
アプローチ
統合テストが完了すると実行されます。
これは主にブラックボックスタイプのテストです。このテストでは、仕様書を使用して、ユーザーの観点からシステムの動作を評価します。コードの設計や構造など、システムに関する内部知識は必要ありません。
これには、アプリケーション/製品の機能領域と非機能領域が含まれています。
焦点基準:
主に以下に焦点を当てています。
- 外部インターフェース
- マルチプログラムと複雑な機能
- セキュリティ
- 回復
- パフォーマンス
- オペレーターとユーザーのシステムとのスムーズな相互作用
- インストール可能性
- ドキュメンテーション
- 使いやすさ
- 負荷/ストレス
なぜシステムテストなのか?
#1) 完全なテストサイクルを完了することは非常に重要であり、STはそれが行われる段階です。
#二) STは本番環境と同様の環境で実行されるため、利害関係者はユーザーの反応をよく理解できます。
#3) 展開後のトラブルシューティングとサポートコールを最小限に抑えるのに役立ちます。
#4 )このSTLCステージでは、アプリケーションアーキテクチャとビジネス要件の両方がテストされます。
このテストは非常に重要であり、高品質の製品を顧客に提供する上で重要な役割を果たします。
日々のタスクを含む以下の例を通して、このテストの重要性を見てみましょう。
- 確認後にオンライン取引が失敗した場合はどうなりますか?
- オンラインサイトのカートに入れられたアイテムが注文を許可しない場合はどうなりますか?
- Gmailアカウントで新しいラベルを作成すると、[作成]タブをクリックしたときにエラーが発生した場合はどうなりますか?
- システムの負荷が増加したときにシステムがクラッシュした場合はどうなりますか?
- システムがクラッシュし、必要に応じてデータを回復できない場合はどうなりますか?
- システムへのソフトウェアのインストールに予想よりもはるかに時間がかかり、最後にエラーが発生した場合はどうなりますか?
- 強化後にWebサイトの応答時間が予想よりもはるかに長くなった場合はどうなりますか?
- Webサイトが遅くなりすぎて、ユーザーが旅行チケットを予約できなくなった場合はどうなりますか?
上記は、適切な方法で実行されなかった場合にシステムテストがどのように影響するかを示すためのほんの数例です。
上記の例はすべて、システムテストが実行されていないか、適切に実行されていない結果です。製品が要件に従って機能することを確認するために、すべての統合モジュールをテストする必要があります。
これはホワイトボックステストですか、それともブラックボックステストですか?
システムテストは、ブラックボックステスト手法と見なすことができます。
ブラックボックステスト ホワイトボックステクニックはコードの内部知識を必要としますが、テクニックはコードの内部知識を必要としません。
システムテストの機能と非機能の実行中に、セキュリティ、パフォーマンス、およびその他の多くのテストタイプがカバーされ、入力がシステムに提供され、出力が検証されるブラックボックス技術を使用してテストされます。システム内部の知識は必要ありません。
ブラックボックステクニック:
システムテストを実行する方法は?
これは基本的にソフトウェアテストの一部であり、テスト計画には常にこのテスト用の特定のスペースが含まれている必要があります。
システム全体をテストするには、要件と期待が明確であり、テスターはアプリケーションのリアルタイムの使用法も理解する必要があります。
また、最もよく使用されるサードパーティツール、OSのバージョン、OSのフレーバー、およびアーキテクチャは、システムの機能、パフォーマンス、セキュリティ、回復可能性、またはインストール可能性に影響を与える可能性があります。
したがって、システムをテストする際には、アプリケーションがどのように使用されるのか、およびアプリケーションがリアルタイムで直面する可能性のある問題の種類を明確に把握することが役立ちます。それに加えて、要件文書はアプリケーションを理解することと同じくらい重要です。
明確で更新された要件ドキュメントは、テスターを多くの誤解、仮定、および質問から救うことができます。
要するに、リアルタイムのアプリケーションの使用法の理解とともに最新の更新を含む、先のとがった鮮明な要件ドキュメントは、STをより実りあるものにすることができます。
このテストは、計画的かつ体系的な方法で行われます。
以下に、このテストの実行中に必要なさまざまな手順を示します。
- 最初のステップは、テスト計画を作成することです。
- システムテストケースとテストスクリプトを作成します。
- このテストに必要なテストデータを準備します。
- システムテストケースとスクリプトを実行します。
- バグを報告してください。修正後、バグを再テストします。
- 回帰試験 コードの変更による影響を確認します。
- システムを展開する準備ができるまで、テストサイクルを繰り返します。
- テストチームからサインオフします。
何をテストしますか?
このテストでは、以下の点について説明します。
- エンドツーエンドのテスト これには、すべてのコンポーネント間および外部周辺機器との相互作用を検証して、システムがいずれかのシナリオで正常に動作するかどうかを確認することが含まれます。
- システムに提供された入力が期待される結果を提供することを確認します。
- すべての機能要件と非機能要件がテストされているかどうか、およびそれらが期待どおりに機能するかどうかを検証します。
- これに スクリプトテストが完了した後、このテストで探索的テストを実行できます。 探索的テスト アドホックテストは、スクリプトテストでは見つけることができないバグを明らかにするのに役立ちます。これは、テスターの希望が経験と直感に基づいているため、テスターが自由にテストできるようにするためです。
利点
いくつかの利点があります。
- このテストには、システムをテストするためのエンドツーエンドのシナリオが含まれます。
- このテストは、実稼働環境と同じ環境で実行されます。これにより、ユーザーの視点を理解し、システムの稼働時に発生する可能性のある問題を防ぐことができます。
- このテストが体系的かつ適切な方法で行われる場合、ポストプロダクションの問題を軽減するのに役立ちます。
- このテストでは、アプリケーションアーキテクチャとビジネス要件の両方をテストします。
入退場基準
システムテストの開始/終了基準を詳しく見てみましょう。
エントリー基準:
- システムは統合テストの終了基準に合格している必要があります。つまり、すべてのテストケースが実行されており、オープン状態のP2バグであるクリティカルまたは優先度P1がないはずです。
- テスト計画 このテストでは、承認して承認する必要があります。
- テストケース/シナリオを実行する準備ができている必要があります。
- テストスクリプトを実行する準備ができている必要があります。
- すべての非機能要件が利用可能であり、同じもののテストケースが作成されている必要があります。
- テスト環境の準備ができている必要があります。
終了基準:
- すべてのテストケースを実行する必要があります。
- 重大なバグ、優先度のバグ、またはセキュリティ関連のバグを開いた状態にしてはなりません。
- 中優先度または低優先度のバグがオープン状態にある場合は、お客様の同意を得て実装する必要があります。
- 終了レポートを提出する必要があります。
システムテスト計画
テスト計画は、開発する製品の目的、目的、および範囲を説明するために使用されるドキュメントです。何をテストする必要があり、何をテストしないか、テスト戦略、使用するツール、必要な環境、およびその他すべての詳細は、テストをさらに進めるために文書化されています。
テスト計画は、非常に体系的かつ戦略的な方法でテストを進めるのに役立ち、テストの実行中にリスクや問題を回避するのに役立ちます。
システムテスト計画は、次の点をカバーしています。
- このテストでは、目的と目的が定義されています。
- 範囲(テストする機能、テストしない機能がリストされています)。
- テスト受け入れ基準(システムが受け入れられる基準、つまり、受け入れ基準に記載されているポイントは合格状態である必要があります)。
- 開始/終了基準(システムテストを開始する時期と完了したと見なす時期の基準を定義します)。
- テストスケジュール(特定の時間に完了するテストの見積もり)。
- テスト戦略 (テスト手法を含みます)。
- リソース(テストに必要なリソースの数、それらの役割、リソースの可用性など)。
- テスト環境(オペレーティングシステム、ブラウザ、プラットフォーム)。
- テストケース (実行するテストケースのリスト)。
- 前提条件(前提条件がある場合は、テスト計画に含める必要があります)。
システムテストケースを作成する手順
システムテストケースは、すべてのシナリオとユースケースをカバーし、機能、非機能、ユーザーインターフェイス、セキュリティ関連のテストケースもカバーします。テストケースは、機能テスト用に作成されたものと同じ方法で作成されます。
システムテストケースには、テンプレートに次のフィールドが含まれています。
- テストケースID
- テストスイート名
- 説明–実行するテストケースについて説明します。
- ステップ–テストの実行方法を説明するステップバイステップの手順。
- テストデータ–アプリケーションをテストするためにダミーデータが用意されています。
- 期待される結果–要件ドキュメントに従って期待される結果がこの列に表示されます。
- 実際の結果–テストケースの実行後の結果がこの列に表示されます。
- 合格/不合格–実際の結果と期待される結果の比較により、合格/不合格の基準が定義されます。
- 備考
システムテストケース
eコマースサイトのテストシナリオの例を次に示します。
- 関連するすべてのページ、機能、ロゴを使用してサイトが適切に起動した場合
- ユーザーがサイトに登録/ログインできる場合
- ユーザーが利用可能な商品を確認できる場合は、カートに商品を追加して支払いを行い、電子メール、SMS、または電話で確認を得ることができます。
- 検索、フィルタリング、並べ替え、追加、変更、ウィッシュリストなどの主要な機能が期待どおりに機能する場合
- (要件文書で定義されている)ユーザー数が同時にサイトにアクセスできる場合
- サイトがすべての主要なブラウザとその最新バージョンで正しく起動する場合
- 特定のユーザーを介してサイトでトランザクションが行われている場合、十分に安全です
- Windows、Linux、モバイルなど、サポートされているすべてのプラットフォームでサイトが適切に起動する場合。
- ユーザーマニュアル/ガイドの返品ポリシー、プライバシーポリシー、およびサイトの使用条件が別のドキュメントとして利用可能であり、初心者または初めてのユーザーに役立つ場合。
- ページのコンテンツが適切に配置され、適切に管理され、スペルミスがない場合。
- セッションタイムアウトが実装され、期待どおりに機能している場合
- ユーザーがサイトを使用した後に満足している場合、つまりユーザーがサイトを使用するのが難しいと感じていない場合。
システムテストの種類
STは、すべての主要なタイプのテストがカバーされているため、すべてのタイプのテストのスーパーセットと呼ばれます。テストの種類に焦点を当てることは、製品、組織のプロセス、タイムライン、および要件に基づいて異なる場合があります。
全体として、次のように定義できます。
機能テスト: システムの機能の範囲内で、製品の機能が定義された要件に従って機能していることを確認するため。
回復可能性テスト: システムがさまざまな入力エラーやその他の障害状況からどの程度回復するかを確認するため。
相互運用性テスト: システムがサードパーティ製品で正常に動作するかどうかを確認するため。
性能試験: パフォーマンス特性の観点から、さまざまな条件下でシステムのパフォーマンスを確認するため。
スケーラビリティテスト: ユーザースケーリング、地理的スケーリング、リソーススケーリングなど、さまざまな用語でシステムのスケーリング機能を確認するため。
信頼性テスト: 障害が発生することなく、システムを長期間操作できるようにするため。
回帰試験: さまざまなサブシステムとメンテナンスタスクの統合を通過する際のシステムの安定性を確保するため。
ドキュメントテスト: システムのユーザーガイドやその他のヘルプトピックのドキュメントが正しく、使用可能であることを確認するため。
セキュリティテスト: システムがデータやリソースへの不正アクセスを許可しないようにするため。
ユーザビリティテスト : システムが使いやすいことを確認するために、学び、操作してください。
その他のシステムテストタイプ
#1)グラフィカルユーザーインターフェイステスト(GUI):
GUIテストは、システムのGUIが期待どおりに機能するかどうかを確認するために実行されます。 GUIは基本的に、ユーザーがアプリケーションを使用しているときに表示されるものです。 GUIテストには、ボタン、アイコン、チェックボックス、リストボックス、テキストボックス、メニュー、ツールバー、ダイアログボックスなどのテストが含まれます。
#2)互換性テスト:
互換性テスト 開発された製品が、要件ドキュメントに従って、さまざまなブラウザ、ハードウェアプラットフォーム、オペレーティングシステム、およびデータベースと互換性があることを確認するために行われます。
#3)例外処理:
例外処理テストは、製品で予期しないエラーが発生した場合でも、正しいエラーメッセージが表示され、アプリケーションが停止しないことを確認するために実行されます。製品が回復している間にエラーが表示されるように例外を処理し、システムが誤ったトランザクションを処理できるようにします。
#4)ボリュームテスト:
ボリュームテストは、大量のデータを使用してテストが行われる非機能テストの一種です。 例えば、 システムのパフォーマンスを検証するために、データベース内のデータの量が増加します。
#5)ストレステスト:
ストレステストは、アプリケーションが故障する程度まで、アプリケーションのユーザー数を(同時に)増やすことによって行われます。これは、アプリケーションが故障するポイントを確認するために行われます。
#6)健全性テスト:
健全性テスト コードまたは機能を変更してビルドがリリースされたとき、またはバグが修正されたときに実行されます。行われた変更がコードに影響を与えておらず、そのために他の問題が発生しておらず、システムが以前と同じように機能していることを確認します。
問題が発生した場合、ビルドはそれ以上のテストに受け入れられません。
基本的に、検出された問題のビルドを拒否するため、時間とコストを節約するために、ビルドの徹底的なテストは行われません。健全性テストは、システム全体ではなく、行われた変更または修正された問題に対して行われます。
#7)スモークテスト:
スモークテスト ビルドがさらにテスト可能かどうかを確認するためにビルドで実行されるテストです。ビルドがテストに対して安定しており、すべての重要な機能が正常に機能していることを確認します。システム全体に対してスモークテストが実行されます。つまり、エンドツーエンドのテストが実行されます。
#8)探索的テスト:
探索的テスト 名前自体が示すように、それはすべてアプリケーションの探索に関するものです。探索的テストでは、スクリプトによるテストは実行されません。テストケースは、テストとともに作成されます。計画よりも実行に重点を置いています。
テスターは、直感、経験、知性を使って自分でテストする自由があります。テスターは、最初にテストする機能を選択できます。つまり、構造的な方法を使用してテストを実行する他の手法とは異なり、テストする機能をランダムに選択できます。
#9)アドホックテスト:
アドホックテスト アプリケーションをテストするためのドキュメントや計画が行われない非公式のテストです。テスターは、テストケースなしでアプリケーションをテストします。テスターの目的は、アプリケーションを壊すことです。テスターは、彼の経験、推測、直感を使用して、アプリケーションの重大な問題を見つけます。
#10)インストールテスト:
インストールテスト ソフトウェアが問題なくインストールされているかどうかを確認することです。
ソフトウェアのインストールはユーザーと製品の間の最初の対話であるため、これはテストの最も重要な部分です。インストールテストの種類は、オペレーティングシステム、プラットフォーム、ソフトウェアの配布などのさまざまな要因によって異なります。
インストールがインターネット経由で行われる場合に含めることができるテストケース:
- ネットワーク速度が悪く、接続が切断されています。
- ファイアウォールとセキュリティ関連。
- サイズとおおよその時間がかかります。
- 同時インストール/ダウンロード。
- 不十分なメモリ
- スペースが足りない
- インストールの中止
#11)メンテナンステスト:
製品が稼働すると、問題は稼働環境で発生する可能性があります。または、製品に何らかの拡張が必要になる場合があります。
製品が稼働すると、メンテナンスが必要になります。メンテナンスチームがそれを処理します。問題、拡張、またはハードウェアへの移行について行われたテストは、メンテナンステストに該当します。
システム統合テストとは何ですか?
これは、同じ環境内の他のシステムと連携してデータの整合性と操作を維持するシステムの能力がチェックされているタイプのテストです。
システム統合テストの例:
有名なオンラインチケット予約サイトhttp://irctc.co.inの例を見てみましょう。
これはチケット予約施設です。オンラインショッピング施設はPayPalと相互作用します。全体として、A * B * C = Rと見なすことができます。
これで、システムレベルで、オンラインチケット予約機能、オンラインショッピング機能、およびオンライン支払いオプション機能を個別にシステムテストしてから、それぞれの統合テストをチェック実行できます。そして、システム全体を体系的にテストする必要があります。
では、システム統合テストはどこに登場するのでしょうか。
Webポータルhttp://Irctc.co.inは、システムの組み合わせです。同じレベル(単一システム、システムのシステム)でテストを実行できますが、各レベルで、さまざまなリスク(統合の問題、独立した機能)に焦点を当てることができます。
- オンラインチケット予約機能のテスト中に、オンラインでチケットを予約できるかどうかを確認できます。統合の問題も検討してください 例えば、 チケット予約機能は、バックエンドとフロントエンド(UI)を統合します。 例えば、 データベースサーバーの応答が遅い場合、フロントエンドはどのように動作しますか?
- オンラインショッピング施設を備えたオンラインチケット予約施設のテスト。システムにログインしたユーザーがオンラインでチケットを予約できるオンラインショッピング機能を利用できることを確認できます。オンラインショッピング施設への統合の検証を検討することもできます。 例えば、 ユーザーが手間をかけずに製品を選択して購入できる場合。
- オンラインチケット予約機能とPayPalの統合のテスト。チケットを予約した後、PayPalアカウントからオンラインチケット予約アカウントに送金されたかどうかを確認できます。 PayPalでの統合の検証を検討することもできます。 例えば、 システムが1回だけお金を引き落とした後、データベースに2つのエントリを配置した場合はどうなりますか?
差システムテストとシステム統合テストの間:
主な違いは次のとおりです。
- システムテストは、関連する環境との単一システムの整合性を管理します
- システム統合テストは、同じ環境にある複数のシステムの相互の整合性を管理します。
したがって、システムテストは、モジュール/機能ではなく、製品全体をテストする実際のテストの始まりです。
システムテストと検収テストの違い
主な違いは次のとおりです。
システムテスト | 受け入れ試験 | |
---|---|---|
1 | システムテストは、システム全体のテストです。エンドツーエンドのテストを実行して、すべてのシナリオが期待どおりに機能していることを確認します。 | 製品が顧客の要件を満たしているかどうかを確認するために、受け入れテストが行われます。 |
二 | システムテストには、機能テストと非機能テストが含まれ、テスターによって実行されます。 | 受け入れテストは機能テストであり、テスターと顧客によって実行されます。 |
3 | テストは、テスターによって作成されたテストデータを使用して実行されます。 | 実動/生産データは、受け入れテストの実行中に使用されます。 |
4 | システム全体がテストされ、製品の機能とパフォーマンスがチェックされます。 | 受け入れテストは、ビジネス要件を検証するために行われます。つまり、顧客が探している目的を解決します。 |
5 | テストで見つかった欠陥を修正できます。 | 検収試験中に発見された欠陥は、製品の故障とみなされます。 |
6 | システムおよびシステム統合テストは、システムテストのタイプです。 | アルファテストとベータテストは、受け入れテストの対象となります。 |
システムテストを実行するためのヒント
- システムは訓練を受けたテスターではなくエンドユーザーによって使用されるため、理想的なテストを行うのではなく、リアルタイムのシナリオを複製します。
- 人間は待ったり、間違ったデータを見たりしたくないので、さまざまな用語でシステムの応答を確認します。
- エンドユーザーが行うことになるため、ドキュメントに従ってシステムをインストールして構成します。
- ビジネスアナリスト、開発者、テスター、顧客など、さまざまな分野の人々を巻き込んで、より良いシステムを送ることができます。
- 定期的なテストは、バグを修正するためのコードのわずかな変更がシステムに別の重大なバグを挿入していないことを確認する唯一の方法です。
結論
システムテストは非常に重要であり、適切に行われなかった場合、ライブ環境で重大な問題に直面する可能性があります。
システム全体として、検証すべきさまざまな特性があります。簡単な例は、任意のWebサイトです。全体としてテストされていない場合、ユーザーはそのサイトが非常に遅いと感じるか、多数のユーザーが同時にログインするとサイトがクラッシュする可能性があります。
そして、これらの特性は、Webサイト全体がテストされるまでテストできません。
このチュートリアルがシステムテストの概念を理解するのに非常に役立つことを願っています。
推奨読書
- ソフトウェアテストの種類:詳細を含むさまざまなテストの種類
- アルファテストとベータテスト(完全ガイド)
- システム統合テスト(SIT)とは:例を使って学ぶ
- 機能テストと非機能テスト
- 継続的インテグレーションプロセス:ソフトウェアの品質を向上させ、リスクを軽減する方法
- 統合テストを作成するための統合テストツールトップ10
- 統合テストとは(統合テストの例を含むチュートリアル)
- ソフトウェアテストにおける耐久性テストとは(例)