8

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

望ましい戦略は、各ユニットを一度に 1 つずつ導入し、大規模な回帰テストを実行し、欠陥を修正してから次のユニットに進むことです。

同じ文書には次のようにも書かれています。

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

スモークテストについて説明するとき、著者は次のように述べています。

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

「広範な」テストと「回帰テスト」が一緒に使用されているのを見たことがなく、「システム全体を完全に回帰テストする」と説明されている回帰テストも見たことがありません。リグレッション テストは、可能な限り軽量かつ迅速に行う必要があります。そして、スモーク テストの定義は、回帰テストが何であるかを私が学んだものです。

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

4

8 に答える 8

5

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

于 2008-10-30T19:41:22.437 に答える
5

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

「壊れる可能性がある場合は、テストしてください」という経験則がここに適用されます。の変更Fooが に影響Barを与える可能性がある場合は、両方の回帰を実行してください。

回帰テストは、以前に合格したテストが失敗した変更が原因であるかどうかを確認するだけです。任意のレベル (ユニット、統合、システム) で実行できます。 参照。

于 2008-10-30T16:17:17.060 に答える
1

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

于 2008-10-30T16:22:32.943 に答える
1

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

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

于 2008-10-30T16:23:36.017 に答える
1

「回帰テスト」という用語についての私の理解は次のとおりです。

  • 単体テストは、システムの作成時に機能をテストするために作成されます
  • バグが発見されると、バグを再現して修正されたことを確認するために、さらに単体テストが作成されます。
  • 回帰テストでは、一連のテスト全体が実行され、古いバグが再発していないことを含め、すべてがまだ機能していることを証明します [つまり、コードが「後退」していないことを証明します]

実際には、変更が加えられた場合は、既存のすべての単体テストを常に実行することをお勧めします。テストのサブセットを気にするのは、完全な単体テスト スイートの実行に「時間がかかりすぎる」ときだけです [「長すぎる」というのはかなり主観的なものです]。

于 2008-10-30T17:13:36.290 に答える
0

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

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

于 2008-10-30T17:31:24.677 に答える
0

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

于 2008-10-30T17:16:52.820 に答える
0

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

「広範な回帰テスト」に言及している記事は、(個別に単純な) 回帰テストの広範なセットを実行することを意味していると思います。

于 2008-10-30T18:34:24.660 に答える