私のプロジェクトでは、継続的インテグレーション環境をセットアップしており、このプロセスの一環として、QA テスト サイクル中に欠陥を同時に修正することを提案しています。
これを QA 環境にリリースする場合、一般的に行われているプロセスは何ですか? これらの修正は (統合テストの後) QA 環境にすぐに展開されますか、それとも現在のテスト サイクルが完了するまで累積されますか。
4009 次
8 に答える
3
テスト サイクルの開始時には、解決されたブロック バグがある場合にのみ、新しいビルドを使用する傾向があります。これにより、私のチームは、新しいビルドと予想外のリグレッションによって引き起こされるスラッシュを回避できます。多くの場合、リリースの初期段階では、機能が実際にどのように実装されたか、製品が最低限の承認基準を満たしているかどうかを理解することに費やされます。
テスト サイクルの途中では、修正ができるだけ多く公開されるようにし、不適切に修正されたバグをできるだけ早く特定するために、より頻繁にビルドを受け入れます。これは通常、長期のストレス テストまたはパフォーマンス テストを実行している環境を除き、毎日行われます。
リリースが近づき、どのバグを修正するかをより細かく制御できるようになります (つまり、現在のリリースはブランチ化されており、より厳格なコード ライン ポリシーを採用しています)。リリースを妨げるバグが見つかった場合にのみ、ビルドを継続します。現時点では、ビルドはベータまたはリリース候補と呼ばれることがよくあります。
于 2009-12-31T06:36:04.077 に答える
1
CI ビルド中に見つかったバグは、開発チームが見つけ次第修正する必要があります。一方、QA チームは、CI ビルドの問題ではなく、通常のリリース サイクルまたはパッチ サイクル中に通常のビルドを受け取ります。
CI ビルドの自動テストでは、多くの QA および非 QA 関連のバグが検出されるため、他の QA アクティビティのパフォーマンスに大きな負荷がかかることに直接つながります。
すべては会社のQAポリシーに依存します。私の主張に同意するものもあれば、同意しないものもあります:)
于 2015-01-29T05:14:29.207 に答える
0
これらの修正は (統合テストの後) QA 環境にすぐに展開されますか、それとも現在のテスト サイクルが完了するまで累積されますか。
場合によります。問題がブロックされていて、テスターがテスト計画全体を完了する (つまり、仕事をする) ためにそれ以上テストを実行できない場合は、修正をすぐにリリースする必要があることは明らかです。問題がブロックされていない場合は、修正をキューに入れ、次のリリースで利用できるようにすることをお勧めします。しかし、これには多くの管理作業 (問題のログ記録、テスト ケースへの注釈付けなど) が必要です。
ここで、QA が開発の非常に早い段階で行われる場合 (つまり、非常に連続した開発サイクルを使用していない場合)、テスターが開発者と緊密に協力している場合は、問題が発見されたらすぐに修正し、回避することもできます。バグの目録を作成する (大きな無駄)。
于 2009-12-22T18:44:36.093 に答える
0
nitzmahon の答えは、CI システムから得られるより頻繁なビルドと、QA がテスト用の既知のターゲットを必要とする必要性とのバランスをとるための優れたアドバイスです。
継続的インテグレーションを利用して、各ビルドの一部として実行されるユニット/スモーク テストの上に追加のテストを取得できます。ここに私がやったことのいくつかがあります：
- システムでパフォーマンス テストを実行し、結果をログに記録するために、スケジュールされたジョブを実行するジョブを CI システムでセットアップします (たとえば、ソース コードの変更によってトリガーされるのではなく、毎日)。このようにして、パフォーマンスを経時的に追跡し、パフォーマンスに悪影響を及ぼしている変更を見つけることができます。
- ビルドと単体テストが成功した場合は、CI ビルド ジョブでシステムを自動デプロイし、デプロイされたシステムをNagiosなどの IT モニターでチェックします。これは、単体テストでは検出されないバグを発見できる、迅速で汚いシステム テストとして機能します。この種のテストに興味がある場合に役立つと思われるブログ投稿を書きました。
于 2009-12-22T18:20:25.303 に答える
0
プロジェクトの開発スタイルによって異なります。あなたがアジャイルチームであると仮定します。
- テストには、反復中のテストと反復終了時のテストの 2 つのレベルがあります。
- CI の目的は、イテレーション中にバグを見つけて修正することです。テストのタイプは、ユニット、機能、およびストーリーの実装に焦点を当てています
- このようなアジャイル チームで見つかったバグは、QA 環境にリリースする前に修正する必要があります。
- 回帰および統合テストを実行するには、QA 環境を使用する必要があります。このようなテストの目的は、機能の機能ではなく、回帰と統合を見つけることです
上記は一般的なアプローチです。もちろん、ソフトウェアとチームの性質に大きく依存します
于 2012-10-18T12:59:10.747 に答える
0
これは、QA チームを内部チームと外部チームというサブチームに分割することで実現できます。内部 QA は開発マネージャーの下で開発チームの一員として働き、外部 QA は開発中の製品のテストを行います。
内部 QA チームは、製品のサニティ テストを担当します。サニティ フローを実行して、ビルドの基本的なヘルス チェックを評価します。健全性フローが失敗した場合、またはメジャー/新しく作成されたモジュールがクラッシュした場合、IQA は電子メールをリリース マネージャー/開発マネージャーにルーティングして、新しいビルドを開発します。健全性フローが渡されると、ビルドは適切なテスト。
ビルドは毎日計画され、障害は外部 QA によって報告されます。内部 QA は、健全性フローと、開発者との迅速なコミュニケーションとディスカッションのために存在します。このようにして、プロセス全体を後押しし、開発チームにそれらを追加することで QA-Dev ギャップを縮小できます。
これがあなたの質問に答えることを願っています! 乾杯 ：）
于 2016-11-20T19:39:20.730 に答える