BUG のライフ サイクルは、BUG が発見されてから BUG がクローズされるまでのプロセスです。具体的なプロセスは次のとおりです。 1. BUG の発見、つまり、バグの抜け穴や欠陥を発見します。ソフトウェア プログラム、2. バグを送信し、欠陥の属性、再現環境、種類、レベル、優先順位、詳細な再現手順、結果と予想などを可能な限り説明します。3. バグの割り当て、つまり、問題を対応する開発者に直接割り当てます; 4. 分析して欠陥として確認します; 5. バグを処理し修正します; 6. 回帰検証バグ; 7. バグを閉じます。
このチュートリアルの動作環境: Windows 7 システム、Dell G3 コンピューター。
ソフトウェアバグとは、狭義にはソフトウェアプログラムの抜け穴や欠陥を指すと理解できますが、広義には発見だけでなく、プログラムに加え、テストエンジニアやユーザーも含まれる 発見・提案されたソフトウェアの改善可能な内容や、要件定義書と異なる機能実装などつまり、テストの介入は需要分析から開始し、開発プロセスを追跡することができます。
バグのライフ サイクルは、バグが発見されてからバグが閉じられるまでのプロセスです。
ライフサイクルにおける欠陥ステータス: 新規-->割り当て済み-->解決済み-->保留中-->閉じる
バグが見つかりました-->送信バグ–>バグの割り当て–>バグを確認するための研究開発–>バグを修正するための研究開発–>回帰検証バグ–>検証に合格するかどうか–>バグを閉じる
検証中にチェック対象のバグが解決されなかった場合は、再度「割り当て」-「解決済み」-「チェック対象」を開き、このプロセスを繰り返す必要があります。
中間のその他の状態: 拒否、延期など。
バグ処理フローチャート (ライフ サイクル図)
a. テスト ケースを追跡し、テスト ケースの予想される結果と矛盾するもの (バグと呼ぶことができるもの) を見つけます。
b. テスト ケースをすべて網羅することはできず、予想を超える要因や神聖な操作によって引き起こされるバグが常に存在します。
c. コストの問題、テスト ケースを作成する時間が不十分、バグが発見された
欠陥を提出する前に、まず最善を尽くしてください。 この欠陥の属性、バグの再現環境、バグの種類、バグのレベル、バグの優先度と詳細な再現手順、結果と期待 など。
もちろん、質問を送信する前に、欠陥チケットの重複を避けるために、この欠陥がこれまでに言及されていないことを確認する必要があります。
この手順は必要ありません。プロジェクト モデルに関連しています。一部の企業では、テスト部門が開発部門から独立しています。そのため、テスターは自分自身のテストについて確信がありません どの開発者がモジュールを担当するか この場合、テスターは問題をプロジェクト チームのリーダーまたはマネージャーに割り当てます プロジェクト チームのリーダー (またはマネージャー) は問題を確認し、割り当てます再度該当の開発者に連絡します。
一部のテスターはさまざまな R&D チームに分散しているため、さまざまな開発者が担当する開発モジュールが非常に明確です。現時点では、問題を対応する開発者に直接割り当てることができます。
この問題は開発者 A が担当すべきところ、開発者 A の異動や退職により他の担当者に担当が移管されたという状況もあります。 「配給」は上司と部下の関係を重視し、「異動」は対等の関係を重視します。
開発者は欠陥を受け取ると、まずそれを分析して再現します。テスターが要件を理解していないため)、または問題を再現できない場合は、その問題をその理由とともにテスターに報告する必要があります。不良であると確認された場合には対応が必要となります。
処理の延期
問題に対処した後、延期する必要があるかどうかを判断する必要があります。この問題は、極端な状況でのみ発生するか、システム アーキテクチャの変更が必要になるか、優先度が非常に低いため、当面はこの問題に対処する必要はありません (または、次のバージョンで修正される予定です)。
修正:
延期された問題は一時的に修正できます (「修正」は QC での名前です)。通常、修正された問題は、プロジェクト マネージャーとテスト マネージャーの間で協議した後にのみ修正できます。
欠陥処理:
開発者は、問題を解決する必要があることを確認すると、それに対処します。 (たとえば、Redmine は、30% が処理された、80% が処理されたなど、問題の処理の進行状況をプロセッサが随時更新するようにサポートしています。もちろん、短期間で修復できる問題については、
回帰欠陥はテスターにとって非常に重要なタスクであり、テスターには 3 つのタスクがあります。入口と出口が2つ。
欠陥以外の問題を確認する: 提出された欠陥について、開発者はそれを問題ではないか、再現できないものとして処理し、回帰のためにテスターに直接転送します。テスターが再度確認し、開発者の言うとおりであれば、問題は終了します。開発者以外が、問題の説明が曖昧であるため、またはその他の理由で問題が再現されると主張した場合は、その理由が再度記録され、開発者に転送されます。
修正すべき問題の確認: 開発者が修正した問題を再度確認し、パスできることが確認できた場合は問題をクローズします。確認に失敗した場合は、問題を再度開き、開発者に転送します。
修正された問題の確認: 計画的に修正された問題を確認します。一部の修正された問題は、時間の経過とともにバージョンが更新されるため、存在しなくなる可能性があります。そのような問題は適時に解決する必要があります。いくつかの修正された問題はまだ存在しており、緊急性が高いため、そのような問題はタイムリーに公開され、処理のために開発者に引き渡される必要があります。
修復された欠陥をクローズしますこれは、欠陥の最後のステータスでもあります。
インターフェイステストを行う場合は、国内のインターフェイステストおよびインターフェイスドキュメント生成ツール apipost を使用できます。
バグはソフトウェアの失敗の原因となります。実行時に予期しない障害が発生すると企業に損失が発生します。ソフトウェア テストのプロセスは、バグを回避するための品質保証作業にすぎません。テスト作業の効率を向上させ、バグの管理、バグの提出、バグの解決をより効率的に行うためには、いくつかのバグ管理ソフトウェアを合理的に使用することが非常に必要です。
Zen Tao
Zen Dao は、国産初のオープンソースのプロジェクト管理ソフトウェアです。アジャイル手法のスクラムを基本とした管理思想を核とし、プロダクト管理やプロジェクト管理を組み込むと同時に、テスト管理、計画管理、リリース管理、ドキュメント管理、トランザクション管理などの機能も補完しています。現在の国内の研究開発状況。 1 つのソフトウェアで、要件、タスク、バグ、ユースケース、計画、リリース、およびソフトウェア開発のその他の要素を秩序だった方法で追跡および管理でき、プロジェクト管理の中核プロセスを完全にカバーできます。
ZenTao は自社開発の zentaophp フレームワークを使用して開発されており、完全な拡張機構が組み込まれており、ユーザーは非常に便利に徹底的な二次開発を行うことができます。 ZenTao は各ページに json インターフェイス API も提供しており、他の言語の呼び出しや対話に便利です。多言語サポート、多スタイルサポート、検索機能、統計機能などの実用的な機能を内蔵しています。
Tracup
Tracup は、シンプルかつ効率的なバグ追跡、便利なプロジェクト管理、安全で安全な機能を提供する軽量のチーム コラボレーション プラットフォームです。安定したデータ保護、バグ管理とチームコラボレーションを完璧に組み合わせます。
バグを修正する場合でも、新しい機能を追加する場合でも、Tracup は理想的な実用的なクラウド プラットフォームを提供できます。便利なチームコラボレーション、軽量プロジェクト管理、完全な問題システム、大容量のファイルストレージにより、ユーザーの作業がより便利になります。
Bugtags
Bugtags は、モバイル テスト用に特別に設計された新世代の欠陥発見および管理ツールです。モバイル アプリのテスト プロセスを改善し、欠陥発見と欠陥提出の間のユーザー エクスペリエンスを結び付け、欠陥のテストと解決の効率を向上させることに尽力しています。テスターがアプリのテストとバグの追跡と管理を効率的に実施できるように支援します。
モバイル アプリにバグタグ SDK が統合された後、テスト ユーザーは WYSIWYG を使用してアプリで直接バグを送信できます。SDK は自動的にスクリーンショットを撮り、デバイス情報、コンソール データ、ユーザー操作などのアプリの実行時データを収集します。などの手順を実行することで、開発者はバグタグ クラウドでバグを効率的に追跡および管理できます。
Bugtags と他のバグ管理システムの最大の違いは次のとおりです:
Bugtags はモバイル開発用に特別に設計されており、Web およびデスクトップ アプリケーション用の以前のバグ管理システムを単純に変更したものではありません。これは、モバイル アプリの開発とテストの観点から完全に再設計されたバグ管理システムです。
Bugtags はデプロイの必要がなく、クラウドに登録するだけで使用できるため、簡単で便利です。
Bugzilla
#Bugzilla は Mozilla によって提供されるオープン ソースです。無料のバグです。ソフトウェア開発における欠陥の提出(新規)、修復(解決)、クローズ(クローズ)のライフサイクル全体を管理できる追跡システム。ソフトウェア開発を管理し、完全なバグ追跡システムを確立するために使用されます。JIRA
JIRA は、Atlassian が開発した欠陥追跡管理システムです。 JIRAという名前は略称ではなく、「Gojira」から取られています。 JIRA は、欠陥追跡、顧客サービス、要件収集、プロセス承認、タスク追跡、プロジェクト追跡、アジャイル管理で広く使用されています。 JIRA は、柔軟な構成、包括的な機能、シンプルな導入、豊富な拡張性を備えており、その 150 以上の機能は、世界 115 か国の 19,000 以上の顧客に認められています。
WebIssues
WebIssues は、小規模な開発をサポートできるクライアント/サーバー モデルのチーム コラボレーション ツールおよび問題追跡システムです。チーム。問題、コメント、添付ファイルのさまざまなプロパティを保存、共有、追跡するために使用できます。インストールと使用が簡単で、高度にカスタマイズ可能です。サーバーは、PHP と MySQL または PostgreSQL をサポートする任意のホストにインストールでき、クライアントは Windows または Linux デスクトップにすることができます。
Bugify
プログラミング教育をご覧ください。 !
以上がバグのライフサイクルは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。