unit-testing - 人気があり、一見矛盾するように見える 2 つの説明を使用して、機能テストをどのように定義しますか?

Question

私は機能テストの定義を調査してきましたが、具体的な説明に出くわすことができず、これを調整するのに役立つ追加情報をいただければ幸いです。

私が遭遇した2つの主なアイデアは次のとおりです。

1. テスト タイプとしての機能テストであり、ユニット テスト、統合テスト、システム テスト、受け入れテストのテスト レベルで構成されます。

2. 単体テストおよび統合テストとは別のレベルとしての機能テスト (システム テストのサブセットが先行する場合もある) は、ブラック ボックス アプローチを使用して製品をエンドツーエンドでテストします。目的は、定義されたすべての機能仕様を検証することです。

Answer 1

さまざまな種類のテスト分類についてです。
ケース 1 では、機能テストと非機能テストを分離しました。どのようなケースがテストされるか
についてのこの分類: - 機能シナリオでは、どのシステムが実行できるかをチェックし、それが要件を満たしているかどうかを確認します。例: ユーザーは Facebook 経由で認証できますか。 - 機能しないシナリオでは、システムがどのように動作するかを確認します: 十分に安全ですか? 明確でシンプルですか (UX、使いやすさなど)? 最適化とパフォーマンスはどうですか?

ケース 2 では、分離レベルに基づいて分離されました。製品のどの部分がテスト
されるか に関するこの分類: 個別のコード モジュール、2 つのサービスの統合、または製品全体をテストしますか? この分類では、機能テストは、単一のビジネス シナリオ (ユーザー機能) のテストを行う場合の抽象化のレベルに関するものです。