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