オリジナル 。 翻訳は、著者自身の経験からの著者の考えや追加によって希釈されます。
それは何ですか
テストエンジニアとして、おそらく煙、健全性テスト、再テスト、回帰テストなどのタイプのテストについて聞いたことがあるでしょう。 これらの種の多くは、日常的に使用されている可能性があります。
この記事では、これらのタイプのテストの違いを明確にして説明し、1つのタイプのテストが終了し、別のタイプのテストが始まる境界を（条件付きではあるが）把握しようとします。
テストの初心者（および経験豊富なテスター）にとって、これらの概念を分離することは困難です。 実際、衛生試験の開始場所と煙の終了場所を区別する方法は？ 「スモーク」テストと呼ぶには、システムまたはそのコンポーネントの機能の一部の検証を制限する必要がありますか？ ユーザーログインフォームにユーザー名/パスワードを入力するのは煙テストですか、それともサイトページに表示されるという事実はすでにテストに合格していますか？
厳密に言えば、違いが何であるか正確には言えない場合でも、テストすることができます。 現在行っているテストの種類を区別することについて考える必要さえありません。 しかし、それでも、専門的な意味で自分より上に成長するためには、自分が何をしているのか、なぜ、どのように正しくやっているのかを知る必要があります。
教育プログラム
以下は、今日比較しているテストの種類の簡単な定義です。
- 煙テスト ： テスト用のプロジェクト（システム）の新しいビルド（バージョン）を取得するたびに実行されますが、比較的不安定であると見なされます。 重要なAUT（テスト対象のアプリケーション）機能が期待どおりに機能することを確認する必要があります。 このタイプのテストのアイデアは、深刻な問題をできるだけ早く特定し、テストの初期段階でこのビルドを拒否して（修正のために戻る）、長く複雑なテストを掘り下げて、明らかに欠陥のあるソフトウェアに時間を浪費しないようにすることです。
- 衛生テスト ：比較的安定したソフトウェアビルドを取得するたびに使用して、パフォーマンスを詳細に判断します。 つまり、システムの機能の重要な部分が要件に応じて低レベルで機能するかどうかの検証がここで行われます。
これらの両方のタイプのテストは、時間と労力の損失を回避することを目的としており、ソフトウェアの短所とその重要性を迅速に特定し、より詳細で徹底的なテストの段階への移行に値するかどうかを判断します。
- 再テスト ：機能/機能にすでに欠陥があり、これらの欠陥が最近修正された場合に実行
- 回帰テスト ：実際、時間の大部分を占めるのは何で、なぜテストの自動化があるのか。 AUT回帰テストは、新しい（追加された）アプリケーション機能/修正された欠陥が、以前に機能（およびテスト）された現在の既存の機能に影響を与えないことを確認する必要があるときに実行されます。
理解を深めるために、これらの概念と適用分野の比較表を以下に示します。
| 煙 | 正気 | 回帰（回帰） | 再テスト |
|---|---|---|---|
| 重要なAUT機能部品が期待どおりに機能していることを確認するために実行されました。 | AUTの特定の部分が、マイナーな変更またはバグの修正後も期待どおりに機能するという事実を確立することを目的としています。 | 彼らは、コードまたはアプリケーション全体の最近の変更が既存の機能/機能セットに悪影響を与えなかったことを確認します | 欠陥が修正された後、以前に失敗したテストケースが合格したという事実を再確認および確認します。 |
| 目標は、システム全体の「安定性」をテストして、より徹底的なテストに青信号を出すことです。 | 目標は、より徹底的なテストを進めるために、システムの一般的な状態を詳細に確認することです。 | 目標は、コードに対する最近の変更が、確立された機能的機能に副作用を及ぼさないようにすることです。 | 再テストにより、欠陥が修正されたことを確認します |
| 欠陥の再確認はSmokeの目標ではありません | 欠陥の再確認は健全性の目標ではありません。 | 欠陥の再確認は、回帰の目的ではありません。 | 欠陥が修正されるという事実は、再テストを確認します |
| 回帰前に煙テストが実行されます | 回帰テストの前と煙テストの後 に衛生テストが実行されます | プロジェクトの要件とリソースの利用可能性（セルフテストで終了）に基づいて実行され、「回帰」は再テストと並行して実行できます。 | -健全性テストの前に再テストが実行されます
-また、再テストの優先度は回帰チェックよりも高いため、それらの前で実行する必要があります |
| 自動または手動で実行できます。 | より頻繁に手動で行われます | このタイプのテストを自動化する最良の理由は、 マニュアルは非常にリソースと時間がかかる場合があります | 自動化を受け入れられない |
| 回帰テストのサブセットです | 受け入れテストのサブセット | これは、既存のプロジェクトの変更または変更で実行されます。 | 再テストは、同じ環境で同じデータを使用して固定アセンブリで実行されますが、入力データのセットは異なります。 |
| テストケースは回帰テストケースの一部ですが、非常に重要な機能をカバーしています。 | サニタリーはテストケースなしで実行できますが、テスト対象のシステムの知識が必要です | 回帰テストのテストケースは、機能要件または仕様、ユーザーマニュアルから取得でき、開発者が修正した内容に関係なく実行されます。 | 欠陥を検出したのと同じテストケースを使用しました。 |
しかし本質的に？
現在のプロジェクトの概念の差別化の例を示します。
例：ユーザーインターフェイスとRESTful APIを備えたWebサービスがあります。 テスターとして、私たちは知っています：
- 簡単にするために、1つのIPにある10個のエントリポイントがあること
- すべてのユーザーがGETログインリクエストを受け入れ、すべてのデータをJSON形式で返します。
その後、どの時点でどのタイプのテストを使用する必要があるかについて、一連のステートメントを作成できます。
- これらのエントリポイントの1つへの1つの単純なGETリクエストを完了し、json形式の応答を受け取ったので、煙のテストに合格したことをすでに確信しています。
これらのエントリポイントの1つがデータベースからデータを返し、最初のエントリポイントがデータを返さない場合、さらに別の要求を実行して、アプリケーションが
データベースクエリを正しく処理します。 そして、この「スモーキー」テストは終了です。
つまり、私たちはリクエストを満たしました-答えはサービスから来ました、そしてそれは「発煙」しませんでした、すなわち、4xxまたは5xxエラーを返さず、jsonの代わりに何かが不明瞭になりました。 これで、「スモーキー」テストに合格したと言えます。 UIが同じように機能することを確認するには、ブラウザーでページを1回開きます。 - この場合のサニタリテストは、APIの10個すべてのエントリポイントへのリクエストを実行し、受信したjsonを必要なデータの存在と同様に予想と一致させることで構成されます。
- 回帰テストは、煙+健全性+ UIで構成され、同じヒープで一緒に実行されます。 目的：11番目のエントリポイントを追加しても、パスワードの回復などが壊れていないことを確認します。
- この例の再テストは、たとえば、次のビルドのAPIで壊れたエントリポイントが意図したとおりに機能するかどうかを確認するポイントチェックです。
同時に、このAPIがポストリクエストも受け入れる場合、これらのリクエストを別の健全性テストセットに含める必要があることは明らかです。 UIとの類推により、アプリケーションのすべてのページをチェックします。
まとめると
この記事を読んだ後、どの段階でどのタイプのテストを使用しているか、そしてこれらのタイプのテストの違いは何かを明確にすることを願っています。 冒頭で述べたように、これらの概念の境界は非常にis意的であり、プロジェクトのフレームワークで自由に選択できます。
UPD ：
多くの場合、「一貫性テスト」または「健全性テスト」は「衛生テスト」という用語と呼ばれます。 これは、音が「衛生的」なものに似ている英語の正気の音声特性のためだと思います。 Google翻訳は明快さをもたらします。 インターネットには両方のオプションがあります。 この記事に関して、「サニタリ」テストを「一貫性のテスト」として検討するようお願いします。
先端をありがとうastenix