メニュー

例を使用した再テストと回帰テストの違い

difference between retesting

問題を排除するために楽器を試してください

再テストと回帰テストの違いは何ですか？

比較対照をテーマにした記事が好きではありませんか？私は知っています。それは、考え、コメント、そしておそらく強い意見の不一致を招くための素晴らしい方法です。

今日のトピックは、再テストと回帰テストです。

=> 完全な回帰テストシリーズについては、ここをクリックしてください。

再テストから始めましょう：

学習内容：

再テスト

再テストとは、再度テストすることを意味します。理由は関係ありません。テストを繰り返すと、再テストします。現在のバージョンの機能を再テストできます。または、バグ修正、以前のバージョンの機能、実行したばかりのテストケースなど。

再テストと回帰テスト

あなたがまだ考えているなら-なぜ-そして以下は他のものと同じくらい良いいくつかの理由です：

  • あなたは昨日テストを実行し、欠陥に遭遇しました。手順と欠陥の再現性を確認する必要があります。だから、あなたは再テストします。
  • テストを実行しました。あなたの注意はそれにありませんでした（多分あなたの電話が鳴ったか、あなたは同僚と話していたなど）。もう一度確認したいので、再テストします。

きっとあなたはそれを手に入れるでしょう。

再テストとは、何らかの理由でテストを繰り返すことです。これは、その定義に忠実な用語の1つです。

回帰テスト

ソフトウェアは進化します。既存のものよりも新しいバージョンがあります。新しい機能や拡張機能などが山積みになっています。しかし、時間の経過とともに、これはアプリケーションの不安定性につながる可能性があります。

1つのブロックを他のブロックの上に追加して、ブロックタワーを作成することを想像してみてください。基盤を強化したり強化したりするのに時間をかけません。塔が墜落するまでそう長くはかからないでしょう？

Webアプリケーション侵入テストの面接の質問

そのように、ソフトウェアのベースの強度と安定性をテストする必要があります。

そのためには、ソフトウェアを再テストする必要があります。それが唯一の方法です。

推奨読書=> 回帰テストとは何ですか？ツールとベストプラクティス

回帰は再テストの一形態です。 「なぜ」と「いつ」の詳細が前者との違いです。

1） いつ 再テストしていますか？ソフトウェアが変更されたとき

二） なぜ 再テストしていますか？新しい追加/変更によって、作業前の機能が不安定にならないようにするため。回帰は一般的であり、次の場合に推奨されます。

  • 新しいバージョンが利用可能になります。 （すべて、または少なくとも古いバージョンの機能の重要な機能を回帰します）
  • バグ修正

注意点： 望ましいとはいえ、徹底的な回帰テストは不可能です。

そういうわけで 回帰分析 テストに直接飛び込む前に。このステップでは、アプリケーションに対してどの程度のリグレッションを実行する必要があるかを決定します。

回帰の程度は何に依存しますか？

  • 変化の性質
  • 現在のシステム/機能に対する変更の関係/影響
  • 利用可能な時間とリソース

テスターはどのようにして回帰の程度を判断できますか？

1） アプリケーションの経験と知識を通じて

二） 開発者と話し合う

3） 変更が加えられた場所。例えば：ホームページにある場合は、アクセスの少ないページの1つにある場合よりも注意が必要です。

プレイ中の要因に応じて、テストチームは次のいずれかに進むことができます。

  • ユニット回帰
  • 部分的な回帰
  • 完全な回帰

ユニット回帰 アプリケーションの変更されたモジュール/領域のみを再テストすることを意味します。

部分回帰とは 変更したモジュールを再テストします。さらに、それと相互作用するものも含まれます。

完全回帰 変更の場所に関係なく、アプリケーション全体をテストしますか。

これは、状況（時間とリソースの可用性）、変更の重大度（影響）、開発者の入力などによって異なります。適切なテストセットを選択すると、すべてのテストよりも効率的になります。

Javaで二重リンクリストを作成する方法

回帰分析は重要な成功要因です。ハードワークではなくスマートワークが必要です。

回帰テストに関する誤解

回帰テストについては多くの誤解があります。

＃1）回帰は常に自動化によって行われます。 いいえ。回帰も手動で行われます。これに関する記事全体があります=> 回帰テストはどのように実行されますか？手動で行うことはできますか？

回帰は自動化の完璧な候補であることに注意してください。繰り返しの程度は時間がかかり、退屈につながる可能性があります。また、重要な検証が見落とされる可能性があります。自動化は、信頼性が高く、高速で効率的な代替手段です。

また読む=> 自動回帰テストの課題

＃2）回帰は決して完全ではありません ：本当。しかし、完全ではありません。

つまり、徹底的な回帰テストは不可能かもしれません。ただし、徹底的な回帰テストも不要な場合があります。

ホームページのスペルミスを変更したとしましょう。この修正はマイナーです。また、アプリケーションの他の領域からも分離されています。したがって、機能を簡単に再テストするだけで十分です。ホームページ周辺の以前の機能を回帰する必要はありません。

＃3）不要です 時間に余裕があるとき ： 違います。十分な回帰がないと、製品に対する信頼が失われます。さまざまなエンドユーザーシナリオへの反応から何を期待できるかはわかりません。

＃4）以前のリリースのすべてのテストケースを実行しています。 繰り返しますが、すべてのテストケースを選択することはこれを行う正しい方法ではありません。テストケースの戦略的な選択が鍵となります。変更を理解し、フィッティングテストケースを選択します。

OK、それは詳細に再テストと回帰テストです。

さて、比較。

再テストと回帰テスト

それらについては何が同じですか？

  • それらは両方とも繰り返しベースです
  • 検証と ブラックボックステスト手法
  • 自動化または手動のテストケースの両方が再テストまたはリグレッションされます
  • 「彼の疑念を検証または排除し、それらをイエスまたはノーの確実性に変換する必要があります-トーマス・カーライル」。それらの両方がこれを行います。

それらの違いは何ですか？

  • 再テストは、すべてのテストに適用できます–現在または以前のバージョンの機能が対象です。リグレッションは、以前のバージョンの機能中心です。
  • 再テストは、該当する変更に依存しません。回帰は変化指向です。

最後に、この概念を家に持ち帰るには：

ID 120の欠陥が発生したテストケースXYZがあるとします。この欠陥は、次のリリースで修正されます。 XYZテストケースを再テストし、その周りの機能を回帰します。リグレッションは、120の修正後にすべてが無傷で機能していることを確認することです。再テストは、欠陥の修正を判別することです。

ですから、どちらでもありませんが 動的デュオを形成する回帰と再テストの組み合わせ 。

さて、それはあなた次第です。ここに記載されている定義と分析に同意しますか？

著者について： この記事はSTHチームメンバーのSwatiSによって書かれました。

テストケースをどのように作成しますか

これについてのあなたの考え、コメント、質問は何ですか？ぜひ共有してください。皆さんとつながりたいと思います。

=> 完全な回帰テストシリーズについては、こちらをご覧ください。

推奨読書

^