発煙試験とは何ですか?

発煙試験とは何ですか?

スモークテスト は、展開されたソフトウェア ビルドが安定しているかどうかを判断するソフトウェア テスト プロセスです。スモーク テストは、QA チームがさらにソフトウェア テストを進めるための確認です。これは、ソフトウェアの機能をテストするために各ビルドで実行される最小限のテスト セットで構成されます。スモーク テストは、「ビルド検証テスト」または「信頼性テスト」とも呼ばれます。

簡単に言うと、スモークテストとは、重要な機能が正しく動作しているか、テスト対象のビルドに致命的な欠陥がないかを確認することです。これは、主要な機能に対する小規模かつ迅速な回帰テストです。このテストによって、ビルドに欠陥があるかどうか、そしてそれ以上のテストが時間とリソースの無駄になるかどうかを判断することができます。

比較 煙と正気度のテスト

なぜ煙探知試験を行うのか？

スモークテストは、ソフトウェア開発において重要な役割を果たします。初期段階でシステムの正確性を確認できるため、テストにかかる労力を削減できます。スモークテストが完了してから、機能テストを開始します。

• 建設工事におけるすべての問題点は、煙テストを実施することによって特定される。
• 煙テストの助けを借りて、ほとんどの欠陥は初期段階で特定されます ソフトウェア開発.
• スモークテストにより、重大な欠陥の検出と修正が簡素化されます。
• スモーク テストにより、QA チームは、新しいコードによって表面化した可能性のあるアプリケーション機能の欠陥を見つけることができます。
• スモークテストにより重大度の大きな欠陥が発見されます。

例1： ログウィンドウ: 送信ボタンをクリックすると、有効なユーザー名とパスワードを使用して次のウィンドウに移動できます。

例2： ユーザーが Web ページからサインアウトできません。

煙感知テストはいつ実施しますか？

これらのメリットは、チェックが適切なタイミングで実行された場合にのみ実現します。スモークテストは、ソフトウェアの新機能が開発され、QA/ステージング環境に展開されている既存のビルドに統合されるたびに実施されます。これにより、すべての重要な機能が正しく動作しているかどうかを確認できます。下の図は、スモークテストが開始される前にビルドがQA環境に到達するまでの過程を示しています。

このテスト方法では、開発チームがビルドをQA環境にデプロイします。テストケースのサブセットが選ばれ、テスターに​​よってビルドの重要な機能に対して実行されます。これらのテストケースは、ビルドに含まれるエラーを明らかにするように設計されています。これらのテストに合格した場合、QAチームは次のテストに進みます。 機能テスト.

何らかの障害が発生した場合は、システムを開発チームに戻す必要があることを示します。 ビルドに変更があった場合は常に、安定性を確保するためにスモーク テストを実行します。

例:: - ログイン ウィンドウに新しい登録ボタンが追加され、新しいコードでビルドがデプロイされます。新しいビルドでスモーク テストを実行します。

スモークテストは、ビルドが正式なテストに進むための資格要件を満たしていることを確認するためのものであり、システムの安定性と要件への適合性を実証することを目的としています。主な目的は、重大な問題を早期に検出することです。ビルドには、1つ以上の製品機能を実装するために必要なすべてのデータファイル、ライブラリ、再利用可能なモジュール、およびエンジニアリングされたコンポーネントが含まれます。

煙テストを実施しないとどうなるか

初期段階で煙試験を実施しないと、後の段階で欠陥が見つかり、費用がかさむ可能性があります。 欠陥 後段階で発見された場合、成果物のリリースに影響を与える重大な問題となる可能性があります。

煙感知テストは誰が実施しますか？

ビルドを QA 環境にリリースした後、QA エンジニア/QA リードによってスモーク テストが実行されます。 新しいビルドがあるたびに、QA チームはスモーク テストを実行するアプリケーションの主要な機能を決定します。 QA チームは、テスト中のアプリケーションに重大な問題がないかチェックします。

煙テストの実施方法

煙テストは通常​​手動で行われますが、自動化によって同じことを実行できる可能性もあります。 組織によって異なる場合があります。

手動スモークテスト

スモークテストは、クリティカルパスのナビゲーションが想定どおりであり、機能に支障をきたさないことを確認するために実施されます。優先度の高い機能テストケースが選定され、システム内の重大な欠陥を検出するためにテストが実行されます。テストに合格した場合は、機能テストを続行します。テストに不合格の場合は、ビルドは却下され、修正のために開発チームに送り返されます。

QAチームは、新しいビルドバージョンでスモークテストを再開します。スモークテストは新しいビルドで実行され、システムの正確性を維持するために古いビルドと統合されます。スモークテストを実行する前に、QAチームは正しいビルドバージョンであることを確認する必要があります。

自動化による煙テスト

自動化テスト 使用され 回帰テストしかし、自動化されたテストケースのセットを使用して、スモークテストを実行することもできます。自動化テストを利用することで、開発者はデプロイ準備が整った新しいビルドができたらすぐにビルドをチェックできます。

新しいソフトウェア ビルドがデプロイされるたびに手動でテストを繰り返す代わりに、記録されたスモーク テスト ケースがビルドに対して実行されます。これにより、主要な機能が引き続き適切に動作するかどうかが検証されます。テストが失敗した場合は、ビルドを修正してすぐに再デプロイできます。これにより、時間を節約し、QA 環境に高品質のビルドを保証できます。

テスト エンジニアは、自動ツールを使用して、ソフトウェア ビルドで実行されるすべての手動ステップを記録します。

煙テストサイクル

下記のフローチャートは、スモークテストの実行方法を示しています。ビルドがQA環境にデプロイされ、スモークテストに合格したら、機能テストに進みます。スモークテストが失敗した場合は、ビルドの問題が解決されるまでテストを中断します。

スモークテストケースを設計するためのベストプラクティス

サイクルを知ることは一つのことですが、ping 信頼性を支えるのは、そのシステムそのものである。煙探知システムは、コンパクトで高速かつ再現性があってこそ、その価値を発揮する。

• まず、クリティカルパスをマッピングします。 製品を商業的に利用可能にするためのワークフロー（ログイン、検索、データ入力、支払い、ログアウトなど）を列挙してください。これらのワークフローのいずれかに不具合があると、テスターに​​とってビルドの価値はなくなります。
• スイートは浅めに、幅は広く保つ。 一つのモジュールを深く掘り下げるのではなく、主要なモジュールすべてに一度は触れてみましょう。境界値、負のデータ、エラーメッセージの表現は、機能テストで行うべきものであり、ここでは扱うべきではありません。
• 実行時間を制限する： ほとんどのチームはランを10分から15分に抑え、スイートを20分から30分程度に制限する。 テストケース1時間かかるようなレースは、もは​​やゲートではなくボトルネックとなる。
• すべてのビルドで同じケースを実行する： 一貫性を保つことで、テストの選択変更ではなく、コード自体に不具合の原因があると判断できるようになります。
• 不安定なケースや依存関係の多いケースを削除する： コードの変更なしに合格と不合格になるケースは、ゲートに対する信頼を損ないます。不安定なサードパーティサービスをスタブまたはモックして、 テスト自動化フレームワーク 許可する。
• 明確な判決を一つ記録する： すべてのケースにおいて、期待される結果は一つだけである必要があり、そうすることで議論なしに構築案が承認または却下される。
• ビルドを使用してスイートのバージョンを設定します。 スモークケースはアプリケーションコードと同じリポジトリに保存し、ゲートが常にテスト対象のリリースと一致するようにしてください。

Rev各リリースごとにスイートを見直し、もはや重要ではなくなった機能に関するケースを削除し、新たに重要になったワークフローを追加します。

CI/CDパイプラインにおけるスモークテスト

このように設計されたスイートは、すべてのコミットで実行できるほど安価であり、現代のデリバリーが要求する要件を満たしている。 継続的インテグレーション サーバーなど Jenkins コードをコンパイルし、ステージング環境にデプロイした後、最初の自動化ステージとしてスモークテストスイートを実行します。グリーン実行の場合は成果物が機能テストおよび回帰テストのステージに進み、レッド実行の場合はパイプラインが失敗し、コミットした開発者に数分以内に通知されます。

一般的には2つの実行方法が用いられます。マージ前の実行では、すべてのプルリクエストを検証することでメインブランチを保護し、デプロイ後の実行では、デプロイされた環境にアクセス可能で、正しく構成されていることを確認します。継続的デプロイを実践しているチームは、リリース直後に本番環境に対して、より簡略化された3つ目の実行を追加することがよくあります。

パイプラインはテストスイートを1日に何度も実行するため、各ケースは非対話型で、自己クリーンアップ機能を持ち、独立している必要があります。人間の判断を待つケースや、テストデータが残ってしまうケースは、パイプラインの実行を阻害します。

スモークテストの利点

煙テストの利点をいくつか挙げます。

• 操作が簡単で、動作も速い
• 重大なエラーや欠陥は、初期段階で容易に検出・修正できる。
• システムの品質を向上させます
• リスクを軽減します
• 進捗状況の評価が容易になった。
• テストの労力と時間を節約します
• 統合リスクを最小限に抑える

⚠ 注意すべき制限事項： スモークテストに合格したとしても、それはビルドがテスト可能であることを示すに過ぎません。主要な機能に浅くしか触れないため、軽微な欠陥、エッジケース、使用頻度の低い機能は、機能テストと回帰テストを実行するまで隠れたままです。スモークテストの結果が緑色だからといって、ビルドに欠陥がないとは決して考えないでください。

スモークテスト、サニティテスト、回帰テスト

これら3つはすべてコード変更後に実行されるため、しばしば混同されます。しかし、それぞれが対象範囲、詳細度、そして回答する質問において違いがあります。

開発環境でコードに対して行われるテストは、ビルドをQAにリリースする前にアプリケーションの正確性を確認するためのもので、サニティテストと呼ばれます。これは、開発中のアプリケーションが基本的な機能要件を満たしていることを検証するプロセスです。

健全性テストは開発フェーズの完了を判定し、ソフトウェア製品を次のテストフェーズに合格するかどうかを決定します。

基礎	煙テスト	健全性テスト	回帰テスト
対象領域	幅広く浅い	狭くて深い	幅広くて深い
質問への回答	このビルドはテストに十分な安定性がありますか？	この特定の修正方法は効果がありますか？	以前は正常に動作していたものが何か故障しましたか？
シーケンス	まず、すべてのビルドで	煙テストに合格した後	健全性テスト後
典型的な期間	10から15分	30から60分	Hours 数日
自動化適合	すごく高い	中程度、多くの場合手動	すごく高い

実際には、ビルドを受け入れるためのスモークテスト、納品された変更を検証するためのサニティテスト、そしてスケジュールが許せば回帰テストという順序で実行されます。

サンプル煙テストケースの例

以下の表は、クリティカルパスごとに1行ずつ、短時間の煙幕テストの結果をまとめたものです。

T.ID	テストシナリオ	DESCRIPTION	テストステップ	期待される結果	実結果	ステータス
1	有効なログイン認証情報	Web アプリケーションのログイン機能をテストして、登録ユーザーがユーザー名とパスワードを使用してログインできることを確認します。	1.アプリを起動する 2.ログインページに移動します 3.有効なユーザー名を入力してください 4.有効なパスワードを入力してください 5.ログインボタンをクリックします	ログインは成功するはずです	予想通り	合格
2	アイテム機能の追加	カートに商品を追加できるようになりました	1.カテゴリーリストを選択 2.商品をカートに追加します	アイテムがカートに追加されるはずです	商品がカートに追加されない	失敗する
3	サインアウト機能	サインアウト機能を確認する	1.サインアウトボタンを選択します	ユーザーはサインアウトできるはずです。	ユーザーはサインアウトできません	失敗する

よくあるご質問