ソフトウェアテストの基礎知識

まず、業界の見通し

序文

この文を持つプログラマの間スプレッドは：一部の人々は、彼らが開発エンジニアを行い、世界を創造したいと、何人かの人々はそれをテストしたいので、彼らはテストエンジニアをしました。

ソフトウェアテストとは何ですか

ソフトウェアのテストは、手動ツールの使用であるか、テストプログラムとプロセスに従って、製品の機能や性能テストをテストし、単にソフトウェアが行うことを意味し、「品質管理」を

ソフトウェアテストの重要性

バグ経済的損失：

ソフトウェアのバグは、私たちの生活に壊滅的な被害をもたらし、仕事になります。毎年恒例のソフトウェアのバグは、市場経済はほぼ$ 600億の損失をもたらしていますことが報告されています！

理由は、ソフトウェアのテスト部門の設立
- ソフトウェアのテストは、ソフトウェアの欠陥が事前に存在して見つけることができます
- そして、より洗練されたソフトウェアのテスト要件 - 労働者の社会的分裂は小さくを得ています
- 責任者、責任

第二に、テストベース

2.1ソフトウェアテストとは何ですか

オペレーティングプログラム（アプリケーションは、.exeのインストールファイル、Webページなど）を指定された条件の下では、エラー、ソフトウェアの品質評価のプロセスを発見します。

ソフトウェアテストの目的2.2

私は原因によって引き起こされる可能性のあるソフトウェアの不具合やエラーにとしてソフトウェアのリリース後にリスクを回避するために、最小限の人員、材料資源と潜在的なソフトウェアのエラーや欠陥のすべての種類を見つけると、さまざまなエラーや欠陥を補正することにより、ソフトウェアの品質を向上させるための時間としたいですビジネスリスクへ。（質問に対する答えは、多くの場合、ソフトウェアテストの定義と混同されることに注意してください）

2.3定義は、ソフトウェアテスト

実行するか、システムをテストするために、手動及び自動の手段を使用することは、その目的は、指定された要件を満たしているかどうかを調べたり、期待される結果と実際の結果との間の差を明らかにすることです。

2.4、ソフトウェアテストの原則

すべてのテストは、ユーザーのニーズにさかのぼるべきである（ビデオサイト、クリックを最大化）
それは「できるだけ早くし、テストし続ける」ことをモットーとすべきです
テストは、独立した専門的なソフトウェアの試験機関によって行われるべきです
パレート原理は、テストでは、80％のエラーはおそらくモジュールの20％に起源ました
テストケースを設計するとき（テストは何？測定方法は？）、あなたはさまざまな状況を考慮すべきです
テストエラーの結果は、プロセスの確認を持っている必要があります（不具合報告を記述）
厳密なテストプログラムを開発
これは、テストが終了する必要があり、完全にテストすることは不可能です
回帰テストの妥当性に注意してください。
すべてのテストドキュメントの適切な保全

2.5、回帰テスト

修正後の変更は、新しいバグを導入したり、エラーを生成するために他のコードが発生することはありませんを確認するために、古いコード、再テストを指します。

第三に、ソフトウェアエンジニアリングとテストモデル

3.1、ソフトウェア開発プロセスモデル

ウォーターフォールモデル、ラピッドプロトタイピングモデル、スパイラルモデル：数十年のソフトウェア開発の実践では、人々は、次のような、複雑な開発プロセスを記述し、表現するために使用されるソフトウェア開発モデルの多くを出ています。

ソフトウェアのテストとソフトウェア開発モデルは密接にリンクされている、テスターとして、あなたは完全に自分の価値を再生するためには、その中で自分の位置を特定するために、ソフトウェア開発モデルを理解する必要があります。

3.1.1、ウォーターフォールモデル

ウォーターフォールモデルは、線形モデルは、すべてのモデルにおいて重要な役割を果たしている他のすべてのモデルのための基礎となります
一度各実装フェーズ、ソフトウェア開発のための線形順序
テストエントリポイント：

ソフトウェアの実装でテスト段階の後、テスト活動のための十分な時間が経過した後、コード補完のままにしなければならない。そうでなければ、テストは、後半にプロジェクトにまで露光すべき多くの問題は十分ではありません。
ウォーターフォールモデルの長所と短所
- 利点：
  - より明確な開発の様々な段階
  - 初期の計画やニーズ評価の重視
  - 製品開発のための安定した需要
- 短所：
  - これは、変更のニーズに適していない、初期の調査のニーズによって異なり
  - シングルプロセス不可逆性
  - リスクは、多くの場合のみ、できるだけ早く修正する機会を失って、遅くまで明らかにされています
  - 後でプロジェクトの問題点が露出されるようになりました
  - 未知のエラーの前に渡されると、ステージのバックに広がる、それがプロジェクトの失敗につながる可能性があります
- 改良
  - 線形思考のウォーターフォールモデルに従って、組み込みの重要な課題のいくつかは、反復を考えて、ステージ間の様々な段階を絞り込みます

3.1.2ソフトウェアテスト＆ソフトウェア工学

密接にソフトウェアのテストとソフトウェア工学、ソフトウェア工学に関連した、ソフトウェアのテストは、組成物の不可欠な部分です。
ソフトウェアエンジニアリング、プロジェクト管理では、品質管理は、ビジネスアプリケーションを標準化された、ソフトウェアのテストは、より円滑に行われる、プレイソフトウェアテストの値が大きくなります。
ソフトウェアエンジニアリング、品質管理、および構成管理とソフトウェアのテストの間の関係に焦点を当て、さまざまな開発モデルでは、どのようにソフトウェアのテストを実施します。

3.2、テストモデル

テストプロセスの管理と開発では、そのような一般的なモデルV、Wモデル、Hモデルとしてテストモデルの多くをまとめたたくさんの練習を通じて、テスター。これらのモデルは密接に抽象的に活動をテストし、開発と統合され、それはテストプロセス管理のための重要な参考となっています。

3.2.1、Vモデル

Vモデルは、ソフトウェア開発の効率と効果を向上させることを目的とした、文献に英国国立コンピュータセンター発行のポール・ルークが提案した1980年代後半に最初の最も重要な代表のテストモデル、、、です。
Vモデルの導入に先立ち、通常のアウトラインの設計、詳細設計の段階の後、分析を必要とするなど、テスト・プロセスに入れて人々が半分の時間がかかりますプロジェクトサイクルのテストが行われているにもかかわらず、完成コーディングが、ほとんどの人が考えます単なるテストを終え、この時点で開始したVモデルは、以前に広く認識業界を変更することです。
Vモデル自体は、ソフトウェア開発バリアントのウォーターフォールモデルである、それは関係のテスト分析と設計活動を反映しています。
Vモデルのテストは、左から右に、プロセスおよびテストプロセスの間に対応開発段階を説明し、本発明の方法自体の様々な段階を示します。

モデルVの詳細な説明
- 要件分析
  - ユーザーのニーズ、ビジネスニーズ、要求仕様
- 概要設計
  - システムアーキテクチャ（BS、CS）、モジュール部門（ホーム・ページ、リストページ、詳細ページ、など）、モジュールとモジュール間のインタフェースは（、リストページを開くには、ホームボタンをクリックし、詳細ページを開くには、リストボタンをクリックしてください）
- 詳細設計
  - ロジックと内部モジュールのメソッド実装（例：QQは - 友人の頭をクリックしてください - チャットページ - タイピング - 送る - 送信されたコンテンツを表示することができます）
- コーディング
  - 上記の設計を達成するために
- ユニットテスト
  - コードシンボル開発かどうかを検出する詳細な設計要件（ソフトウェアの設計は、最小単位である - テスト・プログラム・モジュール）
- 統合テスト
  - 以前に、種々の成分が良好に接着することができる試験したかどうかを検出する（すなわち、テストユニットテストが一緒に組み立てられるがあります）
- システムテスト
  - 製品はシンボル仕様要件（ソフトウェアテストの全体の流れを）統合されたかどうかを検出します
- 受け入れテスト
  - 製品記号は、エンドユーザーのニーズかどうかを検出します
Vモデルの強みと弱み
- 利点
  - すなわち、Vモデルの基礎となる試験の開発はまた、高レベルの試験が含まれています
    - 下地テスト：テストソースコードの品質をテストする、例えば：ユニットテスト
    - など::トップテストシステムテストシステム全体の検査を必要とします
  - Vモデルは明らかにソフトウェア開発の段階を識別します。
  - 開発プロセス全体を通してトップダウン段階的に精緻化方法とVモデルを異なる段階に分割され、作業の各段階は、このように、開発プロセスの制御を容易にする、非常に明確です。すべてのフェーズが完了すると、ソフトウェア開発プロセスはそこで終了します。
- 短所
  - Vモデルは大きな欠点が発生し、独自のシーケンシャルです。テスト段階へ、プログラムはエラーがテスト段階まで発見された初期の多くのミスを発生させた、完成された、でも見つけることができない、頻繁に変更することはできません。
  - 実際の開発プロセスの間に要件フェーズがダウンして、ユーザーのニーズに完全には明らかに困難であり、したがって、需要の変化を繰り返し、ステージにつながる、との要件、設計、コーディング、テスト、および他のプロセス、リワークの非常に大きな金額を繰り返さなければならないときモデルの柔軟性が比較的低いです。
- 改良
  - マイナー反復、アジャイル開発を行います

3.2.2、Wモデル（モデルV-ビス）

提案された活動のIEEE std1012-1998原則「ソフトウェア検証と妥当性確認（V＆V）は、」ソフトウェア要件および設計フェーズをテストし、対応する原則を提唱している必要があります
Evolutif会社によって提案されたWモデル：Vの開発、テストV、Wモデルポートフォリオ
全体のソフトウェア開発サイクルをテストし、テストオブジェクトは単なる手続きではないとともに、要件や設計もテストする必要があります。

長所と短所Wモデル
- 利点
  - ソフトウェア開発サイクル全体でのテストの開発に重点を置いて、テストオブジェクトを使用してテストすることもない単なる手続き、要件、およびアウトラインのデザインです
  - 以前のアクセステスト、欠陥が早期に開発を見つけることができる、それははるかに低いコストで欠陥を修復することができます
  - 同じことは、プロジェクト期間中に制御することは容易な作業を、段階的にされます
- 短所
  - これは、ソフトウェア開発とソフトウェアテストの遺骨のタンデム間の線形関係に依存している、まだ反復的、自発性と変更の調整の需要をサポートすることはできません
  - 現在の多くのプロジェクトでは、実施の過程には、文書が存在しない、基本的なモデルは、Wを適用することはできません
  - 要求のための高い技術的な複雑さ、設計とテストの要件を使用するには、実際には困難です

第四に、ソフトウェアテストの分類

ブラックボックステスト（ブラックボックステスト）
- また、唯一の入力および出力データ・ソフトウェアに関する、ソフトウェアのテストの機能要件に焦点を当て、内部構造、プログラムの内部特性を考慮することなく、データ駆動型テストとして知られています。
- ブラックボックステストは、次のカテゴリのエラーで見つけることができます
  - 機能または機能が欠落していません
  - インターフェイスエラー
  - データベースへのアクセスや処理のエラー
  - パフォーマンスの問題
- ブラックボックステストの利点
  - テスターは、特定のプログラミング言語を含め、実装の詳細を知る必要がありません（プログラミングの経験テストケースを設計することができます）
  - テスターとプログラマーは互いに独立している（ブラックボックステストケースの設計と独立した実装をプログラミングする方法）
  - 試験されたユーザの観点から、受け入れられ、容易に理解
  - 矛盾や発散と仕様を公開するのに役立ち
- ブラックボックスの欠点
  - プログラムの内部の特定の部分をテストすることはできません
  - コードが実行されていない場合はプログラムが見つかりません
  - あなたは、徹底的なテストを行うことはできません
- ブラックボックスの分類
  - 機能テスト（機能検査が） - 一方ではブラックボックスであり、それはソフトウェアの実際の機能は、ユーザーのニーズを満たすチェック
    - テストロジック機能（機能検査）
    - 試験インタフェース（UIテスト）
    - ユーザビリティテスト（ユーザビリティテスト）
    - インストールとテスト（インストール・テスト）
    - 互換性テスト（互換性テスト）
  - パフォーマンステスト（性能試験）は - ハイエンドのソフトウェアテスト、性能テストエンジニアとホワイトボックステストエンジニア同等の治療をされ、通常、我々はシニアソフトウェアテストエンジニア呼んで、一般的にパフォーマンス・テスト・エンジニアやホワイトボックスを指し、
    - タイム・パフォーマンス（トランザクション応答時間など）
    - パフォーマンススペース（システムリソースの消費）
    - 一般的なパフォーマンステスト
    - 安定性試験
    - 負荷試験：様々な作業負荷の下で決定するために、負荷テストを介してシステムの性能指標の変化
    - ストレステストは：ボトルネックまたは単に許容できないパフォーマンスの点を識別することによって、システムは、システムによって提供されるサービスの最大レベルを取得します
ホワイトボックス（ホワイトボックステスト）
- 箱を開け参照し、構造内部のプログラムのソースコードを勉強します。
- ソフトウェア会社では、しばしばブラックボックスの組み合わせによってホワイトボックステスト＆
  - ソフトウェアのブラックボックステストの全体的な機能と性能
  - 白いボックスを使用したソフトウェアのソースコード
グレーボックステスト
- 試験は、順番に白いボックスの内部構造を制御することができるフォーカスブラックボックスを確実にするために、（両方の機能を見て、コードを見て）ホワイトボックスとブラックボックステストの間にあるが、内部プログラムの機能のために行っていません操作の詳細な理解は、グレーボックステストは、ホワイトボックスとブラックボックステストの要素を組み合わせ。
静的試験（静的試験）
- これは、実際にテスト中のソフトウェアを実行するが、唯一の静的検査プログラムコード、存在する可能性があるエラー処理インタフェースやドキュメントではないことを意味します。
動的テスト（動的試験）
- テスト対象プログラムの実際の動作を指し、適切なテストデータ入力は、プロセスは、実際の出力と互換性の期待される結果を確認します。
スモークテスト
- 測定されたプロジェクト全体のプロセスと限り問題はないなどのプロセスと同等の、スモークテストはの採用に相当します
ランダム試験（探索的試験）
- 主セクションでカバーされていないものを、現在のテストのテストケースを含むテスト再テスト中のソフトウェアの重要な機能のいくつかのランダムなテスト。また、ソフトウェアのアップデートや新機能のテストに焦点を増加させます。特に、前のテストで見つかった主要なバグ、再テストのために、いくつかの特別な場合、環境の特殊な使用、同時実行チェックに着目し、回帰テストを組み合わせることができます（回帰テスト）を一緒に行います。
受け入れテスト
- αテスト
  - アルファは今CBと呼ばれているベータ版であり、このバージョンでは、ソフトウェアが通常唯一のプロテスターに分数をリリースしている、社内のソフトウェア開発者を交換し、唯一の予備的な完成品であることを示しています。一般的には、ソフトウェアのバージョンのバグが多い、平均的なユーザーはインストールしないことが最善です。
- βテスト
  - ベータ版は、ベータ版では、ベータ版のすべてのユーザーに開放されています。α版に関してバージョンが大幅に重大なミスを排除し、改善されているが、まだいくつかの欠点があった、我々はさらに排除するために大規模な放出試験を通過する必要があります。このバージョンでは、通常、フリーソフトウェアによって解放され、ユーザーは、関連するサイトからダウンロードすることができます。一部の専門家の愛好家のテストでは、結果が戻って、開発者に、開発者が再び変更を目標としています。このバージョンでは、一般のユーザーがインストールするためには適していません
- γテスト
  - ガンマ版は、公式リリース候補版のソフトウェアバージョンを指します。このバージョンでは、ほぼ同じの次期リリース、公式リリース候補版の正式版で、すでにかなり成熟しています。
- 正式版の発売前のソフトウェアのいくつかのバージョンが、それは問題があるかどうか、それをテストするために誰かを必要としています。同社の社内テストスタッフによるソフトウェア会社の自社開発は呼ば：アルファテスト。使いやすい、ベータテスト、主にソフトウェアの利用者の外観を見て：機能やシステムエラーの重大な損失が存在しない場合は、アルファテストは、一般的には大きな問題ではありません後、参照して、と呼ばれるソフトウェアのユーザーテストを示したためにアルファテスト応答。できるだけ多くのユーザーのニーズを満たすために、一方で、製品の最終テスト版のあまり、それはまた、ソフトウェアのバグを最小限にすると、その後、いくつかの変更をした、公式リリース候補版になった、ガンマが（今RCと呼ばれると呼ばれます-release候補）。
- 簡単に言えば、アルファテストは、開発環境でテストするためのテストで、ベータテストは、実環境でのテスト、またはシミュレートされた実環境での内部スタッフのテストです。