项目过程管理（十三）测试报告

1. 最终目标不是故意找茬，而是让管理者知道哪个环节有问题，能及时做调整
2. 要能反映质量，不要写成在描述需求或业务
3. 质量问题要具体到职能或人；不能模棱两可，看不出谁要为问题负责
4. 记录测试手段，为线上故障的漏测找依据

邮件通知

收件人：项目组群
抄送：测试组群
标题：【测试报告】xxx项目y.y.y（版本）[第z轮|release]

例如【测试报告】微信1.2.1 t1

报告模板与示例

本轮测试结果：[通过|有条件通过|失败打回]。

[有条件通过/打回的原因]。

什么是有条件通过？产品经理同意：某些bug不影响发布，可下次解决；某些需求免测或直接做线上验收

（一两句话总结项目质量）

例如：开发比上一版本的质量有明显提升，需求变更数也少了，给大家点个赞！

遗留问题数：x个。

（不多的话下面直接列出来，带有问题跟踪系统的超链接）

2.质量报告

质量指标：

需求变更数：**10个**，增加工作量：20人天。
测试案例一次通过率：76%。
bug总数：108个。
性能指标：api接口平均响应时间：400ms
兼容性：测试设备（列表见过程记录）中没有发现兼容性问题
（每轮提测的patch数）

bug分布：

（一系列的柱状图或饼图，包括数量和百分比。）

维度：责任人、报bug人、出错原因、严重程度、解决耗时、异常状态（打回和重新激活）

本轮测试后，处于未关闭状态的bug，责任人和数量分布：

（柱状图）

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浏览器 V12.3.3.2342

本节参考

本系列文章的目录： https://hursing.blog.csdn.net/article/details/88025790