ソフトウェア開発&テストバージョン管理の説明

1.バージョン管理を導入した理由

 ： 。

1
2
テスト中に発見されたバグは開発者に提出され、開発者は提出されたバグを修正し、バグが修正された後、開発者は修正されたコードを現在のソフトウェアバージョンに入れることができ、ソフトウェアテストバージョンの発表が頻繁すぎ、テストバージョンが不安定になり、修正されたバグが再び現れ、テストが重複し、失効し、混乱する.テストの進捗状況は保証されず、問題を追跡するのに不便です.原因は:修正したコードに対して、彼らが必ず正しいことを保証することができなくて、開発者が修正した後で、依然として間違いである可能性が高い、あるいは修正した後で依然としてソフトウェアに別の問題をもたらすことができて、テスト者は新しく提出したコードと前のコードに対してすべて再び検証を行って、間違いを並べて、それによって新しい隠れた危険をもたらさないことを確保して、新しい抜け穴、大量の繰り返しテストを招きます.バージョン管理の導入のメリット:開発とテストの効率を向上させ、ソフトウェアのバージョンの安定性を向上させ、問題を遡及しやすい.

2.バージョン管理の定義

1、バージョン管理対象:テストに提出した製品バージョンを開発する.テスト担当者が提出したバグが開発者の手に渡った後、開発者はこれらのバグに対して修復作業を行い、修正したコードをプログラムに入れ、新しいソフトウェアバージョンとして既存のテストバージョンに直接置き換えることはできません.
2、バージョン管理の定義:テストバージョンの交付は専任者の制御の下で、毎回テストのバージョンに対して明確な標識(新しく増加した機能、修復したbugなど)があり、異なるバージョンは安定度の傾向を見ることができ、各バージョンのテスト状態.

3.バージョン管理方法

1.合理的なバージョン発行計画を制定し、バージョン管理を強化する.テストバージョンのリリースとリリース頻度の交渉:開発チームが異なるバージョンをコミットする計画時間、各バージョンの新機能モジュールリスト、バージョンのコミット要件、修復されたバグリストなどを含むバージョン進捗計画を作成します.テストバージョンリリースの基礎:コード評価(コードreview)、バージョン管理のドキュメント(新規または修正された機能を識別し、修正されたバグを識別し、テストバージョンの実行を容易に追跡および監視できる)テスト起動条件:機能が開発されたかどうか、バージョンの品質が悪いことを避けるために、実行中の自己測定があるかどうか(バージョンの品質が悪いことを避ける)、ソフトウェアバージョンの説明.提出後の注意事項:bug fix以外の修正は、説明(コード再構築など)しなければならない.Bug fixに関連するコードは、回帰範囲と影響範囲を明確にします(バグの修復を避けることは共通ファイルを修正し、グローバルな問題を引き起こすことです).
2、テストの参入条件テストの起動条件を強化する:機能が開発完了したかどうか、自己測定を行ったかどうか(バージョンの品質が悪いことを避けるために、自己測定報告を行ったかどうか)、ソフトウェアバージョンの説明(バージョンの更新ごとに何が修正され、どの機能に影響を与えるかを明らかにする).煙のテストを展開する:システムが走ることができることを保証して、テストの仕事を半分にして突然間違いが発生して業務が中断することはありません.最も基本的なテストに問題があれば、直接電話します.
(開発者が1つの問題を解決しようとしたとき、他の機能モジュールの一連の連鎖反応を引き起こした.最初の問題だけを集中的に考慮し、他の問題を無視したため、新しいBugを引き起こす可能性がある.)
発煙テストの合格基準:基本的な機能と流れが合格すればいい.(テストシーン/ポイントは提供できます)ソフトウェアのテスト後の注意事項:bug fix以外の修正は、Bug fixに関連するコード、コードreviewを周知し、回帰範囲を明確にし、品質の危険性を減らす必要があります.
3、bug管理bug内容(発見バージョン、対応人員、発見モジュール、回帰回数、bug閉鎖のバージョン番号)を強化し、異なるバージョンと異なるモジュールbugの動きを分析することができる.今回の反復範囲外の以前に残されたバグを発見し、テスト記録後、開発およびプロジェクト管理者と解決するかどうか、解決方法(コード制限OR操作説明で制限)を検討し、今回の反復の開発時間を占めるかどうか.
4、バージョン管理文書管理作業バージョン情報、テスト記録、テスト結果(開発とテスト活動の遡及)
5、タイムリーなコミュニケーション

4.バージョン管理評価基準

 。

1
2

5.テストの回数を減らす方法

（ 4 ， 3 。 2 3 ， 。 ， 。）

1
2
開発とテストの独立性を保証します:打ったパッケージ、配置の環境、できるだけ181のサービスに接続します.テスト環境と開発環境を分けて、できるだけテストデータが開発者に修正されないようにします.テスト需要を明確にする:需要機能点はすべて実現し、需要があれば規定時間に完成できない場合、需要段階で提出する必要があり、テスト段階で需要を完備するのではなく、開発とテスト時間を長くし、効率に影響を与える.細分化された測定基準:開発がどの程度テストを受けることができるか.予測試験:送検基準に達し、サーバーから試験のバージョンを取り外し、コンパイル、配置後、一部の主要な機能に対して予測試験を行い、予測試験に合格すれば、試験を開始することができる.予測試験に合格しない場合は、開発部門に戻って修正してから予測試験に合格するまで予測試験を行います.制御需要の変更:ソフトウェア需要を変更したら必ず記録と説明があり、相応のテスト用例は直ちに追加とメンテナンスしなければならない.バグの階層化を行う:インタフェースと使いやすいバグは開発が完了し、重要なバグが解決してから変更します.品質意識の強化:オンラインになる前に一時的にコードを変更して問題を修復したり、一時的に口頭で追加した変動を記録したりして、通知しなければならない.

6.テスト環境のメンテナンス

開発ドキュメントと製品需要ドキュメントが生成または変動した後、テストユーザーがタイムリーに作成し、維持することを保証してください.テスト環境は専任者が維持(開発、運営、テスト)し、頻繁に新しい機能を発表したり、修正したりすることは望ましくありません.バージョンの統一性を保証することが重要です.テスト担当者が提出したバグが開発者の手に渡った後、開発者はこれらのバグに対して修復作業を行い、修正したコードをプログラムに入れ、新しいソフトウェアバージョンとして既存のテストバージョンに直接置き換えることはできません. 
コードコミット、review後に再配置、直接パッケージ配置のコードが完全であることを保証できない(コミット競合、コード後のパブリケーション失敗など)
転載自:(原文)https://blog.csdn.net/u010005040/article/details/80277011