プロジェクトプロセス管理(十一)測定プロセスと測定免除基準

ルール＃ルール＃

フロントエンドまたはクライアントが参加するニーズがあり、そうでなければバックエンドが直接測定します.
テスト記録はIM群公告に書くことができ、同じバージョンのテストを上書きしないでください.各バージョンが発表された後、テストの同級生がODSまたはテスト報告書に切り取って保存します.プロジェクト管理ツールがリソースを開発したり、自分で抽出記録システムを作ったりすればもっといいです.
(用語の解釈は「スケジュールと審査」を参照し、tagのフォーマットは「Git分岐管理規範」を参照してください)

プロセス

は自己測定を開発し、主経路に問題がないことを確保した.試験グループが発煙試験を提供する場合、発煙は

に合格しなければならない.

IM群掲示板に今回のテストのtagとテストポイントを記入します.

品質が合格しなければ、テストは

に戻ることができます.

測定通知例

 t1 2.3.3/1803031104  。 、UI 
 t2 2.3.3/1803041203  。 
 t2p1 2.3.3/1803051404 ……  ， 
iOS t3 2.3.3/1803061203  。 
 t1 1803061203  xxx 

pはいくつかのpatchを表し、p 0がなく、各ラウンドの最初のバージョンがp 1であるわけではないことに注意してください.
patchのコミット頻度は日単位であり,1つのバグを解決することなく1つのpatchを抽出することを提案しない.本当に必要であれば、同級生が単対単に検証し、patchを発行するときにテストから複数の問題に戻る必要があります.

リターンマッチ

理由の例:

開発テスト環境が整っていない

メインパスが通じない

開発発煙試験に合格しなかった用例

開発テストポイントが明記されていないコード修正の影響範囲

関連データベース設計ドキュメント、インタフェース設計ドキュメントを提供していない

を開発する.
テストはIM群の中で@すべての人が通告するべきで、原因を説明します

測定免除基準

免測の前提は、テストがわかったことを確認してから、次の条件です.

UIレイアウトまたは文案のみを変更し、インタラクションおよびビジネス

を変更しない

バックグラウンド・レポート統計

のみを変更

この項の参照

『Git分岐管理規範』https://blog.csdn.net/hursing/article/details/78789204
このシリーズの記事の目次:https://hursing.blog.csdn.net/article/details/88025790