受け入れテストと機能テストの本当の違いは何ですか？
それぞれのハイライトまたは目的は何ですか？私が読んだところはどこでも、それらはあいまいに似ています。
117356 次
11 に答える
183
私の世界では、次のように用語を使用します。
機能テスト: これは検証作業です。正しく動作する製品を構築しましたか? ソフトウェアはビジネス要件を満たしていますか?
このタイプのテストには、考えられるすべてのシナリオをカバーするテスト ケースがあります。たとえそのシナリオが「現実の世界」に存在する可能性が低いとしてもです。この種のテストを行うときは、最大のコード カバレッジを目指します。その時点で取得できる任意のテスト環境を使用します。使用可能である限り、「実稼働」レベルである必要はありません。
受け入れテスト: これは検証活動です。私たちは正しいものを作りましたか？これは顧客が本当に必要としているものですか？
これは通常、顧客と協力して行うか、社内の顧客代理人 (製品所有者) によって行われます。このタイプのテストでは、ソフトウェアが使用されると予想される典型的なシナリオをカバーするテスト ケースを使用します。このテストは、お客様が使用するハードウェアと同じ、またはそれに近いハードウェア上で、「本番環境に似た」環境で実施する必要があります。これは、「知能」をテストするときです。
信頼性、可用性: ストレステストにより検証済み。
スケーラビリティ: 負荷テストにより検証済み。
ユーザビリティ: 顧客への検査およびデモンストレーションによって検証されます。UI は好みに合わせて構成されていますか? 顧客のブランディングを適切な場所に配置しましたか? 彼らが要求したすべてのフィールド/画面がありますか?
セキュリティ (別名、セキュラビリティ、単に適合) : デモンストレーションで検証済み。場合によっては、顧客が外部の会社にセキュリティ監査や侵入テストを依頼することがあります。
保守性 : ソフトウェアの更新/パッチを提供する方法のデモンストレーションによって検証されます。
構成可能性 : お客様がニーズに合わせてシステムを変更する方法のデモンストレーションによって検証されます。
これは決して標準ではなく、ここで矛盾する回答が示すように、「標準」の定義はないと思います。組織にとって最も重要なことは、これらの用語を正確に定義し、それらに固執することです。
于 2010-07-30T11:55:45.617 に答える
78
パトリック・カフの答えが好きです。私が追加したいのは、 テストレベルとテストタイプの違いです。これは私にとって目を見張るものでした。
テストレベル
テスト レベルはV モデルを使用して簡単に説明できます。たとえば、
各テスト レベルには対応する開発レベルがあります。これには典型的な時間特性があり、開発ライフ サイクルの特定の段階で実行されます。
- コンポーネント/ユニットテスト => 詳細設計の検証
- コンポーネント/ユニット統合テスト => グローバル設計の検証
- システムテスト => システム要件の検証
- システム統合テスト => システム要件の検証
- 受け入れテスト => ユーザー要件の検証
テストの種類
テスト タイプは特性であり、特定のテスト目的に焦点を当てています。テスト タイプは、技術的側面または非機能的側面とも呼ばれる品質面を強調します。テスト タイプ は、どのテスト レベルでも実行できます。ISO/IEC 25010:2011 で言及されている品質特性をテスト タイプとして使用するのが好きです。
- 機能テスト
- 信頼性試験
- 性能試験
- 操作性試験
- セキュリティテスト
- 互換性テスト
- 保守性テスト
- 転送可能性テスト
それを完成させるために。回帰テストと呼ばれるものもあります。これは、テスト レベルとテスト タイプの次の特別な分類です。リグレッション テストは、製品の重要な部分に触れるため、繰り返したいテストです。実際には、各テスト レベルに対して定義したテストのサブセットです。製品に小さなバグ修正がある場合、すべてのテストを繰り返す時間が常にあるとは限りません。回帰テストはそれに対する答えです。
于 2014-06-12T14:34:03.067 に答える
28
違いは、問題をテストすることと解決策をテストすることです。ソフトウェアは問題の解決策であり、どちらもテストできます。
機能テストでは、問題を解決した方法の境界内でソフトウェアが機能を実行することを確認します。これは、大量生産された製品が工場から出荷される前に行われるテストに匹敵する、ソフトウェア開発の不可欠な部分です。機能テストでは、開発者が考えているとおりに製品が実際に機能することを確認します。
受け入れテストは、製品が実際に解決するように作られた問題を解決することを検証します。これは、ソフトウェアが支援するタスクを実行するなど、ユーザー (顧客) が行うのが最適です。ソフトウェアがこの実際のテストに合格した場合、以前のソリューションを置き換えることが認められます。この受け入れテストは、特に匿名の顧客 (Web サイトなど) がいる場合、本番環境でのみ適切に実行できる場合があります。したがって、新しい機能は、数日または数週間の使用後にのみ受け入れられます。
機能テスト- 製品をテストし、設計または構築した品質 (機能、速度、エラー、一貫性など) があることを確認します。
受け入れテスト- 製品をそのコンテキストでテストします。これには、人間の相互作用 (のシミュレーション) が必要です。元の問題に対して望ましい効果があるかどうかをテストします。
于 2011-11-20T21:57:03.240 に答える
14
答えは意見です。私は多くのプロジェクトで働いており、テストマネージャーとイシューマネージャーであり、さまざまな役割とさまざまな本の説明が異なるため、ここに私のバリエーションがあります。
機能テスト：ビジネス要件を取得し、機能の観点からすべてを適切かつ徹底的にテストします。
受け入れテスト：「有料」の顧客は、納品された製品を受け入れることができるように、好きなテストを行います。顧客によって異なりますが、特に社内プロジェクトの場合、利害関係者が初期のテストフェーズで行われたテスト結果を確認して信頼するため、通常、テストは機能テストほど徹底的ではありません。
私が言ったように、これは私の視点と経験です。機能テストは体系的であり、受け入れテストはむしろビジネス部門が物事をテストすることです。
于 2010-07-30T09:55:16.490 に答える
9
観客。機能テストは、ソフトウェアを作成しているチームのメンバーが期待どおりに動作することを保証することです。受け入れテストは、消費者のニーズを満たしていることを保証することです。
範囲。機能テストでは、一度に 1 つのコンポーネントの機能のみをテストします。受け入れテストは、ソフトウェアを受け入れる前にテストするのに十分消費者にとって重要な製品のあらゆる側面を対象としています (つまり、受け入れ可能性を判断するためにテストするのにかかる時間や費用に見合うもの)。
ソフトウェアは、機能テスト、統合テスト、およびシステム テストに合格できます。機能がニーズを満たしていないことを顧客が発見した場合にのみ、受け入れテストに失敗します。これは通常、誰かが仕様を台無しにしたことを意味します。ソフトウェアがいくつかの機能テストに不合格になることもありますが、受け入れテストに合格することもあります。これは、ソフトウェアが必要なコア機能を適切に実行している限り、顧客がいくつかの機能的なバグに対処することをいとわないためです (ベータ ソフトウェアは、多くの場合、ベータ版ソフトウェアがリリースされる前に一部のユーザーに受け入れられます)。完全に機能します）。
于 2010-11-30T19:46:14.650 に答える
2
機能テスト:最終的なプログラム構造に関係なく、指定された機能要件から派生したテスト データの適用。ブラックボックステストとも呼ばれます。
受け入れテスト:システムが受け入れ基準を満たしているかどうかを判断するために実施される正式なテスト。これにより、エンド ユーザーはシステムを受け入れるかどうかを判断できます。
于 2010-10-26T08:38:03.440 に答える
1
検収試験：
...は、システム（ソフトウェア、製造された機械部品のロット、化学製品のバッチなど）で、納品前に実行されるブラックボックステストです。
これは続けて言うが：
これは、機能テスト、ブラックボックステスト、リリース受け入れ、QAテスト、アプリケーションテスト、信頼性テスト、最終テスト、検証テスト、または工場受け入れテストとも呼ばれます。
「引用が必要」のマークが付いています。
機能テスト（実際にはシステムテストにリダイレクトされます）：
システムが指定された要件に準拠しているかどうかを評価するために、完全な統合システムで実施されます。システムテストはブラックボックステストの範囲内にあるため、コードやロジックの内部設計に関する知識は必要ありません。
したがって、この定義から、それらはほとんど同じものです。
私の経験では、受け入れテストは通常、機能テストのサブセットであり、顧客による正式なサインオフプロセスで使用されますが、機能/システムテストは開発者/QA部門によって実行されます。
于 2010-07-30T09:54:55.880 に答える
1
受け入れテストは、クライアントによって実行されるテストであり、他の種類のテストが含まれます。
- 機能テスト:「このボタンは機能しません」
- 非機能テスト:「このページは機能しますが、遅すぎます」
機能テストと非機能テスト (そのサブタイプ) については、このSO の質問に対する私の回答を参照してください。
于 2016-08-20T10:42:50.483 に答える
1
私の見解では、主な違いは、テストが成功するか失敗するかを誰が判断するかです。
機能テストは、システムが事前定義された要件を満たしていることをテストします。これは、システム開発の責任者によって実行およびチェックされます。
受け入れテストは、ユーザーによって承認されます。ユーザーがテストしたいことを言うのが理想的ですが、実際には、ユーザーが十分な時間を費やさないため、機能テストが終了する可能性があります。このビューは、私が扱っている他の一連のユーザーのビジネス ユーザーからのものであることに注意してください。
于 2010-07-30T09:53:47.013 に答える
0
両者の関係: 通常、受け入れテストには機能テストが含まれますが、追加のテストが含まれる場合もあります。たとえば、ラベリング/文書化の要件を確認します。
機能テストは、テスト対象のデバイスの応答を調べながら、ターゲット環境が通常生成するもの、またはそれを超えるさまざまな刺激 (テストの範囲内) を生成できるテスト環境に製品を配置することです。
物理的な製品 (ソフトウェアではない) の場合、受け入れテストには、設計テストと製造テストの 2 つの主要な種類があります。通常、設計テストでは、製造テストに合格した多数の製品サンプルが使用されます。さまざまな消費者がさまざまな方法でデザインをテストする場合があります。
受け入れテストは、設計が製品仕様に対してテストされる場合の検証と呼ばれ、受け入れテストは、製品が消費者の実際の環境に置かれる場合の検証と呼ばれます。
于 2015-06-02T21:21:37.437 に答える
-1
それらは同じものです。
受け入れテストは、システムが展開または配信される前に、実際の実稼働/展開環境と可能な限り同一で、完成したシステムに対して実行されます。
自動または手動で受け入れテストを行うことができます。
于 2010-07-30T09:55:25.903 に答える