ソフトウェアテストの目的は何ですか？
多くの本を読んだことで、基本的な矛盾があります：
「テストの目的はバグを見つけることである」と言う人もいれば、「テストの目的は製品の品質を均一にすることである」と言う人もいます。つまり、バグはその副産物です。
また、テストが主にバグハントに向けられている場合、実際に検証を行い、ソフトウェアの準備ができているという情報を実際に提供するのは誰ですか。
たとえば Kaner テスト目標の元の定義をバグハンティングから品質評価の提供に変更しましたが、まだ明確な違いはわかりません。私はどちらも同じくらい重要だと考えています。
ソフトウェアを仕様で検証して、機能することを確認できます。その場合、見つかったバグは製品のみによるものです。しかし、私は物事を壊すためだけにテストを実行します。
また、どの定義がより正確ですか？
上記の注意点私は主にソフトウェアテストをプロセスと呼んでいます。
ご存知のとおり、単体テスト、統合テスト、受け入れテストなど、さまざまな種類のソフトウェアテストがあります。そのため、これらすべてを包括的に表す用語であり、この非常に高いレベルの議論として、私たちは本当に広い意味で「品質」についてのみ話すことができます。あなたは単にあなたが適用したい受容性のどんな測定値に対してもソフトウェアを検証しています。テストのさまざまなレベルとタイプで、これらは大きく異なり、唯一の本当の共通点は品質の側面です。
バグ（伝統的に定義されている）はソフトウェアの特定の種類の問題ですが、他にも多くの問題があります。特定の、より低いレベルのテストについて説明しているのでない限り、定義をバグに限定することは意味がありません。少し遅すぎるUIはバグですか？開発者にバスケットをWebストアに追加するように指示するのを忘れたという事実はどうですか？おそらく、混乱は「ソフトウェアテスト」と呼ばれる特定の種類のテストで発生しますが、それは実際には単なる意味論です。
定義を形式化するように推し進められた場合、テストはソフトウェアを要件（定性的な場合もあります）に照らして検証するプロセスであると言えます。バグは、要件の非常に具体的な違反です（具体的には、開発者がすでに正しく機能していると考えているもの）。
編集：私はおそらく「バグ」という言葉が人々によって非常に異なる意味を持つことを付け加えるべきであり、実際にそれを定義することによってこの意味論的議論を始めるべきです。私は開発者の観点から定義を使用しています-これは私（開発者）が意図したとおりに機能しません。これは通常、非常に具体的な要件、または要件の非常に具体的な解釈に基づいています。クライアントの定義は通常似ています-これは[〜＃〜] i [〜＃〜]（クライアント）が意図したとおりには機能しません。これは実際に非常に異なるものです。後者の定義を使用すると、クライアントの希望を満たさないものはすべて「バグ」であるため、品質とバグをほぼ同等と見なすことができます。
ダニエルBの答えから：
私は開発者の観点から定義を使用しています-これは私（開発者）が意図したとおりに機能しません。これは通常、非常に具体的な要件、または要件の非常に具体的な解釈に基づいています。クライアントの定義は通常似ています-これは、私（クライアント）が意図したとおりには機能しません。これは実際に非常に異なっています。
これは基本的に、検証と検証の違いです。検証は、「正しく作成されたか」という質問に答えます。検証は、「正しいものを構築しましたか？」という質問に答えます。検証テストと検証テストはかなり異なります。検証は検証よりもはるかに簡単なタスクです。検証により、何をテストするかがわかります。ソフトウェアが何をすることになっているのかを説明する要件（またはストーリー）です。ここに問題があります：これらの要件やストーリーが間違っているとどうなりますか？その問題をどのようにテストしますか？これが検証で対処しようとするものです。
一部のサークルで使用されているさらに別のコンポーネントは、認定の概念です。これは、ソフトウェアを再利用するときに重要になります。例：車両のシミュレーションを構築していて、その慣性測定ユニットの適切なモデルが必要であるとします。コンポーネントモデルライブラリで既存のIMUモデルを見つけます。この既存のモデルは、要件に対して徹底的に検証され、現実に対して検証されています。飛行データとの比較を含め、テストは非常に広範囲にわたっています。検証および検証済み！いいですね！そのまま再利用してください。
もう一度、多分そうではありません。そのモデルの意図された使用は静止した操作であったかもしれません、あなたの使用は発射段階の間にロケットをモデル化することです。起動時のIMUの動作は、仕様の動作に近くなります。つまり、お粗末です。 IMUは通常、静止動作中に仕様よりもはるかに優れています。そのモデルの使用目的が、使用目的と一致していません。再利用しない方がいい。認定の試みは、検証と検証を超えています。 「これは、この特定の使用目的にとって正しいことですか？」という質問に答えます。
別の例は、アリアン5ロケットの最初の飛行試験です。フライト501の失敗につながったソフトウェアバグは、史上最も悪名高い、最も高価なソフトウェアバグの1つにランクされています。フライトソフトウェアの構築には非常に費用がかかります。これらの莫大なコストを回避するために、Ariane 5フライトソフトウェアは、Ariane 4フライトソフトウェアの大きなチャンクを再利用しました。広範囲に検証および検証されており、すでに実際の環境で使用されています。したがって、そのまま再利用してください。違う。再利用が認められているはずです。 64ビットから16ビットへの変換オーバーフローを含む「起こり得ない」イベントが偶然起こり、その結果、車両が故障しました。
ソフトウェアテストの目的は何ですか？
要約：作者のコメントにあるように、「一般に、ソフトウェアテストはプロセスです」。 -あなたの質問は広範で、これが Wikipediaの記事 での定義です。
ソフトウェアテストは、テスト対象の製品またはサービスの品質に関する情報を関係者に提供するために行われる調査です。ソフトウェアテストは、ソフトウェアの客観的で独立した見方を提供し、企業がソフトウェア実装のリスクを評価および理解できるようにします。
したがって、-目的ソフトウェアテストは独立した情報を提供する製品/ソフトウェアの品質についてです。 -ソフトウェアテストの方法とサブプロセスはどのように行う必要がありますか？ -別の質問です。
編集：ソフトウェアテストプロセスは個別に提供する必要がありますビジネス要件に基づいて。そうでなければ、その価値は低くなります。実際、大規模なソフトウェアプロジェクト（国の不動産プロジェクトなど）では、品質管理、テスト、およびソフトウェアの検証/受け入れプロセスに個別の入札が行われます。
ソフトウェア回帰 が現れたらすぐに特定します。
特にユニットテストは、ビルド/テスト/デプロイチェーンの回帰earlyを識別することを目的としています
受け入れテストは、クライアントとの契約のフルフィルメントの詳細に基づいています。しかし、繰り返しになりますが、受け入れテストの一部が想定されていたものに合格しなかった場合は、対処すべき回帰を特定しました。
Glenford J. Myers著の「The Art of Software Testing」という本が最もよく定義していると思います。
「テストとは、エラーを見つける目的でプログラムを実行するプロセスです。」
彼はこの定義をいくつかの一般的な定義と対比しています：
- 「テストは、エラーが存在しないことを実証するプロセスです。」
- 「テストの目的は、プログラムが意図した機能を正しく実行することを示すことです。」
- 「テストは、プログラムが想定されていることを実行するという信頼を確立するプロセスです。」
プログラムが機能することを証明しようとするのではなく、プログラムにエラーがあると想定する必要があります。ソフトウェアテストの目的は、エラーを見つけることです。そうすることで、ソフトウェアの品質が向上します。これがソフトウェアテストの究極の目的です。
@David Hammenの答えは非常によく書かれていますが、私が言ったこととまったく同じではありません。ベリフィケーションが「これを正しく作成しましたか？」と回答することに同意します。プロセスによって生成されたものはすべて検証できます。製造には、生産されているものが正しく生産されていることの継続的な検証が含まれます。
次に彼は、私たちが同意しているバリデーションを「正しいものを構築したか」と定義します。検証は反対の方向に進んで、設計が正確に正しく機能していることを徹底的に確認していると思います。 「ソリューションが正しく設計されていることを客観的に示す」のようなものです。適切な等級のボルト、適切なサイズの内部変数。作品は仕事次第です。
デビッドの検証、「私たちは正しいものを構築しましたか？」高レベルの質問です。これは、毎日のビルドに対して高く評価したり低く評価したりすることはできません。要件と、それよりは少ないがデザインの判断。画面のテキストボックスやAPIのパラメーターを対象とした賢明な質問ではありません。要件を正確にするための1語の名前がわからない、おそらく要件の検証。要件がエンドユーザーのニーズに対応していることを徹底的に証明します。
対照的に、検証の私の定義は、設計の正確さの証明であり、選択された部分を示す客観的テストが効果を発揮します。 Ariane IVには限られた範囲の角速度の変更があったため、Ariane Vに適さなかったAriane IVソフトウェアはここで失敗します。コードはこの限られた範囲に合わせて最適化され、Ariane Vはより広い範囲の角速度に対応でき、オーバーフローを引き起こしました。両方のオンボードコンピューターがオーバーフローでクラッシュし、自動再起動後に再度クラッシュすると、破壊システムがトリガーされました。
Dykstraが言ったように、「時期尚早な最適化はすべての悪の根源です」。
私の定義では、要件は正しく受け入れられ、要件テストによって検証されていると想定されています。設計またはコード検証は、設計、おそらく実装の少しが正しいことを証明します。それでも正しく実行する必要がありますが、それが検証であることを確認し、承認された要件と承認された設計に基づいてテストします。
これは、開発のウォーターフォールモデルに痛烈に近づいていることに注意してください。それにもかかわらず、要件は設計とは異なり、コードは完全に3番目のものです。ウォーターフォールの要素は有用な説明ですが、「完全」は誤解を招くので、偶然性と可変性を示唆する「承認済み」に変更しました。
ソフトウェアのテストはバグの発見を目的としたものではなく、バグの防止を目的としています。初期段階で適切なテストを行うことで、本番システムへのバグの発生を防ぎます。