ソフトウェアテストのライフサイクル
- 要求分析
- テスト計画
- テスト設計、テスト開発
- テスト実行
- テストの評価
BUGを記述する方法
1バージョンで発見された
開発者は、障害を再現するために、コードの対応するバージョンを取得することができるように、問題のバージョンを知る必要があります。また、統計や各バージョンの品質の分析を助長している。そして、ロゴのバージョンは
2、環境の問題
Webプロジェクト、ブラウザのバージョンを記述する必要があり、クライアントオペレーティングシステムならば、それがある場合の環境は、ハードウェアおよびソフトウェア環境に分かれていますアプリの項目は、モデル、解像度、オペレーティングシステムのバージョンを記述する必要があります。環境の詳細な説明は、障害を見つけるために助長している。
3、エラー再現する手順
問題を再現するために最短手順の説明を。
4、期待される動作について説明し
、ガイドに正しいか、ビューの特にユーザの視点を開発をできるようにしますどのようにプログラムの動作記述。
5、記述の不祥事
エラー現象を記述する。
BUGレベル
-
折りたたむ
に妨げられるに開発したり、問題のテスト ;原因システムがクラッシュ、フリーズ、無限ループデータ損失データベース、データベース接続エラー、機能の主要な損失、基本モジュールおよびその他の問題の不足が生じ、。以下のような：その他のコードエラー、無限ループ、データベースのデッドロック、重要レベルのメニュー機能を使用することはできません、 -
重度の
システムの主な機能部分的損失は、データベース格納されているエラーを呼び出して、ユーザデータの喪失、機能メニューを使用することはできませんが、他の機能には影響しませんテストを。機能的なデザインと深刻な矛盾を要求し、モジュールは、関連する手順、セキュリティ、安定性などの間で紛争を呼び出し、プログラムの再起動、自動引き落としを開始したり、呼び出すことはできません。例えば：データ・ストレージ・ソフトウェア・エラー、データベース内のユーザによって要求された機能の喪失、プログラム・インターフェース・エラー、統計数値誤差 -
一般的には、
フィーチャ、完全に実現していないが、使用には影響しません、欠陥のある機能メニューが、システムの安定性に影響を与えません。以下のような：長い時間、長い時間クエリ、フォーマットエラー、境界条件エラーのために動作し、あまりにも多くのデータベーステーブル、フィールドを削除するには、no確認ボックス等、ありません -
二次
関数が完全に実現されていないが、欠陥の使用には影響しませんが、システムメニューの安定性に影響を与えることはありません。以下のような：長い時間、長い時間クエリ、フォーマットエラー、境界条件エラーのために動作し、あまりにも多くのデータベーステーブル、フィールドを削除するには、no確認ボックス等、ありません
BUGの競合が原因の開発者と行う方法
そして、最終的には成功したのオンラインソフトウェアプロジェクトの開発、そして最終的にテスター。彼らは、ソフトウェア・プロジェクト・チームのバックボーンとなっています。2の作業は、お互いを補完します。
客観的な理由の専門職のために、テスターや開発者、専門的に矛盾があり、競合が正常なものです。しかし、共通の目標は同じですが、ユーザーに配信するソフトウェアの高品質を確保するために、ユーザーのニーズを実現することです。
だから、：
1.まず、自分自身を確認するには、バグの説明かどうかは明らかではありません
2.彼らはバグだと思う理由を与えます：
- 明示的な要件を述べられていない場合は、需要側の分析では、機能の実装と需要が一致しているかどうか、あなたは、プロダクトマネージャーが確認を見つけることができます
- ユーザーの観点からは、この開発が実現され、ユーザが不合理な感じになるか、経験はよいことではありません。
3、十分な根拠であることをグレーディングBUG
レベルにBUG、BUGの参照だけでなく、採点時に、だけでなく、バグがプロセスに影響を与えるかどうかを検討し、多くの場合、ユーザーのレベルと私たちのBUGが違いである
ユーザーの観点から与えられることに、レベルを位置付けることを検討してください。
図4は、質問をするために彼らの技術およびビジネスレベルではないだけを向上させる、解決策を提案することができ最高です
通信のいくつかのラウンド後5、が、開発者は、まだ受け入れることを拒否しました。この時点ではバグレビューを開始することができます。
-
バグに対処する方法を決定します。
-
欠陥の分析、予防特定し
対策を
