ソフトウェアテストの目的は何ですか？[閉まっている]

多くの本を読んだことで、基本的な矛盾があります：

「テストの目的はバグを見つけることです」と言う人もいれば、「テストの目的は製品の品​​質を均一にすることです」と言う人もいます。つまり、バグはその副産物です。

また、テストが主にバグハントに向けられている場合、実際に検証を行い、ソフトウェアの準備ができているという情報を実際に提供するのは誰ですか。

たとえば、Kanerでさえ、テスト目標の元の定義をバグハンティングから品質評価規定に変更しましたが、まだ明確な違いはわかりません。私はどちらも同じくらい重要だと考えています。

ソフトウェアを仕様で検証して機能することを確認できます。その場合、見つかったバグは製品のみによるものです。しかし、私は物事を壊すためだけにテストを実行します。

また、どの定義がより正確ですか？

_{上記の注意点私は主にソフトウェアテストをプロセスと呼んでいます。}

ご存知のとおり、単体テスト、統合テスト、受け入れテストなど、さまざまな種類のソフトウェアテストがあります。このため、これらはすべてこれらを包括的に表す用語であり、議論として、私たちは本当に広い意味で「品質」についてのみ話すことができます。あなたは単にあなたが適用したい受容性のどんな測定値に対してもソフトウェアを検証しています。テストのさまざまなレベルとタイプでは、これらは大幅に異なり、唯一の本当の共通点は品質の側面です。

バグ（伝統的に定義されている）はソフトウェアの特定の種類の問題ですが、他にも多くの問題があります。特定のより低いレベルのテストについて説明しているのでない限り、定義をバグに限定することは意味がありません。少し遅いUIはバグですか？開発者にバスケットをWebストアに追加するように指示するのを忘れたという事実はどうですか？おそらく、混乱は「ソフトウェアテスト」と呼ばれる特定のタイプのテストで発生しますが、それは実際には単なる意味論です。

定義を形式化するように推し進められた場合、テストはソフトウェアを要件（定性的にも可能）に照らして検証するプロセスであると言えるでしょう。バグは、要件の非常に具体的な違反（具体的には、開発者がすでに正しく機能していると考えているもの）です。

編集：私はおそらく「バグ」という言葉が人々によって非常に異なる意味を持つことを付け加えるべきです、そして私達は実際にそれを定義することによってこの意味論的議論を始めるべきです。私は開発者の観点から定義を使用しています-これは私（開発者）が意図したとおりに機能しません。これは通常、非常に具体的な要件、または要件の非常に具体的な解釈に基づいています。クライアントの定義は通常似ています-これは、私（クライアント）が意図したとおりには機能しません。これは実際に非常に異なるものです。後者の定義を使用すると、クライアントの希望を満たさないものはすべて「バグ」であるため、品質とバグをほぼ同等と見なすことができます。

ダニエルBの答えから：

私は開発者の観点から定義を使用しています-これは私（開発者）が意図したとおりに機能しません。これは通常、非常に具体的な要件、または要件の非常に具体的な解釈に基づいています。クライアントの定義は通常似ています-これは私（クライアント）が意図したとおりには機能しません。これは実際に非常に異なっています。

これは基本的に、検証と検証の違いです。検証は、「私たちはそれを正しく構築しましたか？」という質問に答えます。検証は、「正しいものを構築したか？」という質問に答えます。検証テストと検証テストはかなり異なります。検証は検証よりもはるかに簡単なタスクです。検証を行うと、何をテストするかがわかります。ソフトウェアが何をすべきかを明確に示す要件（またはストーリー）です。ここに問題があります：これらの要件やストーリーが間違っているとどうなりますか？その問題をどのようにテストしますか？これが検証で対処しようとしていることです。

一部のサークルで使用されているさらに別のコンポーネントは、認定の概念です。これは、ソフトウェアを再利用するときに重要になります。例：車両のシミュレーションを構築していて、その慣性測定ユニットの適切なモデルが必要だとします。コンポーネントモデルライブラリで既存のIMUモデルを見つけます。この既存のモデルは、要件に対して徹底的に検証され、現実に対して検証されています。飛行データとの比較を含め、テストは非常に広範囲にわたっています。検証および検証済み！いいですね！そのまま再利用してください。

もう一度、多分そうではありません。そのモデルの意図された使用は静止操作であったかもしれません、あなたの使用は発射段階の間にロケットをモデル化することです。起動時のIMUの動作は、仕様の動作に近くなります。つまり、お粗末です。IMUは通常、静止動作中に仕様よりもはるかに優れています。そのモデルの使用目的が、使用目的と一致していません。再利用しない方がいい。認定の試みは、検証と検証を超えています。「これは、この特定の使用目的にとって正しいことですか？」という質問に答えます。

別の例は、アリアン5ロケットの最初の飛行試験です。フライト501の失敗につながったソフトウェアバグは、史上最も悪名高い、最も高価なソフトウェアバグの1つにランクされています。フライトソフトウェアの構築には非常に費用がかかります。これらの莫大なコストを回避するために、Ariane 5フライトソフトウェアは、Ariane 4フライトソフトウェアの大きなチャンクを再利用しました。広範囲に検証および検証されており、すでに実際の環境で使用されています。したがって、そのまま再利用してください。違う。再利用が認められているはずです。64ビットから16ビットへの変換オーバーフローを含む、「起こり得ない」と思われるイベントが発生し、結果として車両が故障しました。

ソフトウェアテストの目的は何ですか？

要するに、質問作者のコメントは、「一般に、プロセスとしてのソフトウェアテスト」です。-あなたの質問は幅広いもので、ウィキペディアの記事での定義です。

ソフトウェアテストは、テスト対象の製品またはサービスの品質に関する情報を関係者に提供するために行われる調査です。ソフトウェアテストは、ソフトウェアの客観的で独立した見方を提供し、ビジネスがソフトウェア実装のリスクを評価および理解できるようにすることもできます。

したがって、ソフトウェアテストの目的は、製品/ソフトウェアの品質に関する独立した情報を提供することです。-ソフトウェアテストのサブプロセスとその実行方法を教えてください。-別の質問です。

編集：ソフトウェアテストプロセスは、ビジネス要件に基づいて個別に提供する必要があります。それ以外の場合は、価値が低くなります。実際、大規模なソフトウェアプロジェクト（国の不動産プロジェクトなど）では、品質管理、テスト、およびソフトウェアの検証/受け入れプロセスに個別の入札が行われます。

ソフトウェアの回帰を特定するしたらすぐに。

特にユニットテストは、リグレッションを早期に特定することを目的としていますは、構築/テスト/展開チェーンのでしています

受け入れテストは、クライアントとの契約を完全に履行するためのものです。しかし、繰り返しになりますが、受け入れテストの一部がそうであるはずであるのにパスしない場合、処理する回帰を特定しました。

Glenford J. Myers著の「The Art of Software Testing」という本が最もよく定義していると思います。

「テストとは、エラーを見つける目的でプログラムを実行するプロセスです。」

彼はこの定義をいくつかの一般的な定義と対比しています：

• 「テストは、エラーが存在しないことを実証するプロセスです。」
• 「テストの目的は、プログラムが意図した機能を正しく実行することを示すことです。」
• 「テストは、プログラムが想定されていることを実行するという確信を確立するプロセスです。」

プログラムが機能することを証明しようとするのではなく、プログラムにエラーがあると想定する必要があります。ソフトウェアテストの目的は、エラーを見つけることです。そうすることで、ソフトウェアの品質が向上します。これがソフトウェアテストの究極の目的です。

@David Hammenの答えは非常によく書かれていますが、私が言ったこととまったく同じではありません。ベリフィケーションが「これを正しく作成しましたか？」と回答することに同意します。プロセスによって生成されたものはすべて検証できます。製造には、生産されているものが正しく生産されていることの継続的な検証が含まれます。

次に彼は、検証は異なると同意し、「正しいものを構築したか」と定義します。検証は反対の方向に進み、設計が正確に正しく機能していることを徹底的に確認します。「ソリューションが正しく設計されていることを客観的に示す」のようなものです。適切な等級のボルト、適切なサイズの内部変数。作品は仕事次第です。

デビッドの検証、「私たちは正しいものを構築しましたか？」高レベルの質問です。これは、毎日のビルドに対して高く評価したり低く評価したりすることはできません。要件と、それよりは少ないがデザインの判断。画面のテキストボックスやAPIのパラメーターに向けられた賢明な質問ではありません。要件を正確にするための1語の名前がわからない、おそらく要件の検証。要件がエンドユーザーのニーズに対応していることを徹底的に証明します。

対照的に、私の検証の定義は、設計の正確さの証明であり、選択された部分を示す客観的テストが効果を発揮します。Ariane IVには限られた範囲の角度レート変更があったため、Ariane Vに適さなかったAriane IVソフトウェアはここでは失敗します。コードはこの限られた範囲に合わせて最適化されており、Ariane Vはより広い範囲の角速度に対応でき、オーバーフローが発生しました。両方のオンボードコンピューターがオーバーフローでクラッシュし、自動再起動後に再度クラッシュすると、破壊システムがトリガーされました。

ディクストラが言ったように、「時期尚早の最適化はすべての悪の根源です」。

私の定義では、要件は正しく、受け入れられ、要件テストによって検証されていると想定されています。設計またはコード検証は、設計、おそらく実装の一部が正しいことを証明します。それでも正しく実行する必要がありますが、それが検証であることを確認し、承認された要件と承認された設計に基づいてテストします。

これは、開発のウォーターフォールモデルに痛烈に近づいていることに注意してください。それでもなお、要件は設計とは異なり、コードは完全に3番目のものです。ウォーターフォールの要素は有用な説明ですが、「完全」は誤解を招くので、偶然性と可変性を示唆する「承認済み」に変更しました。

ソフトウェアのテストはバグの発見を目的としたものではなく、バグの防止を目的としています。初期段階で適切なテストを行うことで、本番システムへのバグの発生を防ぎます。

テストへの投資は、「ユーザーエクスペリエンスを向上させる」ために行われていると思います。

多くの場合、バグは製品の使用に悪影響を与えないために残されます。同様に、「製品の品質を平準化する」ことも、特定の領域で作業することの有用性によって分類されます。最後に、テストの最終状態は常に主観的であるため、「出荷するのに十分良い」という基準を認識する必要があります。

優れた品質のソフトウェアとは、とりわけ、バグが0（または非常に少ない）ソフトウェアです。したがって、バグハンティングは品質を向上させるプロセスです。

すべての機能を満たすソフトウェアも優れた品質のソフトウェアであるため、機能を検証するためのテストは品質を向上させるプロセスです。

ユーザーエクスペリエンスが優れているソフトウェアは、高品質のソフトウェアなどです。

そうですね、ソフトウェアテストの目的は品質を改善することだと思います。そうすれば、バグハンティングテスト、機能の検証と検証、UIのテストなどを実行できます。