再テストと回帰テストの違いは何ですか：
あなたはすべての比較とコントラストをテーマにした記事を愛 分かってる それは思考、コメントおよび多分、強い不一致を誘う非常に大きい方法である。
今日のトピックは、再テストと回帰テストです。
=> 完全な回帰テストシリーズはこちらをクリックしてください。
再テストから始めましょう:
再テスト
再テストは、再びテストすることを意味します。 理由は問題ではありません。 テストを繰り返すと、再テストが行われます。 現在のバージョンの機能を再テストできます。 または、バグ修正、以前のバージョンの機能、実行したばかりのテストケースなど。
あなたはまだ考えている場合-なぜ-その後、以下は、任意のと同じくらい良いいくつかの理由:
- あなたは昨日テストを実行し、欠陥に遭遇しました。 ステップと欠陥の再現性を確認したいとします。 だから、あなたは再テスト。
- あなたはテストを実行しました。 あなたの注意はそれになかった（多分あなたの電話が鳴った、またはあなたが同僚に話していた、など). もう一度確認したいので、再テストします。
きっと分かるだろう。
再テストは、何らかの理由でテストを繰り返したときです。 それはその定義に忠実であるそれらの用語の一つです。
回帰テスト
ソフトウェアが進化します。 既存のものよりも新しいバージョンがあるでしょう。 新機能、拡張機能などの上に積み重ねがあります。 しかし、時間の経過とともに、これはアプリケーションの不安定さにつながる可能性があります。
一つのブロックを他のブロックの上に追加することによって、ブロックタワーを作ることを想像してみてくださ 基盤を補強するか、または増強するのに時間をかけない。 タワーがクラッシュする前に、それは長くはないでしょうか？
それと同じように、ソフトウェアのベースの強度と安定性をテストする必要があります。
これを行うには、ソフトウェアを再テストする必要があります。 それが唯一の方法です。
推奨読み取り=>回帰テストとは何ですか？ ツールとベストプラクティス
回帰は再テストの一形態です。 「なぜ」と「いつ」の詳細は、それを前者と区別するものです。
1) 再テストはいつですか？ ソフトウェアが変更を受けるとき
2)なぜ再テストするのですか？ 新しい追加/変更を確実にするために、作業前の機能が不安定になっていません。 回帰は一般的であり、次の場合に推奨されます:
- 新しいバージョンが利用可能になります。
- バグ修正
注意点：網羅的な回帰テストは不可能ですが、望ましいことです。
だから、テストに直接ジャンプする前に回帰分析を行うのです。 このステップでは、アプリケーションでどの程度の回帰を行うべきかを決定します。
回帰の程度は何に依存していますか？
- 変更の性質
- 関係/変更が現在のシステムに与える影響/機能
- 利用可能な時間とリソース
テスターは回帰の程度をどのように決定できますか？
1)アプリケーションの経験と精通を通じて
2)開発者との議論
3)変更が行われた場所。 例えば: それがホームページ上にある場合、それはアクセスの少ないページのいずれかにあった場合よりも多くの注意が必要です。
プレイ中の要因に応じて、テストチームは次のいずれかのために行くことができます:
- ユニット回帰
- 部分回帰
- 完全回帰
ユニット回帰とは、アプリケーションの変更されたモジュール/領域のみを再テストすることを意味します。
部分回帰は、変更されたモジュールを再テストすることを意味します。 プラスそれと相互に作用するそれらを含んで下さい。
完全回帰は、変更の場所に関係なく、アプリケーション全体をテストすることです。
状況（時間&リソースの可用性）、変更の深刻さ（その影響）、開発者の入力などによって異なります。 適切なテストセットとすべてのテストを選択すると、より効率的になります。
回帰分析は重要な成功要因です。 それはハードワークよりもむしろスマートな仕事を必要とする。
回帰テストに関する誤解
回帰テストについて多くの誤解があります:
#1)回帰は常に自動化を介して行われます:いいえ。 回帰も手動で行われます。 私たちはこれに関する記事全体を持っています=>回帰テストはどのように実行されますか？ 手動で行うことはできますか？
回帰は自動化のための完璧な候補であることに注意してください。 繰り返しの程度は時間がかかり、退屈につながる可能性があります。 また、重要な検証が見逃される可能性があります。 自動化は、信頼性が高く、高速で効率的な代替手段です。
も読む=>自動回帰テストの課題
#2) 回帰は決して完全ではありません：真。 しかし、完全ではありません。
つまり、網羅的な回帰テストは不可能かもしれません。 しかし、徹底的な回帰テストも不要かもしれません。
ホームページのスペルミスを変更したとしましょう。 この修正は軽微です。 また、アプリケーションの他の領域からも分離されています。 そのため、機能の簡単な再テストが行われます。 ホームページの周りに元の機能を退行する必要はありません。
#3)時間のためのクランチがあるときそれは不必要である:本当ではない。 十分な回帰がないと、製品への信頼が失われます。 あなたは、さまざまなエンドユーザーのシナリオへの反応から何を期待するかを知ることはありません。
#4)以前のリリースのすべてのテストケースを実行しています:もう一度、すべてのテストケースを選択することはこれを行う正しい方法ではありません。 テストケースを戦略的に選択することが鍵となります。 変更を理解し、フィッティングのテストケースを選択します。
OK、それは詳細に再テストと回帰テストです。
さて、比較。
再テストと回帰テスト
それらについて同じことは何ですか？
- それらは両方とも繰り返しベースの
- 検証とブラックボックステスト技術
- 自動化または手動テストケースの両方が再テストまたは退行されます
- “疑いを検証または追放し、YesまたはNOの確実性に変換する必要があります-Thomas Carlyle”。 彼らの両方がこれを行います。
それらについて何が違うのですか？
- 再テストは、テスト現在または以前のバージョンの機能を対象としたすべての機能に適用されます。 リグレッションは、以前のバージョンの機能中心です。
- 再テストは適用可能な変更に依存しません。 回帰は変化指向です。
最後に、この概念をホームにするには：
ID120の欠陥をもたらしたテストケースXYZがあるとしましょう。 この不具合は次のリリースで修正されます。 あなたはXYZテストケースを再テストし、その周りの機能を後退させます。 回帰は、120の修正後にすべてが正常に機能していることを確認することです。 再テストは、欠陥の修正を決定することです。
だから、それはどちらでもなく、回帰と再テストの組み合わせが動的なデュオを形成しています。
今、それはあなたに終わりです。 ここで提供されている定義と分析に同意しますか？
著者について：この記事はSTHチームメンバー Swati Sによって書かれています。