注意:此段内容不用编写在测试用例中.编写该测试报告的目的,是为了让相关管理人员花尽量少的时间了解软件的开发情况和质量,尤其是作为产品发布的重要参考项.
简要描述被测试工程的概况,填写版本信息
| 工程信息 | 版本号 | BUG总数 | 测试严重BUG数 |
|---|---|---|---|
| TS+ iOS端 | 1.5.1.1 | 120 | 20 |
**注意:**该栏在不进行回归测试时不用编写
回测测试范围: 整个APP
| 名称 | 数量 | 备注 |
|---|---|---|
| 测试用例总数 | 1000 | |
| 测试用例通过数 | 200 | |
| 测试用例失败数量 | 200 | |
| 测试用例跳过数量 | 600 | 跳过原因(见附1) |
| 测试用时 | 8 * 2 小时 | 8个小时 2个人 |
附1: 今天没下雨,心情不好,不想测试
**注意:**该栏在不进行BUG修复时不用编写
| 名称 | 数量 | 备注 |
|---|---|---|
| BUG总数 | 100 | 开始测试时的BUG数量 |
| 严重BUG数 | 20 | 开始测试时的严重BUG数 |
| BUG修复总数 | 20 | |
| 严重BUG修复数 | 0 | |
| 新增BUG总数 | 20 | |
| 新增严重BUG总数 | 20 | |
| 测试用时 | 8 * 2 | 8个小时 2个人 |
BUG情况总结: 这一届开发不行啊,该换了.
**注意:**该栏在不进行功能测试时不用编写
新增功能说明: 新增了登录手机就会过热爆炸的功能
| 名称 | 数量 | 备注 |
|---|---|---|
| 功能总数 | 10 | 根据 issues而来 |
| 验收通过数 | 5 | |
| 验收未通过数 | 2 | |
| 跳过验收功能数 | ||
| 测试用时 | 8 * 2 小时 | 8个小时 2个人 |
该版本进行了 回归测试/功能验收/BUG修复/ 等事情. (概述)
顺利增加了 登录手机就会过热爆炸的功能 (测试情况概述)
修复了登录很顺畅的严重BUG #250 (测试详细描述)
修复了32个中低等级的BUG,主要集中在小米机型上不能顺利登录后立即过热功能 (测试情况说明)
不建议发布,因为测试手机均已炸毁,不清楚在别的机型上反复登录是否能顺利爆炸. (发布建议,风险评估)