最近の学習を整理し、不適切な点がある場合は修正を求めます。
ソフトウェアテストの基本的なプロセス：
要件分析ステージ->テスト計画ステージ->テストケースの作成->テスト実装ステージ->テストレポートの出力
1.需要分析段階
ソフトウェアテストは、要件に基づく必要があります。要件に基づく必要があります。したがって、最初に、要件を注意深く読み、要件を理解し、要件を分析し、要件のレビューに参加し、要件の論理的な関係を深く理解して把握する必要があります。
2.テスト計画段階
ソフトウェア要件仕様とプロジェクト全体の計画を参照して、ソフトウェアテスト計画をコンパイルします。主に次の5つのコンテンツが含まれています。
a。テストの目的と範囲
b。タスクの割り当てとスケジュール
c。テスト戦略を開発する
d。リスク分析と予防
e。承認項目のさまざまな指標
テスト戦略のパートには、通常、テストメソッド、テストツール、テスト環境の3つのパートが含まれます。テスト戦略では、最初のラウンドはビジネスプロセスに焦点を当て、オンライン機能とページが正常に表示されることを確認します。2回目はページテストに焦点を当て、オンラインビジネスのプロセスとページが正常に表示されることを確認します。3回目はビジネス全体に焦点を当てます。プロセスとページは、起動の各セクションの機能、プロセス、およびページが正常であることを確認するための主なものであり、フォールトトレランステスト、許可テスト、特別な環境テストなどの他の方向テストです。ソフトウェアリスクには、ビジネスリスク、セキュリティリスク、およびスケジュールリスクが含まれます。承認部分には、テスト要件、テスト計画、テストケース、テストレポートなどの成果物、テストケース要件、バージョン承認の欠陥修復率要件が含まれます。
3.テストケースを書く
ソフトウェアテストの場合、テストされるオブジェクトの観点から、ブラックボックステスト、ホワイトボックステスト、グレーボックステストの3つのテスト方法に分類できます。ブラックボックステストの一般的に使用される8つの方法は、等価クラス法、境界値法、決定表法、因果関係図法、状態遷移法、シナリオ法、直交実験法、および誤差推定法であり、ホワイトボックステスト法には、 ：ステートメントカバレッジ、決定カバレッジ、条件カバレッジ、決定/条件カバレッジ、条件組み合わせカバレッジ。
4.テスト実装フェーズ
テスト実装フェーズの作業内容には、テスト環境の構築、テストケースの実行、バグの回帰が含まれます。ソフトウェアのテストは、4つの段階に分けられます。
- ユニットテスト：ソフトウェアでテスト可能な最小ユニットをチェックおよび検証します。一般的なツアー開発者は、設計要件を満たしているかどうか検査機能を実装します。
- 統合テスト：アセンブリテストとも呼ばれます。ユニットテストに基づいて、モジュールは設計要件に従って組み立てられ、対応する機能が完了しているかどうかを確認します。テストモジュールのインターフェイス部分は主にテストされ、テストプロセスで使用されるスタブモジュールまたはドライバーモジュールを設計する必要があります
- システムテスト：実際の動作環境で、コンピューターハードウェア、周辺機器、およびサポートソフトウェアと一緒に確認およびテストされたソフトウェアをテストします
- 受け入れテスト：配信テストとも呼ばれます。これは、システムが受け入れ基準を満たしているかどうかを判断するためのユーザーのニーズとビジネスプロセスの正式なテストであり、ユーザー、顧客、またはその他の承認された組織がシステムを受け入れるかどうかを決定します
これらの4つの段階は、段階的なテストプロセスと、小規模から大規模に、内部から外部に分割して征服するという考え方を具体化しています。その中で、ユニットテストの粒度は最小であり、開発チームは通常、テストボックスが「設計」に準拠しているかどうかを確認するためにホワイトボックステストを使用します。統合テストはユニットテストとシステムテストの間にあり、開発者は通常、ホワイトボックスプラスブラックを使用しますテストの方法は、システムが「設計」を満たしているかどうか、および「要件」を満たしているかどうかを検証することです。システムテストの粒度は最大であり、通常、独立したテストチームがブラックボックス方式を採用して、システムが「要件仕様」を満たしているかどうかをテストします。手動」;受け入れテストはシステムテストに似ています。主な違いは、テスターが異なり、受け入れテストがユーザーによって実行されることです。
5.テストレポートの出力
ソフトウェアテストレポートは、テストプロセスとプロセス結果、プロセス中に発生したいくつかの問題、改善作業の次の段階など、独自の価値とその背後にあるロジックを含む要約ドキュメントです。テストレポートの役割は、レポート、評価、リフレクションの3つの側面で表されます。レポートとは、できるだけ多くのリーダーとプロジェクトにテストレポートの形で報告し、最近のテスト結果を報告することを指します。評価とは、ソフトウェアの品質を評価することを指し、評価はテストチームによって異なり、テストプロジェクトで使用されるユースケースとユースケースが実行されます中央にある結果とソフトウェアの欠陥は、ソフトウェアの品質を直接かつ具体的に示しています。反映とは、レビューを通じて作業を改善する方法を反映することです。ソフトウェアテストレポートは、参照テンプレートのフレームワークの下で記述でき、テストの担当者とリーダーがガイドし、テストフェーズの終了後に実行できます。そのコアコンテンツには次のものが含まれます。
- 経過テスト作業：時間、作業、参加者
- ユースケースと欠陥：機能、合計、実行、欠陥
- ソフトウェア品質評価：機能、リスク、起こり得る品質問題
- 作業改善提案：残りの欠陥、要求提案、テスト環境、プロジェクト管理
参照テンプレート：https : //blog.csdn.net/xqtesting/article/details/78976456