受け入れテストと機能テストの違いは何ですか？
回答:
私の世界では、次のような用語を使用しています。
機能テスト：これは検証アクティビティです。正しく機能する製品を作成しましたか？ソフトウェアはビジネス要件を満たしていますか？
このタイプのテストには、「現実の世界」にシナリオが存在する可能性が低い場合でも、考えられるすべてのシナリオをカバーするテストケースがあります。このタイプのテストを行う場合、最大のコードカバレッジを目指します。現時点で入手可能なテスト環境を使用します。使用可能であれば、「本番」の能力である必要はありません。
受け入れテスト：これは検証アクティビティです。私たちは正しいものを構築しましたか？これはお客様が本当に必要としているものですか？
これは通常、顧客と協力して、または内部顧客プロキシ（製品所有者）によって行われます。このタイプのテストでは、ソフトウェアの使用が想定される一般的なシナリオをカバーするテストケースを使用します。このテストは、顧客が使用するものと同じか、またはそれに近いハードウェアで、「本番に似た」環境で実行する必要があります。これは、私たちが "ilities"をテストするときです。
信頼性、可用性：ストレステストで検証済み。
スケーラビリティ：負荷テストによって検証されています。
ユーザビリティ：検査とお客様へのデモンストレーションによって検証されます。UIは好みに合わせて設定されていますか？顧客のブランドを適切な場所に配置しましたか？彼らが求めたすべてのフィールド/画面はありますか？
セキュリティー （別名、セキュリティ、適合性）：デモンストレーションにより検証済み。時々、顧客はセキュリティ監査や侵入テストを行うために外部の会社を雇うでしょう。
保守性：ソフトウェアの更新/パッチをどのように提供するかをデモンストレーションすることで検証されています。
構成可能性：お客様がニーズに合わせてシステムを変更する方法のデモを通じて検証されています。
これは決して標準ではありません。ここで矛盾する答えが示すように、「標準」の定義があるとは思いません。組織にとって最も重要なことは、これらの用語を正確に定義し、それらに固執することです。
パトリックカフの答えが好きです。追加したいのは、テストレベルとテストの種類の違い でした。
テストレベル
テストレベルは、Vモデル（例）を使用して簡単に説明できます。
各テストレベルには、対応する開発レベルがあります。これには典型的な時間特性があり、開発ライフサイクルの特定のフェーズで実行されます。
- コンポーネント/ユニットテスト=>詳細設計の検証
- コンポーネント/ユニット統合テスト=>グローバル設計の検証
- システムテスト=>システム要件の確認
- システム統合テスト=>システム要件の確認
- 受け入れテスト=>ユーザー要件の検証
テストの種類
テストの種類が特徴で、それは特定のテストの目的に焦点を当てています。テストタイプは、技術的側面または非機能的側面としても知られる品質の側面を強調します。テストタイプ は、どのテストレベルでも実行できます。ISO / IEC 25010：2011に記載されている品質特性をテストタイプとして使用したい。
- 機能テスト
- 信頼性試験
- 性能試験
- 操作性テスト
- セキュリティテスト
- 互換性テスト
- 保守性テスト
- 転移性試験
それを完全にするために。回帰テストと呼ばれるものもあります。これは、テストレベルとテストタイプの横にある追加の分類です。回帰テストは、あなたがそれはあなたの製品の重要な何かに触れたので、リピートしたいテストです。実際には、各テストレベルに対して定義したテストのサブセットです。製品に小さなバグ修正がある場合、すべてのテストを繰り返す時間が常にあるとは限りません。回帰テストはその答えです。
違いは、問題のテストと解決策のテストです。ソフトウェアは問題の解決策であり、どちらもテストできます。
機能テストは、ソフトウェアが問題を解決した方法の範囲内で機能を実行することを確認します。これはソフトウェアの開発に不可欠な部分であり、工場出荷前に大量生産された製品に対して行われるテストに匹敵します。機能テストでは、製品（開発者）が実際に機能していることを確認します。
受け入れテストは、製品が実際に解決するために作成された問題を解決することを確認します。これは、ソフトウェアが支援するタスクを実行するなど、ユーザー（顧客）が最適に実行できます。ソフトウェアがこの実世界のテストに合格すると、以前のソリューションを置き換えることが受け入れられます。この受け入れテストは、特に匿名の顧客（ウェブサイトなど）がある場合は、本番環境でしか正しく実行できない場合があります。したがって、新しい機能は数日または数週間の使用後にのみ受け入れられます。
機能テスト -製品をテストし、設計または構築した品質（機能、速度、エラー、一貫性など）があることを確認します
受け入れテスト -そのコンテキストで製品をテストします。これには、人間の相互作用（のシミュレーション）が必要です。元の問題に望ましい効果があることをテストします。
答えは意見です。私は多くのプロジェクトで働いており、testmanagerとissuemanagerであり、すべての異なる役割とさまざまな本の説明が異なるため、ここに私のバリエーションを示します。
機能テスト：ビジネス要件を取り、機能の観点からすべてを適切かつ徹底的にテストします。
受け入れテスト：「有料」の顧客は、提供された製品を受け入れることができるように、好きなテストを行います。それは顧客に依存しますが、通常、特に社内プロジェクトの場合、テストは機能テストほど徹底的ではありません。関係者は以前のテストフェーズで行われたテスト結果をレビューして信頼するためです。
私が言ったように、これは私の見方と経験です。機能テストは体系的であり、受け入れテストはむしろ事をテストするビジネス部門です。
聴衆。機能テストは、ソフトウェアを作成しているチームのメンバーが期待どおりに機能することを確認することです。受け入れテストは、それが彼らのニーズを満たしていることを消費者に保証することです。
範囲。機能テストでは、一度に1つのコンポーネントの機能のみをテストします。受け入れテストは、ソフトウェアを受け入れる前にテストするのに十分な、消費者にとって重要な製品のあらゆる側面（つまり、ソフトウェアが受け入れ可能かどうかをテストするためにテストするのにかかる時間またはお金に見合うもの）をカバーします。
ソフトウェアは、機能テスト、統合テスト、およびシステムテストに合格できます。お客様が機能がニーズを満たさないことに気付いた場合にのみ、受け入れテストに不合格になります。これは通常、誰かが仕様をめちゃくちゃにしたことを意味します。ソフトウェアも一部の機能テストに失敗する可能性がありますが、ソフトウェアが許容できるほどコアとなる機能をソフトウェアが適切に実行する限り、顧客はいくつかの機能バグに対処する意思があるため、受け入れテストに合格します（ベータソフトウェアは、その前にユーザーのサブセットによって受け入れられることがよくあります）完全に機能しています）。
機能テスト：最終的なプログラム構造に関係なく、指定された機能要件から派生したテストデータの適用。ブラックボックステストとも呼ばれます。
受け入れテスト：システムがその受け入れ基準を満たしているかどうかを判断するために行われる正式なテスト—エンドユーザーがシステムを受け入れるかどうかを判断できるようにします。
私の見解では、主な違いは、テストが成功したか失敗したかをだれが言うかです。
システムが事前定義された要件を満たしていることを機能テストがテストします。システムの開発責任者が実施、確認します。
受け入れテストはユーザーがサインオフします。理想的には、ユーザーがテストしたいものを言うでしょうが、実際には、ユーザーが十分な時間を費やしていないため、機能テストの日没になる可能性があります。このビューは、私が他のユーザーセットと取引しているビジネスユーザーからのものであることに注意してください。
...は、納入前にシステム（ソフトウェア、多数の製造された機械部品、化学製品のバッチなど）で実行されるブラックボックステストです。
これは言い続けますが：
機能テスト、ブラックボックステスト、リリース承認、QAテスト、アプリケーションテスト、信頼性テスト、最終テスト、検証テスト、または工場承認テストとしても知られています
「引用が必要」のマークが付いています。
機能テスト（実際にはシステムテストにリダイレクトします）：
指定された要件へのシステムのコンプライアンスを評価するために、完全な統合システムで実施されました。システムテストはブラックボックステストの範囲に含まれるため、コードやロジックの内部設計に関する知識は必要ありません。
したがって、この定義から、それらはほとんど同じものです。
私の経験では、受け入れテストは通常機能テストのサブセットであり、顧客による正式なサインオフプロセスで使用されますが、機能/システムテストは開発者/ QA部門が実行するテストです。
2つの関係：受け入れテストには通常、機能テストが含まれますが、追加のテストが含まれる場合もあります。たとえば、ラベル/ドキュメントの要件を確認します。
機能テストとは、テスト対象のデバイスの応答を調べながら、テスト対象の製品を、テスト環境の範囲内でさまざまな刺激を生成できるテスト環境に配置して、ターゲット環境が通常生成するものまたはそれを超えるものです。
ソフトウェアではなく物理的な製品の場合、受け入れテストには2つの主要な種類があります。。設計テストと製造テストです。設計テストでは通常、製造テストに合格した多数の製品サンプルを使用します。さまざまな消費者がさまざまな方法でデザインをテストできます。
受け入れテストは設計が製品仕様に対してテストされるときの検証と呼ばれ、受け入れテストは製品が消費者の実際の環境に置かれるときの検証と呼ばれます。
彼らは同じものです。
受け入れテストは、システムが展開または配信される前に、実際の本番環境/展開環境と可能な限り同じように完成したシステムで実行されます。
自動または手動で受け入れテストを実行できます。