回帰テストは、テストスイート全体またはテストのサンプルですか？

Question

回帰テストは、全体的なテストの小さなサンプル（変更または新しいモジュールの導入で何も破られなかったことを証明するのに十分なだけ）であると教えられました。ただし、Ron MorrisonとGrady Boochによるこの記事では、考えが異なります。

  

望ましい戦略は、各ユニットを一度に1つずつ持ち込み、広範な回帰テストを実行し、欠陥を修正してから次のユニットに進むことです。

同じドキュメントには次のようにも書かれています：

  

少数のユニットが追加されるとすぐに、テストバージョンが生成され、「煙のテスト」、統合製品が期待どおりに機能するという確信を得るために、少数のテストが実行されます。その目的は、新しいユニットを徹底的にテストすることでも、システム全体を完全に回帰テストすることでもありません。

煙のテストについて説明するとき、著者はこう言います：

  

Smoke Testは、新しいコンポーネントだけでなく、システム全体のクイックチェックを実行することも重要です。

＆quot; extensive＆quot;を見たことがないおよび「回帰テスト」 「システム全体の完全な回帰テスト」として説明されている回帰テストも一緒に使用されます。回帰テストは、できるだけ軽くて迅速であると想定されています。そして、煙テストの定義は、回帰テストが学んだことです。

教えられたことを誤解しましたか？私は間違って教えられましたか？または、「回帰テスト」の解釈が複数ありますか？

Answer 1

複数の解釈があります。システムの一部に影響するバグのみを修正する場合、回帰テストには、問題のクラスまたはパッケージを実行するテストの小さなスイートのみが含まれる場合があります。バグを修正するか、より広いスコープを持つ機能を追加する場合、回帰テストもより広いスコープを持つ必要があります。

「破損する可能性がある場合はテストする」ここで経験則が適用されます。 Foo の変更が Bar に影響する可能性がある場合は、両方の回帰を実行します。

回帰テストは、変更によって以前に合格したテストが失敗したかどうかを確認するだけです。任意のレベル（ユニット、統合、システム）で実行できます。 リファレンス。

Answer 2

既存の機能が新しい変更によって破損しないことを確認することを目的としたテストを意味するために、常に回帰テストを実施しました。これは、テストスイートのサイズに対する制約を意味するものではありません。

Answer 3

回帰は通常、テストスイート全体を指すために使用されます。 QAがリリース前に行う最後の作業です。表示できる範囲で、以前は機能していたすべてのものがまだ機能していることを示すために使用されます。私の経験では、変更がどれほど小さいかに関係なく、通常はシステム全体のテストのセットです（ただし、小さな変更でも回帰テストがトリガーされない場合があります）。

Answer 4

私が働いているところでは、回帰テストは各リリースの終わりにアプリケーションごとに標準化されています。すべての機能をテストすることを目的としていますが、微妙なバグをキャッチするようには設計されていません。たとえば、さまざまな種類の検証が行われているフォームがある場合、そのフォームの回帰スイートは、各タイプの検証が実行されたこと（フィールドレベルとフォームレベル）を確認し、正しい情報を送信できることを確認します。すべてのケースをカバーするようには設計されていません（つまり、フィールドAを空白のままにするとどうなりますか？フィールドBについてはどうでしょうか？

しかし、私が取り組んでいる現在のプロジェクトでは、回帰テストがはるかに徹底的であり、テスト中に発生する欠陥の数が減少していることがわかりました。これら2つは必ずしも関連しているわけではありませんが、かなり一貫して気づいています。

Answer 5

「回帰テスト」という用語の理解：

• 単体テストは、システムの作成時に機能をテストするために作成されます
• バグが発見されると、バグを再現し、修正されたことを確認するためのユニットテストがさらに作成されます
• 回帰テストを実行すると、テストセット全体が実行され、古いバグが再現されていないことを含め、すべてが引き続き機能することが証明されます（つまり、コードが「回帰」していないことを証明するために]

実際には、変更が行われたときは常に既存のすべての単体テストを実行するのが最善です。テストのサブセットに悩むのは、完全な単体テストスイートが「長すぎる」ときだけです。実行するには[where＆quot; too long＆quot ;;かなり主観的です

Answer 6

達成しようとしていることから始めます。次に、その目標を達成するために必要なことを行います。次に、buzzword bingoを使用して、実際に行っていることに単語を割り当てます。他のみんなと同じように:-)精度はそれほど重要ではありません。

Answer 7

  

...回帰テストは、全体的なテストの小さなサンプル（変更または新しいモジュールの導入で何も破られなかったことを証明するのに十分）でした

テストの小さなサンプルでシステムが機能することを証明するのに十分な場合、残りのテストが存在するのはなぜですか？そして、あなたの変更が機能のサブセットにのみ影響することを知っていると思うなら、なぜあなたは変更を行った後に何かをテストする必要があるのですか？人間は誤りやすいので、何かを変更しても他の何かが壊れるかどうかは、誰にもわかりません。 IMO、テストが自動化されている場合、すべてを再実行します。自動化されていない場合は、自動化します。それまでの間、自動化されたものはすべて再実行してください。

Answer 8

一般に、製品のバージョンXで導入された新しい機能の機能テストのサブセットは、バージョンX + 1、X + 2などの回帰テストの基礎になります。時間が経つにつれて、回帰の影響を受けていない安定した機能の機能/回帰テストにかかる時間を短縮できます。機能が多くのリグレッションに苦しんでいる場合、機能の強調を増やすことが有益な場合があります。

「広範な回帰テスト」に言及している記事は、広範な（個々に単純な）回帰テストを実行することを意味すると思います。