smoke testing vs sanity testing
例を使用して、スモークテストと健全性テストの違いを詳しく調べます。
このチュートリアルでは、ソフトウェアテストにおける健全性テストとスモークテストとは何かを学びます。また、簡単な例を使用して、正気度テストとスモークテストの主な違いについても学習します。
ほとんどの場合、健全性テストとスモークテストの意味が混同されます。まず第一に、これらの2つのテストは方法です。 異なる 」であり、テストサイクルのさまざまな段階で実行されます。
学習内容:
- 健全性テスト
- 私の経験
- 健全性テストと回帰テスト
- モバイルアプリテストの戦略
- 予防措置
- スモークテスト
- スモークテストの例
- スクラム方法論における重要性
- スモークテストとビルド受け入れテスト
- スモークテストサイクル
- 誰がスモークテストを実行する必要がありますか?
- なぜスモークテストを自動化する必要があるのですか?
- 長所と短所
- 煙と健全性テストの違い
- 推奨読書
健全性テスト
健全性テストは、QAとして、すべてのテストケースを実行するのに十分な時間がない場合に実行されます。 機能テスト 、UI、OSまたはブラウザのテスト。
したがって、私は定義します、
「各実装とその影響に触れるために行われるが、完全または詳細ではないテスト実行としての健全性テスト。実装とその影響に応じて、機能、UI、バージョンなどのテストが含まれる場合があります。」
1日か2日でサインオフする必要があるのに、テスト用のビルドがまだリリースされていないという状況に陥りませんか?
Windows10用の最高の無料ファイルコンバーター
ああ、そうです、あなたもソフトウェアテストの経験で少なくとも一度はこの状況に直面したに違いありません。ええと、私のプロジェクトはほとんどアジャイルであり、時には同じ日にそれを提供するように頼まれたので、私はそれに多く直面しました。おっと、どうすれば数時間以内にビルドをテストしてリリースできますか?
たとえそれが小さな機能であったとしても、その影響は途方もないものになる可能性があるので、私は時々気が狂いました。そして、ケーキの上のアイシングとして、クライアントは時々単に余分な時間を与えることを拒否します。どうすれば数時間でテスト全体を完了し、すべての機能を検証できますか? バグ そしてそれを解放しますか?
そのようなすべての問題への答えは非常に単純でした。 健全性テスト戦略。
モジュール、機能、またはシステム全体に対してこのテストを行う場合、 実行のためのテストケース 同じもののすべての重要な部分に触れるように選択されます。つまり、幅は広いが浅いテストです。
テストケースなしでランダムにテストが行われることもあります。でも覚えておいて、 健全性テストは、実行時間が短い場合にのみ実行する必要があります。通常のリリースでは絶対に使用しないでください。理論的には、このテストはのサブセットです 回帰試験 。
私の経験
ソフトウェアテストでの8年以上のキャリアのうち、3年間 アジャイル方法論 yそしてそれは私が主に健全性テストを使用した時でした。
すべての大きなリリースは体系的な方法で計画および実行されましたが、小さなリリースはできるだけ早く配信するように求められることがありました。テストケースの文書化、実行、バグの文書化、リグレッションの実行、プロセス全体の実行に多くの時間がかかりませんでした。
したがって、以下は、そのような状況で私が従った重要な指針のいくつかです。
#1) 実装について話し合うときは、マネージャーと開発チームと一緒に座ってください。彼らは迅速に作業する必要があるため、個別に説明することは期待できません。
これは、彼らが何を実装しようとしているのか、どの領域に影響を与えるのかなどについてのアイデアを得るのにも役立ちます。これは非常に重要なことです。なぜなら、私たちは単にその影響を理解していないことがあり、既存の機能があるかどうかを理解していないからです。 (最悪の場合)妨げられるでしょう。
#二) 時間が足りないので、開発チームが実装に取り組んでいるときには、Evernoteなどのツールでテストケースを大まかに書き留めることができます。ただし、後で追加できるように、必ずどこかに書き込んでください。テストケースツール。
#3) 実装に従ってテストベッドを準備しておき、テストベッドに時間がかかる場合(そしてリリースにとって重要なテストである場合)に特定のデータ作成のような危険信号があると感じた場合は、すぐにそれらのフラグを上げてマネージャーに通知するか、障害物についてのPO。
クライアントができるだけ早く望んでいるからといって、半分テストされていてもQAがリリースされるわけではありません。
#4) チームとマネージャーとの間で合意します。時間の制約があるため、バグは開発チームにのみ通知され、追加の正式なプロセスは、時間を節約するためにバグ追跡ツールのさまざまな段階でバグにマークを付けるために後で行われます。 。
#5) 開発チームが最後にテストしているときに、それらとペアリングして(dev-QAペアリングと呼ばれます)、セットアップ自体で基本的なラウンドを実行します。これにより、基本的な実装が失敗した場合にビルドを行ったり来たりすることを回避できます。 。
#6) ビルドが完了したので、最初にビジネスルールとすべてのユースケースをテストします。フィールドの検証、ナビゲーションなどのテストを後で使用するために保持できます。
# 7) 見つけたバグが何であれ、それらすべてをメモして、開発者が大量に作業するのは簡単なので、個別に報告するのではなく、一緒に開発者に報告するようにしてください。
#8) 全体的な要件がある場合 性能試験 またはストレステストまたは負荷テストを行い、そのための適切な自動化フレームワークがあることを確認します。健全性テストでこれらを手動でテストすることはほぼ不可能だからです。
#9) これは最も重要な部分であり、実際、健全性テスト戦略の最後のステップです。「リリースメールまたはドキュメントのドラフトを作成するときは、実行したすべてのテストケース、ステータスマーカーで見つかったバグ、および残っているものがあるかどうかを伝えます。テストされていない理由でそれを言及する 「」 何がテストされ、検証され、何が行われなかったかについて全員に伝える、テストについての鮮明なストーリーを書いてみてください。
このテストを使用していたとき、私はこれに忠実に従いました。
私自身の経験を共有させてください:
#1) 私たちはウェブサイトで作業していて、それはキーワードに基づいて広告をポップアップするために使用されました。広告主は、同じように設計された画面を持つ特定のキーワードに入札するために使用されました。デフォルトの入札値は0.25ドルと表示されていましたが、入札者はこれを変更することもできます。
このデフォルトの入札が表示されていた場所がもう1つあり、他の値に変更することもできました。クライアントは、デフォルト値を$ 0.25から$ 0.5に変更するように要求されましたが、彼は明白な画面についてのみ言及しました。
ブレーンストーミングのディスカッション中に、この他の画面はあまり使用されていなかったため、忘れてしまいました(?)。しかし、入札の基本的なケースである0.5ドルを実行し、エンドツーエンドでチェックしたときにテストしたところ、ある場所で0.25ドルが見つかったため、同じcronジョブが失敗していることがわかりました。
私はこれを私のチームに報告し、変更を加えて、同じ日に正常に配信しました。
#二) 同じプロジェクト(上記)の下で、入札用のメモ/コメント用の小さなテキストフィールドを追加するように依頼されました。これは非常に単純な実装であり、同じ日に提供することを約束しました。
したがって、前述のように、すべてのビジネスルールとその周辺のユースケースをテストし、検証テストを行ったところ、のような特殊文字の組み合わせを入力すると、ページがクラッシュすることがわかりました。
私たちはそれを検討し、実際の入札者はいかなる場合でもそのような組み合わせを使用しないことを理解しました。そのため、この問題についてよくドラフトされたメモを付けてリリースしました。クライアントはそれをバグとして受け入れましたが、それは重大なバグであり、以前のバグではなかったため、後で実装することに同意しました。
#3) 最近、モバイルアプリプロジェクトに取り組んでおり、タイムゾーンごとにアプリに表示される配信時間を更新する必要がありました。アプリだけでなく、Webサービスでもテストする必要がありました。
開発チームが実装に取り組んでいる間に、Webサービステスト用の自動化スクリプトと、配信アイテムのタイムゾーンを変更するためのDBスクリプトを作成しました。これは私の努力を節約し、私たちは短期間でより良い結果を達成することができました。
健全性テストと回帰テスト
以下に、2つの違いをいくつか示します。
S.いいえ。 | 回帰試験 | 健全性テスト |
---|---|---|
7 | このテストは、数週間または数か月に予定されている場合があります。 | これは主に最大2〜3日以上に及びます。 |
1 | 回帰テストは、完全なシステムとバグ修正が正常に機能していることを確認するために行われます。 | 健全性テストはランダムに実行され、各機能が期待どおりに機能していることを確認します。 |
二 | このテストでは、最も小さな部分がすべて回帰されます。 | これは計画されたテストではなく、時間の制約がある場合にのみ実行されます。 |
3 | これは、十分に精巧で計画されたテストです。 | これは計画されたテストではなく、時間の制約がある場合にのみ実行されます。 |
4 | このテスト用に、適切に設計された一連のテストケースが作成されます。 | テストケースを作成できるとは限りません。通常、テストケースの大まかなセットが作成されます。 |
5 | これには、機能、UI、パフォーマンス、ブラウザ/ OSテストなどの詳細な検証が含まれます。つまり、システムのあらゆる側面が後退します。 | これには主に、ビジネスルール、機能の検証が含まれます。 |
6 | これは広く深いテストです。 | これは広くて浅いテストです。 |
モバイルアプリテストの戦略
ここでモバイルアプリについて具体的に言及しているのはなぜか疑問に思われるかもしれません。
その理由は、WebアプリまたはデスクトップアプリのOSとブラウザーのバージョンはそれほど変わらず、特に画面サイズが標準であるためです。 ただし、モバイルアプリでは、画面サイズ、モバイルネットワーク、OSバージョンなどが、モバイルアプリの安定性、外観、つまり成功に影響を与えます。
したがって、モバイルアプリでこのテストを実行する場合、1つの失敗で大きな問題が発生する可能性があるため、戦略の策定が重要になります。テストは賢く、注意深く行う必要があります。
以下は、「モバイルアプリ」でこのテストを正常に実行するのに役立ついくつかの指針です。
#1) まず、チームでの実装に対するOSバージョンの影響を分析します。
次のような質問への回答を見つけてみてください。動作はバージョン間で異なりますか?実装はサポートされている最低バージョンで機能しますか?バージョンの実装にパフォーマンスの問題はありますか?実装の動作に影響を与える可能性のあるOSの特定の機能はありますか?等
#二) 上記のメモで、電話モデルについても分析します。つまり、実装に影響を与える電話の機能はありますか? GPSで行動を変える実装はありますか?実装の動作はスマートフォンのカメラによって変わりますか?など。影響がないことがわかった場合は、さまざまな電話モデルでのテストを避けてください。
#3) 実装にUIの変更がない限り、UIテストの優先度を最も低くすることをお勧めします。必要に応じて、UIがテストされないことをチームに通知できます。
#4) 強力なネットワークで実装が期待どおりに機能することは明らかであるため、時間を節約するために、適切なネットワークでのテストは避けてください。 4Gまたは3Gネットワークでのテストから始めることをお勧めします。
#5) このテストは短時間で実行されますが、単なるUIの変更でない限り、少なくとも1つのフィールドテストを実行するようにしてください。
#6) 異なるOSとそのバージョンのマトリックスをテストする必要がある場合は、スマートな方法でテストすることをお勧めします。たとえば、テスト用に最低、中、最新のOSバージョンのペアを選択します。リリースドキュメントで、すべての組み合わせがテストされているわけではないことに言及できます。
# 7) 同様に、UI実装の健全性テストでは、時間を節約するために、小、中、大の画面サイズを使用します。シミュレーターとエミュレーターを使用することもできます。
予防措置
健全性テストは、実行時間が短いときに実行されるため、すべてのテストケースを実行することはできません。最も重要なことは、テストを計画するための十分な時間が与えられていないことです。非難ゲームを回避するために、予防措置を講じることをお勧めします。
そのような場合、書面によるコミュニケーションの欠如、テスト文書、およびミスアウトは非常に一般的です。
これの餌食にならないようにするには、次のことを確認してください。
- クライアントが共有する書面による要件が与えられなくなるまで、テスト用のビルドを受け入れないでください。クライアントは、変更や新しい実装を口頭で、チャットで、または電子メールで単純な1ライナーで伝え、それを要件として扱うことを期待していることがあります。いくつかの基本的な機能ポイントと受け入れ基準を提供するようにクライアントを強制します。
- テストケースやバグをきちんと書くのに十分な時間がない場合は、常に大まかなメモをとってください。これらを文書化しないままにしないでください。時間があれば、リードやチームと共有して、不足しているものがあれば簡単に指摘できるようにします。
- あなたとあなたのチームが不足している場合は、バグが電子メールで適切な状態でマークされていることを確認してください。バグの完全なリストをチームに電子メールで送信し、開発者に適切にマークを付けることができます。常に相手のコートにボールを置いてください。
- あなたが持っている場合 自動化フレームワーク 準備ができて、それを使用して、実行しないでください 手動テスト 、そうすれば、より短い時間でより多くをカバーすることができます。
- 配信できることが100%確実でない限り、「1時間でリリース」のシナリオは避けてください。
- 大事なことを言い忘れましたが、上記のように、何がテストされ、何が省略され、理由、リスク、どのバグが解決されたか、何が「後で」あるかなどを伝える詳細なリリースメールをドラフトします。
QAとして、テストする必要のある実装の最も重要な部分と、省略または基本テストできる部分を判断する必要があります。
短時間でも、やりたいことについて戦略を立てれば、与えられた時間枠で最高の成果を上げることができます。
スモークテスト
スモークテストは徹底的なテストではありませんが、その特定のビルドの基本的な機能が期待どおりに機能しているかどうかを確認するために実行されるテストのグループです。これは、「新しい」ビルドで実行される最初のテストであり、常にそうあるべきです。
開発チームがテストのためにビルドをQAにリリースする場合、ビルド全体をテストして、実装にバグがあるかどうか、または機能のいずれかが壊れているかどうかをすぐに確認することは明らかに不可能です。
これに照らして、QAは基本的な機能が正常に機能していることをどのように確認しますか?
これに対する答えは、実行することです スモークテスト 。
テストが(テストスイート内の)スモークテストに合格したとマークされると、そのビルドがQAによって受け入れられ、詳細なテストやリグレッションが行われます。スモークテストのいずれかが失敗した場合、ビルドは拒否され、開発チームは問題を修正して、テスト用に新しいビルドをリリースする必要があります。
理論的には、スモークテストは、開発チームからQAチームに提供されたビルドがさらなるテストの準備ができていることを証明するための表面レベルのテストとして定義されます。このテストは、ビルドをQAチームにリリースする前に、開発チームによっても実行されます。
このテストは通常、統合テスト、システムテスト、および受け入れレベルテストで使用されます。 これを実際のエンドツーエンドの完全なテストの代わりとして扱わないでください 。ビルドの実装に応じて、ポジティブテストとネガティブテストの両方で構成されます。
スモークテストの例
このテストは通常、統合、受け入れ、および システムテスト 。
QAとしてのキャリアでは、スモークテストを実行した後にのみビルドを受け入れていました。それでは、いくつかの例を挙げて、これら3つのテストすべての観点からスモークテストとは何かを理解しましょう。
#1)検収試験
ビルドがQAにリリースされるたびに、スモークテストの形式で 受け入れ試験 行われるべきです。
このテストでは、最初の最も重要なスモークテストは、実装の基本的な期待される機能を検証することです。このように、その特定のビルドのすべての実装を確認する必要があります。
それらのスモークテストを理解するために、ビルドで実行される実装として次の例を取り上げましょう。
- 登録済みのドライバーが正常にログインできるように、ログイン機能を実装しました。
- ダッシュボード機能を実装して、ドライバーが今日実行するルートを表示します。
- 特定の日にルートが存在しない場合に適切なメッセージを表示する機能を実装しました。
上記のビルドでは、受け入れレベルで、スモークテストは基本的な3つの実装が正常に機能していることを確認することを意味します。これら3つのいずれかが壊れている場合、QAはビルドを拒否する必要があります。
#2)統合テスト
このテストは通常、個々のモジュールが実装およびテストされるときに実行されます。の中に 統合テスト レベルでは、このテストは、すべての基本的な統合とエンドツーエンドの機能が期待どおりに正常に機能していることを確認するために実行されます。
これは、2つのモジュールまたはすべてのモジュールの統合である可能性があるため、スモークテストの複雑さは統合のレベルによって異なります。
このテストの統合実装の次の例を考えてみましょう。
- ルートモジュールと停止モジュールの統合を実装しました。
- 到着ステータス更新の統合を実装し、停止画面に同じものを反映します。
- 配信機能モジュールまでの完全なピックアップの統合を実装しました。
このビルドでは、スモークテストはこれらの3つの基本的な実装を検証するだけでなく、3番目の実装では、いくつかのケースで完全な統合も検証します。 統合で導入された問題や、開発チームが気づかなかった問題を見つけるのに大いに役立ちます。
#3)システムテスト
名前自体が示すように、システムレベルでは、スモークテストには、システムの最も重要で一般的に使用されるワークフローのテストが含まれます。これは、システム全体の準備ができてテストされた後にのみ実行されます。このシステムレベルのテストは、回帰テストの前のスモークテストとも呼ばれます。
システム全体の回帰を開始する前に、基本的なエンドツーエンドの機能がスモークテストの一部としてテストされます。システム全体のスモークテストスイートは、エンドユーザーが非常に頻繁に使用するエンドツーエンドのテストケースで構成されています。
これは通常、自動化ツールの助けを借りて行われます。
jarファイルを開くために何を使用するか
スクラム方法論における重要性
今日、プロジェクトはプロジェクトの実装においてウォーターフォールの方法論にほとんど従いません。ほとんどすべてのプロジェクトはアジャイルと スクラム のみ。従来のウォーターフォール方式と比較して、スモークテストはスクラムとアジャイルで高い評価を得ています。
私はスクラムで4年間働きました 。 また、SCRUMではスプリントの期間が短いため、このテストを実行することが非常に重要です。これにより、失敗したビルドをすぐに開発チームに報告し、修正することもできます。
以下はいくつかです 取り除く SCRUMでのこのテストの重要性について:
- 2週間のスプリントのうち、ハーフタイムがQAに割り当てられますが、QAへのビルドが遅れることがあります。
- スプリントでは、問題を早い段階で報告することがチームにとって最善です。
- 各ストーリーには一連の受け入れ基準があるため、最初の2〜3の受け入れ基準をテストすることは、その機能のスモークテストと同じです。単一の基準が失敗した場合、顧客は配達を拒否します。
- 開発チームがビルドを提供してから2日が経過し、デモの残り時間が3日で、基本的な機能障害が発生した場合にどうなるか想像してみてください。
- 平均して、スプリントには5〜10の範囲のストーリーがあります。したがって、ビルドが行われるときは、テストへのビルドを受け入れる前に、各ストーリーが期待どおりに実装されていることを確認することが重要です。
- システム全体をテストして回帰する場合は、スプリントがアクティビティ専用になります。システム全体をテストするために2週間は少し少ないかもしれません。したがって、回帰を開始する前に、最も基本的な機能を確認することが非常に重要です。
スモークテストとビルド受け入れテスト
スモークテストは、ビルドアクセプタンステスト(BAT)に直接関連しています。
BATでは、同じテストを実行して、ビルドが失敗していないかどうか、およびシステムが正常に機能しているかどうかを確認します。ビルドが作成されたときにいくつかの問題が発生し、それが配信されたときにビルドがQAで機能しない場合があります。
システムに障害が発生した場合、QAとしてテスト用のビルドをどのように受け入れることができるので、BATはスモークチェックの一部であると言えます。機能だけでなく、QAが詳細なテストを進める前に、システム自体が機能する必要があります。
スモークテストサイクル
次のフローチャートは、スモークテストサイクルを説明しています。
ビルドがQAにデプロイされると、基本的なサイクルは、スモークテストに合格した場合、ビルドはQAチームによって承認されてさらにテストされますが、失敗した場合、報告された問題が修正されるまでビルドは拒否されます。
テストサイクル
誰がスモークテストを実行する必要がありますか?
すべてのQAの時間の浪費を回避するために、チーム全体がこのタイプのテストに関与しているわけではありません。
スモークテストは、QAリードが理想的に実行します。このリードは、結果に基づいて、ビルドをチームに渡してさらにテストするか、拒否するかを決定します。または、リードがない場合は、QA自身もこのテストを実行できます。
プロジェクトが大規模な場合は、QAのグループがこのテストを実行して、ショートッパーをチェックすることもできます。ただし、SCRUMの場合はそうではありません。これは、SCRUMがリードやマネージャーのないフラットな構造であり、各テスターがストーリーに対して独自の責任を負っているためです。
したがって、個々のQAは、所有するストーリーに対してこのテストを実行します。
なぜスモークテストを自動化する必要があるのですか?
このテストは、開発チームによってリリースされたビルドで実行される最初のテストです。このテストの結果に基づいて、さらにテストが行われます(またはビルドが拒否されます)。
このテストを行う最良の方法は、自動化ツールを使用して、新しいビルドが作成されたときに実行するようにスモークスイートをスケジュールすることです。あなたはなぜ私がすべきか考えているかもしれません 「スモークテストスイートを自動化する」?
次の場合を見てみましょう。
リリースから1週間離れており、合計500のテストケースのうち、スモークテストスイートは80〜90で構成されているとします。これらすべての80-90テストケースを手動で実行し始める場合、どれくらいの時間がかかるか想像してみてください。 4〜5日(最短)だと思います。
ただし、自動化を使用してスクリプトを作成し、これらすべての80〜90のテストケースを実行する場合、理想的には、これらは2〜3時間で実行され、すぐに結果が得られます。貴重な時間を節約し、組み込みに関する結果をはるかに短い時間で提供しませんでしたか?
5年前、私は財務予測アプリをテストしていました。このアプリは、給与や貯蓄などに関する情報を取得し、財務ルールに応じて税金、貯蓄、利益を予測していました。これに加えて、(コード内で)変更に使用された国とその税規則に依存する国のカスタマイズがありました。
このプロジェクトでは、800のテストケースがあり、250はスモークテストケースでした。 Seleniumを使用すると、これらの250のテストケースの結果を3〜4時間で簡単に自動化して取得できます。それは私たちの時間を節約しただけでなく、ショートッパーについてできるだけ早く私たちに示しました。
したがって、自動化が不可能でない限り、このテストでは自動化の助けを借りてください。
長所と短所
最初に、いくつかの欠点と比較して提供できるものがたくさんあるので、利点を見てみましょう。
利点:
- 実行が簡単です。
- リスクを軽減します。
- 欠陥は非常に早い段階で特定されます。
- 労力、時間、お金を節約します。
- 自動化されている場合はすばやく実行されます。
- 最小の統合リスクと問題。
- システムの全体的な品質を向上させます。
短所:
- このテストは、完全な機能テストと同等またはそれに代わるものではありません。
- スモークテストに合格した後でも、目を見張るようなバグが見つかることがあります。
- このタイプのテストは、自動化できる場合に最適です。そうでない場合、特に700〜800のテストケースがある大規模プロジェクトでは、テストケースの手動実行に多くの時間が費やされます。
スモークテストは、非常に早い段階で主要な障害とショートッパーを指摘するため、すべてのビルドで確実に実行する必要があります。これは、新機能だけでなく、モジュールの統合、問題の修正、即興にも当てはまります。実行して正しい結果を得るのは非常に簡単なプロセスです。
このテストは、機能またはシステムの完全な機能テストのエントリポイントとして扱うことができます(全体として)。しかしその前に、 QAチームは、スモークテストとしてどのようなテストを行うべきかについて非常に明確にする必要があります 。このテストにより、労力を最小限に抑え、時間を節約し、システムの品質を向上させることができます。スプリントの時間が少ないので、スプリントでは非常に重要な位置を占めています。
このテストは、手動で行うことも、自動化ツールを使用して行うこともできます。しかし、最善かつ好ましい方法は、自動化ツールを使用して時間を節約することです。
煙と健全性テストの違い
ほとんどの場合、健全性テストとスモークテストの意味が混同されます。まず第一に、これらの2つのテストは方法です。 異なる 」であり、テストサイクルのさまざまな段階で実行されます。
S.いいえ。 | スモークテスト | 健全性テスト |
---|---|---|
1 | スモークテストとは、ビルドで実行された実装が正常に機能していることを(基本的に)検証することを意味します。 | 健全性テストとは、新しく追加された機能やバグなどが正常に機能していることを確認することを意味します。 |
二 | これは、最初のビルドでの最初のテストです。 | ビルドが比較的安定しているときに実行されます。 |
3 | すべてのビルドで実行されます。 | リグレッション後の安定したビルドで実行されます。 |
以下は、それらの違いを図で表したものです。
スモークテスト
- このテストは、 ハードウェア 新しいハードウェアを初めてオンにして、火や煙が出ない場合は成功したと見なすテストの練習。ソフトウェア業界では、このテストは浅くて広いアプローチであり、アプリケーションのすべての領域を深く掘り下げることなくテストします。
- スモークテストは、書面による一連のテストまたは自動テストのいずれかを使用してスクリプト化されます
- スモークテストは、アプリケーションのすべての部分に大まかに触れるように設計されています。浅くて広いです。
- このテストは、プログラムの最も重要な機能が機能しているかどうかを確認するために実施されますが、詳細に煩わされることはありません。 (ビルド検証など)。
- このテストは、アプリケーションを詳細にテストする前に、アプリケーションのビルドに対する通常のヘルスチェックです。
健全性テスト
- 健全性テストは、機能の1つまたはいくつかの領域に焦点を当てた狭い回帰テストです。健全性テストは通常、狭くて深いものです。
- このテストは通常、スクリプト化されていません。
- このテストは、アプリケーションの小さなセクションが小さな変更後も機能していることを確認するために使用されます。
- このテストは大まかなテストであり、アプリケーションが仕様に従って機能していることを証明するのに大まかなテストで十分な場合はいつでも実行されます。このレベルのテストは、回帰テストのサブセットです。
- これは、要件が満たされているかどうかを確認し、すべての機能を幅優先でチェックするためです。
これら2つの広大で重要なソフトウェアテストタイプの違いについて明確に理解していただければ幸いです。下記のコメント欄でお気軽にご意見をお聞かせください!!