プロジェクトプロセス管理(十三)テストレポート

原則

言葉遣いに注意してください.最終目標はわざと仕事を探すのではなく、管理者にどの段階に問題があるかを知らせ、直ちに調整することができる

品質を反映するには、需要または業務を記述する

に書かないでください.

品質問題は具体的に職能または人にしなければならない.曖昧にしてはいけない.誰が問題に責任を負うのか分からない.

は試験手段を記録し、オンライン故障の漏れ測定のために

に基づいている.

読者が読みたいほど前の段落に書きます.だから結論は前で、過程を見たくない人はページをめくる必要はありません.

メール通知

 ： 
 ： 
 ：【 】xxx y.y.y（ ）[ z |release]

例えば【テストレポート】微信1.2.1 t 1

レポートテンプレートと例

1.結果

今回のテスト結果:[合格|条件付き合格|失敗打回].
[条件付き通過/返送の理由]
何が条件付きで通過しますか?製品マネージャの同意:一部のバグは発表に影響しないので、次回解決できます.一部の需要は測定免除または直接オンライン検収を行う.
(一言二言で項目の品質をまとめる)
例えば、開発は前のバージョンより品質が明らかに向上し、需要変更数も少なくなったので、皆さんにいいですね.
残された問題数:x個.
(多くなければ以下に直接列挙し、問題追跡システムのハイパーリンク付き)

2.品質報告

品質指標:

 ：**10 **， ：20 。
 ：76%。
bug ：108 。
 ：api ：400ms
 ： （ ） 
（ patch ）

バグ分布:

（ ， 。）

次元:責任者、バグ報告者、エラーの原因、重大度、解決時間、異常状態(コールバックと再アクティブ化)
今回のテスト後、クローズされていないバグ、責任者、数量の分布:

（ ）

3.プロセス記録

(各種関連リンクURL、需要とテスト担当者は審査書類を参考する)
ケース:

数量:76個

タイプオーバーライド:機能テスト、インタフェーステスト、インタフェース自動化、互換性テスト、性能テスト

自動化事例3つのインタフェースのモニタリング

を追加
テスト環境:
(携帯電話の型番リスト)
(システムタイプとバージョンリスト)
(ブラウザタイプとバージョンリスト)
例:Windows Chrome Version 69.0.3497.100(Official Build)(64-bit)Mac Safari Version 12.0(13606.2.11)iPhone 7,iOS 11.3.2 Safari小米9,MIUI 10.2.2システムブラウザ,UCブラウザV 12.3.3.2342
このシリーズの記事の目次:https://hursing.blog.csdn.net/article/details/88025790