ソフトウェアテストのゼロベースのクイックスタート

ソフトテストの基本概念

ソフトテストの定義

ソフトウェアテストは、初期段階での要件ドキュメントのレビューから、中期でのテストケースの設計とテストの実行、後期での問題チケットの提出とクローズまでの一連のテストプロセスです。

80/20原則は、バグの 80% がモジュールの 20% に集中していることを意味します。

ソフトウェア分類

ブラックボックステスト: ソフトウェアの内部コードの構造やアルゴリズムには注意を払わず、ソフトウェアの外部に表示されるすべての機能特性のみに焦点を当てたテストです。

ホワイトボックステスト: ホワイトボックステストの定義は、ブラックボックステストの正反対です. ホワイトボックステストは、ソフトウェアの内部コードの構造とアルゴリズムのみに焦点を当てたテストであり、ソフトウェアの外側に表示される機能ポイント。

テスト段階

単体テスト: ホワイトボックステストの方法を使用して、コードをテストするために使用されます。
統合テスト: 単体テストから取得したモジュールに対してブラックボックステストを使用する
システムテスト: ソフトウェアの外観、インターフェース、機能、パフォーマンス、セキュリティ、ユーザビリティ、および互換性の 6 つの側面が、要件ドキュメントの要件を満たしているかどうかをテストします (この段階でテスターが介入します)。
受け入れテスト: ユーザーが実施するテスト

ソフトテスト計画

ソフトテスト計画の 5 つのカテゴリ: テストスコープ、テスト環境、テスト戦略、テスト管理、テストリスク

テスト戦略のポイント

テストベース: 要件ドキュメントとテストケースに従って決定
テストアクセス基準: システムがどのような条件を満たしているかを指定してからテストを開始する. アクセス基準は一般的にスモークテストです (つまり、システムテストの前に基本的な機能ポイントをテストし、結果が合格した場合にのみシステムテストを開始します)。
テストツール: セレン
テストの焦点と方法
テスト基準:

テスト管理：主に、テストタスクの配分、タイムスケジュールの調整、およびコミュニケーション方法を指します。

テストリスク: 一般的なリスクには、要件ドキュメントの不完全な理解、テスト時間の過小評価、および不適切なテスト実行が含まれます。

ソフトテスト計画テンプレート

1. ドキュメントの識別
2. テストの目的
3. テストの範囲
4. テスト環境
5. テスト戦略
6. テスト管理
7. テストのリスク

テストケースの設計

テストケースは、特定の要件が満たされているかどうかを検証するために、特定の目的のために準備された一連のテスト入力、実行条件、および期待される結果です。

テストケースは、テスターがテストを実行するための基礎となるものであり、テストの標準として機能し、テスターがテスト作業を実行するためのガイドとなる非常に重要なドキュメントです。

テストケースの設計方法

テストの基本的な考え方: テスト担当者は、要件ドキュメントの制限内ですべてのデータをテストする必要があります; テスト担当者は、要件ドキュメントの制限を超えてすべてのデータをテストする必要もあります

等价类划分法
考えられるすべての入力データをいくつかの領域に分割し、各領域から少数の代表的なデータを取得してテストします

要件ドキュメントで指定された要件を満たさないデータは、無効な等価クラスと呼ばれます。
有効な等価クラスが要件ドキュメントの要件を満たしている

次の図は、登録時に入力されたユーザー名形式の正規化のテストデータを示しています。

[外部リンクの画像の転送に失敗しました。ソースサイトにはリーチング防止メカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-OZfYaSIQ-1681816679733)(./img/softtest/st1.png)]

边界值分析
境界値分析方法は、テストのために境界のわずかに上またはわずかに下のいくつかのデータを取得することです

错误推测法
テスト担当者は、直感、テスト経験、および発散的思考に依存して、ソフトウェアエラーを引き起こす可能性のあるいくつかのテストポイントを設計します。

正交表分析法
たとえば、3 つの入力ボックスの内容を同時にテストする必要がある場合は、直交表法を使用する必要があります。

[外部リンクの画像転送に失敗しました。ソースサイトにはアンチリーチングメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-1mP8LELM-1681816679736)(./img/softtest/st2.png)]

因果判定法は、
主に、より複雑なロジックを持つテスト手順に使用されます。

テストケースのレビュー

テスターは、一般的に次の 5 点に基づいてテストケースのレビューを行います。
(1) テストケースが要件ドキュメントに従って記述されているかどうか。
(2) テストケースの実行手順や入力データが明確、簡潔、正確であるか、繰り返し率の高い実行手順が簡略化されているか。
(3) 各テストケースが明確な期待結果を持っているかどうか。
(4) テストケースに冗長ユースケース（無効、同等、冗長ユースケース）がないか。
(5) テストケースは要求仕様書のすべての機能点を網羅しているか、漏れがないか。

テスト環境

ソフトウェアシステムには、ブラウザ/サーバー（B/S）構造のソフトウェアシステムと、クライアント/サーバー（クライアント/サーバー、C/S）構造のソフトウェアシステムの2つの主要なアーキテクチャがあります。

B/S アーキテクチャ、ジュニアソフトウェアテストエンジニアは、Windows プラットフォームでさまざまなブラウザーを使用したテスト方法に精通していると同時に、VMware での仮想マシンのセットアップに習熟している必要があります。

C/S アーキテクチャ。Windows サーバープラットフォームに精通し、データベースを操作する必要があります。

バグを記録する

バグを記録する方法

バグには次の情報ポイントが含まれる場合があります

[外部リンクの画像転送に失敗しました。ソースサイトにアンチリーチングメカニズムがある可能性があります。画像を保存して直接アップロードすることをお勧めします (img-KCNoHdZE-1681816679736)(./img/softtest/st3.png)]

回帰試験

前回のバグは修正済みであり、次回のテストで新たなバグが発見される可能性がありますが、前回のバグが修正された後、他の問題が発生しないというわけではありません

ソフトウェアのテストは 1 回のテストで完了するわけではなく、通常、ソフトウェア製品がオンライン標準に到達するには、テストと検証を複数回繰り返す必要があります。

ソフトテストレポート

以下は、簡単なテストベースレポートのテンプレートです。

1. 執筆の目的
2. モジュールの機能説明
3. テストプロセス
4. テスト環境
5. 機能点のテスト範囲
6. テストの実行結果
7. リスク評価
8. テストの結論

インタビュー分析

ソフトウェアテストの仕事は、テスターの実践能力とコミュニケーション能力にもっと注意を払う

同社がジュニアのソフトウェアテスターを採用する際、筆記試験問題を出す企業は約35%に過ぎず、ほとんどの企業は採用のための筆記試験を実施しておらず、主に候補者の履歴書で直接面接を行っています。

ソフトウェアテストはどのような原則に従うべきですか?
参考回答: ソフトウェアのテストは 80/20 の原則に従うべきだと思います。つまり、問題が発生しやすいモジュールや、問題が多いモジュールは重点的にテストする必要があります。

ソフトウェアのテストはどの段階で行われますか?
参考回答: 通常、機能テスターの場合、システムテスト中に介入します。