ソフトウェアテスト-クイックガイド

テストとは何ですか？

テストは、指定された要件を満たしているかどうかを確認する目的で、システムまたはそのコンポーネントを評価するプロセスです。簡単に言うと、テストとは、実際の要件とは逆に、ギャップ、エラー、または不足している要件を特定するためにシステムを実行することです。

ANSI / IEEE 1059規格によれば、テストは次のように定義できます。ソフトウェアアイテムを分析して、既存の条件と必要な条件（つまり、欠陥/エラー/バグ）の違いを検出し、ソフトウェアアイテムの機能を評価するプロセス。

誰がテストしますか？

それは、プロセスとプロジェクトの関連する利害関係者によって異なります。IT業界では、大企業には、特定の要件に照らして開発されたソフトウェアを評価する責任を持つチームがあります。さらに、開発者は、と呼ばれるテストも実施しますUnit Testing。ほとんどの場合、次の専門家がそれぞれの能力の範囲内でシステムのテストに関与しています。

ソフトウェアテスター
ソフトウェア開発者
プロジェクトリーダー/マネージャー
エンドユーザー

ソフトウェアテスター、ソフトウェア品質保証エンジニア、QAアナリストなど、経験と知識に基づいてソフトウェアをテストする人の指定は、会社によって異なります。

サイクル中はいつでもソフトウェアをテストすることはできません。次の2つのセクションでは、SDLC中にテストを開始するタイミングと終了するタイミングについて説明します。

いつテストを開始しますか？

テストを早期に開始することで、クライアントに提供されるエラーのないソフトウェアを作り直して作成するためのコストと時間を削減できます。ただし、ソフトウェア開発ライフサイクル（SDLC）では、テストは要件収集フェーズから開始し、ソフトウェアの展開まで継続できます。

また、使用されている開発モデルによっても異なります。たとえば、ウォーターフォールモデルでは、正式なテストはテストフェーズで実行されます。ただし、インクリメンタルモデルでは、すべてのインクリメンタル/反復の最後にテストが実行され、アプリケーション全体が最後にテストされます。

テストは、SDLCのすべてのフェーズでさまざまな形式で行われます-

要件収集フェーズでは、要件の分析と検証もテストと見なされます。
設計を改善する目的で設計段階で設計をレビューすることも、テストと見なされます。
コードの完了時に開発者が実行するテストも、テストとして分類されます。

テストをいつ停止するか？

テストは終わりのないプロセスであり、ソフトウェアが100％テストされているとは誰も主張できないため、テストをいつ停止するかを決定することは困難です。テストプロセスを停止するには、次の側面を考慮する必要があります。

締め切りのテスト
テストケース実行の完了
ある時点までの機能およびコードカバレッジの完了
バグ率が一定レベルを下回り、優先度の高いバグが特定されていない
経営判断

検証と妥当性確認

これらの2つの用語は、同じ意味で使用するほとんどの人にとって非常に混乱します。次の表は、検証と妥当性確認の違いを示しています。

シニア番号	検証	検証
1	検証は懸念に対処します：「あなたはそれを正しく構築していますか？」	検証は懸念に対処します：「あなたは正しいものを構築していますか？」
2	ソフトウェアシステムがすべての機能を満たしていることを確認します。	機能が意図した動作を満たしていることを確認します。
3	検証は最初に行われ、ドキュメント、コードなどのチェックが含まれます。	検証は検証後に行われ、主に製品全体のチェックが含まれます。
4	開発者によって行われます。	テスターによって行われます。
5	ソフトウェアを検証するためのレビュー、ウォークスルー、および検査の収集が含まれるため、静的なアクティビティがあります。	要件に照らしてソフトウェアを実行することを含むため、動的なアクティビティがあります。
6	これは客観的なプロセスであり、ソフトウェアを検証するために主観的な決定を行う必要はありません。	これは主観的なプロセスであり、ソフトウェアがどの程度うまく機能するかについての主観的な決定が含まれます。

以下に示すのは、ソフトウェアテストに関する最も一般的な神話の一部です。

神話1：テストは高すぎる

Reality−ソフトウェア開発中のテストに支払う金額を少なくするか、後でメンテナンスや修正に支払う金額を増やすということわざがあります。初期のテストは多くの面で時間とコストの両方を節約しますが、テストせずにコストを削減すると、ソフトウェアアプリケーションの設計が不適切になり、製品が役に立たなくなる可能性があります。

神話2：テストは時間がかかる

Reality− SDLCフェーズ中、テストは決して時間のかかるプロセスではありません。ただし、適切なテスト中に特定されたエラーの診断と修正は、時間はかかりますが生産的な作業です。

神話3：完全に開発された製品のみがテストされる

Reality−間違いなく、テストはソースコードに依存しますが、要件の確認とテストケースの開発は、開発されたコードから独立しています。ただし、開発ライフサイクルモデルとしての反復的または段階的なアプローチにより、完全に開発されたソフトウェアへのテストの依存度を減らすことができます。

神話4：完全なテストが可能

Reality−クライアントまたはテスターが完全なテストが可能であると考える場合に問題になります。すべてのパスがチームによってテストされている可能性がありますが、完全なテストを実行することは不可能です。ソフトウェア開発ライフサイクル中にテストチームまたはクライアントによって実行されることはなく、プロジェクトが展開されると実行される可能性があるシナリオがいくつかある可能性があります。

神話5：テスト済みのソフトウェアにはバグがない

Reality −これは、クライアント、プロジェクトマネージャー、および管理チームが信じている非常に一般的な神話です。優れたテストスキルを持つテスターがアプリケーションをテストしたとしても、ソフトウェアアプリケーションに100％バグがないと断言することはできません。。

神話6：見逃された欠陥はテスターによるもの

Reality−テストが実行された後でもアプリケーションに残っているバグについてテスターを非難するのは正しいアプローチではありません。この神話は、時間、コスト、および要件の変更の制約に関連しています。ただし、テスト戦略により、テストチームがバグを見逃してしまう可能性もあります。

神話7：テスターは製品の品質に責任があります

Reality−テスターまたはテストチームのみが製品の品質に責任を持つべきであるというのは、非常に一般的な誤解です。テスターの責任には、利害関係者に対するバグの特定が含まれ、バグを修正するかソフトウェアをリリースするかはテスターの決定です。その時点でソフトウェアをリリースすると、テスターはエラーのせいにされるため、テスターにさらにプレッシャーがかかります。

神話8：時間を短縮するために、可能な限りテスト自動化を使用する必要があります

Reality−はい、確かにテスト自動化によってテスト時間が短縮されますが、ソフトウェア開発中はいつでもテスト自動化を開始することはできません。テストオートマトンは、ソフトウェアが手動でテストされ、ある程度安定しているときに開始する必要があります。さらに、要件が変化し続ける場合、テスト自動化を使用することはできません。

神話9：誰でもソフトウェアアプリケーションをテストできる

Reality− IT業界以外の人々は、誰でもソフトウェアをテストでき、テストは創造的な仕事ではないと考え、信じています。しかし、テスターはこれが神話であることをよく知っています。別のシナリオを考えて、潜在的なバグを調査する目的でソフトウェアをクラッシュさせようとすることは、それを開発した人には不可能です。

神話10：テスターの唯一のタスクはバグを見つけることです

Reality−ソフトウェアのバグを見つけることはテスターの仕事ですが、同時に、彼らは特定のソフトウェアのドメインエキスパートです。開発者は、割り当てられた特定のコンポーネントまたは領域に対してのみ責任を負いますが、テスターは、ソフトウェアの全体的な動作、依存関係、およびあるモジュールが別のモジュールに与える影響を理解しています。

テスト、品質保証、および品質管理

ほとんどの人は、品質保証、品質管理、およびテストの違いを特定することになると混乱します。それらは相互に関連しており、ある程度は同じ活動と見なすことができますが、それらを区別する際立った点が存在します。次の表に、QA、QC、およびテストを区別するポイントを示します。

品質保証	品質管理	テスト
QAには、開発されたソフトウェアと意図された要件の検証に関連して、プロセス、手順、および標準の実装を保証するアクティビティが含まれます。	これには、文書化された（場合によってはそうではない）要件に関して、開発されたソフトウェアの検証を確実にするアクティビティが含まれます。	これには、ソフトウェアのバグ/エラー/欠陥を確実に特定するためのアクティビティが含まれます。
システムで実際のテストを実施するのではなく、プロセスと手順に焦点を合わせます。	手順とプロセスの実装を通じてバグ/欠陥を特定することを目的として、ソフトウェアを実行することにより、実際のテストに焦点を当てます。	実際のテストに焦点を当てています。
プロセス指向の活動。	製品志向の活動。	製品志向の活動。
予防活動。	これは修正プロセスです。	それは予防的なプロセスです。
これは、ソフトウェアテストライフサイクル（STLC）のサブセットです。	QCは、品質保証のサブセットと見なすことができます。	テストは品質管理のサブセットです。

監査と検査

Audit−組織またはチーム内で実際のテストプロセスがどのように実行されるかを決定するのは体系的なプロセスです。一般に、これはソフトウェアのテスト中に含まれるプロセスの独立した検査です。IEEEによると、これは組織が実装および従う文書化されたプロセスのレビューです。監査の種類には、法令遵守監査、内部監査、およびシステム監査が含まれます。

Inspection−これは、エラーやギャップを特定することにより、アーティファクトの公式または非公式の技術レビューを含む正式な手法です。IEEE94によると、検査は、ソフトウェア要件、設計、またはコードを作成者以外の個人またはグループが詳細に検査して、障害、開発標準の違反、およびその他の問題を検出する正式な評価手法です。

正式な検査会議には、計画、概要の準備、検査会議、やり直し、およびフォローアップのプロセスが含まれる場合があります。

テストとデバッグ

Testing−ソフトウェアのバグ/エラー/欠陥を修正せずに特定する必要があります。通常、品質保証のバックグラウンドを持つ専門家がバグの特定に関与します。テストは、テストフェーズで実行されます。

Debugging−問題/バグの特定、切り分け、修正が含まれます。ソフトウェアをコーディングする開発者は、コードでエラーが発生するとデバッグを実行します。デバッグは、ホワイトボックステストまたは単体テストの一部です。デバッグは、単体テストの実行中の開発フェーズ、または報告されたバグの修正中のフェーズで実行できます。

世界中の多くの組織が、ソフトウェアの品質ニーズを改善するためにさまざまな標準を開発および実装しています。この章では、品質保証とテストに関連して広く使用されている標準のいくつかについて簡単に説明します。

ISO / IEC 9126

この規格は、ソフトウェアアプリケーションの品質を決定するために次の側面を扱います-

品質モデル
外部メトリック
内部メトリック
使用品質の指標

この規格は、次のようなソフトウェアの品質属性のセットを提示します。

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

上記の品質属性はさらにサブファクターに分けられ、標準を詳細に研究するときに研究することができます。

ISO / IEC 9241-11

この規格のパート11は、特定のユーザーが製品を使用して、特定の使用状況で有効性、効率性、満足度を備えた特定の目標を達成できる範囲を扱っています。

この規格は、ユーザビリティコンポーネントとそれらの間の関係を説明するフレームワークを提案しました。この規格では、ユーザビリティはユーザーのパフォーマンスと満足度の観点から考慮されています。ISO 9241-11によると、ユーザビリティは使用状況に依存し、状況の変化に応じてユーザビリティのレベルが変化します。

ISO / IEC 25000：2005

ISO / IEC 25000：2005は、ソフトウェア品質要件と評価（SQuaRE）のガイドラインを提供する標準として一般に知られています。この標準は、ソフトウェアの品質要件とその評価に関連するプロセスを整理および強化するのに役立ちます。実際には、ISO-25000は2つの古いISO規格、つまりISO-9126とISO-14598に取って代わります。

SQuaRE −などのサブパートに分かれています

ISO2500n-品質管理部門
ISO2501n-品質モデル部門
ISO2502n-品質測定部門
ISO2503n-品質要件部門
ISO2504n-品質評価部門

SQuaREの主な内容は−

用語と定義
参照モデル
一般ガイド
個別部門ガイド
要件エンジニアリングに関連する標準（つまり、仕様、計画、測定、および評価プロセス）

ISO / IEC 12119

この規格は、クライアントに配信されるソフトウェアパッケージを扱います。クライアントの生産プロセスに焦点を当てたり、扱ったりすることはありません。主な内容は以下の項目に関連しています-

ソフトウェアパッケージの要件のセット。
提供されたソフトウェアパッケージを指定された要件に対してテストするための手順。

その他

QAおよびテストプロセスに関連する他の標準のいくつかを以下に示します-

シニア番号	標準と説明
1	IEEE 829 ソフトウェアテストのさまざまな段階で使用されるドキュメントの形式の標準。
2	IEEE 1061 品質要件を確立し、プロセスを識別、実装、分析、および検証するための方法論、およびソフトウェア品質メトリックの製品。
3	IEEE 1059 ソフトウェア検証および妥当性確認計画のガイド。
4	IEEE 1008 ユニットテストの標準。
5	IEEE 1012 ソフトウェアの検証と妥当性確認の標準。
6	IEEE 1028 ソフトウェアインスペクションの標準。
7	IEEE 1044 ソフトウェアの異常を分類するための標準。
8	IEEE 1044-1 ソフトウェアの異常を分類するためのガイド。
9	IEEE 830 システム要件仕様を開発するためのガイド。
10	IEEE 730 ソフトウェア品質保証計画の標準。
11	IEEE 1061 ソフトウェア品質の測定基準と方法論の標準。
12	IEEE 12207 ソフトウェアライフサイクルプロセスとライフサイクルデータの標準。
13	BS 7925-1 ソフトウェアテストで使用される用語の語彙。
14	BS 7925-2 ソフトウェアコンポーネントテストの標準。

このセクションでは、SDLC中にソフトウェアをテストするために使用できるさまざまなタイプのテストについて説明します。

手動テスト

手動テストには、自動化されたツールやスクリプトを使用せずに、ソフトウェアを手動でテストすることが含まれます。このタイプでは、テスターがエンドユーザーの役割を引き継ぎ、ソフトウェアをテストして予期しない動作やバグを特定します。手動テストには、単体テスト、統合テスト、システムテスト、ユーザー受け入れテストなど、さまざまな段階があります。

テスターは、テスト計画、テストケース、またはテストシナリオを使用してソフトウェアをテストし、テストの完全性を確認します。テスターがソフトウェアを探索してソフトウェアのエラーを特定するため、手動テストには探索的テストも含まれます。

自動化テスト

自動化テストは、テスト自動化とも呼ばれ、テスターがスクリプトを作成し、別のソフトウェアを使用して製品をテストする場合です。このプロセスには、手動プロセスの自動化が含まれます。自動化テストは、手動、迅速、および繰り返し実行されたテストシナリオを再実行するために使用されます。

回帰テストとは別に、自動化テストは、負荷、パフォーマンス、およびストレスの観点からアプリケーションをテストするためにも使用されます。手動テストと比較して、テストカバレッジが向上し、精度が向上し、時間と費用が節約されます。

何を自動化するのですか？

ソフトウェアですべてを自動化することは不可能です。ログインフォームや登録フォームなど、ユーザーがトランザクションを実行できる領域、多数のユーザーが同時にソフトウェアにアクセスできる領域は自動化する必要があります。

さらに、手動プロセスを自動化することにより、すべてのGUIアイテム、データベースとの接続、フィールド検証などを効率的にテストできます。

いつ自動化するのですか？

テスト自動化は、ソフトウェアの次の側面を考慮して使用する必要があります-

大規模で重要なプロジェクト
同じ領域を頻繁にテストする必要があるプロジェクト
要件は頻繁に変更されない
多くの仮想ユーザーによる負荷とパフォーマンスのためのアプリケーションへのアクセス
手動テストに関する安定したソフトウェア
時間の可用性

自動化する方法は？

自動化は、VBスクリプトや自動化されたソフトウェアアプリケーションなどのサポートするコンピューター言語を使用して行われます。自動化スクリプトの作成に使用できるツールは多数あります。ツールについて言及する前に、テストプロセスを自動化するために使用できるプロセスを特定しましょう-

自動化のためのソフトウェア内の領域の特定
テスト自動化のための適切なツールの選択
テストスクリプトの作成
テストスーツの開発
スクリプトの実行
結果レポートを作成する
潜在的なバグまたはパフォーマンスの問題を特定します

ソフトウェアテストツール

次のツールは、自動化テストに使用できます-

HPクイックテストプロフェッショナル
Selenium
IBM Rational Functional Tester
SilkTest
TestComplete
どこでもテスト
WinRunner
LoadRunner
Visual Studio Test Professional
WATIR

ソフトウェアテストに使用できるさまざまな方法があります。この章では、使用可能な方法について簡単に説明します。

ブラックボックステスト

アプリケーションの内部動作に関する知識がなくてもテストする手法は、ブラックボックステストと呼ばれます。テスターはシステムアーキテクチャに気づかず、ソースコードにアクセスできません。通常、ブラックボックステストの実行中、テスターは、入力が処理される方法と場所を知らなくても、入力を提供し、出力を調べることによって、システムのユーザーインターフェイスと対話します。

次の表に、ブラックボックステストの長所と短所を示します。

利点	短所
大きなコードセグメントに最適で効率的です。	選択された数のテストシナリオのみが実際に実行されるため、カバレッジが制限されます。
コードアクセスは必要ありません。	テスターがアプリケーションについての知識が限られているため、非効率的なテスト。
視覚的に定義された役割を通じて、ユーザーの視点と開発者の視点を明確に分離します。	テスターは特定のコードセグメントやエラーが発生しやすい領域をターゲットにできないため、ブラインドカバレッジ。
中程度のスキルを持つ多数のテスターは、実装、プログラミング言語、またはオペレーティングシステムの知識がなくてもアプリケーションをテストできます。	テストケースの設計は困難です。

ホワイトボックステスト

ホワイトボックステストは、コードの内部ロジックと構造の詳細な調査です。ホワイトボックステストは、glass testing または open-box testing。実行するためにwhite-box アプリケーションでテストする場合、テスターはコードの内部動作を知る必要があります。

テスターは、ソースコードの内部を調べて、コードのどのユニット/チャンクが不適切に動作しているかを確認する必要があります。

次の表に、ホワイトボックステストの長所と短所を示します。

利点	短所
テスターはソースコードの知識を持っているので、どのタイプのデータがアプリケーションを効果的にテストするのに役立つかを見つけるのは非常に簡単になります。	ホワイトボックステストを実行するには熟練したテスターが必要であるため、コストが増加します。
コードの最適化に役立ちます。	多くのパスがテストされていないため、問題を引き起こす可能性のある隠れたエラーを見つけるために隅々まで調べることが不可能な場合があります。
隠れた欠陥をもたらす可能性のある余分なコード行を削除できます。	ホワイトボックステストは、コードアナライザーやデバッグツールなどの特殊なツールを必要とするため、維持するのは困難です。
コードに関するテスターの知識により、テストシナリオの作成中に最大のカバレッジが達成されます。

グレーボックステスト

グレーボックステストは、アプリケーションの内部動作に関する知識が限られている状態でアプリケーションをテストする手法です。ソフトウェアテストでは、このフレーズをよく知っているほど、アプリケーションのテスト中に大きな重みを持ちます。

システムのドメインをマスターすることで、テスターは常にドメイン知識が限られている人よりも優位に立つことができます。テスターがアプリケーションのユーザーインターフェイスのみをテストするブラックボックステストとは異なります。グレーボックステストでは、テスターは設計ドキュメントとデータベースにアクセスできます。この知識があれば、テスターはテスト計画を立てながら、より良いテストデータとテストシナリオを準備できます。

利点	短所
可能な限り、ブラックボックステストとホワイトボックステストを組み合わせた利点を提供します。	ソースコードへのアクセスが利用できないため、コードを調べてカバレッジをテストする機能は制限されています。
グレーボックステスターはソースコードに依存しません。代わりに、インターフェイスの定義と機能仕様に依存しています。	ソフトウェア設計者がすでにテストケースを実行している場合、テストは冗長になる可能性があります。
利用可能な限られた情報に基づいて、グレーボックステスターは、特に通信プロトコルとデータ型処理に関する優れたテストシナリオを設計できます。	考えられるすべての入力ストリームをテストすることは、不当な時間がかかるため、非現実的です。したがって、多くのプログラムパスはテストされません。
テストは、設計者ではなくユーザーの観点から行われます。

試験方法の比較

次の表に、ブラックボックステスト、グレーボックステスト、およびホワイトボックステストを区別するポイントを示します。

ブラックボックステスト	グレーボックステスト	ホワイトボックステスト
アプリケーションの内部動作を知る必要はありません。	テスターは、アプリケーションの内部動作に関する知識が限られています。	テスターは、アプリケーションの内部動作について完全な知識を持っています。
クローズドボックステスト、データ駆動型テスト、または機能テストとも呼ばれます。	テスターはアプリケーションの内部に関する知識が限られているため、半透明テストとも呼ばれます。	クリアボックステスト、構造テスト、またはコードベースのテストとも呼ばれます。
エンドユーザーだけでなく、テスターや開発者によっても実行されます。	エンドユーザーだけでなく、テスターや開発者によっても実行されます。	通常、テスターと開発者によって行われます。
テストは外部の期待に基づいています-アプリケーションの内部動作は不明です。	テストは、高レベルのデータベース図とデータフロー図に基づいて行われます。	内部の仕組みは完全にわかっており、テスターはそれに応じてテストデータを設計できます。
それは網羅的で、最も時間のかからないものです。	部分的に時間がかかり、網羅的です。	最も徹底的で時間のかかるタイプのテスト。
アルゴリズムのテストには適していません。	アルゴリズムのテストには適していません。	アルゴリズムテストに適しています。
これは試行錯誤の方法でのみ行うことができます。	わかっている場合は、データドメインと内部境界をテストできます。	データドメインと内部境界をより適切にテストできます。

テストの過程でさまざまなレベルがあります。この章では、これらのレベルについて簡単に説明します。

テストのレベルには、ソフトウェアテストの実施中に使用できるさまざまな方法論が含まれます。ソフトウェアテストの主なレベルは次のとおりです。

機能テスト
非機能テスト

機能テスト

これは、テスト対象のソフトウェアの仕様に基づくブラックボックステストの一種です。アプリケーションは入力を提供することによってテストされ、次に、意図された機能に準拠する必要がある結果が調べられます。ソフトウェアの機能テストは、システムが指定された要件に準拠しているかどうかを評価するために、完全な統合システムで実行されます。

アプリケーションの機能をテストする際に必要な5つのステップがあります。

ステップ	説明
私	目的のアプリケーションが実行することを意図している機能の決定。
II	アプリケーションの仕様に基づいたテストデータの作成。
III	テストデータとアプリケーションの仕様に基づく出力。
IV	テストシナリオの作成とテストケースの実行。
V	実行されたテストケースに基づく実際の結果と期待される結果の比較。

効果的なテスト手法では、上記の手順がすべての組織のテストポリシーに適用されるため、ソフトウェアの品質に関して組織が最も厳しい基準を維持することが保証されます。

ユニットテスト

このタイプのテストは、セットアップがテストチームに渡されてテストケースが正式に実行される前に、開発者によって実行されます。ユニットテストは、ソースコードが割り当てられた領域の個々のユニットに対してそれぞれの開発者によって実行されます。開発者は、品質保証チームのテストデータとは異なるテストデータを使用します。

単体テストの目標は、プログラムの各部分を分離し、個々の部分が要件と機能の点で正しいことを示すことです。

ユニットテストの制限

テストでは、アプリケーションのすべてのバグを検出することはできません。すべてのソフトウェアアプリケーションのすべての実行パスを評価することは不可能です。ユニットテストの場合も同じです。

開発者がソースコードを検証するために使用できるシナリオとテストデータの数には制限があります。すべてのオプションを使い果たした後、ユニットテストを停止し、コードセグメントを他のユニットとマージする以外に選択肢はありません。

統合テスト

統合テストは、アプリケーションの結合された部分をテストして、それらが正しく機能するかどうかを判断することとして定義されます。統合テストは、ボトムアップ統合テストとトップダウン統合テストの2つの方法で実行できます。

シニア番号	統合テスト方法
1	Bottom-up integration このテストは、ユニットテストから始まり、モジュールまたはビルドと呼ばれるユニットの段階的に高いレベルの組み合わせのテストが続きます。
2	Top-down integration このテストでは、最高レベルのモジュールが最初にテストされ、その後、下位レベルのモジュールがテストされます。

包括的なソフトウェア開発環境では、通常、ボトムアップテストが最初に実行され、次にトップダウンテストが実行されます。プロセスは、できれば実際の状況を模倣するように設計されたシナリオで、アプリケーション全体の複数のテストで終了します。

システムテスト

システムテストは、システム全体をテストします。すべてのコンポーネントが統合されると、アプリケーション全体が厳密にテストされ、指定された品質基準を満たしていることを確認します。このタイプのテストは、専門のテストチームによって実行されます。

システムテストは、次の理由から重要です。

システムテストは、ソフトウェア開発ライフサイクルの最初のステップであり、アプリケーション全体がテストされます。
アプリケーションは徹底的にテストされ、機能および技術仕様を満たしていることを確認します。
アプリケーションは、アプリケーションがデプロイされる実稼働環境に非常に近い環境でテストされます。
システムテストにより、ビジネス要件とアプリケーションアーキテクチャの両方をテスト、検証、および検証できます。

回帰試験

ソフトウェアアプリケーションに変更が加えられるたびに、アプリケーション内の他の領域がこの変更の影響を受ける可能性があります。リグレッションテストは、修正されたバグが別の機能やビジネスルール違反を引き起こしていないことを確認するために実行されます。リグレッションテストの目的は、バグ修正などの変更によって、アプリケーションで別の障害が発見されないようにすることです。

次の理由により、回帰テストは重要です。

変更を加えたアプリケーションをテストする必要がある場合は、テストのギャップを最小限に抑えます。
新しい変更をテストして、加えられた変更がアプリケーションの他の領域に影響を与えていないことを確認します。
アプリケーションで回帰テストを実行する際のリスクを軽減します。
タイムラインを損なうことなく、テストカバレッジが拡大されます。
製品を販売するためのスピードを上げます。

受け入れ試験

これは、アプリケーションが意図した仕様を満たし、クライアントの要件を満たしているかどうかを判断する品質保証チームによって実施されるため、間違いなく最も重要なタイプのテストです。QAチームには、アプリケーションのテストに使用される一連の事前に作成されたシナリオとテストケースがあります。

アプリケーションについてより多くのアイデアが共有され、アプリケーションの精度とプロジェクトが開始された理由を評価するために、より多くのテストを実行できます。受け入れテストは、単純なスペルミス、外観上のエラー、またはインターフェイスのギャップを指摘するだけでなく、システムのクラッシュやアプリケーションの重大なエラーを引き起こすアプリケーションのバグを指摘することも目的としています。

アプリケーションで受け入れテストを実行することにより、テストチームはアプリケーションが本番環境でどのように実行されるかを削減します。システムを受け入れるための法的および契約上の要件もあります。

アルファテスト

このテストはテストの最初の段階であり、チーム（開発者チームとQAチーム）間で実行されます。ユニットテスト、統合テスト、およびシステムテストを組み合わせた場合、アルファテストと呼ばれます。このフェーズでは、次の側面がアプリケーションでテストされます。

スペルミス
壊れたリンク
曇りの方向
アプリケーションは、ロード時間と遅延の問題をテストするために、最も低い仕様のマシンでテストされます。

ベータテスト

このテストは、アルファテストが正常に実行された後に実行されます。ベータテストでは、対象読者のサンプルがアプリケーションをテストします。ベータテストは、pre-release testing。ソフトウェアのベータテストバージョンは、プログラムに「実際の」テストを提供し、次のリリースのプレビューを提供するために、Web上の幅広い対象者に理想的に配布されます。このフェーズでは、聴衆は以下をテストします-

ユーザーはアプリケーションをインストールして実行し、プロジェクトチームにフィードバックを送信します。
誤植、混乱するアプリケーションフロー、さらにはクラッシュ。
プロジェクトチームはフィードバックを取得して、実際のユーザーにソフトウェアをリリースする前に問題を修正できます。
実際のユーザーの問題を解決するために修正する問題が多いほど、アプリケーションの品質は高くなります。
一般に公開するときに高品質のアプリケーションを使用すると、顧客満足度が向上します。

非機能テスト

このセクションは、非機能属性からのアプリケーションのテストに基づいています。非機能テストには、本質的に非機能であるが、パフォーマンス、セキュリティ、ユーザーインターフェイスなどの重要な要件からソフトウェアをテストすることが含まれます。

重要で一般的に使用される非機能テストタイプのいくつかを以下で説明します。

性能試験

これは主に、ソフトウェアのバグを見つけるのではなく、ボトルネックやパフォーマンスの問題を特定するために使用されます。ソフトウェアのパフォーマンス低下に寄与するさまざまな原因があります-

ネットワーク遅延
クライアント側の処理
データベーストランザクション処理
サーバー間の負荷分散
データレンダリング

パフォーマンステストは、次の点で重要かつ必須のテストタイプの1つと見なされています。

速度（つまり、応答時間、データのレンダリングとアクセス）
Capacity
Stability
Scalability

パフォーマンステストは、定性的または定量的のいずれかであり、次のようなさまざまなサブタイプに分けることができます。 Load testing そして Stress testing。

負荷テスト

これは、ソフトウェアが大きな入力データにアクセスして操作するという点で最大の負荷をかけることにより、ソフトウェアの動作をテストするプロセスです。これは、通常の負荷条件とピーク負荷条件の両方で実行できます。このタイプのテストでは、ソフトウェアの最大容量とピーク時の動作を特定します。

ほとんどの場合、負荷テストは、Load Runner、AppLoader、IBM Rational Performance Tester、Apache JMeter、Silk Performer、Visual Studio LoadTestなどの自動ツールを使用して実行されます。

仮想ユーザー（VUsers）は自動テストツールで定義され、スクリプトが実行されてソフトウェアの負荷テストが検証されます。ユーザー数は、要件に基づいて、同時にまたは段階的に増減できます。

ストレステスト

ストレステストには、異常な条件下でのソフトウェアの動作のテストが含まれます。たとえば、一部のリソースを削除したり、実際の負荷制限を超える負荷を適用したりすることが含まれる場合があります。

ストレステストの目的は、システムに負荷をかけ、ソフトウェアが使用するリソースを引き継いでブレークポイントを特定することにより、ソフトウェアをテストすることです。このテストは、次のようなさまざまなシナリオをテストすることで実行できます。

ネットワークポートのランダムなシャットダウンまたは再起動
データベースをオンまたはオフにする
CPU、メモリ、サーバーなどのリソースを消費するさまざまなプロセスを実行します。

ユーザビリティテスト

ユーザビリティテストはブラックボックス手法であり、ユーザーの使用状況と操作を観察することにより、ソフトウェアのエラーや改善点を特定するために使用されます。

Nielsenによると、ユーザビリティは、使用効率、学習能力、記憶能力、エラー/安全性、満足度の5つの要素で定義できます。彼によると、製品の使いやすさは良好であり、システムは上記の要素を備えていれば使用可能です。

Nigel BevanとMacleodは、ユーザビリティはコンピュータシステムとの相互作用の結果として測定できる品質要件であると考えました。適切なリソースを使用して目的の目標を効果的に達成すれば、この要件を満たすことができ、エンドユーザーは満たされます。

2000年のMolichは、ユーザーフレンドリーなシステムは、次の5つの目標、つまり、習得しやすく、覚えやすく、効率的に使用でき、満足のいくものであり、理解しやすいものでなければならないと述べました。

ユーザビリティのさまざまな定義に加えて、ISO-9126、ISO-9241-11、ISO-13407、IEEE stdなどの属性とサブ属性の形式でユーザビリティを定義する、いくつかの標準と品質のモデルと方法があります。 610.12など

UIとユーザビリティテスト

UIテストには、ソフトウェアのグラフィカルユーザーインターフェイスのテストが含まれます。UIテストは、GUIが要件に従って機能し、色、配置、サイズ、およびその他のプロパティに関してテストされていることを確認します。

一方、ユーザビリティテストでは、簡単に処理できる優れたユーザーフレンドリーなGUIが保証されます。UIテストは、ユーザビリティテストのサブパートと見なすことができます。

セキュリティテスト

セキュリティテストでは、セキュリティと脆弱性の観点から欠陥やギャップを特定するためにソフトウェアをテストします。以下にリストされているのは、セキュリティテストで確認する必要がある主な側面です。

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
ソフトウェアは既知および未知の脆弱性に対して安全です
ソフトウェアデータは安全です
ソフトウェアはすべてのセキュリティ規制に準拠しています
入力のチェックと検証
SQL挿入攻撃
注入の欠陥
セッション管理の問題
クロスサイトスクリプティング攻撃
バッファオーバーフローの脆弱性
ディレクトリトラバーサル攻撃

移植性テスト

移植性テストには、再利用性を確認し、別のソフトウェアから移動できることを目的としたソフトウェアのテストが含まれます。以下は、移植性テストに使用できる戦略です。

インストールされたソフトウェアをあるコンピューターから別のコンピューターに転送する。
さまざまなプラットフォームでソフトウェアを実行するための実行可能ファイル（.exe）をビルドします。

移植性テストは、システムテストのサブパートの1つと見なすことができます。このテストタイプには、さまざまな環境での使用に関するソフトウェアの全体的なテストが含まれるためです。コンピュータハードウェア、オペレーティングシステム、およびブラウザは、移植性テストの主な焦点です。移植性テストの前提条件のいくつかは次のとおりです。

ソフトウェアは、移植性の要件を念頭に置いて設計およびコーディングする必要があります。
ユニットテストは、関連するコンポーネントで実行されました。
統合テストが実行されました。
テスト環境が確立されました。

テストドキュメントには、ソフトウェアのテスト前またはテスト中に開発する必要のあるアーティファクトのドキュメントが含まれます。

ソフトウェアテストのドキュメントは、必要なテスト作業、テストカバレッジ、要件の追跡/トレースなどを見積もるのに役立ちます。このセクションでは、ソフトウェアテストに関連して一般的に使用されるドキュメント化されたアーティファクトのいくつかについて説明します。

テスト計画
テストシナリオ
テストケース
トレーサビリティマトリックス

テスト計画

テスト計画は、アプリケーションのテストに使用される戦略、使用されるリソース、テストが実行されるテスト環境、およびテストの制限とテストアクティビティのスケジュールの概要を示します。通常、品質保証チームリーダーは、テスト計画の作成を担当します。

テスト計画には次のものが含まれます-

テスト計画ドキュメントの概要
アプリケーションのテスト中の前提条件
アプリケーションのテストに含まれるテストケースのリスト
テストする機能のリスト
ソフトウェアのテスト中にどのようなアプローチを使用するか
テストが必要な成果物のリスト
アプリケーションのテストに割り当てられたリソース
テストプロセス中に伴うリスク
達成すべきタスクとマイルストーンのスケジュール

テストシナリオ

これは、アプリケーションのどの領域がテストされるかを通知する1行のステートメントです。テストシナリオは、すべてのプロセスフローがエンドツーエンドでテストされていることを確認するために使用されます。アプリケーションの特定の領域には、アプリケーションの規模と複雑さに応じて、わずか1つのテストシナリオから数百のシナリオが含まれる場合があります。

「テストシナリオ」と「テストケース」という用語は同じ意味で使用されますが、テストシナリオにはいくつかのステップがありますが、テストケースには1つのステップがあります。この観点から見ると、テストシナリオはテストケースですが、いくつかのテストケースとそれらを実行する順序が含まれています。これとは別に、各テストは前のテストからの出力に依存しています。

テストケース

テストケースには、テストタスクの実行中に使用できる一連の手順、条件、および入力が含まれます。このアクティビティの主な目的は、ソフトウェアがその機能やその他の側面で合格か不合格かを確認することです。テストケースには、機能、ネガティブ、エラー、論理テストケース、物理テストケース、UIテストケースなど、さまざまな種類があります。

さらに、テストケースは、ソフトウェアのテスト範囲を追跡するために作成されています。通常、テストケースの作成中に使用できる正式なテンプレートはありません。ただし、次のコンポーネントは常に利用可能であり、すべてのテストケースに含まれています-

テストケースID
製品モジュール
製品バージョン
改訂履歴
Purpose
Assumptions
Pre-conditions
Steps
期待される結果
実際の結果
Post-conditions

多くのテストケースは、単一のテストシナリオから導き出すことができます。さらに、テストスイートと総称される単一のソフトウェアに対して複数のテストケースが作成される場合があります。

トレーサビリティマトリックス

トレーサビリティマトリックス（要件トレーサビリティマトリックス-RTMとも呼ばれます）は、ソフトウェア開発ライフサイクル中に要件をトレースするために使用されるテーブルです。フォワードトレース（つまり、要件から設計またはコーディングへ）またはバックワード（つまり、コーディングから要件へ）に使用できます。RTMには多くのユーザー定義テンプレートがあります。

RTMドキュメントの各要件は、関連するテストケースにリンクされているため、前述の要件に従ってテストを実行できます。さらに、バグIDも含まれており、関連する要件とテストケースにリンクされています。このマトリックスの主な目標は次のとおりです。