XXX需求_ST测试报告

一、引言部分

1、项目背景

2、参考资料

二、测试基本信息

1、测试范围（需求规格说明书，列表整理——测试了什么东西）

• 产品
• 模块
• 子模块
• 功能
• 测试点——不等于测试用例
• 优先级
• 测试工程师

2、测试案例设计思路

根据上述测试范围测试点进行测试用例的设计。

• 测试类型（功能测试、UI界面测试、兼容性测试）
• 测试用例的设计方法或思路

三、测试结果及缺陷分析

1、测试执行情况与记录

测试组织

• 项目经理
• 软件工程师（开发）
• 测试工程师
• 业务负责人（产品经理）

测试组织

• 测试阶段
• 计划开始时间
• 计划结束时间
• 实际开始时间
• 实际结束时间
• 计划工作量（人天）
• 实际工作量（人天）

冒烟情况

验证主流程能不能通过，如果不通过，怎么办？

• 冒烟测试
• 时间
• 是否通过
• 如不通过，请写原因

测试用例设计

• 案例总数
• 可执行个数
• 未执行个数
• 成功个数
• 失败个数
• 案例成功率

2、缺陷的统计与分析

缺陷汇总： 列出本次实际发现缺陷数、解决的缺陷数、残留的缺陷数（未解决缺陷）。
缺陷分析： 对测试中发现的缺陷按缺陷类型、严重程度进行分类统计： 对测试中发现的缺陷就其功能分布、测试阶段进行统计，分析软件缺陷倾向及其主要原因：
残留缺陷与未解决问题 对残留缺陷对系统功能的影响情况进行分析：对未解决问题对项目的影响(**如有，列表说明)
缺陷汇总： 本次测试总共发现bug：43，其中已关闭：7，残留：43
缺陷分析： 按缺陷类型： 大量的bug属于功能问题，页面优化有5个，占比达到10%，其他的类型一共有45个，占比达8% 按严重程度： 大量的bug属于一般bug。严重性的有47个，占比达到了28%，细微错误有29个。 按功能分布： 我的账户模块有79个，占比达到46%。投资理财44个，注册27个，登录17个。 按测试阶段

• 第一轮：1.0
• 第二轮：2.0
• Trunk：上线的版本
• 1.0版本发现的Bug最多，2.0较少，Trunk只有10个

四、测试结论与建议

1、风险分析及建议（实际存在的一些风险）

测试人员变更——①. 测试用例评审 ②. 组内培训 
需求变更频繁——建立需求版本库 
测试时间不够——加班，加人，延期。 
遗留的Bug比较多

2、测试结论

本项目根据业务需求及开发人员，产品经理的反馈意见，覆盖了所有的测试需求，所有的案例均已在ST环境测试完成，有效案例一共 234个，执行率 87.5%,，成功率96.4%，缺陷关闭率为95%，未解决的bug（延期处理，不予解决，暂不处理等等）已经和产品经理，开发工程师进行沟通，不影响本次上线的基本功能。
综上所述，XXX项目达到ST项目测试上线标准，本项目ST测试通过，可以进行发布

五、文档交付（各个测试阶段的产出物）

• 《xx项目 测试计划》
• 《xx项目 测试用例》
• 《xx项目 测试用例评审记录表》
• 《xx项目 测试报告》