ソフトウェアテスト - テストの分類 (焦点: ブラックボックステスト、ホワイトボックステスト、単体テスト、統合テスト、システムテスト)

1. テスト対象に応じて分ける

1) インターフェーステスト

インターフェイスはユーザーと直接対話し、インターフェイス設計の品質によって、ソフトウェア使用時のユーザーの直感的なエクスペリエンスが決まります。

インターフェイステスト (UI テスト) には通常、次のものが含まれます。

UI デザインのドラフトを比較して、システム表示インターフェイスの一貫性と正確さを検証します。
インターフェイス上のすべての機能が正確であることを確認する
インターフェイスのレイアウトが適切かどうかを確認します。フォントサイズ、画像レイアウト、鮮明さなど。
インターフェイスコントロールが適切に機能していることを確認します。スクロールバー、ボタン、テキストボックスなど
さまざまな解像度でインターフェイスをテストする
- ページが大から小へ (または小から大へ) 遅延なくスムーズに変化することを確認します。
- ページ上のフォントがぼやけたり、ゴーストになったり、消えたりしていないことを確認します。
- ページ上の写真が消えず、レイアウトが適切であることを確認してください。
- ページの機能が正常に使用されていることを確認します

2) 信頼性試験

信頼性とは、システムの正常な動作の能力または程度を指し、通常はパーセンテージで表されます。

信頼性 = 稼働時間 / (稼働時間 + 異常な稼働時間)

ソフトウェアの信頼性に影響を与える要因:

ソフトウェア自体
電力、ネットワーク、ハードウェア機器などの外部要因

3) フォールトトレランステスト

フォールトトレランスとは、システム自体または外部の関係者による異常な動作による例外またはエラーをシステム自体で処理する能力を指します。

フォールトトレランステストには次の側面が含まれます。

ユーザーが異常なデータを入力した場合、システムはプロンプトを表示しますか、それともシステムが何らかの内部処理を行いますか?
ユーザーが複雑な操作やデータのセキュリティを危険にさらす可能性のある操作を実行する場合、プロンプトは表示されますか?
停電やネットワーク障害、あるいはハードウェア機器に問題が発生した場合、シームレスにバックアップサーバーに切り替えることができますか?
ディザスタリカバリテストでは、
人為的にサーバー障害を引き起こし、ソフトウェアシステムの環境回復能力、システムデータ回復能力、回復時間をテストします。

4) 書類審査

要件文書、設計文書、機能文書、ユーザーマニュアルなど、開発プロセス全体で生成されるさまざまな文書をテストして、文書の正確性、一貫性、完全性を検証します。

5) 互換性テスト

プラットフォームの互換性: さまざまなブラウザ、オペレーティングシステム、さまざまなブランドの携帯電話またはコンピュータとのシステムの互換性を確認します。
ソフトウェア自体の互換性: ソフトウェアの新しい機能と古い機能の互換性を検証し、新しく開発された機能が古い機能の使用に影響を与えることはありません。
ソフトウェアとユーザーデータの互換性: たとえば、データベース内のテーブルに新しいフィールドを追加しても、ユーザーの以前のデータの保存に影響を与えることはできません。
サードパーティソフトウェアとのソフトウェア互換性: 機能またはデータでサードパーティソフトウェアと対話する場合、サードパーティソフトウェアの使用に影響を与えることはできません。

6) ユーザビリティテスト

ユーザビリティテストとは、ユーザーがソフトウェアを使用する際に、柔軟で快適で使いやすいかどうかを検証することを指します。

ユーザビリティテストには通常、次の点が含まれます。

規格および仕様への準拠

今日のソフトウェアの UI デザイン標準は徐々に確立されており、ほとんどのユーザーはそのような標準や仕様に慣れています。例えば、ソフトウェアに重大なエラーが発生した場合の画像やフォントの色
直観性

インターフェイスのレイアウトは合理的であり、ソフトウェアの機能は操作が簡単で、明確で理解しやすいものである必要があります。
柔軟性

ユーザーは自分の習慣に合わせて自分に合った操作方法を選択できます

たとえば、携帯電話のキーボードは、9 マスのグリッド、フルキーボード、手書き入力、および 5 ストローク入力を切り替えることができます。
快適

ユーザーが不安を感じさせずに自分の操作感を感じられるようにする

ソフトウェアをインストールまたはダウンロードするときに、進行状況バーを追加します

7) ソフトウェアのインストールとアンインストールのテスト

主なテストポイントは次のとおりです。

通常、異なる方法を使用してソフトウェアのインストールとアンインストールを行うことはできますか?
インストールまたはアンインストール時に手動で一時停止またはキャンセルすることはできますか?
インストールスペースが不足している場合にプロンプトを表示するかどうか?
アンインストールの途中でアンインストールを中止した場合、ソフトウェアは正常に使用できますか?
アンインストールまたはインストール中の異常なテスト (ネットワーク切断、停電、クラッシュなど)
アンインストール完了後、ソフトウェアのデータファイル情報は消去されますか?

8) セキュリティテスト

セキュリティとは情報セキュリティを指します。これは、ネットワークとシステムがユーザーのデータとプライバシーを侵害や漏洩から保護することを意味します。

ウイルス対策、ハッカー対策、XSS インジェクション対策、SQL インジェクション対策、クローラー対策

9) 性能試験

ソフトウェアを使用しているときに、Web ページが開くのが遅くなったり、データのクエリ時にリストの表示に時間がかかったりすることがありますが、これらはすべてシステムのパフォーマンスの問題が原因です。

一般的なパフォーマンスの問題には次のようなものがあります。

リソース漏洩
リソースのボトルネック
スレッドのデッドロック、スレッドのブロッキング
クエリ速度が遅い、または非効率的である

システムのパフォーマンスを測定するための主要な指標には、ユーザー操作の応答時間、スループット、メモリおよび CPU 使用率が含まれます。

10) メモリリークテスト

メモリリークにより、ソフトウェアの動作がますます遅くなり、最終的には応答しなくなる可能性があります。

メモリリークの一般的な原因:

メモリが割り当てられた後はリサイクルされません
プログラムの記述方法に問題があるため、リサイクルできません (たとえば、無限ループによりリサイクルステップが実行できません)
API 関数が間違って使用されているため、リサイクルできません

2. コードを見るかどうかで分ける

1) ブラックボックステスト

ブラックボックステストでは、ソフトウェアの内部コードの実装や論理構造はまったく考慮されず、システムの入出力が期待どおりかどうか、機能が要件仕様に準拠しているかどうかのみが考慮されます。

ブラックボックステストの利点:

コードの内部構造を理解する必要がなく、コーディングスキルの低い人でもテストできます。
ユーザーの視点からシステム機能をテストすることは、テスターのユーザー思考の育成に役立ちます
テストケースは要件仕様に従って設計されているため、要件を見逃すことは簡単ではありません。

ブラックボックステストの欠点: ブラックボックステストはシステムの内部コードの実装を考慮しないため、コードをテストできません。

ブラックボックステスト方法:

同値類法、境界値法、誤差推定法、特性要因図法、シナリオ法、直交法

2) ホワイトボックステスト

ホワイトボックステストとは、コードをテストし、コードの論理構造に従ってテストケースを設計し、コードの実際の実行状態が期待される状態を満たしているかどうかを検証することです。

ホワイトボックステストのテスト方法:

ステートメントの対象範囲:

プログラム内のすべてのステートメントが少なくとも 1 回実行されるように、十分なテストケースを設計します。

判決範囲:

プログラム内の各決定ステートメントの各分岐が少なくとも 1 回実行されるように、十分なテストケースを設計します。

例: if else ステートメントの if 条件は true か false かをテストする必要があり、switch case ステートメントの各ケースはテストする必要があります。
条件の適用範囲:

決定ステートメントの各論理条件が少なくとも 1 回は true または false になるように、十分なテストケースを設計します。

たとえば、if (a > 0 && b < 0) では、2 つの論理条件 a > 0 と b < 0 がそれぞれ true と false であり、少なくとも 1 回出現することを確認します。
決定 - 条件範囲:

決定ステートメントの各論理条件 (真か偽かに関係なく) が少なくとも 1 回発生し、決定ステートメントの考えられるすべての結果も少なくとも 1 回発生するように、十分なテストケースを設計します。

例: if (a > 0 && b < 0) では、2 つの論理条件 a > 0 と b < 0 がそれぞれ true と false であることを確認し、同時に if (a > 0 && b < 0 ) ステートメントが true か false かを判定することも少なくとも 1 回発生します
条件の組み合わせの範囲:

決定ステートメント内の論理条件結果の考えられるすべての組み合わせが少なくとも 1 回発生するように、十分なテストケースを設計します。

たとえば、if (A && B) には 2 つの条件 A と B があり、条件の組み合わせのカバレッジには、テストケースに次の状況が含まれる必要があります。

A は真、B は真
A は真、B は偽
A は偽、B は真
A は偽、B は偽
パスの適用範囲:

プログラム内のすべての可能なパスが少なくとも 1 回実行されるように、十分なテストケースを設計します。

3) グレーボックステスト

ブラックボックステストとホワイトボックステストの中間のテスト。主に結合テストのフェーズで使用されます。プログラムの入出力だけでなく、プログラムの内部状態にも注目します。

3. 発達段階に応じた分割

テストピラミッド: 下に行くほどテストの効率が高まり、問題の特定が容易になります。

1) 単体テスト（Vモデルとの組み合わせ）

単体テストとは、ソフトウェアの最小単位であるモジュールをテストし、ソフトウェアの基本モジュールが正しいかどうかを検証することです。

テストフェーズ：コーディング後またはコーディング前（TDD）

TDD : テスト駆動開発。開発者は機能コードを作成する前に、まずテストケースコードを設計し、次にテストケースコードに基づいて機能コードを作成します。最終的な目標は、開発前に設計されたすべてのテストケースが確実に実行され、合格した。

テスト対象：ソフトウェアの各モジュール

テスト方法：ホワイトボックステスト

テスター: ホワイトボックステストエンジニアまたは開発者

テストベース：詳細設計書

テスト内容：モジュールインターフェース、境界テスト、例外テスト、パステスト、ローカルデータ構造テスト

Java での単体テストのための Junit フレームワークの使用

2) 結合テスト

単位モジュールを一定の戦略に従って組み合わせて大規模な機能モジュールを形成し、この大規模な機能モジュールをテストします

テスト段階: 単体テスト後

試験対象：統合大型モジュール

試験方法：グレーボックス試験

テストベース: 概要設計書

テスター: ホワイトボックステスターまたは開発者

テスト内容：モジュール全体の機能の正しさ、単位モジュール間のインターフェースの正しさ、単一モジュールの欠陥によるモジュール全体の機能への影響、モジュール間の機能競合、グローバルデータ構造のテスト

3) システムテスト

ソフトウェアシステム全体の機能と性能、およびソフトウェアが実行されるソフトウェアおよびハードウェア環境の包括的なテスト

テストフェーズ: 統合テストに合格した後

テスト対象: ソフトウェアシステム全体

テスト方法: ブラックボックステスト

テスター: ブラックボックステスター

テストベース: 要件仕様書

テスト内容：機能、インターフェース、互換性、セキュリティ、パフォーマンス、信頼性、使いやすさ、フォールトトレランス

システムテストには、回帰テストとスモークテストも含まれます。

回帰テスト: 新しいコードがシステムに導入されたとき、または古いコードが変更されたときに、システムのすべての機能が適切に機能していることを確認するために再テストします。

回帰テストでは通常、自動テストが使用されます。
スモークテスト: 正式テストの前に、システムの基本プロセスとコア機能がテストされ、テストに合格すると正式テストが開始されます。

4) 受け入れテスト

ソフトウェアがオンラインになる前の最後のテストは、ユーザーまたは製品提供者によってユーザーのニーズに基づいて実施されます。

テスト段階: システムテスト後

テスト対象：システム全体

テスター: ユーザーまたは製品提供者

テストベース: ユーザーのニーズ

テスト方法: ブラックボックステスト

テスト内容：同一システムテスト

5) 上記 4 つの試験方法を V モデルの段階に対応させる

4. 試験実施機関ごとに分ける

1) αテスト

αテストとは、開発者やテスター以外のユーザーや社内担当者が開発現場に出向いてテストすることを指します。

2) ベータテスト

ベータテストとは、時間や場所を問わず、実際のユーザーが実際の使用環境でテストすることを指します。

たとえば、一部のゲームは正式にリリースされる前にテストサーバーを開き、一部のプレイヤーをテストに招待します。

アルファテストとベータテストの違い:

アルファテストはベータテストの前に行われます
両者のテスト環境は異なり、アルファテストは開発環境、ベータテストは実際のユーザー環境で行われます。
ベータテストはアルファテストに比べて規模が大きく、テストサイクルも長くなります。

3) 第三者によるテスト

ソフトウェアは、業界の標準および仕様に従って、サードパーティのソフトウェアテスト機関によってテストされます。

5. 稼働中か否かで分ける

1) 静的テスト

コードを実行せずに、コード内のエラーが発生する可能性のある場所を静的にチェックし、コードの論理構造と特定のメソッドの実装が要件を満たしているかどうかを分析します。

2) 動的テスト

コードを実行し、テスト用のテストケースを実行します。

6.手動か否かで分ける

1) 手動テスト

テストケースを 1 つずつ手動で実行し、テスト結果を表示します。

利点: 探索的テストに役立ち、自動テストに置き換えることはできません

短所: 使用例が多いとエラーが発生しやすく、効率が比較的低い

2) 自動テスト

正常・異常などあらかじめ設定した条件に従って試験を行います。

自動テストは、テスト対象に応じて、UI 自動化、インターフェイス自動化、パフォーマンス自動化にも分類できます。

自動化の価値と重要性: 人員の節約: 自動化されたスクリプトの利用率が高いほど、その価値は高くなります。

すべてのプロジェクトが自動テストに適しているわけではありません

自動テストは、不安定なプロジェクトや頻繁に機能が変更されるプロジェクトには適しておらず、通常は回帰テストやスモークテストに使用されます。

7. 地域ごとに分ける

地理的区分に応じて、ローカリゼーションテストと国際テストに分けられます。

ソフトウェアの国際化: ソフトウェアを開発する際に、ソフトウェアのソースコードを変更することなく、各国の言語、習慣、使用習慣にソフトウェアを適応させるエンジニアリング技術。

ソフトウェアの国際化とローカリゼーションは、世界中のさまざまな地域のユーザーが使用するソフトウェアシステムの 2 つのプロセスであり、ローカリゼーションテストと国際化テストは、そのようなソフトウェア製品のテストです。

最後に、私の学習教材の一部を共有したいと思います:

上記のコンテンツは、ソフトウェアテストの友人にとって最も包括的で完全な準備倉庫となるはずです。各モジュールをより適切に整理するために、多くの高品質のブログ投稿も参照しました。インターネット上でのプロジェクトやプロジェクトで、すべての知識ポイントを見逃さないように努めています。多くの友人がこれらのコンテンツを参考にしてレビューし、BATJ などの大手メーカーからオファーを獲得しました。この倉庫は多くのソフトウェアテスト学習者にも役立ちました。あなたにもお役に立てれば幸いです。 . .

以下の WeChat 公式アカウントをフォローして無料で入手してください! ↓ ↓ ↓ ↓ ↓