适合当前敏捷研发模式的 测试报告
测试报告的价值用来是什么？
1、衡量当前的测试工作落实情况
2、衡量当前的产品质量情况
3、能否发布上线的一个依据文档
没有哪个测试报告是最好的，只有适合当前研发模式的，脱离了研发过程的测试报告都是无效的，不接受反驳~
迭代项目名 测试报告
1.1. 需求背景
|
序号 |
需求ID |
需求名 |
用例个数 |
|
|
|
|
|
|
|
|
|
|
1.2. 测试准备阶段
1.2.1. 用例评审记录
|
用例评审日期 |
8月4日 |
用例数 |
215 |
|
用例最终评分 |
91.4分 |
用例清单 |
1.3. 测试过程情况
1.3.1. Bug等级定义
bug等级划分
1、 P1（致命）：系统奔溃，账号无法使用和登录平台；循环报错，涉及金钱，无法支付等。
2、 P2（严重）：重要功能不能实现；错误的波及面广，影响其他重要功能正常实现，如聊天页面听不到语音，无法查看图片，数据错误等；app闪退；主要流程受到影响等。
3、 P3（一般）：不影响业务流程，但外观有比较大的缺陷，一些名称乱码；边界条件错误，输入过长没有提示，导致保存时报错；格式错误；提示语错误；页面显示重复；搜索条件错误，不支持模糊搜索等。
4、 P4（轻微）：不影响功能和业务流程使用；聊天界面不能及时刷新；内容不能全部显示，需要滑动查看；输入框不能自动弹出键盘等，易用性不好，存在错别字等。
1.3.2. 测试轮数定义
第1轮的定义：测试环境 第1次全量测试所有功能点 被称为第1轮
第2轮的定义：测试环境 第2次测试验证 待测的Bug 被称为第2轮
第3轮的定义：集成环境 迭代需求主要核心功能 + 交互体验（产品原型）
用例通过率= （总用例个数-用例未通过数）÷ 总用例个数
测试环境测试执行 用例平均个数= 测试环境执行用例个数÷ 测试环境所用天数
集成环境测试执行 用例平均个数= 集成环境执行用例个数÷ 集成环境所用天数
测试阶段 平均 执行用例个数= (测试环境执行用例个数+集成环境执行个数）÷ (测试环境所用天数+集成环境所用天数)
天数可以为0.1 → 5.0
1.3.3. 冒烟测试标准
后端 接口自测的范围 供开发参考不做要求
1、字段完整性覆盖（接口是否遗留字段检查）
2、接口必填字段 检查
3、接口字段 数据类型 检查
4、接口字段 字符长度 检查
5、接口功能规则中的 状态码检查
6、接口正常数据 传参 返回结果 检查
7、接口非法数据 传参 返回结果 检查
前端与后端 在共享的测试报告的清单里面，填上自测截图 方可提交测试
1.3.3.1. 后端开发 功能自测截图记录
PS：截图可以截多张，比如一个功能自测后 能够清晰表达测试过程与结果，
|
序号 |
需求ID+名称 |
截图 |
是否 通过 |
|
1 |
|
|
|
|
|
|
|
|
1.3.3.2. 前端开发自测截图记录
PS：截图可以截多张，能够清晰表达测试过程与结果
|
序号 |
需求ID+名称 |
截图 |
是否 通过 |
|
|
|
|
|
|
|
|
|
|
1.3.4. 用例执行记录情况
PS：表格可以从excle做好计算公式 复制拷贝过来，或者手动填入
|
用例执行轮数 |
总用例个数 |
执行用例数 |
用例未通过数 |
用例通过率 |
|
第1轮 |
|
|
|
|
|
第2轮 |
|
|
|
|
|
第3轮 |
|
|
|
|
1.3.5. 用例执行平均效能
|
测试阶段 |
执行用例个数 |
测试天数 |
用例平均个数 |
|
测试环境 |
|
|
|
|
集成环境 |
|
|
|
|
总数 |
|
|
|
1.4. 测试执行结果分析
1.4.1. bug统计图
1.4.2. 测试环境-第1轮测试 Bug情况
|
bug等级 |
出现数 |
修复数 |
遗留数 |
每项修复率 |
|
P1-致命 |
|
|
|
|
|
P2-严重 |
|
|
|
|
|
P3-一般 |
|
|
|
|
|
P4-轻微 |
|
|
|
|
|
合计 |
|
|
|
|
1.4.3. 测试环境-第2轮测试 Bug情况
|
bug等级 |
出现数 |
修复数 |
遗留数 |
每项修复率 |
|
P1-致命 |
|
|
|
|
|
P2-严重 |
|
|
|
|
|
P3-一般 |
|
|
|
|
|
P4-轻微 |
|
|
|
|
|
合计 |
|
|
|
|
1.4.4. 集成环境-第3轮 测试bug情况
|
bug等级 |
出现数 |
修复数 |
遗留数 |
每项修复率 |
|
P1-致命 |
|
|
|
|
|
P2-严重 |
|
|
|
|
|
P3-一般 |
|
|
|
|
|
P4-轻微 |
|
|
|
|
|
合计 |
|
|
|
|
1.4.5. 禅道bug记录
https://ncdzentao.kanghehealth.com/zentao/project-bug-115.html###
1.4.6. 遗留问题清单
可以把禅道上bug标题 复制粘贴过来（带链接更好）
1.4.7. 禅道上需求受影响功能点清单检查
1.4.7.1. 存在受影响功能点：拷贝需求ID+需求标题 到此处
1.4.7.2. 没有注明受影响功能点：拷贝需求ID+需求标题 到此处
1.5. 测试通过标准
1.5.1. 定义与标准
DI值-Defect Index(缺陷率)
DI= 致命级别的问题个数*10+严重级别的问题个数*3+一般级别的问题个数*1+提示级别的问题个数*0.1
通过DI值=0*10+0*3+5*1+5*0.1=5.5
遗留bug DI值 <=5.5 表示通过
遗留bug DI值>5.5 不予发布 预发布环境
1.5.2. 测试各阶段发版标准
n 测试环境发布到集成环境标准：
遗留 P1等级bug个数 为0
遗留 p2 等级bug个数 为0
遗留 P3等级bug个数 <=5 个
遗留 P4等级 bug个数 <=10 个
n 集成环境发布预发布环境标准：
遗留bug DI值 <=5.5 表示通过，可以发布预发布环境
1.6. 测试结论
1.6.1. DI值判断
DI=实际遗留P1的bug数*10+实际遗留P2的bug数*3+实际遗留P3的bug数*1+实际遗留P4的bug数 < 5.5 测试通过 予以提交预发布环境
1.6.2. 各端测试结论
|
客户端 |
是否通过 |
|
后台PC端 |
通过 |
|
医护端APP-IOS |
通过 |
|
医护端APP-Android |
通过 |
|
患者端APP-IOS |
通过 |
|
患者端APP-Android |
通过 |
|
患者端-公众号 |
通过 |
|
最终结果 |
通过 |
1.6.3. 上线风险评估
1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
2．可能存在的潜在缺陷和后续工作
3．对缺陷修改和产品设计的建议
4．对过程改进方面的建议
1.6.4. 需求通过清单
（从1.1需求背景拷贝过来，方便运维发版，方便我们后续直接复制提交发生产）
|
序号 |
需求ID |
需求名 |
用例个数 |
是否通过 |
|
|
|
|
|
√ |
|
|
|
|
|
× |
2022/08/24 谢志飞
浙公网安备 33010602011771号